Document Action: 'Displaying Downgraded Messages for Email Address Internationalization' to Experimental RFC

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [IETF]     [IETF Discussion]     [Linux Kernel]

  Powered by Linux