Email Address Internationalization                        Y. YONEYA, Ed.
(EAI)                                                   K. Fujiwara, Ed.
Internet-Draft                                                      JPRS
Intended status: Experimental                                Mar 5, 2007
Expires: September                               July 6, 2007
Expires: January 7, 2008

      Downgrading mechanism for Email Address Internationalization
                    draft-ietf-eai-downgrade-03.txt
                    draft-ietf-eai-downgrade-04.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. January 7, 2008.

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 (UTF8SMTP) allows UTF-8 characters in SMTP
   envelope and mail header fields (UTF8SMTP). fields.  To deliver Non-
   ASCII mail address via internationalized Email
   messages to/via UTF8SMTP non-compliant environment, some sort of
   converting mechanism (i.e. downgrading) is required.  This document describes requirements
   downgrading mechanism for downgrading, SMTP downgrading, Email header downgrading and implementation consideration. Address Internationalization.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3  4
   3.  Downgrade Requirements . . . . . . . . . . . . . . . . . . . .  3
     3.1.  Timing and conditions of downgrading . . . . . . . . . . .  3
     3.2.  Requirements . . . . . .  New header fields definition . . . . . . . . . . . . . . . . .  4
   4.  Downgraded header  . . . . . . .  SMTP Downgrading . . . . . . . . . . . . . . .  4
   5.  SMTP Downgrading . . . . . . . .  5
   5.  Email header fields downgrading  . . . . . . . . . . . . . . .  5  6
   6.  Email header Downgrading . . . . . .  MIME body part headers downgrading . . . . . . . . . . . . .  6
     6.1.  Downgrading address headers .  9
   7.  Security considerations  . . . . . . . . . . . . . .  7
   7.  Upgrading downgraded header . . . . . 10
   8.  IANA Considerations  . . . . . . . . . . . .  7
   8.  Implementation consideration . . . . . . . . . 10
   9.  Acknowledgements . . . . . . . .  8
   9.  Security considerations . . . . . . . . . . . . . . . 11
   10. Change History . . . .  8
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 11
     10.1.  draft-yoneya-ima-downgrade: Version 00  .  8
   11. Acknowledgements . . . . . . . . 11
     10.2.  draft-yoneya-ima-downgrade: Version 01  . . . . . . . . . 11
     10.3.  draft-ietf-eai-downgrade: Version 00  . . . . . .  8
   12. Change History . . . . 11
     10.4.  draft-ietf-eai-downgrade: Version 01  . . . . . . . . . . 12
     10.5.  draft-ietf-eai-downgrade: Version 02  . . . . . . . . . .  9
     12.1. draft-yoneya-ima-downgrade: 12
     10.6.  draft-ietf-eai-downgrade: Version 00 03  . . . . . . . . . .  9
     12.2. draft-yoneya-ima-downgrade: 12
     10.7.  draft-ietf-eai-downgrade: Version 01 04  . . . . . . . . . .  9
     12.3. draft-ietf-eai-downgrade: Version 00 12
   11. Normative References . . . . . . . . . . . .  9
     12.4. draft-ietf-eai-downgrade: Version 01 . . . . . . . . . 12
   Appendix A.  Displaying downgraded message . .  9
     12.5. draft-ietf-eai-downgrade: Version 02 . . . . . . . . . . 14
     A.1.   Displaying technique 1  . .  9
     12.6. draft-ietf-eai-downgrade: Version 03 . . . . . . . . . . .  9
   13. Normative References . . . . 14
     A.2.   Displaying technique 2  . . . . . . . . . . . . . . . . . 10 14
   Appendix A. B.  Examples  . . . . . . . . . . . . . . . . . . . . . . 10
     A.1. 14
     B.1.   Downgrading example 1 . . . . . . . . . . . . . . . . . . 10
     A.2.  Upgrading 14
     B.2.   Displaying example (Displaying technique 1) . . . . . . . 17
     B.3.   Displaying example (Displaying technique 2) . . . . . . . . . . . . . 13
     A.3. 17
     B.4.   Downgrading example 2 . . . . . . . . . . . . . . . . . . 15 19
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 21
   Intellectual Property and Copyright Statements . . . . . . . . . . 18 22

1.  Introduction

   Traditional mail systems which are defined by [RFC2821] and [RFC2822]
   allow US-ASCII characters in SMTP envelope and mail header field
   bodies.
   values.  The UTF8SMTP proposal proposals [I-D.ietf-eai-framework],
   [I-D.ietf-eai-utf8headers] and [I-D.ietf-eai-smtpext] allows allow UTF-8
   characters in SMTP envelope and mail header field bodies.

   Carrying Non-ASCII values.

   Delivering non-ASCII mail address addresses from a sender to recipients
   requires all components on the mail delivery route are UTF8SMTP
   compliant.
   Otherwise Non-ASCII  Otherwise, non-ASCII mail address can't be delivered.  To
   solve the problem, this document describes downgrading mechanism that
   enables delivering Non-ASCII non-ASCII mail address addresses to traditional mail
   system by converting it them to corresponding US-ASCII representation on current representation.
   And more, [I-D.ietf-eai-utf8headers] expands that mail delivery system.  Not only
   SMTP envelope, but also Non-ASCII characters in header fields
   and MIME header fields are allowed to use any UTF-8 characters.  This
   downgrading mechanism targets mail header fields
   MUST and MIME header
   fields to be converted to US-ASCII. US-ASCII only to send to UTF8SMTP non-
   compliant receivers.

   [I-D.ietf-eai-smtpext] section 2.2 defines when downgrading occurs.
   Mail clients (MUAs, MSAs, MTAs) try to deliver Email messages to SMTP
   servers by static setting or DNS MX resource records resolution.  If
   the SMTP client has an UTF8SMTP envelope or an UTF8SMTP message and
   the SMTP client detects that SMTP server doesn't support "UTF8SMTP"
   option at EHLO, then the SMTP client MUST NOT send the UTF8SMTP
   envelope or UTF8SMTP message to the SMTP server.  The section shows 4
   choices.  The second choice "reject or generate a notification of
   non-deliverability" is always allowed.  The fourth choice is
   downgrading.

   Downgrading may be implemented in MUAs, MSAs, MTAs, MDAs which
   generates or receives UTF8SMTP envelopes or UTF8SMTP messages and may
   send them to non-UTF8SMTP compliant systems.

   This document tries to define the downgrading process clearly and it
   preserves the original information as much as possible.

   Downgrading in UTF8SMTP consists from of the following two four parts:
   o  New header fields definition
   o  SMTP Downgrading downgrading
   o  Email header Downgrading

   Decoding downgraded envelope/message is called 'Upgrading' in this
   document.  Each fields downgrading mechanism has corresponding upgrading
   mechanism.

   In this document, requirements for
   o  MIME header fields downgrading are described in
   Before sending to traditional SMTP server, the downgrading process
   need to perform SMTP downgrading, Email header fields downgrading,
   and MIME header fields downgrading.

   In Section 3, two header fields are introduced.  One is "Envelope-
   Downgraded:", it preserves the original envelope information.  The
   other is "Downgraded:", it preserves the original header fields which
   contains non-ASCII email addresses or which does not have clear
   downgrading definition.

   The SMTP Downgrading downgradin is described in Section 5, and 4.  It generates US-ASCII
   only envelope information from an UTF8SMTP envelope.

   The Email header Downgrading fields downgrading is described in Section 6.

   This document assumes that 5.  It
   generates US-ASCII only header fields.

   The MIME headers header fields are not extended to use UTF-8
   characters because it is not clearly defined expanded in [I-D.ietf-eai-utf8headers].
   The MIME header fields downgrading is described in Section 6.  It
   generates US-ASCII only MIME header fields.

2.  Terminology

   Terminology for

   The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED",
   and "MAY" in 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 non-ASCII characters to be interpreted as described in RFC
   2119 [RFC2119].

   All specialized terms used in this specification are
      included defined in the SMTP envelope
   EAI overview [I-D.ietf-eai-framework] or mail header fields in the SMTP
      DATA.

3.2.  Requirements

   Followings [RFC2821][RFC2822], MIME
   documents [RFC2045] [RFC2047] [RFC2183] [RFC2231].  The terms "ASCII
   address", "internationalized email address", "non-ASCII address",
   "i18mail address", "UTF8SMTP", "message" and "mailing list" 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 used
   with the
       message."
   3.  Downgrading and upgrading must be automated.
   4.  Downgrading and upgrading should be easy definitions from [I-D.ietf-eai-framework] document.

   This document depends on [I-D.ietf-eai-smtpext],
   [I-D.ietf-eai-utf8headers], and lightweight as it [I-D.ietf-eai-dsn].  Key words used
   in these document are used in this document, too.

   The term "non-ASCII" 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 an UTF-8 string which contains at least one
   non-ASCII character.

   An "UTF8SMTP envelope" has Email originator/recipient addresses
   expanded by [I-D.ietf-eai-smtpext] and [I-D.ietf-eai-dsn].

   An "UTF8SMTP message" is Email messages expanded by
   [I-D.ietf-eai-utf8headers].

3.  New header information, new fields definition

   A generic encapsulation header "Downgraded:" is required.  The new defined to preserve
   the original header is required, and it is specified as
   "Downgraded". field.  It has two value fields.  The first former
   value field is holds the
   encapsulated original header field name.  The second latter value
   field contains holds the encapsulated original header field value.  Any original header
   field value which is treated as an unstructured value.  The latter value
   field of this header MUST be encoded by [RFC2047] section 5(1) method
   with UTF-8 tag. charset='UTF-8' same as a 'Subject' header.  The header field
   syntax is specified as follows:

   fields     =/ downgraded
   downgraded =  "Downgraded:" [CFWS] [FWS] field-name ":" dvalue unstructured 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

   Encapsulating a header in a Downgraded: header.  The "dvalue"
   field is encoded by [RFC2047].  "Downgraded header decoding" means
   that generating is defined as:
   1.  Generate new Downgraded: header whose header name former value is "field-name" the
       original header field
   that retrieving preserved field-name name and dvalue decoded latter value is the original
       header fleid value.
   2.  Encode the generated header by [RFC2047].

   To [RFC2047] section 5(1) method with
       charset='UTF-8'.
   3.  Replace the original header field as the generated header field.

   Another new header "Envelope-Downgraded:" is defined to preserve SMTP
   envelope downgraded information, another new header
   is required, information.  SMTP envelope downgraded
   information consists of the original non-ASCII address and it the
   downgraded all-ASCII address.  The non-ASCII address is specified as "Envelope-Downgraded".  Details
   are described in Section 5. encoded by
   [RFC2047] with charset='UTF-8'.  The header field syntax is specified
   as follows:

   fields      =/ edowngraded
   edowngraded = "Envelope-Downgraded:" [CFWS] field-name [FWS] edowngraded-field ":" value CRLF
   field-name = "From" / "To"
   value = CFWS
                                        [FWS] "<" uPath ">" CFWS [FWS]
                                        "<" Mailbox ">" CFWS

   ; Mailbox [FWS] CRLF
   edowngraded-field =  "From" / "To"

   Original non-ASCII address <uPath> is defined in RFC 2821, section 4.1.2
   ; uPath
   [I-D.ietf-eai-smtpext]. <Mailbox> is defined in [I-D.ietf-eai-smtpext]

5. [RFC2821], section
   4.1.2.  The "Envelope-Downgraded:" header field is encoded by
   [RFC2047] in the downgraded message.

4.  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:
   o  ORCPT parameter

   Downgrading in SMTP envelope uses ALT-ADDRESS parameter proposed defined 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 address is
   US-ASCII address or the address has US-ASCII address specified by
   ALT-ADDRESS parameter.

   If each SMTP recipient address individually.  First,
   split a multiple recipients session to each sessions.  If and the
   recipient return 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 message header fields and MIME header fields in the
   message body including non-ASCII characters or
   bounce. characters.  This is described in
   Section 5 and Section 6.

   Downgrading

   MTA replaces Non-ASCII non-ASCII mail address with specified alternative US-ASCII address. US-
   ASCII address when downgrading.  Before replacing, decode the ALT-
   ADDRESS parameter value because it is encoded as xtest [RFC3461].
   Also MTA preserves original information using "Envelope-Downgraded"
   header defined in Section 4 3 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  The non-
   ASCII mail addresses are encoded by [RFC2047] and put into "Envelope-
   Downgraded" header.

   Not to disclose whole recipient address,
   MUA/MTA SHOULD make SMTP connection per each recipient address.

   Also note that by appending "Envelope-Downgraded:" headers, addresses, MUA/MTA MUST perform Email NOT add
   "Envelope-Downgraded: To:" header Downgrading described in if the SMTP downgrading targets
   multiple recipients.  See Section 6.

   NOTE: 7 for more detail.

   While the recipient address downgrading, the "RCPT TO" command may
   have an ORCPT

   ESMTP parameter.  The ORCPT parameter is used for Delivery Status Notifications
   (DSNs) DSN
   [RFC3461].  ORCPT parameters contain mail addresses.  After
   extending  If the ORCPT parameter to support Non-ASCII mail addresses, contains "utf-8" address type
   address and the address contains non-ASCII characters, the ORCPT
   parameter downgrading should MUST 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 converted to utf-8-addr-xtext 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 or utf-8-addr-
   unitext form which is required.

6. described in [I-D.ietf-eai-dsn].

5.  Email header Downgrading fields downgrading

   This section defines conversion method to US-ASCII for each header
   field which may contain Non-ASCII non-ASCII characters.  Header fields are
   listed in [RFC4021].  If the whole mail header field does not contain Non-ASCII
   non-ASCII characters, email header field downgrading is not required.  Otherwise, email header downgrading checks each header
   whether it contains UTF-8 characters or not.
   If the header field contains
   UTF-8 non-ASCII characters, convert the header in a suitable method for of each
   header.
   field.  Each header's header field's downgrading method is described below:
   From, To, CC, Reply-To, Return-Path: below.

   o  Downgrading Address header fields

      From:
      Sender:

      Reply-To:
      To:
      Cc:
      Bcc:
      Resent-From:
      Resent-Sender:
      Resent-To:
      Resent-Cc:

      The header field body value is composed of single or multiple angle-
      addr/addr-spec <angle-
      addr>/<utf8-addr-spec> fields defined in
      [I-D.ietf-eai-utf8headers].
      If the header has no 'angle-addr' <angle-addr> or 'utf8-addr-spec' <utf8-addr-spec> which
      contains UTF-8 non-ASCII characters, only "display-name" part contains UTF-8 or
      comments contain non-ASCII characters, encode the header "display-name" or
      comments are encoded by [RFC2047] with UTF-8 tag and
      replace it. charset='UTF-8'.
      Otherwise, preserve the header field in "Downgraded:" header and header,
      generate US-ASCII only header defined in Section 6.1, address header, and replace the original
      header field with the generated US-ASCII only header.  When
      this address header downgrading fails, this downgrading fails field.  New
      header generation method are shown in below.

      Extract every field and downgrade each <mailbox>/<angle-addr>/
      <utf8-addr-spec>.

      If the non-ASCII address is in <utf8-addr-spec> form, then rewrite
      it as "Internationalized Address utf8-addr-spec-encoded
      Removed:;". "utf8-addr-spec" is encoded to "utf8-addr-spec-
      encoded" by [RFC2047].

      The field may contain multiple <comment> fields.  The <comment>
      fields are encoded by [RFC2047] with charset='UTF-8', if
      necessary.

      <mailbox> is defined as "display-name <angle-addr>" in
      [I-D.ietf-eai-utf8headers].  The "display-name" field is encoded
      by [RFC2047] with charset='UTF-8', if necessary.

      The <angle-addr> may contain comments.  Before processing, remove
      comments from the <angle-addr>.

      UTF8SMTP <angle-addr> defined in [I-D.ietf-eai-utf8headers]
      consists of 3 forms.  Downgrading method is defined for each form.

      *  <US-ASCII>
         <US-ASCII> is used as is.
      *  <non-ASCII>
         Non-ASCII mail address without sender-specified US-ASCII
         address is replaced as
         "Internationalized Address non-ASCII-encoded Removed:;".
         non-ASCII address is encoded to "non-ASCII-encoded" by
         [RFC2047].
      *  <non-ASCII <US-ASCII>>
         Non-ASCII mail address with sender-specified US-ASCII address
         MUST be bounced.

   Subject:
      Encode replaced as "display-name <US-ASCII>".

   o  Downgrading Non-ASCII in comments

      Date:
      Message-ID:
      In-Reply-To:
      References:
      Resent-Date:
      Resent-Message-ID:
      MIME-Version:
      Content-ID:

      These header fields do not contain non-ASCII characters except in
      comments.  If the header contains UTF-8 characters in comments,
      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. charset='UTF-8'.

   o  Trace header

      Received:

      If the FOR clause contains UTF-8 non-ASCII addresses, remove the FOR
      clause in the header.  The other part does not contain non-ASCII
      values.

   o  MIME Content header must be
      downgraded.  In this case, preserve

      Content-Type:
      Content-Disposition:

      Encode the header by [RFC2231] with charset='UTF-8'.

   o  Unstructured text headers and structured text headers

      Subject:
      Comments:
      Keywords:
      Content-Description:

      Encode the header by [RFC2047] with charset='UTF-8'.

   o  URI headers

      List-Archive:
      List-Help:
      List-Owner:
      List-Post:
      List-Subscribe:
      List-Unsubscribe:

      If the header contains UTF-8 characters in "Downgraded:" comments, encode the
      header and remove by [RFC2047] with charset='UTF-8'.  If the FOR clause header contains
      UTF-8 characters in URI, Encode the header.
   other headers: URI by [RFC3987].

   o  Other target headers
      All other headers which contains UTF-8 non-ASCII characters are
      preserved in Downgraded: header and removed.

   Downgraded

   o  ASCII only headers

      Content-Transfer-Encoding:

      This header is not target of downgrading.

   Downgraded header fields should be inserted or replaced at the same
   position of the original header.

6.1.  Downgrading address header field.

6.  MIME body part headers downgrading

   MIME body part header fields may contain non-ASCII characters
   [I-D.ietf-eai-utf8headers].  This procedure targets "From:", "To:", "CC:", "Reply-To:", "Return-
   Path:" headers which contains Originator/Destination address(es).
   1.  Extract every section defines conversion method
   to US-ASCII for each MIME header field which may contain non-ASCII
   characters.  Parse the message body's MIME structure for all level
   and downgrade each 'mailbox'/'angle-
       addr'/'utf8-addr-spec'. check all MIME header fields whether contains non-ASCII
   characters.  If the Non-ASCII address is header contains non-ASCII characters in utf8-addr-spec form, then the
   header downgrading fails because value, the form has no alt-address.

       "mailbox" header 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 a target of 3 forms.  Downgrading method is defined for each
       form.
       1.  <US-ASCII>
           US-ASCII is used as is.
       2.  <Non-ASCII>
           This email the MIME body part headers
   downgrading.  Each MIME header field's downgrading fails because this header is
           not downgradable.
       3.  <Non-ASCII<US-ASCII>>
           Non-ASCII mail address with sender-specified US-ASCII address
           is replaced as <US-ASCII>.

7.  Upgrading downgraded header

   Upgrading downgraded header method is
   described below:
   o  Check if the mail

   Content-ID:
      The Content-ID: header contains 'Downgraded:' headers.
      Otherwise, upgrading is does not required.

   o  Perform "Downgraded header decoding" for each "Downgraded:"
      headers and replace the 'Downgraded:' header with its decoded
      header.
      * contain non-ASCII characters
      except in comments.  If the decoded header is an address header described in
         Section 6.1,
         +  Generate ASCII only header described contains UTF-8 characters in Section 6.1 from
      comments, encode the
            decoded header.
         +  Remove header by [RFC2047] with charset='UTF-8'.

   Content-Type:
   Content-Disposition:
      Encode the header line which is by [RFC2231] with charset='UTF-8'.

   Content-Description:
      Encode the same header by [RFC2047] with charset='UTF-8'.

   Content-Transfer-Encoding:
      This header does not contain non-ASCII characters.

7.  Security considerations

   o  Rewriting headers increases the generated
            ASCII opportunities for undetected
      spoofing.
   o  Recipients addresses can be undisclosed if those addresses are
      listed on Bcc or group address.  Those undisclosed addresses are
      used only header.  (REQUIRE HEADER NORMALIZATION)
      *  If the decoded header is a "Received:" header,
         +  Removing in the 'FOR' clause Envelope.  Copying information from the decoded header generates
            ASCII only header.
         +  Remove the header line which Envelope
      into headers creates some risk of inadvertent information
      disclosure (not just about addresses).
   o  It is likely that the same techniques suggested here will invalidate
      methods that depend on signatures over headers or the envelope.
      "Issues" does talk about that, but, because this document strongly
      implies that one can downgrade and then upgrade again with no risk
      of loss of information, the generated
            header.  (REQUIRE HEADER NORMALIZATION) topic should be explored further.
   o  If each mail header has [RFC2047] encoded part  Many gateways 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 servers on the Internet will discard headers
      with which they are not familiar.  To the same encoding extent to which the
      downgrade procedures depend on new headers (e.g., "Downgraded") to
      avoid information loss, then the risk of body
   part while downgrading.

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

9.  Security considerations its implications must be identified.  In particular,
      it appears to me that, if the Downgraded headers are dropped,
      there is no possibility of reconstructing the original information
      at any point (before, during, or after delivery).

   See "Security considerations" section in [I-D.ietf-eai-framework] for
   more discussion.

10.

8.  IANA Considerations

   IANA is requested to add register the "Envelope-Downgraded:", and
   "Downgraded:" new headers to following header fields in the registry
   Permanent Message Header Field Repository, in accordance with the entries pointing
   to this specification for its definition.

11.
   procedures set out in [RFC3864].

   Header field name:  Downgraded
   Applicable protocol:  mail
   Status:  experimental
   Author/change controller:  IETF
   Specification document(s):  This document (Section 3)

   Header field name:  Envelope-Downgraded
   Applicable protocol:  mail
   Status:  experimental
   Author/change controller:  IETF
   Specification document(s):  This document (Section 3)

9.  Acknowledgements

   Significant comments and suggestions were received from John Klensin,
   Harald Alvestrand, Chris Newman, Charles Lindsey, Marcos Sanz, Alexey Melnikov
   Melnikov, Frank Ellermann and JET members.

12.

10.  Change History

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

12.1.

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

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

12.2.

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

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

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

12.5.

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

12.6.

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

10.7.  draft-ietf-eai-downgrade: Version 04

   o  Followed draft-ietf-eai-utf8headers-06, draft-ietf-eai-smtpext-07
      and draft-ietf-eai-dsn-02
   o  Downgrading requirements and conditions were moved to
      Introduction.
   o  Descriptions about upgrading were removed.
   o  SPF and DKIM discussion were removed.
   o  Added many header fields downgrading.
   o  Allow address literal rewriting without alternate US-ASCII address
      in header fields.
   o  Added MIME body part headers downgrading.
   o  Added ORCPT downgrading.

11.  Normative References

   [I-D.ietf-eai-dsn]
              Newman, C., C. and A. Melnikov, "International Delivery and
              Disposition Notifications", draft-ietf-eai-dsn-00 draft-ietf-eai-dsn-02 (work in
              progress),
              January July 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 draft-ietf-eai-smtpext-07 (work in
              progress), February June 2007.

   [I-D.ietf-eai-utf8headers]
              Yeh, J., "Internationalized Email Headers",
              draft-ietf-eai-utf8headers-03
              draft-ietf-eai-utf8headers-05 (work in progress),
              March
              April 2007.

   [RFC2045]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
              Extensions (MIME) Part One: Format of Internet Message
              Bodies", RFC 2045, November 1996.

   [RFC2047]  Moore, K., "MIME (Multipurpose Internet Mail Extensions)
              Part Three: Message Header Extensions for Non-ASCII Text",
              RFC 2047, November 1996.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2183]  Troost, R., Dorner, S., and K. Moore, "Communicating
              Presentation Information in Internet Messages: The
              Content-Disposition Header Field", RFC 2183, August 1997.

   [RFC2231]  Freed, N. and K. Moore, "MIME Parameter Value and Encoded
              Word Extensions:
              Character Sets, Languages, and Continuations", RFC 2231,
              November 1997.

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

   [RFC3864]  Klyne, G., Nottingham, M., and J. Mogul, "Registration
              Procedures for Message Header Fields", BCP 90, RFC 3864,
              September 2004.

   [RFC3987]  Duerst, M. and M. Suignard, "Internationalized Resource
              Identifiers (IRIs)", RFC 3987, January 2005.

   [RFC4021]  Klyne, G. and J. Palme, "Registration of Mail and MIME
              Header Fields", RFC 4021, March 2005.

Appendix A.  Displaying downgraded message

   Displaying downgraded message is mostly retrieved by MIME decoding
   [RFC2047][RFC2231].  Result of MIME decoding, downgraded address
   header fields and undefined header fields are still in Downgraded:
   headers, but it is MIME decoded.  This decoded Downgraded: headers
   contain the original headers and the recipient can read them.  But
   the recipient's MUA cannot use the original header fields
   automatically.

   Additionally, MUAs can decode Downgraded: header.  It is described in
   Appendix A.1 and Appendix A.2.

A.1.  Displaying technique 1

   MUA can remove 'Downgraded:' from decoded 'Downgraded:' header
   fields.  With this technique, The address header fields may be
   displayed twice, one is ASCII-only downgraded header field and the
   other is from decoded Downgraded: header.

A.2.  Displaying technique 2

   MUA can decode and regenerate headers which contains the original
   non-ASCII addresses.  It is described below:
   o  For each Downgraded: header, generate new header which field-name
      is the second field of the Downgraded: header and the header value
      is the third field of the Downgraded: header.
      *  If the header is an address header described in Section 5,
         +  Generate ASCII only header defined in Section 5 from the
            decoded header.
         +  Remove the header field which is the same with the generated
            ASCII only header from the header fields.  If the headers
            contain [RFC2047] encoded part, decode it before comparison.

Appendix A. B.  Examples

A.1.

B.1.  Downgrading example 1

   This section shows a an SMTP Downgrading example.  Consider a
   downgradable mail message.
   o  The sender address is "NON-ASCII-FROM" which is Non-ASCII non-ASCII address.
      Its ASCII alternative is "ASCII-FROM".

   o  The "To" address is "NON-ASCII-TO" which is Non-ASCII non-ASCII address.
      Its ASCII alternative is "ASCII-TO".
   o  The "CC" address is non-ASCII address "NON-ASCII-CC" which is Non-ASCII address.
      Its ASCII without
      alternative address is "ASCII-CC". US-ASCII address.
   o  The Subject header is "UTF8-SUBJECT" "NON-ASCII-SUBJECT" which contains Non-ASCII non-ASCII
      characters.

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

   MAIL_BODY

                    Figure 3: Original UTF8SMTP message

   In this example, there are two sessions, SMTP recipients, one is To:, the other
   is CC:.  Both sessions are downgradable.  Figure 4 shows  In this example, assume the Cc: recipient's MTA supports
   UTF8SMTP and the To: recipient's MTA does not support UTF8SMTP.  The
   SMTP downgrading treats To: session downgrading.

   After  Figure 4 shows SMTP Downgrading
   downgraded example.

   MAIL From: <ASCII-FROM>
   RCPT TO: <ASCII-TO>
   -------------------------------------------------------------
   Envelope-Downgraded: From: <NON-ASCII-FROM> <RFC2047(NON-ASCII-FROM)> <ASCII-FROM>
   Envelope-Downgraded: To: <NON-ASCII-TO> <RFC2047(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: UTF8-SUBJECT NON-ASCII-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<ASCII-CC>> <NON-ASCII-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.  Return-Path header will
   be added the destination MTA.

   Result of the header downgrading.

   Downgraded:

   Return-Path: <ASCII-FROM>
   Envelope-Downgraded: From:
               MIME(<NON-ASCII-FROM>) <RFC2047(NON-ASCII-FROM)> <ASCII-FROM>
   Downgraded:
   Envelope-Downgraded: To:
               MIME(<NON-ASCII-TO>) <RFC2047(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) RFC2047(UTF-8_SUBJECT)
   Downgraded: From: MIME(<NON-ASCII-FROM<ASCII-FROM>>) RFC2047(<NON-ASCII-FROM <ASCII-FROM>>)
   From: <ASCII-FROM>
   Downgraded: To: MIME(<NON-ASCII-TO<ASCII-TO>>) RFC2047(<NON-ASCII-TO <ASCII-TO>>)
   To: <ASCII-TO>
   Downgraded: CC: MIME(<NON-ASCII-CC<ASCII-CC>>)
   To: <ASCII-CC> RFC2047(<NON-ASCII-CC>)
   CC: Internationalized address RFC2047(NON-ASCII-CC) removed:;
   Date: DATE

   MAIL_BODY

                    Figure 5: Header downgraded message

   MIME()
   RFC2047() stands for [RFC2047] encoding.

A.2.  Upgrading

B.2.  Displaying example (Displaying technique 1)

   This example shows upgrading process MIME decoded message of Figure 5.

   First, check 'Downgraded:' header existence.  The UTF8SMTP downgraded
   message has 'Downgraded:' headers.

   Select 'Downgraded:' headers.

   Downgraded:

   Result of MIME decoding.

   Return-Path: <ASCII-FROM>
   Envelope-Downgraded: From:
               MIME(<NON-ASCII-FROM>) <NON-ASCII-FROM> <ASCII-FROM>
   Downgraded:
   Envelope-Downgraded: To:
               MIME(<NON-ASCII-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
   Downgraded: From: MIME(<NON-ASCII-FROM<ASCII-FROM>>) <NON-ASCII-FROM <ASCII-FROM>>
   From: <ASCII-FROM>
   Downgraded: To: MIME(<NON-ASCII-TO<ASCII-TO>>) <NON-ASCII-TO <ASCII-TO>>
   To: <ASCII-TO>
   Downgraded: CC: MIME(<NON-ASCII-CC<ASCII-CC>>) <NON-ASCII-CC>
   CC: Internationalized address NON-ASCII-CC removed:;
   Date: DATE

   MAIL_BODY

                      Figure 6: Upgrading: selecting Downgraded headers MIME decoded message

B.3.  Displaying example (Displaying technique 2)

   This example has five Downgraded headers.

   Decode shows displaying process of Appendix A.2 for Figure 5.

   First, check 'Downgraded:' header existence.

   Select 'Downgraded:' headers.

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

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

      Figure 7: Upgrading: upgraded Displaying technique 2: selecting Downgraded headers
   Apply address header downgrading to the decoded header.

   From: <ASCII-FROM>
   To: <ASCII-TO>
   CC: <ASCII-CC> Internationalized address RFC2047(NON-ASCII-CC) removed:;

      Figure 8: Upgrading: Displaying technique 2: downgraded upgraded decoded Downgraded
                                  headers

   Remove the header line which is the same with the downgraded line.

   Downgraded:
   If the headers contain [RFC2047] encoded part, decode it before
   comparison.

   Return-Path: <ASCII-FROM>
   Envelope-Downgraded: From:
               MIME(<NON-ASCII-FROM>) <NON-ASCII-FROM> <ASCII-FROM>
   Downgraded:
   Envelope-Downgraded: To:
               MIME(<NON-ASCII-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: MIME(UTF-8_SUBJECT) UTF-8_SUBJECT
   Downgraded: From: MIME(<NON-ASCII-FROM<ASCII-FROM>>) <NON-ASCII-FROM <ASCII-FROM>>
   Downgraded: To: MIME(<NON-ASCII-TO<ASCII-TO>>) <NON-ASCII-TO <ASCII-TO>>
   Downgraded: CC: MIME(<NON-ASCII-CC<ASCII-CC>>) <NON-ASCII-CC <ASCII-CC>>
   Date: DATE

   MAIL_BODY

       Figure 9: Upgrading: Displaying technique 2: 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.

   Return-Path: <ASCII-FROM>
   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: <NON-ASCII-TO<ASCII-TO>> <NON-ASCII-TO <ASCII-TO>>
   CC: <NON-ASCII-CC<ASCII-CC>> <NON-ASCII-CC <ASCII-CC>>
   Date: DATE

   MAIL_BODY

              Figure 10: Downgraded header upgraded Display technique 2: decoded message

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

A.3.
   displayed in the original form.

B.4.  Downgrading example 2

   In many cases, the sender wants to use Non-ASCII non-ASCII address and the
   recipient does not support UTF8SMTP and does not have Non-ASCII non-ASCII
   address.
   o  The sender address is "NON-ASCII-FROM" which is Non-ASCII 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" "NON-ASCII-SUBJECT" which contains Non-ASCII 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 NON-ASCII-SUBJECT
   From: <NON-ASCII-FROM<ASCII-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
   downgraded example.

   MAIL From: <ASCII-FROM>
   RCPT TO: <ASCII-TO>
   -------------------------------------------------------------
   Envelope-Downgraded: From: <NON-ASCII-FROM> <RFC2047(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 NON-ASCII-SUBJECT
   From: <NON-ASCII-FROM<ASCII-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  The
   downgraded messages are example is shown in Figure 13.

   Result of the header downgrading.

   Downgraded:

   Envelope-Downgraded: From:
               MIME(<NON-ASCII-FROM>) <RFC2047(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) RFC2047(UTF-8_SUBJECT)
   Downgraded: From: MIME(<NON-ASCII-FROM<ASCII-FROM>>) RFC2047(<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 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).