Subject: RE: [EAI] RCPT TO and ALT-ADDRESS - do we have a consensus?

From: "Tan, William" <[email-masked]>
Date: Fri, 28 Jul 2006 11:39:22 -0400

Hi list,

I don't know which is worse, telling people that:

A. Here's my internationalized email address. If your email client supports IEA you can send me an email to the IEA but be sure to also include my regular ASCII address in the ALT-ADDR field.

Or 

B. Here's my internationalized email address. Try sending me an email with it. If you get an error upon message submission or a bounce, resend to my regular ASCII address.

The latter option may work sometimes but could also fail at other times (e.g. a primary MX that supports UTF8SMTP but secondary MX does not).

So, I'd pick the "I don't have enough information to decide yet" option.

wil.

> -----Original Message-----
> From: Harald Alvestrand [mailto:[email-masked]]
> Sent: Friday, July 28, 2006 9:27 PM
> To: [email-masked]
> Subject: [EAI] RCPT TO and ALT-ADDRESS - do we have a consensus?
> 
> It seems reasonably clear to me that:
> 
> - when an UTF8SMTP user sends to an ASCII address, he doesn't need to
> include ALT-ADDR on the RCPT TO - the address is already ASCII.
> 
> - when an UTF8SMTP user sends to an UTF8SMTP address, and all the MTAs
> in between are UTF8SMTP, there is no need for an ALT-ADDR on the RCPT TO
> - the message will not be downgraded.
> 
> So there are two cases (that I can see) where ALT-ADDR on RCPT TO may be
> useful:
> 
> - when an UTF8SMTP user sends to an UTF8SMTP address, and there is a
> non-UTF8SMTP MTA on the path
> 
> - when an UTF8SMTP user sends to what he thinks is an UTF8SMTP address,
> but the recipient, for reasons of his own, has decided that he wants the
> mail delivered to an ASCII address
> 
> If we remove ALT-ADDR from RCPT TO, we have made the last two cases
> impossible to support - but we have made both the specification and the
> deployment of it simpler.
> 
> I have seen a number of messages indicating that this might be OK.
> 
> So I'd like to check what people think if forced to choose between
> alternatives:
> 
> A - RCPT TO supports the ALT-ADDR parameter
> B - RCPT TO does not support the ALT-ADDR parameter
> 
> Possible responses would be "A", "B", or "I don't have enough
> information to decide yet"....
> 
>                               Harald
> 
> 
> 
> 
> _______________________________________________
> IMA mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ima
_______________________________________________
IMA mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ima

---

From: "Charles Lindsey" <[email-masked]>
Date: Sun, 30 Jul 2006 09:48:08 +0100

On Fri, 28 Jul 2006 16:39:22 +0100, Tan, William <[email-masked]>  
wrote:

> A. Here's my internationalized email address. If your email client  
> supports IEA you can send me an email to the IEA but be sure to also  
> include my regular ASCII address in the ALT-ADDR field.

I think what the man is most likely to do is to say "my email address is
     <utf8@utf8:ascii@ascii>"
or maybe
     "<utf8@utf8:atomic>"
(assuming that ':' is the separator we have not fixed on yet). And he will  
expect the man to figure it out or, more likely, to paste it into his MUA  
and let his MUA figure it out.

-- 
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: John C Klensin <[email-masked]>
Date: Sun, 30 Jul 2006 18:50:03 -0400

--On Sunday, July 30, 2006 9:48 AM +0100 Charles Lindsey 
<[email-masked]> wrote:

> On Fri, 28 Jul 2006 16:39:22 +0100, Tan, William
> <[email-masked]>  wrote:
>
>> Hi list,
>>
>> A. Here's my internationalized email address. If your email
>> client   supports IEA you can send me an email to the IEA but
>> be sure to also   include my regular ASCII address in the
>> ALT-ADDR field.
>
> (assuming that ':' is the separator we have not fixed on yet).
> And he will  expect the man to figure it out or, more likely,
> to paste it into his MUA  and let his MUA figure it out.

But each of these approaches causes its own problems, starting 
with not being acceptable to a system that doesn't understand 
any of these conventions -- the precise one that downgrading is 
intended to help.

FWIW, the syntax <string1@string2:string3@string4> has been 
historically accepted by some MTAs, in the interest of 
robustness, as equivalent to 
<@string1,@string2:string3@string4>.  Now, we could say "they 
are broken, or too permissive, and so don't count", but that 
doesn't seem wise to me.

     john

---

From: John C Klensin <[email-masked]>
Date: Sun, 30 Jul 2006 18:44:46 -0400

--On Friday, July 28, 2006 11:39 AM -0400 "Tan, William" 
<[email-masked]> wrote:

> client supports IEA you can send me an email to the IEA but be
> sure to also include my regular ASCII address in the ALT-ADDR
> field.
>
> Or
>
> B. Here's my internationalized email address. Try sending me
> an email with it. If you get an error upon message submission
> or a bounce, resend to my regular ASCII address.
>
> The latter option may work sometimes but could also fail at
> other times (e.g. a primary MX that supports UTF8SMTP but
> secondary MX does not).

See the earlier discussion about configuration choices. 
However, I'd suggest that there is a "C":

        Here is my internationalized email address.  It should
        work, but, if something should go wrong and the message
        bounce back to you, here is a different address that you
        can use instead.

Now, observe two things about that statement.  The first is that 
similar things are done today, even when all of the relevant 
addresses are all-ASCII.  Web sites often ask for alternate 
addresses in case the main one is undeliverable, people with 
particularly aggressive anti-spam or other policy filters 
(especially ones that are not under their control) sometimes 
supply alternate addresses, people give out alternate phone 
numbers, and so on.   The second is that, as stated, downgrading 
is done, if necessary, by the sender and not by some automated 
conversion process in the middle of the network.  Those more 
formalized in-network processes may be more convenient if we can 
get them to work well and reliably but we should keep in mind 
that, ultimately, they are just substitutes for a "tell the 
sender what to do if something doesn't work" mechanism.

> So, I'd pick the "I don't have enough information to decide

I'm undecided too, but, as complexity gets layered on complexity 
in an effort to resolve this, I'm gradually shifting (although 
I'd like to see downgrading work and my mind is definitely not 
made up).

      john

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 31 Jul 2006 08:03:40 +0200

Charles Lindsey wrote:
> (assuming that ':' is the separator we have not fixed on yet). And he 
> will expect the man to figure it out or, more likely, to paste it into 
> his MUA and let his MUA figure it out. 
As far as I read the Montreal minutes, the WG there decided to abandon 
the idea of messing with the syntax inside the angle brackets.
If that decision is upheld (and reflected in our work on mailto: and so 
on), what you mention above won't happen.

                   Harald

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 31 Jul 2006 11:11:20 +0100

> the idea of messing with the syntax inside the angle brackets.

Well that has not been reported to this List. What else was decided at  
Montreal that we have not been told about?

And more to the point, what notation has been put in its place?

We are agreed that a man may need to have alternative utf8 and ASCII  
addresses. What is he supposed to put in his From/Reply-To in order to  
inform his correspondents how to get back to him?

> on), what you mention above won't happen.

And yes, we are going to need some notation in a revised mailto to convey  
this same information.

---

From: Tony Finch <[email-masked]>
Date: Mon, 31 Jul 2006 19:41:26 +0100

On Mon, 31 Jul 2006, Harald Alvestrand wrote:

> As far as I read the Montreal minutes, the WG there decided to abandon the
> idea of messing with the syntax inside the angle brackets.

That's true at the 821 level but not the 822 level. That is, the sense of
the room was that UTF8SMTP should use the existing ESMTP extension
mechanisms for downgrade metadata (MAIL extension parameters) and not
change the essential <path> syntax. This should minimize the changes
necessary for 821 implementations. It does not affect the choice of syntax
used in message headers etc. which will need some other way to express the
downgrade metadata.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
FISHER: WEST OR NORTHWEST 4 OR 5 BECOMING VARIABLE 3 OR 4. FAIR. MODERATE OR
GOOD.