Email Address Internationalization Y. YONEYA, Ed. (EAI) K. Fujiwara, Ed. Internet-Draft JPRS Intended status: Experimental Mar 5, 2007 Expires: September 6, 2007 Downgrading mechanism for Email Address Internationalization draft-ietf-eai-downgrade-03.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 September 6, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract Traditional mail systems handle only US-ASCII characters in SMTP envelope and mail header fields. The Email Address Internationalization is implemented by allowing UTF-8 characters in SMTP envelope and mail header fields (UTF8SMTP). To deliver Non- ASCII mail address via UTF8SMTP non-compliant environment, some sort of converting mechanism (i.e. downgrading) is required. This document describes requirements for downgrading, SMTP downgrading, YONEYA & Fujiwara Expires September 6, 2007 [Page 1] Internet-Draft UTF8SMTP Downgrade Mar 2007 Email header downgrading and 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. Downgraded header . . . . . . . . . . . . . . . . . . . . . . 4 5. SMTP Downgrading . . . . . . . . . . . . . . . . . . . . . . . 5 6. Email header Downgrading . . . . . . . . . . . . . . . . . . . 6 6.1. Downgrading address headers . . . . . . . . . . . . . . . 7 7. Upgrading downgraded header . . . . . . . . . . . . . . . . . 7 8. Implementation consideration . . . . . . . . . . . . . . . . . 8 9. Security considerations . . . . . . . . . . . . . . . . . . . 8 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 12. Change History . . . . . . . . . . . . . . . . . . . . . . . . 9 12.1. draft-yoneya-ima-downgrade: Version 00 . . . . . . . . . . 9 12.2. draft-yoneya-ima-downgrade: Version 01 . . . . . . . . . . 9 12.3. draft-ietf-eai-downgrade: Version 00 . . . . . . . . . . . 9 12.4. draft-ietf-eai-downgrade: Version 01 . . . . . . . . . . . 9 12.5. draft-ietf-eai-downgrade: Version 02 . . . . . . . . . . . 9 12.6. draft-ietf-eai-downgrade: Version 03 . . . . . . . . . . . 9 13. Normative References . . . . . . . . . . . . . . . . . . . . . 10 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 10 A.1. Downgrading example 1 . . . . . . . . . . . . . . . . . . 10 A.2. Upgrading example . . . . . . . . . . . . . . . . . . . . 13 A.3. Downgrading example 2 . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . . . 18 YONEYA & Fujiwara Expires September 6, 2007 [Page 2] Internet-Draft UTF8SMTP Downgrade Mar 2007 1. Introduction Traditional mail systems which are defined by [RFC2821] and [RFC2822] allow US-ASCII characters in SMTP envelope and mail header field bodies. The UTF8SMTP 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 header field bodies. Carrying Non-ASCII mail address from sender to recipients requires all components on the mail delivery route are UTF8SMTP 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 Non-ASCII characters in mail header fields MUST be converted to US-ASCII. Downgrading in UTF8SMTP consists from following two parts: o SMTP Downgrading o Email 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 are described in Section 3, SMTP Downgrading is described in Section 5, and Email header Downgrading is described in Section 6. This document assumes that MIME headers are not extended to use UTF-8 characters because it is not clearly defined in [I-D.ietf-eai-utf8headers]. 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. YONEYA & Fujiwara Expires September 6, 2007 [Page 3] Internet-Draft UTF8SMTP Downgrade Mar 2007 Timing: SMTP client detects that SMTP server doesn't support "UTF8SMTP" option at EHLO. [I-D.ietf-eai-smtpext] Conditions: SMTP client detects that non-ASCII characters are included in the SMTP envelope or mail header fields in the SMTP DATA. 3.2. Requirements Followings are requirements of downgrading. 1. Downgrading should be performed only once. 2. "Upgrading MUST be performed (if at all) when it is known that a subsequent downgrade will not be needed. This could mean that the upgrading is delayed until the recipient MUA processes the message." 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 should support SPF and DKIM. 8. Downgrading occurrence should be recorded. 4. Downgraded header To preserve all header information, new generic encapsulation header is required. The new header is required, and it is specified as "Downgraded". It has two fields. The first field is the encapsulated header name. The second field contains the encapsulated header value which is encoded by [RFC2047] with UTF-8 tag. The header field syntax is specified as follows: fields =/ downgraded downgraded = "Downgraded:" [CFWS] field-name ":" dvalue CRLF field-name = 1*ftext ftext = %d33-57 / %d59-126 ; printable ASCII except ":" dvalue = 1*any-ascii any-ascii = %d32-126 Any headers can be preserved in Downgraded: header. The "dvalue" field is encoded by [RFC2047]. "Downgraded header decoding" means that generating new header whose header name is "field-name" field that retrieving preserved field-name and dvalue decoded by [RFC2047]. To preserve SMTP envelope downgraded information, another new header is required, and it is specified as "Envelope-Downgraded". Details are described in Section 5. The header field syntax is specified as YONEYA & Fujiwara Expires September 6, 2007 [Page 4] Internet-Draft UTF8SMTP Downgrade Mar 2007 follows: fields =/ edowngraded edowngraded = "Envelope-Downgraded:" [CFWS] field-name ":" value CRLF field-name = "From" / "To" value = CFWS "<" uPath ">" CFWS "<" Mailbox ">" CFWS ; Mailbox is defined in RFC 2821, section 4.1.2 ; uPath is defined in [I-D.ietf-eai-smtpext] 5. SMTP Downgrading Downgrading MUST be performed for each SMTP recipient address. 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 US-ASCII address or the address has US-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 individually. 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 UTF8SMTP non-compliant. Even if no downgrading is performed for envelope from/to, MUA/MTA MUST downgrade mail header fields including non-ASCII characters or bounce. This is described in Section 6. Downgrading MTA replaces Non-ASCII mail address with specified alternative US-ASCII address. Also MTA preserves original information using "Envelope-Downgraded" header defined in Section 4 with From or To field name. YONEYA & Fujiwara Expires September 6, 2007 [Page 5] Internet-Draft UTF8SMTP Downgrade Mar 2007 Envelope-Downgraded: From: Envelope-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 "Envelope-Downgraded:" headers, MUA/MTA MUST perform Email header Downgrading described in Section 6. 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. Case study: SPF check SPF checks domain name of the envelope from and SMTP connection IP address. If ALT-ADDRESS domain name 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. 6. Email header Downgrading This section defines conversion method to US-ASCII for each header which may contain Non-ASCII characters. If the whole mail header does not contain Non-ASCII characters, email header downgrading is not required. Otherwise, email header downgrading checks each header whether it contains UTF-8 characters or not. If the header contains UTF-8 characters, convert the header in a suitable method for of each header. Each header's downgrading method is described below: From, To, CC, Reply-To, Return-Path: The header field body is composed of single or multiple angle- addr/addr-spec fields defined in [I-D.ietf-eai-utf8headers]. If the header has no 'angle-addr' or 'utf8-addr-spec' which contains UTF-8 characters, only "display-name" part contains UTF-8 characters, encode the header by [RFC2047] with UTF-8 tag and replace it. Otherwise, preserve the header in "Downgraded:" header and generate US-ASCII only header defined in Section 6.1, replace the original header with the generated US-ASCII only header. When this address header downgrading fails, this downgrading fails and the mail MUST be bounced. YONEYA & Fujiwara Expires September 6, 2007 [Page 6] Internet-Draft UTF8SMTP Downgrade Mar 2007 Subject: Encode the header by [RFC2047] with UTF-8 tag and replace it. Message-ID:, Date:, In-Reply-To: "ID"s and "Date"s does not contain UTF-8 characters. Received: If the FOR clause contains UTF-8 addresses, the header must be downgraded. In this case, preserve the header in "Downgraded:" header and remove the FOR clause in the header. other headers: All other headers which contains UTF-8 characters are preserved in Downgraded: header and removed. Downgraded headers should be inserted or replaced at the same position of the original header. 6.1. Downgrading address headers This procedure targets "From:", "To:", "CC:", "Reply-To:", "Return- Path:" headers which contains Originator/Destination address(es). 1. Extract every field and downgrade each 'mailbox'/'angle- addr'/'utf8-addr-spec'. If the Non-ASCII address is in utf8-addr-spec form, then the header downgrading fails because the form has no alt-address. "mailbox" is defined as "DISPLAY NAME angle-addr" in [I-D.ietf-eai-utf8headers]. The "DISPLAY NAME" field should be encoded by [RFC2047] with UTF-8 tag, if necessary. UTF8SMTP angle-addr defined in [I-D.ietf-eai-utf8headers] consists of 3 forms. Downgrading method is defined for each form. 1. US-ASCII is used as is. 2. This email header downgrading fails because this header is not downgradable. 3. > Non-ASCII mail address with sender-specified US-ASCII address is replaced as . 7. Upgrading downgraded header Upgrading downgraded header is described below: o Check if the mail header contains 'Downgraded:' headers. Otherwise, upgrading is not required. YONEYA & Fujiwara Expires September 6, 2007 [Page 7] Internet-Draft UTF8SMTP Downgrade Mar 2007 o Perform "Downgraded header decoding" for each "Downgraded:" headers and replace the 'Downgraded:' header with its decoded header. * If the decoded header is an address header described in Section 6.1, + Generate ASCII only header described in Section 6.1 from the decoded header. + Remove the header line which is the same with the generated ASCII only header. (REQUIRE HEADER NORMALIZATION) * If the decoded header is a "Received:" header, + Removing the 'FOR' clause from the decoded header generates ASCII only header. + Remove the header line which is the same with the generated header. (REQUIRE HEADER NORMALIZATION) o If each mail header has [RFC2047] encoded part and which encoding is "UTF-8", it may be a downgraded header, so decode it. 8. Implementation consideration UTF8SMTP 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. UTF8SMTP compliant MUA MUST upgrade downgraded mail and MUST show Non-ASCII mail addresses on display. 9. Security considerations See "Security considerations" section in [I-D.ietf-eai-framework] for more discussion. 10. IANA Considerations IANA is requested to add the "Envelope-Downgraded:", and "Downgraded:" new headers to the registry with the entries pointing to this specification for its definition. 11. Acknowledgements John Klensin, Harald Alvestrand, Chris Newman, Charles Lindsey, Marcos Sanz, Alexey Melnikov and JET members. YONEYA & Fujiwara Expires September 6, 2007 [Page 8] Internet-Draft UTF8SMTP Downgrade Mar 2007 12. Change History This section is used for tracking the update of this document. Will be removed after finalize. 12.1. draft-yoneya-ima-downgrade: Version 00 o Initial version o Followed draft-yeh-ima-utf8headers-00 and draft-yao-smtpext-00 12.2. draft-yoneya-ima-downgrade: Version 01 o Document structure was changed o Followed 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 12.3. draft-ietf-eai-downgrade: Version 00 o Followed draft-yeh-ima-utf8headers-01 and draft-ietf-eai-smtpext-00 o No header downgrading method was proposed o Header encapsulation method was proposed 12.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 12.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 12.6. draft-ietf-eai-downgrade: Version 03 o Followed draft-ietf-eai-utf8headers-03 and draft-ietf-eai-smtpext-03 o Downgraded: and Envelope-Downgraded: headers definition was added o Mail header downgrading method was refined o Examples in Appendix A were refined YONEYA & Fujiwara Expires September 6, 2007 [Page 9] Internet-Draft UTF8SMTP Downgrade Mar 2007 13. Normative References [I-D.ietf-eai-dsn] Newman, C., "International Delivery and Disposition Notifications", draft-ietf-eai-dsn-00 (work in progress), January 2007. [I-D.ietf-eai-framework] Klensin, J. and Y. Ko, "Overview and Framework for Internationalized Email", draft-ietf-eai-framework-05 (work in progress), February 2007. [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-03 (work in progress), February 2007. [I-D.ietf-eai-utf8headers] Yeh, J., "Internationalized Email Headers", draft-ietf-eai-utf8headers-03 (work in progress), March 2007. [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. Downgrading example 1 This section shows a SMTP Downgrading example. Consider a downgradable mail message. YONEYA & Fujiwara Expires September 6, 2007 [Page 10] Internet-Draft UTF8SMTP Downgrade Mar 2007 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. Its ASCII alternative address is "ASCII-CC". o The Subject header is "UTF8-SUBJECT" which contains Non-ASCII characters. Original UTF8SMTP message SMTP session MAIL From: ALT-ADDRESS RCPT TO: ALT-ADDRESS RCPT TO: ALT-ADDRESS ------------------------------------------------------------- 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 3: Original UTF8SMTP message In this example, there are two sessions, one is To:, the other is CC:. Both sessions are downgradable. Figure 4 shows To: session downgrading. YONEYA & Fujiwara Expires September 6, 2007 [Page 11] Internet-Draft UTF8SMTP Downgrade Mar 2007 After SMTP Downgrading MAIL From: RCPT TO: ------------------------------------------------------------- Envelope-Downgraded: From: Envelope-Downgraded: To: 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 4: SMTP Downgraded UTF8SMTP message After SMTP downgrading, header downgrading is performed. Final downgraded messages are shown in Figure 5. Result of the header downgrading. Downgraded: Envelope-Downgraded: From: MIME() Downgraded: Envelope-Downgraded: To: MIME() 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(>) To: Date: DATE MAIL_BODY YONEYA & Fujiwara Expires September 6, 2007 [Page 12] Internet-Draft UTF8SMTP Downgrade Mar 2007 Figure 5: Header downgraded message MIME() stands for [RFC2047] encoding. A.2. Upgrading example This example shows upgrading process of Figure 5. First, check 'Downgraded:' header existence. The UTF8SMTP downgraded message has 'Downgraded:' headers. Select 'Downgraded:' headers. Downgraded: Envelope-Downgraded: From: MIME() Downgraded: Envelope-Downgraded: To: MIME() Downgraded: From: MIME(>) Downgraded: To: MIME(>) Downgraded: CC: MIME(>) Figure 6: Upgrading: selecting Downgraded headers This example has five Downgraded headers. Decode 'Downgraded:' headers. Envelope-Downgraded: From: Envelope-Downgraded: To: From: > To: > CC: > Figure 7: Upgrading: upgraded Downgraded headers Apply address header downgrading to the decoded header. From: To: CC: Figure 8: Upgrading: downgraded upgraded Downgraded headers YONEYA & Fujiwara Expires September 6, 2007 [Page 13] Internet-Draft UTF8SMTP Downgrade Mar 2007 Remove the header line which is the same with the downgraded line. Downgraded: Envelope-Downgraded: From: MIME() Downgraded: Envelope-Downgraded: To: MIME() 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 Decode each 'Downgraded' header and replace it with its decoded header. If each mail header has [RFC2047] encoded part and which encoding is "UTF-8", it is a downgraded header, so decode it. Envelope-Downgraded: From: Envelope-Downgraded: To: 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 10: Downgraded header upgraded message As a result, in this simple example, all headers are preserved. YONEYA & Fujiwara Expires September 6, 2007 [Page 14] Internet-Draft UTF8SMTP Downgrade Mar 2007 A.3. Downgrading example 2 In many cases, the sender wants to use Non-ASCII address and the recipient does not support UTF8SMTP and does not have Non-ASCII address. o The sender address is "NON-ASCII-FROM" which is Non-ASCII address. Its ASCII alternative is "ASCII-FROM". o The "To" address is "ASCII-TO" which is ASCII only. o The Subject header is "UTF8-SUBJECT" which contains Non-ASCII characters. Original UTF8SMTP message SMTP session MAIL From: ALT-ADDRESS RCPT TO: ------------------------------------------------------------- Message-Id: MESSAGE_ID Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Subject: UTF8-SUBJECT From: > To: Date: DATE MAIL_BODY Figure 11: Original UTF8SMTP message 2 In this example, SMTP session is downgradable. Figure 12 shows SMTP downgrading. YONEYA & Fujiwara Expires September 6, 2007 [Page 15] Internet-Draft UTF8SMTP Downgrade Mar 2007 After SMTP Downgrading MAIL From: RCPT TO: ------------------------------------------------------------- Envelope-Downgraded: From: Message-Id: MESSAGE_ID Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Subject: UTF8-SUBJECT From: > To: Date: DATE MAIL_BODY Figure 12: SMTP Downgraded UTF8SMTP message 2 After SMTP downgrading, header downgrading is performed. Final downgraded messages are shown in Figure 13. Result of the header downgrading. Downgraded: Envelope-Downgraded: From: MIME() 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: To: Date: DATE MAIL_BODY Figure 13: Header downgraded message 2 This downgraded message's header part contains ASCII characters only. But it still contains MIME encapsulated subject header which contains UTF-8 characters. And more, the body part contains UTF-8 message. "ascii user" needs to accept UTF-8 mail body and UTF-8 subject which YONEYA & Fujiwara Expires September 6, 2007 [Page 16] Internet-Draft UTF8SMTP Downgrade Mar 2007 is MIME encoded. 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 September 6, 2007 [Page 17] Internet-Draft UTF8SMTP Downgrade Mar 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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, THE IETF TRUST 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 September 6, 2007 [Page 18]