Subject: [EAI] smtp MAIL FROM dowgrading

From: Kari Hurtta <[email-masked]>
Date: 01 Oct 2006 09:00:54 +0300

One method for smtp
    MAIL FROM:<utf-8-address>

downgrading is use similar trick what SPF uses for
it's forwarding problem. For SPF that is SRS
(Sender Rewriting Scheme).

So when  mail with
    MAIL FROM:<utf-8-address>

need to go to next smtp hop which do not support UTF8SMTP
it can be similarry replaced with

    MAIL FROM:<hash@converting-smtp-host>

and then maintain that bounces and DSNes with

    MAIL FROM:<>
    RCPT TO:<hash@converting-smtp-host>

are forwarded as

    RCPT TO:<utf-8-address>

for one month time.

That have same problems than SRS that it is not
used as involuntary relay, but if SRS can be used
then that also is possible.

This trick also do not require that any other participant
knows that trick and do not require standard.

/ Kari Hurtta

_______________________________________________
IMA mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ima

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 03 Oct 2006 20:21:55 +0200

This would work for MAIL FROM (at the cost of creating state in the relay).
But how would one do downgrading of From: and Cc: fields in the message 
header?

After all, "email works" is closely related to "reply works".....

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 03 Oct 2006 21:37:18 +0100

>     RCPT TO:<hash@converting-smtp-host>

Actually, that raises several interesting possibilities, which we really  
ought to allow.

Essentially, some agent (even a MUA perhaps) finds that the host it wants  
to send to does not support UTF8smtp.

So far, we have said "in that case, either bounce or downgrade". But we  
should not preclude other solutions, and notably we should allow it to  
send instead to some "smarter" host that can figure it out. There are many  
things that "sarter host" might do, and the obvious one is the case of a  
(more or less) public service that will do a proper job of downgrading and  
then forward it to the intended destination. That might enable many other  
servers not to have to implement downgrading themselves, which might in  
turn lead to a faster takeup of this whole scheme.

And doubtless there are other things a "smarter" server could do, such as  
the man-in-the-middle scheme that Kari has just proposed.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

---

From: Kari Hurtta <[email-masked]>
Date: 04 Oct 2006 08:31:52 +0300

Harald Alvestrand <[email-masked]> writes in gmane.ietf.ima:

> But how would one do downgrading of From: and Cc: fields in the
> message header?
> 

Yes,

"smart proxy" is willing to do

From:  <utf-8-address@domain>

conversion on headers

From:  <hash@converting-smtp-host>

only if it ready to relay incoming mail to 'domain'
for any arriving mail with

MAIL FROM:<somethiging>
RCPT TO: <hash@converting-smtp-host>

These means some kind agreement between converting-smtp-host
and 'domain' for service.

/ Kari Hurtta

---

From: Kari Hurtta <[email-masked]>
Date: 04 Oct 2006 19:40:50 +0300

"Charles Lindsey" <[email-masked]> writes:

> Actually, that raises several interesting possibilities, which we
> really  ought to allow.
> 
> Essentially, some agent (even a MUA perhaps) finds that the host it
> wants  to send to does not support UTF8smtp. 

> And doubtless there are other things a "smarter" server could do, such
> as  the man-in-the-middle scheme that Kari has just proposed.

Yes,

one possibile for example what that kind gateway can do:

- Gateway puts original message to store accessible via http or https

- Then gateway sends short note whare gives URL  to that message
  on store

- Replying is done via WWW form

That kind products exists (for different purpose).

/ Kari Hurtta

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 05 Oct 2006 06:58:14 +0200

I think this kind of "gateway" is out of scope for this working group.
There's a limit to what kind of complexity I see a point in making 
standards for.

                       Harald

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 05 Oct 2006 10:51:46 +0100

> There's a limit to what kind of complexity I see a point in making  

Sure, but we should not write the standard in such a way as to actively  
forbid such schemes - just so long as they do succeed in getting the  
messages delivered to their recipients intact (essentially, so that your  
scenarios still work).

I agree that Kari's suggestion for putting the message on a website and  
inviting the recipient to look there would stretch that principle right to  
the limit, but the scheme for a man-in-the-middle to deliver replies looks  
workable, even if bizarre.

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 05 Oct 2006 03:56:31 -0700

Charles Lindsey wrote:
> Sure, but we should not write the standard in such a way as to 
> actively forbid such schemes - just so long as they do succeed in 
> getting the messages delivered to their recipients intact 
> (essentially, so that your scenarios still work).
>
> I agree that Kari's suggestion for putting the message on a website 
> and inviting the recipient to look there would stretch that principle 
> right to the limit, but the scheme for a man-in-the-middle to deliver 
> replies looks workable, even if bizarre. 
I operated such schemes in the late 80s/early 90s (x.400 to SMTP 
gatewaying).

"workable" is not exactly a false statement, if your criteria for 
"workable" are low enough.

/C=no/PRMD=uninett/O=sintef/OU=delab/S=Alvestrand/I=T/G=Harald/@aun.uninett.no 
would reach me for a while - provided none of the mailers involved 
bounced mail with an address that started with a slash "for security 
reasons"......

                         Harald