Email Address Internationalization Y. YONEYA, Ed. (EAI) K. Fujiwara, Ed. Internet-Draft JPRS Intended status: Experimental Aug 16, 2006 Expires: February 17, 2007 Downgrading mechanism for Email Address Internationalization (EAI) draft-ietf-eai-downgrade-02.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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 February 17, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract Traditional mail systems handle only US-ASCII characters in SMTP envelope and mail headers. The Email Address Internationalization (EAI) is implemented by allowing UTF-8 characters in SMTP envelope and mail headers. To deliver Non-ASCII mail address through EAI incompliant environment, some sort of converting mechanism (i.e. downgrading) is required. This document describes requirements for downgrading, SMTP Downgrading, SMTP DATA/Header Downgrading and YONEYA & Fujiwara Expires February 17, 2007 [Page 1] Internet-Draft EAI Downgrade Aug 2006 implementation consideration. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Downgrade Requirements . . . . . . . . . . . . . . . . . . . . 3 3.1. Timing and conditions of downgrading . . . . . . . . . . . 3 3.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 4. SMTP Downgrading . . . . . . . . . . . . . . . . . . . . . . . 4 5. SMTP DATA/Header Downgrading . . . . . . . . . . . . . . . . . 5 5.1. Header conversion . . . . . . . . . . . . . . . . . . . . 6 5.1.1. Downgrading address headers . . . . . . . . . . . . . 7 6. Implementation consideration . . . . . . . . . . . . . . . . . 8 6.1. MUA . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 7. Security considerations . . . . . . . . . . . . . . . . . . . 8 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 10. Change History . . . . . . . . . . . . . . . . . . . . . . . . 8 10.1. draft-yoneya-ima-downgrade: Version 00 . . . . . . . . . . 8 10.2. draft-yoneya-ima-downgrade: Version 01 . . . . . . . . . . 9 10.3. draft-ietf-eai-downgrade: Version 00 . . . . . . . . . . . 9 10.4. draft-ietf-eai-downgrade: Version 01 . . . . . . . . . . . 9 10.5. draft-ietf-eai-downgrade: Version 02 . . . . . . . . . . . 9 11. Normative References . . . . . . . . . . . . . . . . . . . . . 9 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 10 A.1. SMTP Downgrading Example . . . . . . . . . . . . . . . . . 10 A.2. Header conversion downgrading example . . . . . . . . . . 12 A.3. Header conversion upgrading example . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . . . . 17 YONEYA & Fujiwara Expires February 17, 2007 [Page 2] Internet-Draft EAI Downgrade Aug 2006 1. Introduction Traditional mail systems which are defined by [RFC2821] and [RFC2822] allow US-ASCII characters in SMTP envelope and mail headers in body part. The EAI proposal [I-D.ietf-eai-framework], [I-D.ietf-eai-utf8headers] and [I-D.ietf-eai-smtpext] allows UTF-8 characters in SMTP envelope and mail headers in body part. Carrying Non-ASCII mail address from sender to recipients requires all components on the mail delivery route are EAI compliant. Otherwise Non-ASCII mail address can't be delivered. To solve the problem, this document describes downgrading mechanism that enables delivering Non-ASCII mail address by converting it to corresponding US-ASCII representation on current mail delivery system. Not only SMTP envelope, but also UTF-8 characters in mail headers MUST be converted to US-ASCII. Downgrading in EAI consists from following two parts: o SMTP Downgrading o SMTP DATA/Header Downgrading Decoding downgraded envelope/message is called 'Upgrading' in this document. Each downgrading mechanism has corresponding upgrading mechanism. In this document, requirements for downgrading is described in section Section 3, SMTP Downgrading is described in Section 4, and SMTP DATA/Header Downgrading is described in Section 5. 2. Terminology Terminology for this document is defined in [I-D.ietf-eai-framework]. 3. Downgrade Requirements 3.1. Timing and conditions of downgrading Followings are timing and conditions of downgrading. Timing: SMTP client detects that SMTP server doesn't support "UTF8SMTP" option at EHLO. [I-D.ietf-eai-smtpext] Conditions: SMTP client detects that UTF-8 is included in the SMTP envelope or mail headers in the SMTP DATA. Note: If the UTF8SMTP header exists, downgrading will be performed. If UTF-8 characters exist in mail headers without the UTF8SMTP YONEYA & Fujiwara Expires February 17, 2007 [Page 3] Internet-Draft EAI Downgrade Aug 2006 header, this is a protocol error, and handling of this situation is outside the scope of this specification. 3.2. Requirements Followings are requirements of downgrading. 1. Downgrading must be performed only once. 2. Upgrading must be performed at minimized place such as final destination like recipient MUA. 3. Downgrading and upgrading must be automated. 4. Downgrading and upgrading should be easy and lightweight as it is possible to do with MTA like 8BITMIME encapsulation. 5. Downgrade and upgrade method must be defined clearly. 6. Downgrading and upgrading should preserve all header information. 7. Downgrading must support SPF and DKIM. 8. Downgrading occurrence must be recorded. 4. SMTP Downgrading Downgrading MUST be performed in each SMTP session. Target of downgrading elements in SMTP envelope are below: o MAIL FROM: o RCPT TO: Downgrading in SMTP envelope uses ALT-ADDRESS parameter proposed in [I-D.ietf-eai-smtpext]. An address is downgradable if the address is all-ASCII address or the address has all-ASCII address specified by ALT-ADDRESS parameter. If the return address in the envelope ("MAIL FROM:") is not downgradable, downgrading fails. One SMTP session may contain multiple recipients. Downgrading SHOULD be performed for each SMTP recipient address. First, split a multiple recipients session to each sessions. If the recipient address is downgradable, the SMTP session to the recipient is downgradable. When MUA/MTA is transferring mail and finding its envelope contains Non-ASCII addresses, it MUST decide to bounce or downgrade if receiving MTA is EAI incompliant. Even if no downgrading is performed for envelope from/to, MUA/MTA MUST downgrade mail headers including UTF-8 or bounce. This is described in next section. YONEYA & Fujiwara Expires February 17, 2007 [Page 4] Internet-Draft EAI Downgrade Aug 2006 MTA replaces Non-ASCII mail address with specified alternative US- ASCII address. Then appends replaced information with EAI- Downgraded-From: and EAI-Downgraded-To: header in mail header (outgoing SMTP DATA). EAI-Downgraded-From: EAI-Downgraded-To: Note that when downgrading, not to disclose whole recipient address, MUA/MTA SHOULD make SMTP connection per each recipient address. Also note that by appending EAI-Downgraded-From/To: headers, MUA/MTA MUST perform SMTP DATA/Header Downgrading. This is described in next section. Case study: SPF check SPF checks domainname of the envelope from and SMTP connection IP address. If ALT-ADDRESS domainname is Punycode/IDNA form of Non- ASCII domainname, it will be compatible with current SPF. In this case, SPF check will be performed correctly. Otherwise, more detailed consideration is required. NOTE: ORCPT ESMTP ORCPT parameter is used for Delivery Status Notifications (DSNs) [RFC3461]. ORCPT parameters contain mail addresses. After extending ORCPT parameter to support Non-ASCII mail addresses, ORCPT parameter downgrading should be defined here. 5. SMTP DATA/Header Downgrading Target and non-target of downgrading elements in mail headers (SMTP data) are below: Originator address(es): Non-ASCII mail addresses in From:, Reply-To:, Sender: and their Resent- headers MUST be target of downgrading. Destination address(es): Non-ASCII mail addresses in To:, CC:, Bcc: and their Resent- headers MUST be target of downgrading. IDs: IDs such as Message-ID:, Date:, In-Reply-To: and References: MUST NOT be target of downgrading. Trace headers: Received: headers MUST NOT be target of downgrading because they do not contain Non-ASCII mail addresses. YONEYA & Fujiwara Expires February 17, 2007 [Page 5] Internet-Draft EAI Downgrade Aug 2006 other headers: UTF-8 in other headers MUST be target of downgrading. UTF8SMTP header: Identification of internationalized email header requires special consideration. 5.1. Header conversion This section defines conversion method to US-ASCII for each header which may contain Non-ASCII characters. Each header has its own downgrading method. To preserve all header information, define generic encapsulation header: "Downgraded: HeaderName: HeaderValue". The header value is encoded by [RFC2047] with UTF-8 tag. Downgrading: * Check if the mail has 'UTF8SMTP' header and its value is "UTF8". Otherwise, downgrading is not required. * Check each header whether it contains UTF-8 characters or not. If the header contains UTF-8 characters, + If the header is an address header which is described in Section 5.1.1, - Preserve the header in 'Downgraded' header. - Downgrade the header defined in Section 5.1.1. + The other header case, encode the header by [RFC2047] with UTF-8 tag. * Change 'UTF8SMTP' header value to "Downgraded". Upgrading: * Check if the mail has 'UTF8SMTP' header and its value is "Downgraded". Otherwise, upgrading is not required. * Decode all 'Downgraded' headers. + Decode header value field string which is [RFC2047] encoded. + If the header is address header described in Section 5.1.1, - Apply address header downgrading to the decoded header. - Remove the header line which is the same with the downgraded line. + Remove the 'Downgraded' header. + Add decoded header to mail header. * If each mail header has [RFC2047] encoded part and which encoding is "UTF-8", it is a downgraded header, so decode it. * Change 'UTF8SMTP' header value to "UTF8". Followings are pros and cons of this method. Pros: * EAI incompliant MUA displays the downgraded mail body except original Non-ASCII mail addresses. YONEYA & Fujiwara Expires February 17, 2007 [Page 6] Internet-Draft EAI Downgrade Aug 2006 * EAI incompliant MUA displays and handles the sender specified alternative address (ALT-ADDRESS). * EAI compliant MUA displays and handles original headers. Cons: * Implementation and processing cost is not so easy and lightweight because MUA/MTA must parse each header and encode it by defined method. * Hard to preserve whole information AS IS. The address headers are preserved but the other headers which is [RFC2047] encoded with UTF-8 tag are not distinguished that it is downgraded or it is encoded by sender's MUA. Also, restoration order of the downgraded headers is not guaranteed. Therefore, to check DKIM requires special consideration. [[Reference to [I-D.ietf-eai-scenarios] and evaluation of each case should be described here.]] 5.1.1. Downgrading address headers This section targets From:, Sender:, Reply-To:, To:, CC:, Bcc:, Resent-From:, Resent-To:, Resent-CC:, Resent-Bcc:, Resent-sender: headers which contains Originator/Destination address(es). The header value is composed of single or multiple mailbox/angle-addr fields defined in [I-D.ietf-eai-utf8headers]. If the header contains UTF-8 characters, downgrading method is follows. 1. Extract every field and downgrade mailbox/angle-addr described below. 2. By mailbox/angle-addr downgrading, if the field became empty, the field should be removed. 3. If all header field is removed, remove the header. 4. If From header is removed, generate new From: header from envelope-from address. EAI angle-addr defined in [I-D.ietf-eai-utf8headers] consists of 3 forms. Downgrading method is defined for each form. 1. US-ASCII mail address case, preserve it. 2. Non-ASCII mail address without ALT-ADDRESS parameter case, remove this angle-addr. 3. Non-ASCII mail address with sender-specified US-ASCII address case, replace it as . "mailbox" is defined as "DISPLAY NAME angle-addr" in YONEYA & Fujiwara Expires February 17, 2007 [Page 7] Internet-Draft EAI Downgrade Aug 2006 [I-D.ietf-eai-utf8headers]. The "DISPLAY NAME" field should be encoded by [RFC2047] with UTF-8 tag, if necessary. If the angle-addr is removed, remove the field including "DISPLAY NAME". 6. Implementation consideration 6.1. MUA EAI compliant MUA MUST implement downgrading mechanism for sending. MUA MAY encode UTF-8 in Subject header with the same encoding of body part while downgrading. EAI compliant MUA MUST upgrade downgraded mail and MUST show Non- ASCII mail addresses on display. 7. Security considerations See the extended security considerations discussion in [I-D.ietf-eai-framework] 8. IANA Considerations IANA is requested to add the "EAI-Downgraded-From:", "EAI-Downgraded-To:" and "Downgraded:" new headers to the registry with the entries pointing to this specification for its definition. 9. Acknowledgements John Klensin, Harald Alvestrand, Chris Newman, Charles Lindsey, Marcos Sanz, Alexey Melnikov and JET members. 10. Change History This section is used for tracking the update of this document. Will be removed after finalize. 10.1. draft-yoneya-ima-downgrade: Version 00 o Initial version o Fllowed draft-yeh-ima-utf8headers-00 and draft-yao-smtpext-00 YONEYA & Fujiwara Expires February 17, 2007 [Page 8] Internet-Draft EAI Downgrade Aug 2006 10.2. draft-yoneya-ima-downgrade: Version 01 o Document structure was changed o Fllowed draft-yeh-ima-utf8headers-01 and draft-yao-smtpext-02 o Downgrading requirements were added o SMTP DATA encapsulation method was proposed o Downgrading examples was provided 10.3. draft-ietf-eai-downgrade: Version 00 o Fllowed draft-yeh-ima-utf8headers-01 and draft-ietf-eai-smtpext-00 o No header downgrading method was proposed o Header encapsulation method was proposed 10.4. draft-ietf-eai-downgrade: Version 01 o Followed draft-ietf-eai-utf8headers-00 o Header conversion and encapsulation method was merged o Header conversion method was defined in detail 10.5. draft-ietf-eai-downgrade: Version 02 o Followed draft-ietf-eai-utf8headers-01 and draft-ietf-eai-smtpext-01 o Specification about algorithmic generated address is removed o No header downgrading method was removed o SMTP DATA encapsulation method was removed 11. Normative References [I-D.ietf-eai-framework] Klensin, J. and Y. Ko, "Overview and Framework for Internationalized Email", draft-ietf-eai-framework-01 (work in progress), June 2006. [I-D.ietf-eai-scenarios] Alvestrand, H., "UTF-8 Mail: Scenarios", draft-ietf-eai-scenarios-01 (work in progress), June 2006. [I-D.ietf-eai-smtpext] Yao, J. and W. Mao, "SMTP extension for internationalized email address", draft-ietf-eai-smtpext-01 (work in progress), July 2006. [I-D.ietf-eai-utf8headers] Yeh, J., "Internationalized Email Headers", draft-ietf-eai-utf8headers-01 (work in progress), YONEYA & Fujiwara Expires February 17, 2007 [Page 9] Internet-Draft EAI Downgrade Aug 2006 August 2006. [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996. [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001. [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001. [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, January 2003. Appendix A. Examples A.1. SMTP Downgrading Example This section shows a SMTP Downgrading example. Consider a downgradable mail message. o The sender address is "NON-ASCII-FROM" which is Non-ASCII address. Its ASCII alternative is "ASCII-FROM". o The "To" address is "NON-ASCII-TO" which is Non-ASCII address. Its ASCII alternative is "ASCII-TO". o The "CC" address is "NON-ASCII-CC" which is Non-ASCII address. It has no ASCII alternative address. o The Subject header is "UTF8-Subject" which contains Non-ASCII characters. YONEYA & Fujiwara Expires February 17, 2007 [Page 10] Internet-Draft EAI Downgrade Aug 2006 Original EAI message SMTP session MAIL From: ALT-ADDRESS RCPT TO: ALT-ADDRESS RCPT TO: ------------------------------------------------------------- UTF8SMTP: UTF8 Message-Id: MESSAGE_ID Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Subject: UTF8-SUBJECT From: To: CC: Date: DATE MAIL_BODY Figure 1: Original EAI message In this example, there are two sessions, one is To:, the other is CC:. The CC: session does not contain ASCII alternative address, it is not downgradable and bounced. The To: session can be downgraded to the next example Figure 2. YONEYA & Fujiwara Expires February 17, 2007 [Page 11] Internet-Draft EAI Downgrade Aug 2006 After SMTP Downgrading MAIL From: RCPT TO: ------------------------------------------------------------- EAI-Downgraded-From: EAI-Downgraded-To: UTF8SMTP: UTF8 Message-Id: MESSAGE_ID Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Subject: UTF8-SUBJECT From: To: CC: Date: DATE MAIL_BODY Figure 2: SMTP Downgraded EAI message A.2. Header conversion downgrading example Original EAI message UTF8SMTP: UTF8 Message-Id: MESSAGE_ID Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Subject: UTF-8_SUBJECT From: To: CC: Date: DATE MAIL_BODY Figure 3: Original EAI message YONEYA & Fujiwara Expires February 17, 2007 [Page 12] Internet-Draft EAI Downgrade Aug 2006 SMTP Downgrading adds EAI-Downgraded-From: and EAI-Downgraded-To: headers. EAI-Downgraded-From: EAI-Downgraded-To: Figure 4: Headers added by SMTP Downgrading Result of the header conversion downgrading. EAI-Downgraded-From: MIME( EAI-Downgraded-To: MIME( UTF8SMTP: Downgraded Message-Id: MESSAGE_ID Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Subject: MIME(UTF-8_SUBJECT) Downgraded: From: MIME() From: Downgraded: To: MIME() To: Downgraded: CC: MIME() Date: DATE MAIL_BODY Figure 5: Header conversion downgraded message MIME() stands for [RFC2047] encoding. A.3. Header conversion upgrading example This example shows upgrading process of Figure 5. First, check 'UTF8SMTP:' header. Its value is "Downgraded", it is EAI downgraded message. YONEYA & Fujiwara Expires February 17, 2007 [Page 13] Internet-Draft EAI Downgrade Aug 2006 Decode all 'Downgraded:' headers. Downgraded: From: MIME() Downgraded: To: MIME() Downgraded: CC: MIME() Figure 6: Upgrading: selecting Downgraded headers Decode header value field string which is [RFC2047] encoded. From: To: CC: Figure 7: Upgrading: upgraded Downgraded headers Apply address header downgrading to the decoded header. From: To: Figure 8: Upgrading: downgraded upgraded Downgraded headers YONEYA & Fujiwara Expires February 17, 2007 [Page 14] Internet-Draft EAI Downgrade Aug 2006 Remove the header line which is the same with the downgraded line. EAI-Downgraded-From: MIME( EAI-Downgraded-To: MIME( UTF8SMTP: Downgraded Message-Id: MESSAGE_ID Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Subject: MIME(UTF-8_SUBJECT) Downgraded: From: MIME() Downgraded: To: MIME() Downgraded: CC: MIME() Date: DATE MAIL_BODY Figure 9: Upgrading: Removing duplicated headers Remove the 'Downgraded' header and add decoded Downgraded headers If each mail header has [RFC2047] encoded part and which encoding is "UTF-8", it is a downgraded header, so decode it. Change 'UTF8SMTP' header value to "UTF8". EAI-Downgraded-From: EAI-Downgraded-To: UTF8SMTP: UTF8 Message-Id: MESSAGE_ID Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Subject: UTF-8_SUBJECT From: To: MIME( CC: MIME( Date: DATE MAIL_BODY Figure 10: Header conversion upgraded message As a result, in this example, all headers are preserved. YONEYA & Fujiwara Expires February 17, 2007 [Page 15] Internet-Draft EAI Downgrade Aug 2006 Authors' Addresses Yoshiro YONEYA (editor) JPRS Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda Chiyoda-ku, Tokyo 101-0065 Japan Phone: +81 3 5215 8451 Email: yone@jprs.co.jp Kazunori Fujiwara (editor) JPRS 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 YONEYA & Fujiwara Expires February 17, 2007 [Page 16] Internet-Draft EAI Downgrade Aug 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). YONEYA & Fujiwara Expires February 17, 2007 [Page 17]