Network Working Group                                     Y. YONEYA, Ed.
Internet-Draft                                          K. Fujiwara, Ed.
Expires: September 7, 2006                                          JPRS
                                                           March 6, 2006

    Downgrading mechanism for Internationalized eMail Address (IMA)

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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on September 7, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).


   Traditional mail system handles only US-ASCII characters in SMTP
   envelope and mail headers.  The Internationalized eMail Address (IMA)
   is implemented by allowing UTF-8 characters in SMTP envelope and mail
   headers.  To deliver IMA through IMA incompliant environment, some
   sort of converting mechanism (i.e. downgrading) is required.  This
   document describes requirements for downgrading, SMTP session
   downgrade, header downgrade and implementation consideration.

YONEYA & Fujiwara       Expires September 7, 2006               [Page 1]

Internet-Draft                IMA Downgrade                   March 2006

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Downgrade Requirements . . . . . . . . . . . . . . . . . . . .  4
     3.1.  Timing and conditions of downgrading . . . . . . . . . . .  4
     3.2.  Mail Header Downgrading  . . . . . . . . . . . . . . . . .  4
     3.3.  Requirements . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  SMTP Downgrading . . . . . . . . . . . . . . . . . . . . . . .  5
   5.  SMTP DATA/Header downgrading . . . . . . . . . . . . . . . . .  6
     5.1.  Downgrading with MIME encapsulation  . . . . . . . . . . .  6
     5.2.  Header conversion  . . . . . . . . . . . . . . . . . . . .  8
   6.  Implementation consideration . . . . . . . . . . . . . . . . .  8
     6.1.  MUA  . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     6.2.  MDA Requirements . . . . . . . . . . . . . . . . . . . . .  9
   7.  Security considerations  . . . . . . . . . . . . . . . . . . .  9
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
   10. Normative References . . . . . . . . . . . . . . . . . . . . .  9
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
   Intellectual Property and Copyright Statements . . . . . . . . . . 13

YONEYA & Fujiwara       Expires September 7, 2006               [Page 2]

Internet-Draft                IMA Downgrade                   March 2006

1.  Introduction

   Traditional mail system which is defined by [RFC2821] and [RFC2822]
   allows US-ASCII characters in SMTP envelop and mail headers.  IMA
   proposal [IMA-Framework],[IMA-UTF8], [IMA-SMTPext] allows UTF-8
   characters in SMTP envelop and mail headers.

   Carrying IMA from sender to recipients requires all components on the
   mail delivery route are IMA compliant.  Otherwise IMA can't be
   delivered.  To solve the problem, this document describes downgrade
   mechanism that enables delivering IMA by converting it to
   corresponding US-ASCII representation on current mail delivery
   system.  Not only SMTP envelope, but also UTF-8 in mail headers MUST
   be converted to US-ASCII.

   Converting IMA to US-ASCII SHOULD base on algorithmic method which is
   proposed by [IMA-SMTPext].

   Downgrading in IMA consists from following two parts:
   o  SMTP session downgrade
   o  header downgrade

   In this document, requirements for downgrading is described in
   section Section 3, SMTP session downgrade is described in Section 4,
   and header downgrade is described in Section 5.

2.  Terminology

   This document assumes a reasonable understanding of the protocols and
   terminology of the core email standards as documented in [RFC2821]
   and [RFC2822].

   Much of the description in this document depends on the abstractions
   of "Mail Transfer Agent" ("MTA") and "Mail User Agent" ("MUA").
   However, it is important to understand that those terms and the
   underlying concepts postdate the design of the Internet's email
   architecture and the "protocols on the wire" principle.  That email
   architecture, as it has evolved, and the "wire" principle have
   prevented any strong and standardized distinctions about how MTAs and
   MUAs interact on a given origin or destination host (or even whether
   they are separate).

   The final ("delivery") MTA stores Mail messages in a "message store"
   or resends messages where the receiver has assigned.  In this
   document, this function is called Mail Delivery Agent(MDA).

   In this document, an address is "all-ASCII" if every character in the

YONEYA & Fujiwara       Expires September 7, 2006               [Page 3]

Internet-Draft                IMA Downgrade                   March 2006

   address is in the ASCII character repertoire [ASCII]; an address is
   "non-ASCII" if any character is not in the ASCII character
   repertoire.  The term "all-ASCII" is also applied to other protocol
   elements when the distinction is important, with "non-ASCII" or
   "internationalized" as its opposite.

   The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED",
   and "MAY" in this document are to be interpreted as described in RFC
   2119 [RFC2119].

3.  Downgrade Requirements

3.1.  Timing and conditions of downgrading

   This section describes timing and conditions of downgrading.
   o  Timing: SMTP client detects SMTP server doesn't support "IEmail"
      option at EHLO.  [IMA-SMTPext]
   o  Conditions: SMTP client detects UTF-8 is included in SMTP envelope
      or mail headers.

   Note that SMTP client SHOULD check headers in outgoing SMTP DATA
   whether they include 8bit (UTF-8) data.

3.2.  Mail Header Downgrading

   Target of downgrading elements in mail headers (SMTP data) are below:

   Originator address(es): IMA in From, Reply-To and Sender and their
      Resent- headers MUST be target of downgrading.
   Destination address(es): IMA in To and Cc and their Recent- headers
      MUST be target of downgrading.
   IDs: IDs such as Message-ID, In-Reply-To and Referenece MUST NOT be
      target of downgrading.
   other headers: UTF-8 in other headers such as Subject and Received
      SHOULD be target of downgrading.

3.3.  Requirements

   1.  Downgrading MUST be performed only once.
   2.  Upgrading MUST be performed at minimized place such as final
       destination like receipient MUA.
   3.  Downgrading and upgrading MUST be automated.
   4.  Downgrading and upgrading MUST be easy and lightweight as it is
       possible to do with MTA like 8BITMIME encapsulation.
   5.  Downgrade and upgrade method MUST be defined clearly.

YONEYA & Fujiwara       Expires September 7, 2006               [Page 4]

Internet-Draft                IMA Downgrade                   March 2006

   6.  Downgrading and upgrading MUST preserve all header information.
   7.  Downgrading MUST support sender authentication header checking
       such as SPF and DomainKeys/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-ADDR and ATOMIC option proposed
   in [IMA-SMTPext].

   MUA of mail sender MUST append ALT-ADDR or ATOMIC option to all
   envelope from (MAIL FROM) and envelope to (RCPT TO) to denote
   alternative US-ASCII address when sending mail.

   When MUA/MTA is transfering mail and finds its envelope is IMA, it
   MUST decide to bounce or downgrade if receiving MTA is IMA

   Further, even if no downgrading is performed for envelope from/to,
   MUA/MTA SHOULD downgrade headers including UTF-8.  This is described
   in next session.

   MTA MAY downgrade messages that envelope from/to of IMA have ALT-ADDR
   with alternative US-ASCII address or ATOMIC is "y".

   MTA generates alternative US-ASCII address when ALT-ADDR option is
   not specified and ATOMIC is "y".

   Alternative US-ASCII address generation algorithms are below:
   domain-part: Punycode/IDNA
   local-part: Punycode without normalization.  Prefix MUST be assigned
      by IANA (which is not "xn--").

   MTA replaces IMA with specified or generated alternative US-ASCII
   address.  Then appends replaced information with IMA-Downgraded-From
   and IMA-Downgraded-To header in mail header (outgoing SMTP DATA).
      IMA-Downgraded-From: <IMA> <US-ASCII>
      IMA-Downgraded-To: <IMA> <US-ASCII>

   Note that when downgrading, not to disclose whole recipient address,
   MUA/MTA SHOULD make SMTP connection per each receipient address.

YONEYA & Fujiwara       Expires September 7, 2006               [Page 5]

Internet-Draft                IMA Downgrade                   March 2006

   Also note that by appending IMA-Downgraded-From/To headers, MUA/MTA
   MUST perform SMTP/Header downgrading.  This is described in next

   Downgraded envelope to is parsed only in MDA and delived to final

   Case study: SPF check

   SPF checks envelope from's domainname and smtp connection IP address.
   If ALT-ADDR's domainname is Punycode/IDNA of IMA domainname, it is
   equal to SPF/IMA (need to define).  In this case, SPF check will be
   performed correctly.  Otherwise, more detailed consideration is

5.  SMTP DATA/Header downgrading

   In this section, two methods for SMTP DATA/Header downgrading is
   proposed.  One is to encapsulate whole data, and other is to
   translate header by header.

5.1.  Downgrading with MIME encapsulation

   This downgrade method requires new MIME 'Content-Type:' which express
   EAI(Email Address Internationalization).  This document assumes
   'Content-Type: Message/EAI' existence.

      *  If mail header contains UTF-8 data, downgrade whole message to
         be MIME encoded.  Whole message becomes new MIME part (Message/
      *  Originator Addresses (From, Sender, etc.), Destination
         Addresses (To, CC, etc.), IDs (Message-ID, etc.), Subject, Date
         headers are copied from original header.
      *  If From header contains IMA, it is replaced with downgraded
      *  If To or CC headers contain IMA, they are replaced with single
         downgraded envelope-to as To header.
      *  If Subject header contains UTF-8, it is rewrited to a certain
         message or encoded by RFC2047.
      *  Message-ID, Date headers are preserved.
      As a result, new body contains one MIME part (Message/EAI).

YONEYA & Fujiwara       Expires September 7, 2006               [Page 6]

Internet-Draft                IMA Downgrade                   March 2006

      Encoding example

   Message-Id: MESSAGE_ID
   Mime-Version: 1.0
   Content-Type: Multipart/Mixed;
   Content-Transfer-Encoding: 8bit
   Date: DATE

   Content-Type: Message/EAI
   Content-Transfer-Encoding: 8bit
   Content-Disposition: inline

   IMA-Downgraded-From: <IMA> <DOWNGRADED_FROM>
   IMA-Downgraded-To: <IMA> <DOWNGRADED_TO>
   Received: ...
   Received: ...
   Message-Id: MESSAGE_ID
   Mime-Version: 1.0
   Subject: UTF-8_SUBJECT
   From: IMA
   To: IMA
   Date: DATE



      Figure 1

      *  If mail message contains only one MIME part and its Content-
         Type is 'Message/EAI', it may be downgraded.  To check if
         downgraded, compare mail body's message-id and MIME part's
         message-id.  If message-ids are same, it is downgraded message.
         Then, treat MIME part as entire mail message.
      *  When checking trace field, checker SHOULD check Received header
         both in wrapping headers and headers in encapsulated part.

   Case study: DomainKeys/DKIM

   DomainKeys/DKIM checker performs upgrade/decode downgraded message

YONEYA & Fujiwara       Expires September 7, 2006               [Page 7]

Internet-Draft                IMA Downgrade                   March 2006

      *  MTA does not need to decode each headers carefully.
      *  Whole headers can be submitted AS IS.
      *  IMA from/to can not distinguish from encoded mail headers.
      *  IMA incompliant MUA can not treat encoded message.

5.2.  Header conversion

   Define conversion method to US-ASCII for all headers which contains

   Each header has its own downgrading method.  Basically, MIME encoding
   of RFC 2047.  Receipient/Sender addresses and Received headers which
   may contain IMA need special processing.

   Downgrading mail addresses in mail header: Extract every addr-spec
      [RFC2822] of mailboxes from mail headers including UTF-8.  For
      each addr-spec, if it includes UTF-8, convert it into ACE with the
      same method described in Section 4.  Original IMA SHOULD remain as
      a comment encoded by base64 of MIME with UTF-8 tag.  Note that
      some special characters in addr-spec MUST be escaped.  If mailbox
      elements except for addr-spec include UTF-8, those MUST be encoded
      by base64 with UTF-8 tag.
   Downgrading other data: Encode UTF-8 part of headers by base64 of
      MIME with UTF-8 tag.

      *  IMA incompliant MUA can display mail body except for original
         IMA from/to.
      *  Implementation is difficult because MUA/MTA must parse each
         header and encode it by defined method.
      *  Hard to preserve whole information AS IS.  Therefore, to check
         DomainKeys/DKIM requires special consideration.

6.  Implementation consideration

6.1.  MUA

   IMA compliant MUA MUST implement downgrade mechanism for sending.

   MUA MAY encode UTF-8 in Subject header with the same encoding of body
   part while downgrading.

   IMA compliant MUA MUST decode downgraded mail and MUST show IMA on

YONEYA & Fujiwara       Expires September 7, 2006               [Page 8]

Internet-Draft                IMA Downgrade                   March 2006

6.2.  MDA Requirements

   This section describes downgrading in MDA.
   1.  MDA MUST NOT convert downgraded header to UTF-8.
   2.  Record Return-Path header in ACE form.
   3.  Perform downgrading for each Storage/Back-end-Process.  If and
       only if MDA knows MUA is IMA compliant, then no downgrading is
   4.  If MDA detects that SMTP recipient address is downgraded IMA,
       then MDA MUST decode IMA and perform the same processing as if it
       were IMA.  MDA MAY normalize or canonicalize local-part before
       processing it.

7.  Security considerations

   See the extended security considerations discussion in [IMA-

8.  IANA Considerations

   To distinguish downgraded IMA in ACE form, it MUST have ACE-Prefix.
   The ACE-Prefix MUST be differ from IDNA ACE-Prefix to avoid possible
   confusion.  IANA will assign IMA ACE-Prefix when RFC is published.

9.  Acknowledgements

   John Klensin, Harald Alvestrand, Yangwoo Ko, YAO Jiankang, Jeff Yeh,
   James Seng and JET members.

10.  Normative References

   [ASCII]    American National Standards Institute (formerly United
              States of America Standards Institute), "USA Code for
              Information Interchange", ANSI X3.4-1968, 1968.

              ANSI X3.4-1968 has been replaced by newer versions with
              slight modifications, but the 1968 version remains
              definitive for the Internet.

              Hoffman, P. and A. Costello, "Internationalizing Mail
              Addresses in Applications (IMAA)", draft-hoffman-imaa-03
              (work in progress), October 2003.


YONEYA & Fujiwara       Expires September 7, 2006               [Page 9]

Internet-Draft                IMA Downgrade                   March 2006

              Klensin, J., "Internationalization in Internet
              Applications: Issues, Tradeoffs, and Email Addresses",
              draft-klensin-ima-constraints-00 (work in progress),
              Febrary 2006.

              Klensin, J. and Y. Ko, "Overview and Framework for
              Internationalized Email", draft-klensin-ima-framework-01
              (work in progress), February 2006.

              Yao, J., Ed., "SMTP extension for internationalized email
              address", draft-yao-smtpext-02 (work in progress),
              Febrary 2006.

              Yeh, J., "Internationalized Email Headers",
              draft-yeh-ima-utf8headers-01 (work in progress),
              February 2006.

   [JET-IMA]  Yao, J. and J. Yeh, "Internationalized eMail Address
              (IMA)", draft-lee-jet-ima-00 (work in progress),
              June 2005.

              Klensin, J., "Internationalization of Email Addresses",
              draft-klensin-emailaddr-i18n-03 (work in progress),
              July 2005.

   [RFC1123]  Braden, R., "Requirements for Internet Hosts - Application
              and Support", STD 3, RFC 1123, October 1989.

   [RFC1651]  Klensin, J., Freed, N., Rose, M., Stefferud, E., and D.
              Crocker, "SMTP Service Extensions", RFC 1651, July 1994.

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

   [RFC2821]  Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
              April 2001.

   [RFC2822]  Resnick, P., "Internet Message Format", RFC 2822,
              April 2001.

YONEYA & Fujiwara       Expires September 7, 2006              [Page 10]

Internet-Draft                IMA Downgrade                   March 2006

   [RFC3490]  Faltstrom, P., Hoffman, P., and A. Costello,
              "Internationalizing Domain Names in Applications (IDNA)",
              RFC 3490, March 2003.

   [RFC3492]  Costello, A., "Punycode: A Bootstring encoding of Unicode
              for Internationalized Domain Names in Applications
              (IDNA)", RFC 3492, March 2003.

   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
              10646", STD 63, RFC 3629, November 2003.

YONEYA & Fujiwara       Expires September 7, 2006              [Page 11]

Internet-Draft                IMA Downgrade                   March 2006

Authors' Addresses

   Yoshiro YONEYA (editor)
   Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda
   Chiyoda-ku, Tokyo  101-0065

   Phone: +81 3 5215 8451

   Kazunori Fujiwara (editor)
   Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda
   Chiyoda-ku, Tokyo  101-0065

   Phone: +81 3 5215 8451

YONEYA & Fujiwara       Expires September 7, 2006              [Page 12]

Internet-Draft                IMA Downgrade                   March 2006

Intellectual Property Statement

   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

   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

Disclaimer of Validity

   This document and the information contained herein are provided on an

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.


   Funding for the RFC Editor function is currently provided by the
   Internet Society.

YONEYA & Fujiwara       Expires September 7, 2006              [Page 13]