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

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/