Subject: [EAI] Comments on draft-ietf-eai-frmwrk-4952bis-01

From: Ernie Dainow <[email-masked]>
Date: Wed, 07 Jul 2010 09:41:40 -0400

2. Role of This Specification
[[anchor2: Note in Draft: Is 5825 still relevant, or is a victim of the 
"no in-transit downgrade" decision.??]]

Comment:  RFC 5825 describes how to construct the original headers from 
the "Downgraded-" headers. This is not relevant unless we are planning 
to use such headers (defined in 5504) for specifying how a final 
delivery SMTP server/mail store should downgrade messages that POP or 
IMAP can restore for UTF8 clients.

7.1 SMTP Extension for Internationalized Email Address
Conformance to the group of standards specified here for email transport 
and delivery requires implementation of the SMTP Extension 
specification, including recognition of the keywords associated with 
alternate addresses, and the UTF-8 Header specification.

Comment:  remove "including recognition of the keywords associated with 
alternate addresses".

8. Downgrading before and after SMTP Transactions
While the experiments that preceded these specifications included a 
mechanism for passing backup ASCII addresses to intermediate relay 
systems and having those systems alter the relevant message header 
fields and substitute the addresses,

Comment:  add a reference to RFC 5504 for future readers who may not 
know anything about the Experimental drafts.

9. Downgrading in Transit
[[anchor16: ... this section will simply be dropped.]]

Comment:  Leading up to the recharter, there was a lot of heated 
discussion on algorithmic/ACE transformations, even though it had been 
covered at the beginning of the working group. I think we need to 
capture some of this history or future readers of the standard will 
raise the same questions again. I suggest the following as a starting point.

Section 2.3.11 of RFC 2321, and RFC 2821 before that, states that "due 
to a long history of problems when intermediate hosts have attempted to 
optimize transport by modifying them, the local-part MUST be interpreted 
and assigned semantics only by the host specified in the domain part of 
the address".

Adherence to this rule means that a downgrade mechanism that transforms 
the local-part of an email address cannot be done in transit. It can 
only be done at the endpoints, namely by the MUA or submission server or 
by the final delivery SMTP server.

One of the reasons for this rule has to do with legacy email systems 
that use source routing in the local-part of the address field. 
Transforming the email address destroys such routing information. There 
is no way a server other than the final delivery server can know, for 
example, whether the local-part of [email-masked] is a route 
("user" is reached via "foo") or simply a local address.

     - Ernie

---

From: John C Klensin <[email-masked]>
Date: Wed, 07 Jul 2010 11:53:55 -0400

Unless there is disagreement with any of these changes, they
will be incorporated in -02 (which will probably be posted
before the weekend).

  john

--On Wednesday, July 07, 2010 09:41 -0400 Ernie Dainow
<[email-masked]> wrote:

> [[anchor2: Note in Draft: Is 5825 still relevant, or is a
> victim of the "no in-transit downgrade" decision.??]]
> 
> Comment:  RFC 5825 describes how to construct the original
> headers from the "Downgraded-" headers. This is not relevant
> unless we are planning to use such headers (defined in 5504)
> for specifying how a final delivery SMTP server/mail store
> should downgrade messages that POP or IMAP can restore for
> UTF8 clients.
> 
> Conformance to the group of standards specified here for email
> transport and delivery requires implementation of the SMTP
> Extension specification, including recognition of the keywords
> associated with alternate addresses, and the UTF-8 Header
> specification.
> 
> Comment:  remove "including recognition of the keywords
> associated with alternate addresses".
> 
> While the experiments that preceded these specifications
> included a mechanism for passing backup ASCII addresses to
> intermediate relay systems and having those systems alter the
> relevant message header fields and substitute the addresses,
> 
> Comment:  add a reference to RFC 5504 for future readers who
> may not know anything about the Experimental drafts.
> 
> Comment:  Leading up to the recharter, there was a lot of
> heated discussion on algorithmic/ACE transformations, even
> though it had been covered at the beginning of the working
> group. I think we need to capture some of this history or
> future readers of the standard will raise the same questions
> again. I suggest the following as a starting point.
> 
> Section 2.3.11 of RFC 2321, and RFC 2821 before that, states
> that "due to a long history of problems when intermediate
> hosts have attempted to optimize transport by modifying them,
> the local-part MUST be interpreted and assigned semantics only
> by the host specified in the domain part of the address".
> 
> Adherence to this rule means that a downgrade mechanism that
> transforms the local-part of an email address cannot be done
> in transit. It can only be done at the endpoints, namely by
> the MUA or submission server or by the final delivery SMTP
> server.
> 
> One of the reasons for this rule has to do with legacy email
> systems that use source routing in the local-part of the
> address field. Transforming the email address destroys such
> routing information. There is no way a server other than the
> final delivery server can know, for example, whether the
> local-part of [email-masked] is a route ("user" is
> reached via "foo") or simply a local address.
> 
> 
>      - Ernie
> 
> _______________________________________________
> IMA mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ima

---

From: Ernie Dainow <[email-masked]>
Date: Fri, 09 Jul 2010 14:52:21 -0400

Small typo below, plus another reference that goes back to 1989.

    -Ernie

>> Section 2.3.11 of RFC 2321, and RFC 2821 before that, states
Change to:

Section 2.3.11 of RFC 5321 states (with equivalent wording in earlier standards RFC 2821 and RFC 1123)