Email Address Internationalization                        Y. YONEYA, Ed.
(EAI)                                                   K. Fujiwara, Ed.
Internet-Draft                                                      JPRS
Intended status: Experimental                               Aug 16, 2006                                Mar 5, 2007
Expires: February 17, September 6, 2007

      Downgrading mechanism for Email Address Internationalization (EAI)
                    draft-ietf-eai-downgrade-02.txt
                    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 February 17, September 6, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006). IETF Trust (2007).

Abstract

   Traditional mail systems handle only US-ASCII characters in SMTP
   envelope and mail headers. header fields.  The Email Address
   Internationalization
   (EAI) is implemented by allowing UTF-8 characters in
   SMTP envelope and mail headers. header fields (UTF8SMTP).  To deliver Non-ASCII Non-
   ASCII mail address through EAI
   incompliant via UTF8SMTP non-compliant environment, some sort
   of converting mechanism (i.e. downgrading) is required.  This
   document describes requirements for downgrading, SMTP Downgrading, SMTP DATA/Header Downgrading downgrading,
   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.  SMTP Downgrading .  Downgraded header  . . . . . . . . . . . . . . . . . . . . . .  4
   5.  SMTP DATA/Header Downgrading . . . . . . . . . . . . . . . . .  5
     5.1.  Header conversion  . . . . . . . . .  5
   6.  Email header Downgrading . . . . . . . . . . .  6
       5.1.1.  Downgrading address headers . . . . . . . .  6
     6.1.  Downgrading address headers  . . . . .  7
   6.  Implementation consideration . . . . . . . . . .  7
   7.  Upgrading downgraded header  . . . . . . .  8
     6.1.  MUA . . . . . . . . . .  7
   8.  Implementation consideration . . . . . . . . . . . . . . . . .  8
   7.
   9.  Security considerations  . . . . . . . . . . . . . . . . . . .  8
   8.
   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
   9.
   11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  8
   10.
   12. Change History . . . . . . . . . . . . . . . . . . . . . . . .  8
     10.1.  9
     12.1. draft-yoneya-ima-downgrade: Version 00 . . . . . . . . . .  8
     10.2.  9
     12.2. draft-yoneya-ima-downgrade: Version 01 . . . . . . . . . .  9
     10.3.
     12.3. draft-ietf-eai-downgrade: Version 00 . . . . . . . . . . .  9
     10.4.
     12.4. draft-ietf-eai-downgrade: Version 01 . . . . . . . . . . .  9
     10.5.
     12.5. draft-ietf-eai-downgrade: Version 02 . . . . . . . . . . .  9
   11.
     12.6. draft-ietf-eai-downgrade: Version 03 . . . . . . . . . . .  9
   13. Normative References . . . . . . . . . . . . . . . . . . . . .  9 10
   Appendix A.  Examples  . . . . . . . . . . . . . . . . . . . . . . 10
     A.1.  SMTP  Downgrading Example example 1  . . . . . . . . . . . . . . . . . . 10
     A.2.  Header conversion downgrading  Upgrading example  . . . . . . . . . . 12 . . . . . . . . . . 13
     A.3.  Header conversion upgrading  Downgrading example 2  . . . . . . . . . . . 13 . . . . . . . 15
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 17
   Intellectual Property and Copyright Statements . . . . . . . . . . 17 18

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. header field
   bodies.  The EAI 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 headers in body part. header field bodies.

   Carrying Non-ASCII mail address from sender to recipients requires
   all components on the mail delivery route are EAI 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 UTF-8 Non-ASCII characters in mail headers header fields
   MUST be converted to US-ASCII.

   Downgrading in EAI UTF8SMTP consists from following two parts:
   o  SMTP Downgrading
   o  SMTP DATA/Header  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 is are described in
   section
   Section 3, SMTP Downgrading is described in Section 4, 5, and
   SMTP DATA/Header Email
   header Downgrading is described in Section 5. 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.

   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 non-ASCII characters are
      included in the SMTP envelope or mail headers header fields 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
   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 should be performed only once.
   2.  Upgrading must  "Upgrading MUST be performed (if at minimized place such as final
       destination like 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. 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 must should support SPF and DKIM.
   8.  Downgrading occurrence must should 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  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
   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
   all-ASCII
   US-ASCII address or the address has all-ASCII 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. 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 EAI incompliant. UTF8SMTP non-compliant.

   Even if no downgrading is performed for envelope from/to, MUA/MTA
   MUST downgrade mail headers header fields including UTF-8 non-ASCII characters or
   bounce.  This is described in next section. Section 6.

   Downgrading MTA replaces Non-ASCII mail address with specified
   alternative US-
   ASCII US-ASCII address.  Then appends replaced  Also MTA preserves original
   information with EAI-
   Downgraded-From: and EAI-Downgraded-To: using "Envelope-Downgraded" header defined in mail header
   (outgoing SMTP DATA).

   EAI-Downgraded-From:  <Non-ASCII {US-ASCII}> <US-ASCII>
   EAI-Downgraded-To:  <Non-ASCII {US-ASCII}> <US-ASCII> Section 4
   with From or To field name.

   Envelope-Downgraded: From:  <Non-ASCII-FROM> <US-ASCII-FROM>
   Envelope-Downgraded: To:  <Non-ASCII-TO> <US-ASCII-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: "Envelope-Downgraded:" headers, MUA/MTA
   MUST perform SMTP DATA/Header Downgrading.  This is Email header Downgrading described in next
   section. 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 domainname domain name of the envelope from and SMTP connection IP
   address.  If ALT-ADDRESS domainname 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.

   NOTE: ORCPT

   ESMTP ORCPT parameter is used

6.  Email header Downgrading

   This section defines conversion method to US-ASCII for Delivery Status Notifications
   (DSNs) [RFC3461].  ORCPT parameters each header
   which may 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 characters.  If the whole 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 header
   does not contain Non-ASCII mail addresses.

   other headers:  UTF-8 in other headers MUST be target of downgrading.
   UTF8SMTP header:  Identification of internationalized characters, 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  Otherwise, email header downgrading checks each header
   whether it contains UTF-8 characters or not.  If the header contains
   UTF-8 characters,
         +  If convert the header is an address header which is described in
            Section 5.1.1,
            -  Preserve the header in 'Downgraded' a suitable method for of each
   header.
            -  Downgrade the  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 Section 5.1.1.
         +  The other [I-D.ietf-eai-utf8headers].
      If the header case, 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.
      *  Change 'UTF8SMTP' header value to "Downgraded".
   Upgrading:
      *  Check if the mail has 'UTF8SMTP' header tag and its value is
         "Downgraded".
      replace it.
      Otherwise, upgrading is not required.
      *  Decode all 'Downgraded' headers.
         +  Decode header value field string which is [RFC2047] encoded.
         +  If preserve the header is address in "Downgraded:" header described and
      generate US-ASCII only header defined in Section 5.1.1,
            -  Apply address header downgrading to the decoded header.
            -  Remove 6.1, replace the
      original header line which is the same with the
               downgraded line.
         +  Remove the 'Downgraded' generated US-ASCII only header.
         +  Add decoded  When
      this address header to mail header.
      *  If each downgrading fails, this downgrading fails and
      the mail MUST be bounced.

   Subject:
      Encode the header has by [RFC2047] encoded part with UTF-8 tag and which
         encoding is "UTF-8", it is a downgraded header, so decode replace it.
      *  Change 'UTF8SMTP' header value to "UTF8".

   Followings are pros
   Message-ID:, Date:, In-Reply-To:
      "ID"s and cons of this method.

   Pros:
      *  EAI incompliant MUA displays "Date"s does not contain UTF-8 characters.
   Received:
      If the downgraded mail body except
         original Non-ASCII mail addresses.

      *  EAI incompliant MUA displays and handles FOR clause contains UTF-8 addresses, 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 header must parse each be
      downgraded.  In this case, preserve the header in "Downgraded:"
      header and encode
         it by defined method.
      *  Hard to preserve whole information AS IS.  The address headers
         are preserved but remove 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 FOR clause in the
         downgraded headers is not guaranteed.  Therefore, to check DKIM
         requires special consideration.

   [[Reference to [I-D.ietf-eai-scenarios] header.
   other headers:
      All other headers which contains UTF-8 characters are preserved in
      Downgraded: header and evaluation of each case removed.

   Downgraded headers should be described here.]]

5.1.1. inserted or replaced at the same
   position of the original header.

6.1.  Downgrading address headers

   This section procedure targets From:, Sender:, Reply-To:, To:, CC:, Bcc:,
   Resent-From:, Resent-To:, Resent-CC:, Resent-Bcc:, Resent-sender: "From:", "To:", "CC:", "Reply-To:", "Return-
   Path:" 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. each 'mailbox'/'angle-
       addr'/'utf8-addr-spec'.

       If all header field the Non-ASCII address is removed, remove in utf8-addr-spec form, then the header.
   4.  If From
       header downgrading fails because the form has no alt-address.

       "mailbox" is removed, generate new From: header from
       envelope-from address.

   EAI 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>
           US-ASCII mail address case, preserve it. is used as is.
       2.  <Non-ASCII>
          Non-ASCII mail address without ALT-ADDRESS parameter case,
          remove
           This email header downgrading fails because this angle-addr. header is
           not downgradable.
       3.  <Non-ASCII {US-ASCII}>  <Non-ASCII<US-ASCII>>
           Non-ASCII mail address with sender-specified US-ASCII address
          case, replace it
           is replaced as <US-ASCII>.

   "mailbox"

7.  Upgrading downgraded header

   Upgrading downgraded header is defined as "DISPLAY NAME angle-addr" described below:
   o  Check if the mail header contains 'Downgraded:' headers.
      Otherwise, upgrading is not required.

   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
   [I-D.ietf-eai-utf8headers].  The "DISPLAY NAME" field should be
   encoded by [RFC2047]
         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 UTF-8 tag, if necessary. the generated
            ASCII only header.  (REQUIRE HEADER NORMALIZATION)
      *  If the angle-addr decoded header is a "Received:" header,
         +  Removing the 'FOR' clause from the decoded header generates
            ASCII only header.
         +  Remove the header line which is removed, remove the field including "DISPLAY NAME".

6. 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

6.1.  MUA

   EAI

   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.

   EAI

   UTF8SMTP compliant MUA MUST upgrade downgraded mail and MUST show Non-
   ASCII
   Non-ASCII mail addresses on display.

7.

9.  Security considerations

   See the extended security considerations discussion "Security considerations" section in [I-D.ietf-eai-framework]

8. for
   more discussion.

10.  IANA Considerations

   IANA is requested to add the "EAI-Downgraded-From:",
   "EAI-Downgraded-To:" "Envelope-Downgraded:", and
   "Downgraded:" new headers to the registry with the entries pointing
   to this specification for its definition.

9.

11.  Acknowledgements

   John Klensin, Harald Alvestrand, Chris Newman, Charles Lindsey,
   Marcos Sanz, Alexey Melnikov and JET members.

10.

12.  Change History

   This section is used for tracking the update of this document.  Will
   be removed after finalize.

10.1.

12.1.  draft-yoneya-ima-downgrade: Version 00

   o  Initial version
   o  Fllowed  Followed draft-yeh-ima-utf8headers-00 and draft-yao-smtpext-00

10.2.

12.2.  draft-yoneya-ima-downgrade: Version 01

   o  Document structure was changed
   o  Fllowed  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

10.3.

12.3.  draft-ietf-eai-downgrade: Version 00

   o  Fllowed  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

10.4.

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

10.5.

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

11.

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

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-01 draft-ietf-eai-framework-05
              (work in progress), June 2006. 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-01 draft-ietf-eai-smtpext-03 (work in
              progress), July 2006. February 2007.

   [I-D.ietf-eai-utf8headers]
              Yeh, J., "Internationalized Email Headers",
              draft-ietf-eai-utf8headers-01
              draft-ietf-eai-utf8headers-03 (work in progress),
              August 2006.
              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.  SMTP  Downgrading Example example 1

   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
      Its ASCII alternative address. address is "ASCII-CC".
   o  The Subject header is "UTF8-Subject" "UTF8-SUBJECT" which contains Non-ASCII
      characters.

   Original EAI UTF8SMTP message SMTP session

   MAIL From: <NON-ASCII-FROM> ALT-ADDRESS <ASCII-FROM>
   RCPT TO: <NON-ASCII-TO> ALT-ADDRESS <ASCII-TO>
   RCPT TO: <NON-ASCII-CC> ALT-ADDRESS <ASCII-CC>
   -------------------------------------------------------------
   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: <NON-ASCII-FROM {ASCII-FROM}> <NON-ASCII-FROM<ASCII-FROM>>
   To: <NON-ASCII-TO {ASCII-TO}> <NON-ASCII-TO<ASCII-TO>>
   CC: <NON-ASCII-CC> <NON-ASCII-CC<ASCII-CC>>
   Date: DATE

   MAIL_BODY

                    Figure 1: 3: Original EAI UTF8SMTP 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  Both sessions are downgradable.  Figure 4 shows To: session can be downgraded
   to the next example Figure 2.
   downgrading.

   After SMTP Downgrading

   MAIL From: <ASCII-FROM>
   RCPT TO: <ASCII-TO>
   -------------------------------------------------------------
   EAI-Downgraded-From: <NON-ASCII-FROM {ASCII-FROM}>
   Envelope-Downgraded: From: <NON-ASCII-FROM> <ASCII-FROM>
   EAI-Downgraded-To: <NON-ASCII-TO {ASCII-TO}>
   Envelope-Downgraded: To: <NON-ASCII-TO> <ASCII-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: <NON-ASCII-FROM {ASCII-FROM}> <NON-ASCII-FROM<ASCII-FROM>>
   To: <NON-ASCII-TO {ASCII-TO}> <NON-ASCII-TO<ASCII-TO>>
   CC: <NON-ASCII-CC> <NON-ASCII-CC<ASCII-CC>>
   Date: DATE

   MAIL_BODY

                Figure 2: 4: 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: <NON-ASCII-FROM {ASCII-FROM}>
   To: <NON-ASCII-TO {ASCII-TO}>
   CC: <NON-ASCII-CC>
   Date: DATE

   MAIL_BODY

                      Figure 3: Original EAI UTF8SMTP message

   After SMTP Downgrading adds EAI-Downgraded-From: and EAI-Downgraded-To:
   headers.

   EAI-Downgraded-From: <Non-ASCII {DOWNGRADED_FROM}> <DOWNGRADED_FROM>
   EAI-Downgraded-To: <Non-ASCII {DOWNGRADED_TO}> <DOWNGRADED_TO> downgrading, header downgrading is performed.  Final
   downgraded messages are shown in Figure 4: Headers added by SMTP Downgrading 5.

   Result of the header conversion downgrading.

   EAI-Downgraded-From:
       MIME(<Non-ASCII {DOWNGRADED_FROM}) <DOWNGRADED_FROM>
   EAI-Downgraded-To:
       MIME(<Non-ASCII {DOWNGRADED_TO}) <DOWNGRADED_TO>
   UTF8SMTP: Downgraded

   Downgraded: Envelope-Downgraded: From:
               MIME(<NON-ASCII-FROM>) <ASCII-FROM>
   Downgraded: Envelope-Downgraded: To:
               MIME(<NON-ASCII-TO>) <ASCII-TO>
   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(<NON-ASCII-FROM {ASCII-FROM}>) MIME(<NON-ASCII-FROM<ASCII-FROM>>)
   From: <ASCII-FROM>
   Downgraded: To: MIME(<NON-ASCII-TO {ASCII-TO}>) MIME(<NON-ASCII-TO<ASCII-TO>>)
   To: <ASCII-TO>
   Downgraded: CC: MIME(<NON-ASCII-CC>) MIME(<NON-ASCII-CC<ASCII-CC>>)
   To: <ASCII-CC>
   Date: DATE

   MAIL_BODY
                    Figure 5: Header conversion downgraded message

   MIME() stands for [RFC2047] encoding.

A.3.  Header conversion upgrading

A.2.  Upgrading example

   This example shows upgrading process of Figure 5.

   First, check 'UTF8SMTP:' header.  Its value is "Downgraded", it is
   EAI 'Downgraded:' header existence.  The UTF8SMTP downgraded message.

   Decode all
   message has 'Downgraded:' headers.

   Select 'Downgraded:' headers.

   Downgraded: Envelope-Downgraded: From:
               MIME(<NON-ASCII-FROM>) <ASCII-FROM>
   Downgraded: Envelope-Downgraded: To:
               MIME(<NON-ASCII-TO>) <ASCII-TO>
   Downgraded: From: MIME(<NON-ASCII-FROM {ASCII-FROM}>) MIME(<NON-ASCII-FROM<ASCII-FROM>>)
   Downgraded: To: MIME(<NON-ASCII-TO {ASCII-TO}>) MIME(<NON-ASCII-TO<ASCII-TO>>)
   Downgraded: CC: MIME(<NON-ASCII-CC>) MIME(<NON-ASCII-CC<ASCII-CC>>)

             Figure 6: Upgrading: selecting Downgraded headers

   This example has five Downgraded headers.

   Decode header value field string which is [RFC2047] encoded. 'Downgraded:' headers.

   Envelope-Downgraded: From: <NON-ASCII-FROM {ASCII-FROM}> <NON-ASCII-FROM> <ASCII-FROM>
   Envelope-Downgraded: To: <NON-ASCII-TO> <ASCII-TO>
   From: <NON-ASCII-FROM<ASCII-FROM>>
   To: <NON-ASCII-TO {ASCII-TO}> <NON-ASCII-TO<ASCII-TO>>
   CC: <NON-ASCII-CC> <NON-ASCII-CC<ASCII-CC>>

             Figure 7: Upgrading: upgraded Downgraded headers

   Apply address header downgrading to the decoded header.

   From: <ASCII-FROM>
   To: <ASCII-TO>
   CC: <ASCII-CC>

        Figure 8: Upgrading: downgraded upgraded Downgraded headers
   Remove the header line which is the same with the downgraded line.

   EAI-Downgraded-From:
       MIME(<Non-ASCII {DOWNGRADED_FROM}) <DOWNGRADED_FROM>
   EAI-Downgraded-To:
       MIME(<Non-ASCII {DOWNGRADED_TO}) <DOWNGRADED_TO>
   UTF8SMTP: Downgraded

   Downgraded: Envelope-Downgraded: From:
               MIME(<NON-ASCII-FROM>) <ASCII-FROM>
   Downgraded: Envelope-Downgraded: To:
               MIME(<NON-ASCII-TO>) <ASCII-TO>
   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(<NON-ASCII-FROM {ASCII-FROM}>) MIME(<NON-ASCII-FROM<ASCII-FROM>>)
   Downgraded: To: MIME(<NON-ASCII-TO {ASCII-TO}>) MIME(<NON-ASCII-TO<ASCII-TO>>)
   Downgraded: CC: MIME(<NON-ASCII-CC>) MIME(<NON-ASCII-CC<ASCII-CC>>)
   Date: DATE

   MAIL_BODY

             Figure 9: Upgrading: Removing duplicated headers

   Remove the

   Decode each 'Downgraded' header and add replace it with its decoded Downgraded headers
   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".

   EAI-Downgraded-From: <Non-ASCII {DOWNGRADED_FROM}> <DOWNGRADED_FROM>
   EAI-Downgraded-To: <Non-ASCII {DOWNGRADED_TO}> <DOWNGRADED_TO>
   UTF8SMTP: UTF8

   Envelope-Downgraded: From: <NON-ASCII-FROM> <ASCII-FROM>
   Envelope-Downgraded: To: <NON-ASCII-TO> <ASCII-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: <NON-ASCII-FROM {ASCII-FROM}> <NON-ASCII-FROM<ASCII-FROM>>
   To: MIME(<NON-ASCII-TO {ASCII-TO}> <NON-ASCII-TO<ASCII-TO>>
   CC: MIME(<NON-ASCII-CC> <NON-ASCII-CC<ASCII-CC>>
   Date: DATE

   MAIL_BODY

               Figure 10: Header conversion Downgraded header upgraded message

   As a result, in this simple example, all headers are preserved.

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: <NON-ASCII-FROM> ALT-ADDRESS <ASCII-FROM>
   RCPT TO: <ASCII-TO>
   -------------------------------------------------------------
   Message-Id: MESSAGE_ID
   Mime-Version: 1.0
   Content-Type: text/plain; charset="UTF-8"
   Content-Transfer-Encoding: 8bit
   Subject: UTF8-SUBJECT
   From: <NON-ASCII-FROM<ASCII-FROM>>
   To: <ASCII-TO>
   Date: DATE

   MAIL_BODY

                  Figure 11: Original UTF8SMTP message 2

   In this example, SMTP session is downgradable.  Figure 12 shows SMTP
   downgrading.

   After SMTP Downgrading

   MAIL From: <ASCII-FROM>
   RCPT TO: <ASCII-TO>
   -------------------------------------------------------------
   Envelope-Downgraded: From: <NON-ASCII-FROM> <ASCII-FROM>
   Message-Id: MESSAGE_ID
   Mime-Version: 1.0
   Content-Type: text/plain; charset="UTF-8"
   Content-Transfer-Encoding: 8bit
   Subject: UTF8-SUBJECT
   From: <NON-ASCII-FROM<ASCII-FROM>>
   To: <ASCII-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(<NON-ASCII-FROM>) <ASCII-FROM>
   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(<NON-ASCII-FROM<ASCII-FROM>>)
   From: <ASCII-FROM>
   To: <ASCII-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
   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

Full Copyright Statement

   Copyright (C) The Internet Society (2006). 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 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).