< draft-ietf-eai-downgraded-display-02.txt   draft-ietf-eai-downgraded-display-03.txt >
Email Address Internationalization K. Fujiwara Email Address Internationalization K. Fujiwara
(EAI) JPRS (EAI) JPRS
Internet-Draft Sep 8, 2009 Internet-Draft B. Leiba
Intended status: Experimental Intended status: Experimental Huawei Technologies
Expires: March 12, 2010 Expires: June 4, 2010 December 1, 2009
Displaying Downgraded Messages for Email Address Internationalization Displaying Downgraded Messages for Email Address Internationalization
draft-ietf-eai-downgraded-display-02.txt draft-ietf-eai-downgraded-display-03.txt
Abstract
This document describes a method for displaying downgraded messages
which originally contained internationalized E-mail addresses or
internationalized header fields.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 33 skipping to change at page 1, line 39
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 12, 2010. This Internet-Draft will expire on June 4, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
This document describes a method for displaying downgraded messages described in the BSD License.
which originally contained internationalized E-mail addresses or
internationalized header fields.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Consideration of displaying downgraded message . . . . . . . . 4 3. Converting downgraded message headers for display . . . . . . 3
4. Displaying downgraded message . . . . . . . . . . . . . . . . 4 3.1. Considerations . . . . . . . . . . . . . . . . . . . . . . 3
5. Security considerations . . . . . . . . . . . . . . . . . . . 6 3.2. The process . . . . . . . . . . . . . . . . . . . . . . . 4
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 3.2.1. No reconstruction of the Envelope Information
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 Preservation Header Fields . . . . . . . . . . . . . . 4
8. Change History . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2.2. Reconstructing the Address Header Fields'
8.1. draft-fujiwara-eai-downgraded-display: Version 00 . . . . 7 Preservation Header Fields . . . . . . . . . . . . . . 4
8.2. draft-ietf-eai-downgraded-display: Version 00 . . . . . . 7 3.2.3. The Unknown Header Fields' Preservation Header
8.3. draft-ietf-eai-downgraded-display: Version 01 . . . . . . 7 Fields . . . . . . . . . . . . . . . . . . . . . . . . 5
8.4. draft-ietf-eai-downgraded-display: Version 02 . . . . . . 7 4. Security considerations . . . . . . . . . . . . . . . . . . . 6
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
9.2. Informative References . . . . . . . . . . . . . . . . . . 8 7. Change History . . . . . . . . . . . . . . . . . . . . . . . . 6
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 9 7.1. draft-fujiwara-eai-downgraded-display: Version 00 . . . . 7
7.2. draft-ietf-eai-downgraded-display: Version 00 . . . . . . 7
7.3. draft-ietf-eai-downgraded-display: Version 01 . . . . . . 7
7.4. draft-ietf-eai-downgraded-display: Version 02 . . . . . . 7
7.5. draft-ietf-eai-downgraded-display: Version 03 . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . . 8
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 8
A.1. Displaying example . . . . . . . . . . . . . . . . . . . . 12 A.1. Displaying example . . . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
The Email Address Internationalization (UTF8SMTP) extension document The Email Address Internationalization (UTF8SMTP) extension document
set [RFC4952] [RFC5336] [RFC5335] [RFC5337] expands Email address set [RFC4952] [RFC5336] [RFC5335] [RFC5337] expands Email address
structure, syntax and Email header format. To avoid rejection of structure, syntax and Email header format. To avoid rejection of
internationalized Email messages, the downgrading mechanism [RFC5504] internationalized Email messages, the downgrading mechanism [RFC5504]
converts an internationalized message to a traditional Email message converts an internationalized message to a traditional Email message
when a server in the delivery path does not support the UTF8SMTP when a server in the delivery path does not support the UTF8SMTP
extension. The downgraded message is a traditional Email message, extension. The downgraded message is a traditional Email message,
except the message has "Downgraded-" header fields. except the message has "Downgraded-" header fields.
A perfect reverse-function of the downgrading does not exist because A perfect reverse-function of the downgrading does not exist because
the encoding defined in [RFC2047] is not exactly reversible and the encoding defined in [RFC2047] is not exactly reversible and
Received header field downgrading may remove FOR clause information. Received header field downgrading may remove FOR clause information.
The restoration of the downgrading should be done once at the final The restoration of the downgrading should be done once at the final
destination of the downgraded message such as MUAs or IMAP servers. destination of the downgraded message such as MUAs or IMAP servers.
This document describes the restoration methods as displaying This document describes the restoration methods for displaying
downgraded messages in MUAs. downgraded messages in MUAs.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Specialized terms used in this specification are defined in the EAI Specialized terms used in this specification are defined in the EAI
overview [RFC4952] or in [RFC5321][RFC5322], MIME documents [RFC2045] overview [RFC4952] or in [RFC5321][RFC5322], MIME documents [RFC2045]
[RFC2047] [RFC2183] [RFC2231]. [RFC2047] [RFC2183] [RFC2231].
This document depends on [RFC5335] and [RFC5504]. Key words used in This document depends on [RFC5335] and [RFC5504]. Key words used in
these document are used in this document, too. these document are used in this document, too.
The term "non-ASCII" is an UTF-8 string which contains at least one
non-ASCII character.
The term "address header field" is used for a header field which
contains <mailbox> elements which is defined in [RFC5322]. "Address
header fields" contain "From", "Sender", "Reply-To", "To", "Cc",
"Bcc", "Resent-From", "Resent-Sender", "Resent-To", "Resent-Cc",
"Return-Path" header fields.
An "UTF8SMTP message" is an Email messages expanded by [RFC5335].
The term "MIME decode" is used for both "encoded-word" decoding The term "MIME decode" is used for both "encoded-word" decoding
defined by [RFC2047] and MIME parameter value decoding defined by defined by [RFC2047] and MIME parameter value decoding defined by
[RFC2231]. [RFC2231].
3. Consideration of displaying downgraded message 3. Converting downgraded message headers for display
Displaying downgraded message is mostly performed by MIME decoding 3.1. Considerations
according to [RFC2047] and [RFC2231]. As a result of MIME decoding,
the header of the message still contains "Downgraded-" header fields,
but the header field bodies are MIME decoded. These decoded
"Downgraded-" header fields contain the original header field name
and the original header field values. The recipient can read them.
But the recipient's MUA cannot use the original header fields
automatically.
Additionally, A MUA can process "Downgraded-" header fields. The order of some header fields (such as "Resent-*" fields) is
significant. The process of regenerating the original fields from
the downgraded ones MUST NOT reorder the fields.
The easiest way to process "Downgraded-" header fields is to remove In order to regenerate a field from a specific downgraded header
"Downgraded-" from the decoded "Downgraded-" header fields' names. field, it's necessary to find the corresponding replacement in the
Then, the "address header fields" may be displayed twice, one is from current message. If the corresponding field can not be found, the
downgraded header field and the other is from decoded "Downgraded-" downgraded header field in question can not be regenerated and used.
header field. Although it is very easy, it MUST NOT be used because
of the following reasons.
o [RFC5322] section 3.6 defines number of times each field may occur
in the header section of a message and the maximum number for
"From", "Sender", "To", "Cc", "Bcc" header fields is 1. It
violates [RFC5322].
o Users cannot distinguish which is the original downgraded header
field and which is the generated header field.
o The "Downgraded-" header field and corresponding header field may
not have relations.
4. Displaying downgraded message 3.2. The process
A MUA MAY decode and re-generate the original header fields of the A MUA MAY decode and re-generate the original header fields of the
message. This procedure can be used to reverse the Downgrade process message (MTAs and MDAs SHOULD NOT attempt to do this; it SHOULD be
but will not construct exactly the original header fields in all left to the MUA). This procedure can be used to approximately
cases. reverse the Downgrade process, but it will not always construct the
original header fields exactly.
Displaying downgraded message is implemented by the following steps. Three types of Downgraded header fields are described in section 3 of
[RFC5504]:
1. "Envelope Information Preservation Header Fields", described in
RFC5504 section 3.1 and in Section 3.2.1, below.
2. "Address Header Fields' Preservation Header Fields", described in
RFC5504 section 3.2 and in Section 3.2.2, below.
3. "Unknown Header Fields' Preservation Header Fields", described in
RFC5504 section 3.3 and in Section 3.2.3, below.
Input: After processing Downgraded header fields, decode all header fields,
The input to this procedure is the header of the message as as described in [RFC2047] and [RFC2231].
received. Copy the entire header into an edit space.
Step 1: 3.2.1. No reconstruction of the Envelope Information Preservation
Select the "Address Header Fields' Preservation Header Fields" Header Fields
described in Section 3.2 of [RFC5504] in the edit space. These
header fields are "Downgraded-From", "Downgraded-Sender",
"Downgraded-To", "Downgraded-Cc", "Downgraded-Bcc", "Downgraded-
Reply-To", "Downgraded-Resent-From", "Downgraded-Resent-Sender",
"Downgraded-Resent-To", "Downgraded-Resent-Cc", "Downgraded-
Resent-Bcc", "Downgraded-Resent-Reply-To", "Downgraded-Return-
Path" and "Downgraded-Disposition-Notification-To" header fields.
Step 2: Envelope Information Preservation Header Fields are new fields that
For each header field from the output of Step 1, generate a new might have been added by the downgrade process. Because they do not
header field where the field name is the original header field represent fields that appeared in the original message, this process
name and the field value is the result of MIME decoding header is not applicable to them.
field value.
Step 3: 3.2.2. Reconstructing the Address Header Fields' Preservation Header
Apply "Email Header Fields Downgrading" defined in section 5 of Fields
[RFC5504] to the output of Step 2 without re-generating
"Downgraded-" header fields and copy the output into a new space
(hereafter, call it as a "comparison space").
Step 4: Reconstructing Address Header Fields' Preservation Header Fields is
Compare the header fields in the comparison space with the header OPTIONAL, and a decision MAY be made on each field, individually. In
fields of the same name in the edit space. Before this particular, it might be less important to process the Resent-* header
comparison, canonicalize each header field described below. fields, so an implementation MAY choose to skip those.
To construct a displayable copy of a header field from one of these
downgraded header fields, follow this procedure:
1. In an edit buffer, create a new header field:"
1a. For the field name, remove the "Downgraded-" prefix from the
downgraded field name. For example, "Downgraded-From" becomes
"From", and "Downgraded-Resent-To" becomes "Resent-To".
1b. For the field value, decode the MIME-encoded value of the
downgraded field according to [RFC2047].
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.
3. Apply "Email Header Fields Downgrading", defined in section 5 of
[RFC5504], to the field in the edit buffer, but do not prepend the
"Downgraded-" prefix. Put the result into comparison buffer 1.
4. Canonicalize the header fields in the comparison buffer:
1. Unfold all header field continuation lines as described in 1. Unfold all header field continuation lines as described in
[RFC5322]. [RFC5322].
2. Insert a space character before and after <mailbox-list> 2. Ensure that there is one space character before and one after
separator "," if there is no space character. the <mailbox-list> separator ",". If a space character is
3. Insert a space character before and after <comment> if there missing, insert one.
is no space character. 3. Ensure that there is one space character before and one after
4. Decode each <encoded-word> whose charset is 'UTF-8'. each <comment>. If a space character is missing, insert one.
4. Decode each <encoded-word> whose charset is "UTF-8".
5. Convert all sequences of one or more WSP characters to a 5. Convert all sequences of one or more WSP characters to a
single space character. WSP characters here include those single space character. WSP characters here include those
before and after a line folding boundary. before and after a line-folding boundary.
6. Delete all WSP characters at the end of each unfolded header 6. Delete all WSP characters at the end of each unfolded header
field value. field value.
7. Delete any WSP characters remaining before and after the colon 7. Delete any WSP characters remaining before and after the colon
separating the header field name from the header field value. separating the header field name from the header field value,
The colon separator MUST be retained. retaining the colon separator.
5. Locate the first instance of the corresponding field in the
For each header field, if the same header fields exist in the message's headers.
comparison space and in the edit space, remove the original header 6. Canonicalize the located field as in step 4, and put the result
field in the edit space and the generated header field in the into comparison buffer 2.
comparison space. 7. Compare the header field in comparison buffer 1 with the header
field in comparison buffer 2. If they match, go to step 9.
Remaining header fields in the comparison space may be bogus or 8. Locate the next instance of the corresponding field in the
broken "Address Header Fields' Preservation Header Fields" origin. message's headers. If one is found, go to step 6. If none is
found, stop: you can not use this downgraded field because you
Step 5: can't find its replacement in the message.
Decode all MIME encoded header fields according to [RFC2047] and 9. Replace the located header field with the one in the edit
[RFC2231] in the edit space. buffer. You MUST NOT reorder the header fields when you do this;
it's important to replace the field in place.
Step 6:
For each "Unknown Header Fields' Preservation Header Fields"
described in section 3.3 of [RFC5504] and "Address Header Fields'
Preservation Header Fields", generate a new header field where the
field name is the original header field name and the field value
is the result of MIME decoding header field value, then replace
the original "Downgraded-" header field by the generated header
field in the edit space. "Envelope Information Preservation
Header Fields" are not targets of this step.
The output of this procedure is an UTF8SMTP header in the edit space. 3.2.3. The Unknown Header Fields' Preservation Header Fields
It will closely resemble the original header.
After this procedure, the MUA may decode MIME body part header fields The Unknown Header Fields' Preservation Header Fields SHOULD be left
according to [RFC2047] and [RFC2231]. as they are unless the MUA has special knowledge of a particular
field. An MUA with such knowledge MAY use the procedure in
Section 3.2.2, above, for those fields that it knows about.
5. Security considerations 4. Security considerations
While information in any email header should usually treated with While information in any email header should usually be treated with
some suspicion, current email systems commonly employ various some suspicion, current email systems commonly employ various
mechanisms and protocols to make the information more trustworthy. mechanisms and protocols to make the information more trustworthy.
For example, an organization's boundary MTA can modify "From:" lines For example, an organization's boundary MTA can modify "From:" lines
so that messages arriving from outside the organization are easily so that messages arriving from outside the organization are easily
distinguishable from internal emails. As a result of rewriting, the distinguishable from internal emails. As a result of that rewriting,
"Downgraded-From" header field may not be decoded. it might not be possible to reconstruct the "Downgraded-From" header
field.
A MUA may emphasize bogus or broken "Downgraded-" header fields in A MUA MAY emphasize bogus or broken Address Header Fields'
step 4 of Section 4. Preservation Header Fields found in step 8 of Section 3.2.2.
Hiding the information from the actual header fields when using the Hiding the information from the actual header fields when using the
"Downgraded-" header fields does not cause loss of information if the "Downgraded-" header fields does not cause loss of information if
comparison done in step 4 of Section 4 is successful. To ensure that generating MIME decoded header fields in step 1 of Section 3.2.2 and
no information is lost, a MUA SHOULD have a function that uses the the comparison done in step 8 are successful. To ensure that no
information is lost, a MUA SHOULD have a function that uses the
actual message that was received (with/without MIME decoding) to actual message that was received (with/without MIME decoding) to
render the message. render the message.
See "Security considerations" section in [RFC5504] and [RFC4952] for See "Security considerations" section in [RFC5504] and [RFC4952] for
more discussion. more discussion.
6. IANA Considerations 5. IANA Considerations
This document makes no requests for IANA action. This section can be This document makes no requests for IANA action. This section can be
removed by the RFC Editor before publication. removed by the RFC Editor before publication.
7. Acknowledgements 6. Acknowledgements
This document was separated from [RFC5504]. Both documents were This document was separated from [RFC5504]. Both documents were
developed in the EAI WG. Significant comments and suggestions were developed in the EAI WG. Significant comments and suggestions were
received from John Klensin, Harald Alvestrand, Chris Newman, Randall received from John Klensin, Harald Alvestrand, Chris Newman, Randall
Gellens, Charles Lindsey, Marcos Sanz, Alexey Melnikov, Frank Gellens, Charles Lindsey, Marcos Sanz, Alexey Melnikov, Pasi Eronen,
Ellermann, Edward Lewis, S. Moonesamy and JET members. Frank Ellermann, Edward Lewis, S. Moonesamy and JET members.
8. Change History 7. Change History
This section is used for tracking the update of this document. Will This section is used for tracking the update of this document. Will
be removed after finalize. be removed after finalize.
8.1. draft-fujiwara-eai-downgraded-display: Version 00 7.1. draft-fujiwara-eai-downgraded-display: Version 00
o Initial version o Initial version
o It is separated from Appendix A of draft-ietf-eai-downgrade-05.txt o It is separated from Appendix A of draft-ietf-eai-downgrade-05.txt
8.2. draft-ietf-eai-downgraded-display: Version 00 7.2. draft-ietf-eai-downgraded-display: Version 00
o Submitted as a working group draft o Submitted as a working group draft
8.3. draft-ietf-eai-downgraded-display: Version 01 7.3. draft-ietf-eai-downgraded-display: Version 01
o Prohibited and removed Displaying Technique 1 o Prohibited and removed Displaying Technique 1
o Added new texts to Security Considerations o Added new texts to Security Considerations
8.4. draft-ietf-eai-downgraded-display: Version 02 7.4. draft-ietf-eai-downgraded-display: Version 02
o updated by comments from Chair's review and AD's review o updated by comments from Chair's review and AD's review
o Fixed references o Fixed references
o Rewrote section 4 to be more comprehensible o Rewrote section 4 to be more comprehensible
o Added bogus or broken "Downgraded-" header fields o Added bogus or broken "Downgraded-" header fields
o Added sentences in Security considerations o Added sentences in Security considerations
9. References 7.5. draft-ietf-eai-downgraded-display: Version 03
9.1. Normative References
o Section 3 (formerly 3 and 4) was rewritten by Barry Leiba.
8. References
8.1. Normative References
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996. Bodies", RFC 2045, November 1996.
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
Part Three: Message Header Extensions for Non-ASCII Text", Part Three: Message Header Extensions for Non-ASCII Text",
RFC 2047, November 1996. RFC 2047, November 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
skipping to change at page 8, line 23 skipping to change at page 8, line 4
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating [RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating
Presentation Information in Internet Messages: The Presentation Information in Internet Messages: The
Content-Disposition Header Field", RFC 2183, August 1997. Content-Disposition Header Field", RFC 2183, August 1997.
[RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded
Word Extensions: Word Extensions:
Character Sets, Languages, and Continuations", RFC 2231, Character Sets, Languages, and Continuations", RFC 2231,
November 1997. November 1997.
[RFC4952] Klensin, J. and Y. Ko, "Overview and Framework for [RFC4952] Klensin, J. and Y. Ko, "Overview and Framework for
Internationalized Email", RFC 4952, July 2007. Internationalized Email", RFC 4952, July 2007.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
October 2008. October 2008.
[RFC5335] Abel, Y., "Internationalized Email Headers", RFC 5335, [RFC5335] Abel, Y., "Internationalized Email Headers", RFC 5335,
September 2008. September 2008.
[RFC5504] Fujiwara, K. and Y. Yoneya, "Downgrading Mechanism for [RFC5504] Fujiwara, K. and Y. Yoneya, "Downgrading Mechanism for
Email Address Internationalization", RFC 5504, March 2009. Email Address Internationalization", RFC 5504, March 2009.
9.2. Informative References 8.2. Informative References
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
October 2008. October 2008.
[RFC5336] Yao, J. and W. Mao, "SMTP Extension for Internationalized [RFC5336] Yao, J. and W. Mao, "SMTP Extension for Internationalized
Email Addresses", RFC 5336, September 2008. Email Addresses", RFC 5336, September 2008.
[RFC5337] Newman, C. and A. Melnikov, "Internationalized Delivery [RFC5337] Newman, C. and A. Melnikov, "Internationalized Delivery
Status and Disposition Notifications", RFC 5337, Status and Disposition Notifications", RFC 5337,
September 2008. September 2008.
Appendix A. Examples Appendix A. Examples
This section shows a example of displaying downgraded message. This section shows a example of displaying a downgraded message.
First, an example of the original UTF8SMTP message and its downgraded First, an example of the original UTF8SMTP message and its downgraded
message are shown. They are the same as "Example 1" of [RFC5504]. message are shown. The example comes from "Example 1" of [RFC5504]
The example UTF8SMTP message is shown in Figure 1. and three header fields, "Unknown-Field", "Resent-From", and
"Resent-To", are added. The example UTF8SMTP message is shown in
Figure 1.
Message-Id: MESSAGE_ID Message-Id: MESSAGE_ID
Mime-Version: 1.0 Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8" Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit
Subject: NON-ASCII-SUBJECT Subject: NON-ASCII-SUBJECT
Unknown-Field: NON-ASCII-Unknown
From: DISPLAY-local <NON-ASCII-local@example.com From: DISPLAY-local <NON-ASCII-local@example.com
<ASCII-local@example.com>> <ASCII-local@example.com>>
To: DISPLAY-remote1 <NON-ASCII-remote1@example.net To: DISPLAY-remote1 <NON-ASCII-remote1@example.net
<ASCII-remote1@example.net>> <ASCII-remote1@example.net>>
Cc: DISPLAY-remote2 <NON-ASCII-remote2@example.org> Cc: DISPLAY-remote2 <NON-ASCII-remote2@example.org>
Resent-From: DISPLAY-remote1 <NON-ASCII-remote1@example.net
<ASCII-remote1@example.net>>
Resent-To: DISPLAY-reto <NON-ASCII-reto@example.net
<ASCII-reto@example.net>>
Date: DATE Date: DATE
MAIL_BODY MAIL_BODY
Figure 1: Original message Figure 1: Original message
Delivered downgraded message is shown in Figure 2. Return-Path Delivered downgraded message is shown in Figure 2. Return-Path
header will be added by the final destination MTA. header will be added by the final destination MTA. Some of Received:
header fields may be added.
Return-Path: <ASCII-local@example.com> Return-Path: <ASCII-local@example.com>
Received: ...
Downgraded-Mail-From: =?UTF-8?Q?<NON-ASCII-local@example.com_?= Downgraded-Mail-From: =?UTF-8?Q?<NON-ASCII-local@example.com_?=
=?UTF-8?Q?<ASCII-local@example.com>>?= =?UTF-8?Q?<ASCII-local@example.com>>?=
Downgraded-Rcpt-To: =?UTF-8?Q?<NON-ASCII-remote1@example.net_?= Downgraded-Rcpt-To: =?UTF-8?Q?<NON-ASCII-remote1@example.net_?=
=?UTF-8?Q?<ASCII-remote1@example.net>>?= =?UTF-8?Q?<ASCII-remote1@example.net>>?=
Message-Id: MESSAGE_ID Message-Id: MESSAGE_ID
Mime-Version: 1.0 Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8" Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit
Subject: =?UTF-8?Q?NON-ASCII-SUBJECT?= Subject: =?UTF-8?Q?NON-ASCII-SUBJECT?=
Downgraded-Unknown-Field: =?UTF-8?Q?NON-ASCII-Unknown?=
From: =?UTF-8?Q?DISPLAY-local?= <ASCII-local@example.com> From: =?UTF-8?Q?DISPLAY-local?= <ASCII-local@example.com>
Downgraded-From: =?UTF-8?Q?DISPLAY-local_<NON-ASCII-local@example.com_?= Downgraded-From: =?UTF-8?Q?DISPLAY-local_<NON-ASCII-local@example.com_?=
=?UTF-8?Q?<ASCII-local@example.com>>?= =?UTF-8?Q?<ASCII-local@example.com>>?=
To: =?UTF-8?Q?DISPLAY-remote1?= <ASCII-remote1@example.net> To: =?UTF-8?Q?DISPLAY-remote1?= <ASCII-remote1@example.net>
Downgraded-To: =?UTF-8?Q?DISPLAY-remote1_?= Downgraded-To: =?UTF-8?Q?DISPLAY-remote1_?=
=?UTF-8?Q?<NON-ASCII-remote1@example.net_<ASCII-remote1@example.net>>?= =?UTF-8?Q?<NON-ASCII-remote1@example.net_<ASCII-remote1@example.net>>?=
Cc: =?UTF-8?Q?DISPLAY-remote2?= Internationalized address Cc: =?UTF-8?Q?DISPLAY-remote2?= Internationalized address
=?UTF-8?Q?NON-ASCII-remote2@example.org?= removed:; =?UTF-8?Q?NON-ASCII-remote2@example.org?= removed:;
Downgraded-Cc: =?UTF-8?Q?DISPLAY-remote2_?= Downgraded-Cc: =?UTF-8?Q?DISPLAY-remote2_?=
=?UTF-8?Q?<NON-ASCII-remote2@example.org>?= =?UTF-8?Q?<NON-ASCII-remote2@example.org>?=
Resent-From: =?UTF-8?Q?DISPLAY-remote1?= <ASCII-remote1@example.net>
Downgraded-Resent-From: =?UTF-8?Q?DISPLAY-remote1_?=
=?UTF-8?Q?<NON-ASCII-remote1@example.net_<ASCII-remote1@example.net>>?=
Resent-To: =?UTF-8?Q?DISPLAY-reto?= <ASCII-reto@example.net>
Downgraded-Resent-To: =?UTF-8?Q?DISPLAY-reto_?=
=?UTF-8?Q?<NON-ASCII-reto@example.net_<ASCII-reto@example.net>>?=
Date: DATE Date: DATE
MAIL_BODY MAIL_BODY
Figure 2: Downgraded message Figure 2: Downgraded message
Figure 3 shows MIME decoded message of Figure 2. The recipient can Figure 3 shows MIME decoded message of Figure 2. The recipient can
read the original From, To, Cc header fields as Downgraded-From, read the original From, To, Cc and Unknown-Field header fields as
Downgraded-To, Downgraded-Cc header fields. Downgraded-From, Downgraded-To, Downgraded-Cc and Downgraded-Unknown-
Field header fields.
Return-Path: <ASCII-local@example.com> Return-Path: <ASCII-local@example.com>
Received: ...
Downgraded-Mail-From: <NON-ASCII-local@example.com Downgraded-Mail-From: <NON-ASCII-local@example.com
<ASCII-local@example.com>> <ASCII-local@example.com>>
Downgraded-Rcpt-To: <NON-ASCII-remote1@example.net Downgraded-Rcpt-To: <NON-ASCII-remote1@example.net
<ASCII-remote1@example.net>> <ASCII-remote1@example.net>>
Message-Id: MESSAGE_ID Message-Id: MESSAGE_ID
Mime-Version: 1.0 Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8" Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit
Subject: NON-ASCII-SUBJECT Subject: NON-ASCII-SUBJECT
Downgraded-Unknown-Field: NON-ASCII-Unknown
From: DISPLAY-local <ASCII-local@example.com> From: DISPLAY-local <ASCII-local@example.com>
Downgraded-From: DISPLAY-local <NON-ASCII-local@example.com Downgraded-From: DISPLAY-local <NON-ASCII-local@example.com
<ASCII-local@example.com>> <ASCII-local@example.com>>
To: DISPLAY-remote1 <ASCII-remote1@example.net> To: DISPLAY-remote1 <ASCII-remote1@example.net>
Downgraded-To: DISPLAY-remote1 <NON-ASCII-remote1@example.net Downgraded-To: DISPLAY-remote1 <NON-ASCII-remote1@example.net
<ASCII-remote1@example.net>> <ASCII-remote1@example.net>>
Cc: DISPLAY-remote2 Internationalized address Cc: DISPLAY-remote2 Internationalized address
NON-ASCII-remote2@example.org removed:; NON-ASCII-remote2@example.org removed:;
Downgraded-Cc: DISPLAY-remote2 <NON-ASCII-remote2@example.org> Downgraded-Cc: DISPLAY-remote2 <NON-ASCII-remote2@example.org>
Resent-From: DISPLAY-remote1 <ASCII-remote1@example.net>
Downgraded-Resent-From: DISPLAY-remote1
<NON-ASCII-remote1@example.net <ASCII-remote1@example.net>>
Resent-To: DISPLAY-reto <ASCII-reto@example.net>
Downgraded-Resent-To: DISPLAY-reto
<NON-ASCII-reto@example.net <ASCII-reto@example.net>>
Date: DATE Date: DATE
MAIL_BODY MAIL_BODY
Figure 3: MIME decoded message Figure 3: MIME decoded message
A.1. Displaying example A.1. Displaying example
This example shows processes of 'Displaying downgraded message' for This example shows how to display the message in Figure 2, above,
Figure 2. using the process defined in Section 3. For simplicity, we will show
the reconstruction of all the applicable fields at once.
First, perform Step 1. Selecting all Downgraded-* fields gives this:
Downgraded-Mail-From: =?UTF-8?Q?<NON-ASCII-local@example.com_?=
=?UTF-8?Q?<ASCII-local@example.com>>?=
Downgraded-Rcpt-To: =?UTF-8?Q?<NON-ASCII-remote1@example.net_?=
=?UTF-8?Q?<ASCII-remote1@example.net>>?=
Downgraded-Unknown-Field: =?UTF-8?Q?NON-ASCII-Unknown?=
Downgraded-From: =?UTF-8?Q?DISPLAY-local_<NON-ASCII-local@example.com_?= Downgraded-From: =?UTF-8?Q?DISPLAY-local_<NON-ASCII-local@example.com_?=
=?UTF-8?Q?<ASCII-local@example.com>>?= =?UTF-8?Q?<ASCII-local@example.com>>?=
Downgraded-To: =?UTF-8?Q?DISPLAY-remote1_?= Downgraded-To: =?UTF-8?Q?DISPLAY-remote1_?=
=?UTF-8?Q?<NON-ASCII-remote1@example.net_<ASCII-remote1@example.net>>?= =?UTF-8?Q?<NON-ASCII-remote1@example.net_<ASCII-remote1@example.net>>?=
Downgraded-Cc: =?UTF-8?Q?DISPLAY-remote2_?= Downgraded-Cc: =?UTF-8?Q?DISPLAY-remote2_?=
=?UTF-8?Q?<NON-ASCII-remote2@example.org>?= =?UTF-8?Q?<NON-ASCII-remote2@example.org>?=
Downgraded-Resent-From: =?UTF-8?Q?DISPLAY-remote1_?=
=?UTF-8?Q?<NON-ASCII-remote1@example.net_<ASCII-remote1@example.net>>?=
Downgraded-Resent-To: =?UTF-8?Q?DISPLAY-reto_?=
=?UTF-8?Q?<NON-ASCII-reto@example.net_<ASCII-reto@example.net>>?=
Figure 4: Displaying: Output of Step 1 Figure 4: Downgraded header fields
Then, perform Step 2. Two of the fields, Downgraded-Mail-From and Downgraded-Rcpt-To, are
Envelope Information Preservation Header Fields, and will not be
reconstructed. One field, Downgraded-Unknown-Field, is an Unknown
Header Fields' Preservation Header Field, and will also not be
reconstructed. That leaves these to be reconstructed, the Address
Header Fields' Preservation Header Fields:
Downgraded-From: =?UTF-8?Q?DISPLAY-local_<NON-ASCII-local@example.com_?=
=?UTF-8?Q?<ASCII-local@example.com>>?=
Downgraded-To: =?UTF-8?Q?DISPLAY-remote1_?=
=?UTF-8?Q?<NON-ASCII-remote1@example.net_<ASCII-remote1@example.net>>?=
Downgraded-Cc: =?UTF-8?Q?DISPLAY-remote2_?=
=?UTF-8?Q?<NON-ASCII-remote2@example.org>?=
Downgraded-Resent-From: =?UTF-8?Q?DISPLAY-remote1_?=
=?UTF-8?Q?<NON-ASCII-remote1@example.net_<ASCII-remote1@example.net>>?=
Downgraded-Resent-To: =?UTF-8?Q?DISPLAY-reto_?=
=?UTF-8?Q?<NON-ASCII-reto@example.net_<ASCII-reto@example.net>>?=
Figure 5: Header fields for the reconstruction
Now, perform Step 1, creating temporary fields.
From: DISPLAY-local <NON-ASCII-local@example.com From: DISPLAY-local <NON-ASCII-local@example.com
<ASCII-local@example.com>> <ASCII-local@example.com>>
To: DISPLAY-remote1 <NON-ASCII-remote1@example.net To: DISPLAY-remote1 <NON-ASCII-remote1@example.net
<ASCII-remote1@example.net>> <ASCII-remote1@example.net>>
Cc: DISPLAY-remote2 <NON-ASCII-remote2@example.org> Cc: DISPLAY-remote2 <NON-ASCII-remote2@example.org>
Resent-From: DISPLAY-remote1
<NON-ASCII-remote1@example.net <ASCII-remote1@example.net>>
Resent-To: DISPLAY-reto
<NON-ASCII-reto@example.net <ASCII-reto@example.net>>
Figure 5: Displaying: Output of Step 2 Figure 6: Output of Step 1
Perform Step 3.
From: =?UTF-8?Q?DISPLAY-local?= <ASCII-local@example.com>
To: =?UTF-8?Q?DISPLAY-remote1?= <ASCII-remote1@example.net>
Cc: =?UTF-8?Q?DISPLAY-remote2?= Internationalized address
=?UTF-8?Q?NON-ASCII-remote2@example.org?= removed:;
Figure 6: Displaying: Output of Step 3 In step 2, we set aside the "From", "To", and "Cc" fields, and
continue to step 3 with just "Resent-From" and "Resent-To" (the
fields that may appear more than once). The fields we set aside will
be picked up again later, in step 9.
Perform Step 4. "From", "To", "Cc" header fields are removed in Perform Steps 3 and 4. The edit buffer contains re-generated ASCII
Figure 7. header fields, canonicalized.
Return-Path: <ASCII-local@example.com> Resent-From: =?UTF-8?Q?DISPLAY-remote1?= <ASCII-remote1@example.net>
Downgraded-Mail-From: =?UTF-8?Q?<NON-ASCII-local@example.com_?= Resent-To: =?UTF-8?Q?DISPLAY-reto?= <ASCII-reto@example.net>
=?UTF-8?Q?<ASCII-local@example.com>>?=
Downgraded-Rcpt-To: =?UTF-8?Q?<NON-ASCII-remote1@example.net_?=
=?UTF-8?Q?<ASCII-remote1@example.net>>?=
Message-Id: MESSAGE_ID
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Subject: =?UTF-8?Q?NON-ASCII-SUBJECT?=
Downgraded-From: =?UTF-8?Q?DISPLAY-local_<NON-ASCII-local@example.com_?=
=?UTF-8?Q?<ASCII-local@example.com>>?=
Downgraded-To: =?UTF-8?Q?DISPLAY-remote1?_?=
=?UTF-8?Q?<NON-ASCII-remote1@example.net_<ASCII-remote1@example.net>>?=
Downgraded-Cc: =?UTF-8?Q?DISPLAY-remote2_?=
=?UTF-8?Q?<NON-ASCII-remote2@example.org>?=
Date: DATE
MAIL_BODY Figure 7: The edit buffer (output of Step 4)
Figure 7: Displaying: Output of Step 4 Perform Steps 5 to 7, comparison, for each header field. Both the
Resent-From and Resent-To fields will match, and we will proceed to
step 9. (Step 8, iteration, does not apply in this example.
Perform Step 5 and 6. Perform step 9, replacing all applicable fields, without changing the
order. Then do MIME decoding on everything, for display.
Return-Path: <ASCII-local@example.com> Return-Path: <ASCII-local@example.com>
Received: ...
Downgraded-Mail-From: <NON-ASCII-local@example.com Downgraded-Mail-From: <NON-ASCII-local@example.com
<ASCII-local@example.com>> <ASCII-local@example.com>>
Downgraded-Rcpt-To: <NON-ASCII-remote1@example.net> Downgraded-Rcpt-To: <NON-ASCII-remote1@example.net>
<ASCII-remote1@example.net> <ASCII-remote1@example.net>
Message-Id: MESSAGE_ID Message-Id: MESSAGE_ID
Mime-Version: 1.0 Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8" Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit
Subject: NON-ASCII-SUBJECT Subject: NON-ASCII-SUBJECT
Downgraded-Unknown-Field: NON-ASCII-Unknown
From: DISPLAY-local <NON-ASCII-local@example.com From: DISPLAY-local <NON-ASCII-local@example.com
<ASCII-local@example.com>> <ASCII-local@example.com>>
To: DISPLAY-remote1 <NON-ASCII-remote1@example.net To: DISPLAY-remote1 <NON-ASCII-remote1@example.net
<ASCII-remote1@example.net>> <ASCII-remote1@example.net>>
Cc: DISPLAY-remote2 <NON-ASCII-remote2@example.org> Cc: DISPLAY-remote2 <NON-ASCII-remote2@example.org>
Resent-From: DISPLAY-remote1 <NON-ASCII-remote1@example.net
<ASCII-remote1@example.net>>
Resent-To: DISPLAY-reto <NON-ASCII-reto@example.net
<ASCII-reto@example.net>>
Date: DATE Date: DATE
MAIL_BODY Figure 8: The final result
Figure 8: Decoded message
As a result, in this simple example, all original header fields are As a result, in this simple example, some original header fields are
displayed in the original form. Differences between Figure 1 and now displayed in their original form. Differences between Figure 1
Figure 8 are Return-Path, Downgraded-Mail-From, Downgraded-Rcpt-To and Figure 8 are Return-Path, Downgraded-Mail-From,
header fields only. Downgraded-Rcpt-To, and Downgraded-Unknown-Field.
Author's Address Authors' Addresses
Kazunori Fujiwara Kazunori Fujiwara
Japan Registry Services Co., Ltd. Japan Registry Services Co., Ltd.
Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda
Chiyoda-ku, Tokyo 101-0065 Chiyoda-ku, Tokyo 101-0065
Japan Japan
Phone: +81-3-5215-8451 Phone: +81-3-5215-8451
Email: fujiwara@jprs.co.jp Email: fujiwara@jprs.co.jp
Barry Leiba
Huawei Technologies
Phone: +1 646 827 0648
Email: barryleiba@computer.org
URI: http://internetmessagingtechnology.org/
 End of changes. 75 change blocks. 
202 lines changed or deleted 249 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/