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