The IESG has approved the following document: - 'Displaying Downgraded Messages for Email Address Internationalization ' <draft-ietf-eai-downgraded-display-03.txt> as an Experimental RFC This document is the product of the Email Address Internationalization Working Group. The IESG contact persons are Alexey Melnikov and Lisa Dusseault. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-downgraded-display-03.txt Technical Summary This document describes a method for displaying downgraded messages which originally contain internationalized E-mail addresses or internationalized header fields. Working Group Summary The WG has consensus on publishing this document as Experimental. Document Quality The author's organization has indicated intent to implement. Personnel Harald Alvestrand is the document shepherd for this document. Alexey Melnikov is the responsible AD. RFC Editor Note Add a new paragraph at the end of Section 3.1: NEW: In any case where reconstruction of a particular downgraded header field fails, both header fields (the "downgraded-YYY" header field and the "YYY" header field) SHOULD be left in the message as they are. The MUA MAY choose to communicate the situation to the user (see Security Considerations). In Section Section 3.2.2, remove the step # 2 and renumber the remaining steps (Please also update step numbers in section 4 as well). REMOVE: 2. If the header field is one that can only appear once, according to the table in [RFC5322] section 3.6 ("From", "Sender", "To", "CC", "BCC", "Reply-To"), locate the corresponding field in the message's headers, and skip to step 9. Otherwise, continue with step 3. Replace the last sentence in Section 3.2.3 with: OLD: An MUA with such knowledge MAY use the procedure in Section 3.2.2, above, for those fields that it knows about. NEW: An MUA with such knowledge MAY use the procedure similar to the procedure in Section 3.2.2, above, for those fields that it knows about. (Note that the whitespace canonicalization rule might not be applicable to some header fields.) In the Security Considerations section: OLD: For example, an organization's boundary MTA can modify "From:" lines so that messages arriving from outside the organization are easily distinguishable from internal emails. As a result of that rewriting, it might not be possible to reconstruct the "Downgraded-From" header field. NEW: For example, an organization's boundary MTA can modify "From:" lines so that messages arriving from outside the organization are easily distinguishable from internal emails. As a result of that rewriting, the "From:" header field might not match the "Downgraded-From" header field. In Section 4: OLD: See "Security considerations" section in [RFC5504] and [RFC4952] for more discussion. NEW: We have focused, here, on issues with displaying downgraded messages. For more discussion of downgraded and internationalized messages in general, see the "Security considerations" sections in [RFC5504] and [RFC4952]. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce