Subject: Re: [EAI] mail bounce versus punycode conversion

From: Shawn Steele <[email-masked]>
Date: Tue, 10 Aug 2010 17:52:31 +0000

> I think this is correct, but unnecessarily confusing about what
> we really intend.  In particular, "the client" implies that
> transformations can be made by _any_ SMTP client; we want to
> encourage that only for either MUAs/MSAs or for the

I'm confused about this.  We're defining EAI behavior, however this is primarily a discussion of IDNA2008/legacy SMTP behavior.  IDNA2008 already enables punycoding of DNS and is very bad about saying when that conversion can/should be made (eg: somewhere other than on the wire, in the "application").  So it's already "leaked" into lots of strange places.  Seems to me that we cannot retroactively make what IDNA2008 enabled more restrictive now.

It seems to me that we're making this unnecessarily complicated.  EAI is intended to enable a new scenario.  That needs to be clearly defined.  Once it's not the new scenario any more, then it's "legacy SMTP".  We don't have to redefine legacy SMTP, my understanding is that it's already well defined.  I'd rather just remind people that if you're talking to a legacy SMTP then use those rules, instead of trying to insert those rules in the middle of this RFC.

   If a server advertises UTF8SMTPbis and the client does not recognize the
   extension, the client may send a regular message using legacy SMTP,
   subject to the limitations of those standards and IDNA.

   If a server advertises UTF8SMTPbis and receives an ACE label such
   as those generated by IDNA, then the UTF8SMTPbis server MUST
   recognize and decode the ACE label(s) as appropriate.

When & what is allowed is clearly spelled out in the relevant RFCs.  We don't need to go into the details here.   I think it just makes this document more confusing.

I'm also a bit wary of specifying RFC5321, 5322, 5890 directly, what if they're updated to IDNA2015 or something?  I'd rather say "legacy SMTP" and "IDNA" with a pointer to the current versions than forcing users of this RFC to be limited to something that might get stale.  Of course, this RFC "could" be updated if the other RFCs were ever updated, but that seems unnecessarily difficult.  IDNA now points to Unicode without specifying an explicit version, I think that approach is sound here too.  (Specify legacy SMTP, IDNA rather than explicit versions of them).
   
However I can live with the text suggested by Yao, &/or the suggestions made by John.  I just fear ratholing on the details if we overspecify how legacy SMTP works.

- Shawn

---

From: John C Klensin <[email-masked]>
Date: Tue, 10 Aug 2010 15:10:25 -0400

--On Tuesday, August 10, 2010 17:52 +0000 Shawn Steele
<[email-masked]> wrote:

>> I think this is correct, but unnecessarily confusing about
>> what we really intend.  In particular, "the client" implies
>> that transformations can be made by _any_ SMTP client; we
>> want to encourage that only for either MUAs/MSAs or for the
> 
> I'm confused about this.  We're defining EAI behavior, however
> this is primarily a discussion of IDNA2008/legacy SMTP
> behavior.  IDNA2008 already enables punycoding of DNS and is
> very bad about saying when that conversion can/should be made
> (eg: somewhere other than on the wire, in the "application").
> So it's already "leaked" into lots of strange places.  Seems
> to me that we cannot retroactively make what IDNA2008 enabled
> more restrictive now.

Although the prohibition in IDNA2008 is much less restrictive
than that in IDNA2003, remember that the latter explicitly
prohibits showing A-labels to users except in debugging.  The
model for applications that are IDNA-aware is basically that
users see U-labels; A-labels are created only as a step
immediately prior to DNS lookup.  Now we know that things
haven't worked out that way in practice, with lots of A-labels
being user-visible as security or convenience mechanisms.

I'm happy having the EAI documents say absolutely nothing about
what happens in the ASCII-address@non-ASCII-domain cases when
the extension keyword is not offered by the next-hop server.
That case really lies outside EAI, which is a set of
specifications about what happens when the extension _is_
offered.  But, if we are going to get into that territory,
whatever is said needs, IMO, to be worded very carefully and to
be very clearl
 
> It seems to me that we're making this unnecessarily
> complicated.  EAI is intended to enable a new scenario.  That
> needs to be clearly defined.  Once it's not the new scenario
> any more, then it's "legacy SMTP".  We don't have to redefine
> legacy SMTP, my understanding is that it's already well
> defined.  I'd rather just remind people that if you're talking
> to a legacy SMTP then use those rules, instead of trying to
> insert those rules in the middle of this RFC.

I think that is consistent with my comments above.

>    If a server advertises UTF8SMTPbis and the client does not
> recognize the    extension, the client may send a regular
> message using legacy SMTP,    subject to the limitations of
> those standards and IDNA.

s/may send/may send only.../
and I'd rather clarify "those standards".

>    If a server advertises UTF8SMTPbis and receives an ACE
> label such    as those generated by IDNA, then the UTF8SMTPbis
> server MUST    recognize and decode the ACE label(s) as
> appropriate.

The above would work for me, with suggestions noted.

> When & what is allowed is clearly spelled out in the relevant
> RFCs.  We don't need to go into the details here.   I think it
> just makes this document more confusing.

> I'm also a bit wary of specifying RFC5321, 5322, 5890
> directly, what if they're updated to IDNA2015 or something?

Then this specification would need to be reviewed to determine
whether the new SMTP/ Internet Message Format/ IDNA specs still
provided the intended functionality and definitions.  We write
RFCs that way all the time; I don't think EAI is the place to
change  that.

> I'd rather say "legacy SMTP" and "IDNA" with a pointer to the
> current versions than forcing users of this RFC to be limited
> to something that might get stale.

If you say "legacy SMTP", someone will read it as "RFC 821".
Similarly for IDNA.  But I think part of your goal is
accomplished by the mechanism I suggested earlier for other
reasons, e.g., talking about

   as specified by legacy SMTP [RFC5321]

rather than

   as specified by [RFC5321].

>  Of course, this RFC
> "could" be updated if the other RFCs were ever updated, but
> that seems unnecessarily difficult.  IDNA now points to
> Unicode without specifying an explicit version, I think that
> approach is sound here too.

It actually does not.  While the specification of IDNA is
constructed to be Unicode version-independent, when IDNA2008
mentions Unicode, it points very explicitly to the Unicode 5.2
definition and specific versions of assorted UAXs and UTRs.

>  (Specify legacy SMTP, IDNA rather
> than explicit versions of them).    
> However I can live with the text suggested by Yao, &/or the
> suggestions made by John.  I just fear ratholing on the
> details if we overspecify how legacy SMTP works.

Agreed.

    john

---

From: Shawn Steele <[email-masked]>
Date: Tue, 10 Aug 2010 19:20:52 +0000

> I'm happy having the EAI documents say absolutely nothing 
> about what happens in the ASCII-address@non-ASCII-domain
> cases when the extension keyword is not offered by the
> next-hop server.
> That case really lies outside EAI, which is a set of specifications 
> about what happens when the extension _is_ offered.  But, if
> we are going to get into that territory, whatever is said needs,
> IMO, to be worded very carefully and to be very clearl

Yes :)  I think it's OK to point out that there is a legacy SMTP and, perhaps, an IDNA, but drilling down on the details just gets confusing.

> But I think part of your goal is accomplished by the mechanism
> I suggested earlier for other reasons, e.g., talking about

>   as specified by [RFC5321].

I'll defer to your experience :)

- Shawn

---

From: Joseph Yee <[email-masked]>
Date: Tue, 10 Aug 2010 16:51:57 -0400

> Yes :)  I think it's OK to point out that there is a legacy SMTP and, perhaps, an IDNA, but drilling down on the details just gets confusing.

As discussed during IETF78, we want to be more restricted and prevent the 'leaking' of ascii@non-ascii address into ascii@a-label.  So it is beyond what happens when the extension is offered, extending a bit to capture and identify the MUST-reject scenario is good IMO.  

I agreed the current text is harder to people who are not familiar to the related RFC, any suggestion to make the text better?

Joseph

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

---

From: Shawn Steele <[email-masked]>
Date: Tue, 10 Aug 2010 20:56:50 +0000

Legacy SMTP already has it's defined behavior, which I'm led to understand is must reject, and it impacts deployed code so nobody's going to change it no matter what's said here?

It's worth calling out the must-upgrade ACE to UTF-8, since that does impact the updated servers.

-Shawn

-----Original Message-----
From: Joseph Yee [mailto:[email-masked]] 
Sent: Tuesday, August 10, 2010 1:52 PM
To: Shawn Steele
Cc: John C Klensin; [email-masked]
Subject: Re: [EAI] mail bounce versus punycode conversion

On 2010-08-10, at 3:20 PM, Shawn Steele wrote:

>> I'm happy having the EAI documents say absolutely nothing about what 
>> happens in the ASCII-address@non-ASCII-domain cases when the 
>> extension keyword is not offered by the next-hop server.
>> about what happens when the extension _is_ offered.  But, if we are 
>> going to get into that territory, whatever is said needs, IMO, to be 
>> worded very carefully and to be very clearl
> 

Joseph

> 
>> But I think part of your goal is accomplished by the mechanism I 
>> suggested earlier for other reasons, e.g., talking about
>