draft-ietf-eai-downgrade-03.txt   draft-ietf-eai-downgrade-04.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
Intended status: Experimental Mar 5, 2007 Intended status: Experimental July 6, 2007
Expires: September 6, 2007 Expires: January 7, 2008
Downgrading mechanism for Email Address Internationalization Downgrading mechanism for Email Address Internationalization
draft-ietf-eai-downgrade-03.txt draft-ietf-eai-downgrade-04.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 35 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 September 6, 2007. This Internet-Draft will expire on January 7, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
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 header fields. The Email Address envelope and mail header fields. The Email Address
Internationalization is implemented by allowing UTF-8 characters in Internationalization (UTF8SMTP) allows UTF-8 characters in SMTP
SMTP envelope and mail header fields (UTF8SMTP). To deliver Non- envelope and mail header fields. To deliver internationalized Email
ASCII mail address via UTF8SMTP non-compliant environment, some sort messages to/via UTF8SMTP non-compliant environment, some sort of
of converting mechanism (i.e. downgrading) is required. This converting mechanism is required. This document describes
document describes requirements for downgrading, SMTP downgrading, downgrading mechanism for Email Address Internationalization.
Email header downgrading and implementation consideration.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Downgrade Requirements . . . . . . . . . . . . . . . . . . . . 3 3. New header fields definition . . . . . . . . . . . . . . . . . 4
3.1. Timing and conditions of downgrading . . . . . . . . . . . 3 4. SMTP Downgrading . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 5. Email header fields downgrading . . . . . . . . . . . . . . . 6
4. Downgraded header . . . . . . . . . . . . . . . . . . . . . . 4 6. MIME body part headers downgrading . . . . . . . . . . . . . . 9
5. SMTP Downgrading . . . . . . . . . . . . . . . . . . . . . . . 5 7. Security considerations . . . . . . . . . . . . . . . . . . . 10
6. Email header Downgrading . . . . . . . . . . . . . . . . . . . 6 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6.1. Downgrading address headers . . . . . . . . . . . . . . . 7 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
7. Upgrading downgraded header . . . . . . . . . . . . . . . . . 7 10. Change History . . . . . . . . . . . . . . . . . . . . . . . . 11
8. Implementation consideration . . . . . . . . . . . . . . . . . 8 10.1. draft-yoneya-ima-downgrade: Version 00 . . . . . . . . . 11
9. Security considerations . . . . . . . . . . . . . . . . . . . 8 10.2. draft-yoneya-ima-downgrade: Version 01 . . . . . . . . . 11
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 10.3. draft-ietf-eai-downgrade: Version 00 . . . . . . . . . . 11
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 10.4. draft-ietf-eai-downgrade: Version 01 . . . . . . . . . . 12
12. Change History . . . . . . . . . . . . . . . . . . . . . . . . 9 10.5. draft-ietf-eai-downgrade: Version 02 . . . . . . . . . . 12
12.1. draft-yoneya-ima-downgrade: Version 00 . . . . . . . . . . 9 10.6. draft-ietf-eai-downgrade: Version 03 . . . . . . . . . . 12
12.2. draft-yoneya-ima-downgrade: Version 01 . . . . . . . . . . 9 10.7. draft-ietf-eai-downgrade: Version 04 . . . . . . . . . . 12
12.3. draft-ietf-eai-downgrade: Version 00 . . . . . . . . . . . 9 11. Normative References . . . . . . . . . . . . . . . . . . . . . 12
12.4. draft-ietf-eai-downgrade: Version 01 . . . . . . . . . . . 9 Appendix A. Displaying downgraded message . . . . . . . . . . . . 14
12.5. draft-ietf-eai-downgrade: Version 02 . . . . . . . . . . . 9 A.1. Displaying technique 1 . . . . . . . . . . . . . . . . . 14
12.6. draft-ietf-eai-downgrade: Version 03 . . . . . . . . . . . 9 A.2. Displaying technique 2 . . . . . . . . . . . . . . . . . 14
13. Normative References . . . . . . . . . . . . . . . . . . . . . 10 Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 14
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 10 B.1. Downgrading example 1 . . . . . . . . . . . . . . . . . . 14
A.1. Downgrading example 1 . . . . . . . . . . . . . . . . . . 10 B.2. Displaying example (Displaying technique 1) . . . . . . . 17
A.2. Upgrading example . . . . . . . . . . . . . . . . . . . . 13 B.3. Displaying example (Displaying technique 2) . . . . . . . 17
A.3. Downgrading example 2 . . . . . . . . . . . . . . . . . . 15 B.4. Downgrading example 2 . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
Intellectual Property and Copyright Statements . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . . . 22
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 header field allow US-ASCII characters in SMTP envelope and mail header field
bodies. The UTF8SMTP proposal [I-D.ietf-eai-framework], values. The UTF8SMTP proposals [I-D.ietf-eai-framework],
[I-D.ietf-eai-utf8headers] and [I-D.ietf-eai-smtpext] allows UTF-8 [I-D.ietf-eai-utf8headers] and [I-D.ietf-eai-smtpext] allow UTF-8
characters in SMTP envelope and mail header field bodies. characters in SMTP envelope and mail header field values.
Carrying Non-ASCII mail address from sender to recipients requires Delivering non-ASCII mail addresses from a sender to recipients
all components on the mail delivery route are UTF8SMTP compliant. requires all components on the mail delivery route are UTF8SMTP
Otherwise Non-ASCII mail address can't be delivered. To solve the compliant. Otherwise, non-ASCII mail address can't be delivered. To
problem, this document describes downgrading mechanism that enables solve the problem, this document describes downgrading mechanism that
delivering Non-ASCII mail address by converting it to corresponding enables delivering non-ASCII mail addresses to traditional mail
US-ASCII representation on current mail delivery system. Not only system by converting them to corresponding US-ASCII representation.
SMTP envelope, but also Non-ASCII characters in mail header fields And more, [I-D.ietf-eai-utf8headers] expands that mail header fields
MUST be converted to US-ASCII. and MIME header fields are allowed to use any UTF-8 characters. This
downgrading mechanism targets mail header fields and MIME header
fields to be converted to US-ASCII only to send to UTF8SMTP non-
compliant receivers.
Downgrading in UTF8SMTP consists from following two parts: [I-D.ietf-eai-smtpext] section 2.2 defines when downgrading occurs.
o SMTP Downgrading Mail clients (MUAs, MSAs, MTAs) try to deliver Email messages to SMTP
o Email header Downgrading 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.
Decoding downgraded envelope/message is called 'Upgrading' in this Downgrading may be implemented in MUAs, MSAs, MTAs, MDAs which
document. Each downgrading mechanism has corresponding upgrading generates or receives UTF8SMTP envelopes or UTF8SMTP messages and may
mechanism. send them to non-UTF8SMTP compliant systems.
In this document, requirements for downgrading are described in This document tries to define the downgrading process clearly and it
Section 3, SMTP Downgrading is described in Section 5, and Email preserves the original information as much as possible.
header Downgrading is described in Section 6.
This document assumes that MIME headers are not extended to use UTF-8 Downgrading in UTF8SMTP consists of the following four parts:
characters because it is not clearly defined in o New header fields definition
[I-D.ietf-eai-utf8headers]. o SMTP downgrading
o Email header fields downgrading
o MIME header fields downgrading
Before sending to traditional SMTP server, the downgrading process
need to perform SMTP downgrading, Email header fields downgrading,
and MIME header fields downgrading.
2. Terminology 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.
Terminology for this document is defined in [I-D.ietf-eai-framework]. The SMTP downgradin is described in Section 4. It generates US-ASCII
only envelope information from an UTF8SMTP envelope.
3. Downgrade Requirements The Email header fields downgrading is described in Section 5. It
generates US-ASCII only header fields.
3.1. Timing and conditions of downgrading The MIME header fields are 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.
Followings are timing and conditions of downgrading. 2. Terminology
Timing: SMTP client detects that SMTP server doesn't support The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED",
"UTF8SMTP" option at EHLO. [I-D.ietf-eai-smtpext] and "MAY" in this document are to be interpreted as described in RFC
Conditions: SMTP client detects that non-ASCII characters are 2119 [RFC2119].
included in the SMTP envelope or mail header fields in the SMTP
DATA.
3.2. Requirements All specialized terms used in this specification are defined in the
EAI overview [I-D.ietf-eai-framework] or in [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 used
with the definitions from [I-D.ietf-eai-framework] document.
Followings are requirements of downgrading. This document depends on [I-D.ietf-eai-smtpext],
[I-D.ietf-eai-utf8headers], and [I-D.ietf-eai-dsn]. Key words used
in these document are used in this document, too.
1. Downgrading should be performed only once. The term "non-ASCII" is an UTF-8 string which contains at least one
2. "Upgrading MUST be performed (if at all) when it is known that a non-ASCII character.
subsequent downgrade will not be needed. This could mean that
the upgrading is delayed until the recipient MUA processes the
message."
3. Downgrading and upgrading must be automated.
4. Downgrading and upgrading should be easy and lightweight as it is
possible to do with MTA like 8BITMIME encapsulation.
5. Downgrade and upgrade method must be defined clearly.
6. Downgrading and upgrading should preserve all header information.
7. Downgrading should support SPF and DKIM.
8. Downgrading occurrence should be recorded.
4. Downgraded header An "UTF8SMTP envelope" has Email originator/recipient addresses
expanded by [I-D.ietf-eai-smtpext] and [I-D.ietf-eai-dsn].
To preserve all header information, new generic encapsulation header An "UTF8SMTP message" is Email messages expanded by
is required. The new header is required, and it is specified as [I-D.ietf-eai-utf8headers].
"Downgraded". It has two fields. The first field is the
encapsulated header name. The second field contains the encapsulated 3. New header fields definition
header value which is encoded by [RFC2047] with UTF-8 tag. The
header field syntax is specified as follows: A generic encapsulation header "Downgraded:" is defined to preserve
the original header field. It has two value fields. The former
value field holds the original header field name. The latter value
field holds the original header field value. Any original header
field value is treated as an unstructured value. The latter value
field of this header MUST be encoded by [RFC2047] section 5(1) method
with charset='UTF-8' same as a 'Subject' header. The header field
syntax is specified as follows:
fields =/ downgraded fields =/ downgraded
downgraded = "Downgraded:" [CFWS] field-name ":" dvalue CRLF downgraded = "Downgraded:" [FWS] field-name ":" 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 in Downgraded: header. The "dvalue" Encapsulating a header in a Downgraded: header is defined as:
field is encoded by [RFC2047]. "Downgraded header decoding" means 1. Generate new Downgraded: header whose former value is the
that generating new header whose header name is "field-name" field original header field name and latter value is the original
that retrieving preserved field-name and dvalue decoded by [RFC2047]. header fleid value.
2. Encode the generated header by [RFC2047] section 5(1) method with
charset='UTF-8'.
3. Replace the original header field as the generated header field.
To preserve SMTP envelope downgraded information, another new header Another new header "Envelope-Downgraded:" is defined to preserve SMTP
is required, and it is specified as "Envelope-Downgraded". Details envelope downgraded information. SMTP envelope downgraded
are described in Section 5. The header field syntax is specified as information consists of the original non-ASCII address and the
follows: downgraded all-ASCII address. The non-ASCII address is encoded by
[RFC2047] with charset='UTF-8'. The header field syntax is specified
as follows:
fields =/ edowngraded fields =/ edowngraded
edowngraded = "Envelope-Downgraded:" [CFWS] field-name ":" value CRLF edowngraded = "Envelope-Downgraded:" [FWS] edowngraded-field ":"
field-name = "From" / "To" [FWS] "<" uPath ">" [FWS]
value = CFWS "<" uPath ">" CFWS "<" Mailbox ">" CFWS "<" Mailbox ">" [FWS] CRLF
edowngraded-field = "From" / "To"
; Mailbox is defined in RFC 2821, section 4.1.2 Original non-ASCII address <uPath> is defined in
; uPath is defined in [I-D.ietf-eai-smtpext] [I-D.ietf-eai-smtpext]. <Mailbox> is defined in [RFC2821], section
4.1.2. The "Envelope-Downgraded:" header field is encoded by
[RFC2047] in the downgraded message.
5. SMTP Downgrading 4. SMTP Downgrading
Downgrading MUST be performed for each SMTP recipient address.
Target of downgrading elements in SMTP envelope are below: Target of downgrading elements in SMTP envelope are below:
o MAIL FROM: o MAIL FROM:
o RCPT TO: o RCPT TO:
o ORCPT parameter
Downgrading in SMTP envelope uses ALT-ADDRESS parameter proposed in Downgrading in SMTP envelope uses ALT-ADDRESS parameter defined in
[I-D.ietf-eai-smtpext]. An address is downgradable if the address is [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 US-ASCII address or the address has US-ASCII address specified by
ALT-ADDRESS parameter. ALT-ADDRESS parameter.
If the return address in the envelope ("MAIL FROM:") is not If each recipient address and the return address is downgradable, the
downgradable, downgrading fails. SMTP to the recipient is downgradable.
One SMTP session may contain multiple recipients. Downgrading SHOULD Even if no downgrading is performed for envelope from/to, MUA/MTA
be performed for each SMTP recipient address individually. First, MUST downgrade message header fields and MIME header fields in the
split a multiple recipients session to each sessions. If the message body including non-ASCII characters. This is described in
recipient address is downgradable, the SMTP session to the recipient Section 5 and Section 6.
is downgradable.
When MUA/MTA is transferring mail and finding its envelope contains MTA replaces non-ASCII mail address with specified alternative US-
Non-ASCII addresses, it MUST decide to bounce or downgrade if ASCII address when downgrading. Before replacing, decode the ALT-
receiving MTA is UTF8SMTP non-compliant. ADDRESS parameter value because it is encoded as xtest [RFC3461].
Also MTA preserves original information using "Envelope-Downgraded"
header defined in Section 3 with From or To field name. The non-
ASCII mail addresses are encoded by [RFC2047] and put into "Envelope-
Downgraded" header.
Even if no downgrading is performed for envelope from/to, MUA/MTA Not to disclose whole recipient addresses, MUA/MTA MUST NOT add
MUST downgrade mail header fields including non-ASCII characters or "Envelope-Downgraded: To:" header if the SMTP downgrading targets
bounce. This is described in Section 6. multiple recipients. See Section 7 for more detail.
Downgrading MTA replaces Non-ASCII mail address with specified While the recipient address downgrading, the "RCPT TO" command may
alternative US-ASCII address. Also MTA preserves original have an ORCPT parameter. The ORCPT parameter is used for DSN
information using "Envelope-Downgraded" header defined in Section 4 [RFC3461]. If the ORCPT parameter contains "utf-8" address type
with From or To field name. address and the address contains non-ASCII characters, the ORCPT
parameter MUST be converted to utf-8-addr-xtext form or utf-8-addr-
unitext form which is described in [I-D.ietf-eai-dsn].
Envelope-Downgraded: From: <Non-ASCII-FROM> <US-ASCII-FROM> 5. Email header fields downgrading
Envelope-Downgraded: To: <Non-ASCII-TO> <US-ASCII-TO>
Note that when downgrading, not to disclose whole recipient address, This section defines conversion method to US-ASCII for each header
MUA/MTA SHOULD make SMTP connection per each recipient address. field which may contain non-ASCII characters. Header fields are
listed in [RFC4021]. If the whole mail header field does not contain
non-ASCII characters, email header field downgrading is not required.
If the header field contains non-ASCII characters, convert the header
field. Each header field's downgrading method is described below.
Also note that by appending "Envelope-Downgraded:" headers, MUA/MTA o Downgrading Address header fields
MUST perform Email header Downgrading described in Section 6.
NOTE: ORCPT From:
Sender:
ESMTP ORCPT parameter is used for Delivery Status Notifications Reply-To:
(DSNs) [RFC3461]. ORCPT parameters contain mail addresses. After To:
extending ORCPT parameter to support Non-ASCII mail addresses, ORCPT Cc:
parameter downgrading should be defined here. Bcc:
Resent-From:
Resent-Sender:
Resent-To:
Resent-Cc:
Case study: SPF check The header field value is composed of single or multiple <angle-
addr>/<utf8-addr-spec> fields defined in
[I-D.ietf-eai-utf8headers].
If the header has no <angle-addr> or <utf8-addr-spec> which
contains non-ASCII characters, only "display-name" part or
comments contain non-ASCII characters, the "display-name" or
comments are encoded by [RFC2047] with charset='UTF-8'.
Otherwise, preserve the header field in "Downgraded:" header,
generate US-ASCII only address header, and replace the original
header field with the generated US-ASCII only header field. New
header generation method are shown in below.
SPF checks domain name of the envelope from and SMTP connection IP Extract every field and downgrade each <mailbox>/<angle-addr>/
address. If ALT-ADDRESS domain name is Punycode/IDNA form of Non- <utf8-addr-spec>.
ASCII domainname, it will be compatible with current SPF. In this
case, SPF check will be performed correctly. Otherwise, more
detailed consideration is required.
6. Email header Downgrading 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].
This section defines conversion method to US-ASCII for each header The field may contain multiple <comment> fields. The <comment>
which may contain Non-ASCII characters. If the whole mail header fields are encoded by [RFC2047] with charset='UTF-8', if
does not contain Non-ASCII characters, email header downgrading is necessary.
not required. Otherwise, email header downgrading checks each header
whether it contains UTF-8 characters or not. If the header contains <mailbox> is defined as "display-name <angle-addr>" in
UTF-8 characters, convert the header in a suitable method for of each [I-D.ietf-eai-utf8headers]. The "display-name" field is encoded
header. Each header's downgrading method is described below: by [RFC2047] with charset='UTF-8', if necessary.
From, To, CC, Reply-To, Return-Path:
The header field body is composed of single or multiple angle- The <angle-addr> may contain comments. Before processing, remove
addr/addr-spec fields defined in [I-D.ietf-eai-utf8headers]. comments from the <angle-addr>.
If the header has no 'angle-addr' or 'utf8-addr-spec' which
contains UTF-8 characters, only "display-name" part contains UTF-8 UTF8SMTP <angle-addr> defined in [I-D.ietf-eai-utf8headers]
characters, encode the header by [RFC2047] with UTF-8 tag and consists of 3 forms. Downgrading method is defined for each form.
replace it.
Otherwise, preserve the header in "Downgraded:" header and * <US-ASCII>
generate US-ASCII only header defined in Section 6.1, replace the <US-ASCII> is used as is.
original header with the generated US-ASCII only header. When * <non-ASCII>
this address header downgrading fails, this downgrading fails and Non-ASCII mail address without sender-specified US-ASCII
the mail MUST be bounced. 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 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 charset='UTF-8'.
o Trace header
Subject:
Encode the header by [RFC2047] with UTF-8 tag and replace it.
Message-ID:, Date:, In-Reply-To:
"ID"s and "Date"s does not contain UTF-8 characters.
Received: Received:
If the FOR clause contains UTF-8 addresses, the header must be
downgraded. In this case, preserve the header in "Downgraded:"
header and remove the FOR clause in the header.
other headers:
All other headers which contains UTF-8 characters are preserved in
Downgraded: header and removed.
Downgraded headers should be inserted or replaced at the same If the FOR clause contains non-ASCII addresses, remove the FOR
position of the original header. clause in the header. The other part does not contain non-ASCII
values.
6.1. Downgrading address headers o MIME Content header
This procedure targets "From:", "To:", "CC:", "Reply-To:", "Return- Content-Type:
Path:" headers which contains Originator/Destination address(es). Content-Disposition:
1. Extract every field and downgrade each 'mailbox'/'angle-
addr'/'utf8-addr-spec'.
If the Non-ASCII address is in utf8-addr-spec form, then the Encode the header by [RFC2231] with charset='UTF-8'.
header downgrading fails because the form has no alt-address.
"mailbox" is defined as "DISPLAY NAME angle-addr" in o Unstructured text headers and structured text headers
[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] Subject:
consists of 3 forms. Downgrading method is defined for each Comments:
form. Keywords:
1. <US-ASCII> Content-Description:
US-ASCII is used as is.
2. <Non-ASCII>
This email header 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 Encode the header by [RFC2047] with charset='UTF-8'.
Upgrading downgraded header is described below: o URI headers
o Check if the mail header contains 'Downgraded:' headers.
Otherwise, upgrading is not required.
o Perform "Downgraded header decoding" for each "Downgraded:" List-Archive:
headers and replace the 'Downgraded:' header with its decoded List-Help:
header. List-Owner:
* If the decoded header is an address header described in List-Post:
Section 6.1, List-Subscribe:
+ Generate ASCII only header described in Section 6.1 from the List-Unsubscribe:
decoded header.
+ Remove the header line which is the same with the generated
ASCII only header. (REQUIRE HEADER NORMALIZATION)
* If the decoded header is a "Received:" header,
+ Removing the 'FOR' clause from the decoded header generates
ASCII only header.
+ Remove the header line which is the same with the generated
header. (REQUIRE HEADER NORMALIZATION)
o If each mail header has [RFC2047] encoded part and which encoding
is "UTF-8", it may be a downgraded header, so decode it.
8. Implementation consideration If the header contains UTF-8 characters in comments, encode the
header by [RFC2047] with charset='UTF-8'. If the header contains
UTF-8 characters in URI, Encode the URI by [RFC3987].
UTF8SMTP compliant MUA MUST implement downgrading mechanism for o Other target headers
sending. All other headers which contains non-ASCII characters are
preserved in Downgraded: header and removed.
MUA MAY encode UTF-8 in Subject header with the same encoding of body o ASCII only headers
part while downgrading.
UTF8SMTP compliant MUA MUST upgrade downgraded mail and MUST show Content-Transfer-Encoding:
Non-ASCII mail addresses on display.
9. Security considerations This header is not target of downgrading.
Downgraded header fields should be inserted or replaced at the same
position of the original header field.
6. MIME body part headers downgrading
MIME body part header fields may contain non-ASCII characters
[I-D.ietf-eai-utf8headers]. This 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 check all MIME header fields whether contains non-ASCII
characters. If the header contains non-ASCII characters in the
header value, the header is a target of the MIME body part headers
downgrading. Each MIME header field's downgrading method is
described below:
Content-ID:
The Content-ID: header does not contain non-ASCII characters
except in comments. If the header contains UTF-8 characters in
comments, encode the header by [RFC2047] with charset='UTF-8'.
Content-Type:
Content-Disposition:
Encode the header by [RFC2231] with charset='UTF-8'.
Content-Description:
Encode the 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 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 in the Envelope. Copying information from the Envelope
into headers creates some risk of inadvertent information
disclosure (not just about addresses).
o It is likely that the 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 topic should be explored further.
o Many gateways and servers on the Internet will discard headers
with which they are not familiar. To the extent to which the
downgrade procedures depend on new headers (e.g., "Downgraded") to
avoid information loss, then the risk of having those headers
dropped and 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 See "Security considerations" section in [I-D.ietf-eai-framework] for
more discussion. more discussion.
10. IANA Considerations 8. IANA Considerations
IANA is requested to add the "Envelope-Downgraded:", and IANA is requested to register the following header fields in the
"Downgraded:" new headers to the registry with the entries pointing Permanent Message Header Field Repository, in accordance with the
to this specification for its definition. procedures set out in [RFC3864].
11. Acknowledgements Header field name: Downgraded
Applicable protocol: mail
Status: experimental
Author/change controller: IETF
Specification document(s): This document (Section 3)
John Klensin, Harald Alvestrand, Chris Newman, Charles Lindsey, Header field name: Envelope-Downgraded
Marcos Sanz, Alexey Melnikov and JET members. Applicable protocol: mail
Status: experimental
Author/change controller: IETF
Specification document(s): This document (Section 3)
12. Change History 9. Acknowledgements
Significant comments and suggestions were received from John Klensin,
Harald Alvestrand, Chris Newman, Charles Lindsey, Marcos Sanz, Alexey
Melnikov, Frank Ellermann and JET members.
10. Change History
This section is used for tracking the update of this document. Will This section is used for tracking the update of this document. Will
be removed after finalize. be removed after finalize.
12.1. draft-yoneya-ima-downgrade: Version 00 10.1. draft-yoneya-ima-downgrade: Version 00
o Initial version o Initial version
o Followed draft-yeh-ima-utf8headers-00 and draft-yao-smtpext-00 o Followed draft-yeh-ima-utf8headers-00 and draft-yao-smtpext-00
12.2. draft-yoneya-ima-downgrade: Version 01 10.2. draft-yoneya-ima-downgrade: Version 01
o Document structure was changed o Document structure was changed
o Followed draft-yeh-ima-utf8headers-01 and draft-yao-smtpext-02 o Followed draft-yeh-ima-utf8headers-01 and draft-yao-smtpext-02
o Downgrading requirements were added o Downgrading requirements were added
o SMTP DATA encapsulation method was proposed o SMTP DATA encapsulation method was proposed
o Downgrading examples was provided o Downgrading examples was provided
12.3. draft-ietf-eai-downgrade: Version 00 10.3. draft-ietf-eai-downgrade: Version 00
o Followed draft-yeh-ima-utf8headers-01 and o Followed draft-yeh-ima-utf8headers-01 and
draft-ietf-eai-smtpext-00 draft-ietf-eai-smtpext-00
o No header downgrading method was proposed o No header downgrading method was proposed
o Header encapsulation method was proposed o Header encapsulation method was proposed
12.4. draft-ietf-eai-downgrade: Version 01 10.4. draft-ietf-eai-downgrade: Version 01
o Followed draft-ietf-eai-utf8headers-00 o Followed draft-ietf-eai-utf8headers-00
o Header conversion and encapsulation method was merged o Header conversion and encapsulation method was merged
o Header conversion method was defined in detail o Header conversion method was defined in detail
12.5. draft-ietf-eai-downgrade: Version 02 10.5. draft-ietf-eai-downgrade: Version 02
o Followed draft-ietf-eai-utf8headers-01 and o Followed draft-ietf-eai-utf8headers-01 and
draft-ietf-eai-smtpext-01 draft-ietf-eai-smtpext-01
o Specification about algorithmic generated address is removed o Specification about algorithmic generated address is removed
o No header downgrading method was removed o No header downgrading method was removed
o SMTP DATA encapsulation method was removed o SMTP DATA encapsulation method was removed
12.6. draft-ietf-eai-downgrade: Version 03 10.6. draft-ietf-eai-downgrade: Version 03
o Followed draft-ietf-eai-utf8headers-03 and o Followed draft-ietf-eai-utf8headers-03 and
draft-ietf-eai-smtpext-03 draft-ietf-eai-smtpext-03
o Downgraded: and Envelope-Downgraded: headers definition was added o Downgraded: and Envelope-Downgraded: headers definition was added
o Mail header downgrading method was refined o Mail header downgrading method was refined
o Examples in Appendix A were refined o Examples in Appendix A were refined
13. Normative References 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] [I-D.ietf-eai-dsn]
Newman, C., "International Delivery and Disposition Newman, C. and A. Melnikov, "International Delivery and
Notifications", draft-ietf-eai-dsn-00 (work in progress), Disposition Notifications", draft-ietf-eai-dsn-02 (work in
January 2007. progress), July 2007.
[I-D.ietf-eai-framework] [I-D.ietf-eai-framework]
Klensin, J. and Y. Ko, "Overview and Framework for Klensin, J. and Y. Ko, "Overview and Framework for
Internationalized Email", draft-ietf-eai-framework-05 Internationalized Email", draft-ietf-eai-framework-05
(work in progress), February 2007. (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] [I-D.ietf-eai-smtpext]
Yao, J. and W. Mao, "SMTP extension for internationalized Yao, J. and W. Mao, "SMTP extension for internationalized
email address", draft-ietf-eai-smtpext-03 (work in email address", draft-ietf-eai-smtpext-07 (work in
progress), February 2007. progress), June 2007.
[I-D.ietf-eai-utf8headers] [I-D.ietf-eai-utf8headers]
Yeh, J., "Internationalized Email Headers", Yeh, J., "Internationalized Email Headers",
draft-ietf-eai-utf8headers-03 (work in progress), draft-ietf-eai-utf8headers-05 (work in progress),
March 2007. 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) [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
Part Three: Message Header Extensions for Non-ASCII Text", Part Three: Message Header Extensions for Non-ASCII Text",
RFC 2047, November 1996. 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, [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001. April 2001.
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, [RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
April 2001. April 2001.
[RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service
Extension for Delivery Status Notifications (DSNs)", Extension for Delivery Status Notifications (DSNs)",
RFC 3461, January 2003. RFC 3461, January 2003.
Appendix A. Examples [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90, RFC 3864,
September 2004.
A.1. Downgrading example 1 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource
Identifiers (IRIs)", RFC 3987, January 2005.
This section shows a SMTP Downgrading example. Consider a [RFC4021] Klyne, G. and J. Palme, "Registration of Mail and MIME
downgradable mail message. Header Fields", RFC 4021, March 2005.
o The sender address is "NON-ASCII-FROM" which is Non-ASCII address. 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 B. Examples
B.1. Downgrading example 1
This section shows an 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". Its ASCII alternative is "ASCII-FROM".
o The "To" address is "NON-ASCII-TO" which is Non-ASCII address.
o The "To" address is "NON-ASCII-TO" which is non-ASCII address.
Its ASCII alternative is "ASCII-TO". Its ASCII alternative is "ASCII-TO".
o The "CC" address is "NON-ASCII-CC" which is Non-ASCII address. o The "CC" address is non-ASCII address "NON-ASCII-CC" without
Its ASCII alternative address is "ASCII-CC". alternative US-ASCII address.
o The Subject header is "UTF8-SUBJECT" which contains Non-ASCII o The Subject header is "NON-ASCII-SUBJECT" which contains non-ASCII
characters. characters.
Original UTF8SMTP message SMTP session Original UTF8SMTP message SMTP session
MAIL From: <NON-ASCII-FROM> ALT-ADDRESS <ASCII-FROM> MAIL From: <NON-ASCII-FROM> ALT-ADDRESS <ASCII-FROM>
RCPT TO: <NON-ASCII-TO> ALT-ADDRESS <ASCII-TO> RCPT TO: <NON-ASCII-TO> ALT-ADDRESS <ASCII-TO>
RCPT TO: <NON-ASCII-CC> ALT-ADDRESS <ASCII-CC> RCPT TO: <NON-ASCII-CC>
------------------------------------------------------------- -------------------------------------------------------------
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: UTF8-SUBJECT Subject: NON-ASCII-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&lt;ASCII-CC>&gt; CC: <NON-ASCII-CC>
Date: DATE Date: DATE
MAIL_BODY MAIL_BODY
Figure 3: Original UTF8SMTP message Figure 3: Original UTF8SMTP message
In this example, there are two sessions, one is To:, the other is In this example, there are two SMTP recipients, one is To:, the other
CC:. Both sessions are downgradable. Figure 4 shows To: session is CC:. In this example, assume the Cc: recipient's MTA supports
downgrading. UTF8SMTP and the To: recipient's MTA does not support UTF8SMTP. The
SMTP downgrading treats To: session downgrading. Figure 4 shows SMTP
After SMTP Downgrading downgraded example.
MAIL From: <ASCII-FROM> MAIL From: <ASCII-FROM>
RCPT TO: <ASCII-TO> RCPT TO: <ASCII-TO>
------------------------------------------------------------- -------------------------------------------------------------
Envelope-Downgraded: From: <NON-ASCII-FROM> <ASCII-FROM> Envelope-Downgraded: From: <RFC2047(NON-ASCII-FROM)> <ASCII-FROM>
Envelope-Downgraded: To: <NON-ASCII-TO> <ASCII-TO> Envelope-Downgraded: To: <RFC2047(NON-ASCII-TO)> <ASCII-TO>
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: UTF8-SUBJECT Subject: NON-ASCII-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&lt;ASCII-CC>&gt; CC: <NON-ASCII-CC>
Date: DATE Date: DATE
MAIL_BODY MAIL_BODY
Figure 4: SMTP Downgraded UTF8SMTP message Figure 4: SMTP Downgraded UTF8SMTP message
After SMTP downgrading, header downgrading is performed. Final After SMTP downgrading, header downgrading is performed. Final
downgraded messages are shown in Figure 5. downgraded messages are shown in Figure 5. Return-Path header will
be added the destination MTA.
Result of the header downgrading. Result of the header downgrading.
Downgraded: Envelope-Downgraded: From: Return-Path: <ASCII-FROM>
MIME(<NON-ASCII-FROM>) <ASCII-FROM> Envelope-Downgraded: From: <RFC2047(NON-ASCII-FROM)> <ASCII-FROM>
Downgraded: Envelope-Downgraded: To: Envelope-Downgraded: To: <RFC2047(NON-ASCII-TO)> <ASCII-TO>
MIME(<NON-ASCII-TO>) <ASCII-TO>
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: RFC2047(UTF-8_SUBJECT)
Downgraded: From: MIME(<NON-ASCII-FROM<ASCII-FROM>>) Downgraded: From: RFC2047(<NON-ASCII-FROM <ASCII-FROM>>)
From: <ASCII-FROM> From: <ASCII-FROM>
Downgraded: To: MIME(<NON-ASCII-TO<ASCII-TO>>) Downgraded: To: RFC2047(<NON-ASCII-TO <ASCII-TO>>)
To: <ASCII-TO> To: <ASCII-TO>
Downgraded: CC: MIME(<NON-ASCII-CC<ASCII-CC>>) Downgraded: CC: RFC2047(<NON-ASCII-CC>)
To: <ASCII-CC> CC: Internationalized address RFC2047(NON-ASCII-CC) removed:;
Date: DATE Date: DATE
MAIL_BODY MAIL_BODY
Figure 5: Header downgraded message Figure 5: Header downgraded message
RFC2047() stands for [RFC2047] encoding.
MIME() stands for [RFC2047] encoding. B.2. Displaying example (Displaying technique 1)
A.2. Upgrading example This example shows MIME decoded message of Figure 5.
This example shows upgrading process of Figure 5. Result of MIME decoding.
First, check 'Downgraded:' header existence. The UTF8SMTP downgraded Return-Path: <ASCII-FROM>
message has 'Downgraded:' headers. 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
Downgraded: From: <NON-ASCII-FROM <ASCII-FROM>>
From: <ASCII-FROM>
Downgraded: To: <NON-ASCII-TO <ASCII-TO>>
To: <ASCII-TO>
Downgraded: CC: <NON-ASCII-CC>
CC: Internationalized address NON-ASCII-CC removed:;
Date: DATE
Select 'Downgraded:' headers. MAIL_BODY
Downgraded: Envelope-Downgraded: From: Figure 6: MIME decoded message
MIME(<NON-ASCII-FROM>) <ASCII-FROM>
Downgraded: Envelope-Downgraded: To:
MIME(<NON-ASCII-TO>) <ASCII-TO>
Downgraded: From: MIME(<NON-ASCII-FROM<ASCII-FROM>>)
Downgraded: To: MIME(<NON-ASCII-TO<ASCII-TO>>)
Downgraded: CC: MIME(<NON-ASCII-CC<ASCII-CC>>)
Figure 6: Upgrading: selecting Downgraded headers B.3. Displaying example (Displaying technique 2)
This example has five Downgraded headers. This example shows displaying process of Appendix A.2 for Figure 5.
Decode 'Downgraded:' headers. First, check 'Downgraded:' header existence.
Envelope-Downgraded: From: <NON-ASCII-FROM> <ASCII-FROM> Select 'Downgraded:' headers.
Envelope-Downgraded: To: <NON-ASCII-TO> <ASCII-TO>
From: <NON-ASCII-FROM<ASCII-FROM>>
To: <NON-ASCII-TO<ASCII-TO>>
CC: <NON-ASCII-CC<ASCII-CC>>
Figure 7: Upgrading: upgraded Downgraded headers Downgraded: From: <NON-ASCII-FROM <ASCII-FROM>>
Downgraded: To: <NON-ASCII-TO <ASCII-TO>>
Downgraded: CC: <NON-ASCII-CC>
Figure 7: Displaying technique 2: selecting Downgraded headers
Apply address header downgrading to the decoded header. Apply address header downgrading to the decoded header.
From: <ASCII-FROM> From: <ASCII-FROM>
To: <ASCII-TO> To: <ASCII-TO>
CC: <ASCII-CC> CC: Internationalized address RFC2047(NON-ASCII-CC) removed:;
Figure 8: Displaying technique 2: downgraded decoded Downgraded
headers
Figure 8: Upgrading: downgraded upgraded Downgraded headers
Remove the header line which is the same with the downgraded line. Remove the header line which is the same with the downgraded line.
If the headers contain [RFC2047] encoded part, decode it before
comparison.
Downgraded: Envelope-Downgraded: From: Return-Path: <ASCII-FROM>
MIME(<NON-ASCII-FROM>) <ASCII-FROM> Envelope-Downgraded: From: <NON-ASCII-FROM> <ASCII-FROM>
Downgraded: Envelope-Downgraded: To: Envelope-Downgraded: To: <NON-ASCII-TO> <ASCII-TO>
MIME(<NON-ASCII-TO>) <ASCII-TO>
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: UTF-8_SUBJECT
Downgraded: From: MIME(<NON-ASCII-FROM<ASCII-FROM>>) Downgraded: From: <NON-ASCII-FROM <ASCII-FROM>>
Downgraded: To: MIME(<NON-ASCII-TO<ASCII-TO>>) Downgraded: To: <NON-ASCII-TO <ASCII-TO>>
Downgraded: CC: MIME(<NON-ASCII-CC<ASCII-CC>>) Downgraded: CC: <NON-ASCII-CC <ASCII-CC>>
Date: DATE Date: DATE
MAIL_BODY MAIL_BODY
Figure 9: Upgrading: Removing duplicated headers Figure 9: Displaying technique 2: Removing duplicated headers
Decode each 'Downgraded' header and replace it with its decoded Decode each 'Downgraded' header and replace it with its decoded
header. If each mail header has [RFC2047] encoded part and which header. 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.
Return-Path: <ASCII-FROM>
Envelope-Downgraded: From: <NON-ASCII-FROM> <ASCII-FROM> Envelope-Downgraded: From: <NON-ASCII-FROM> <ASCII-FROM>
Envelope-Downgraded: To: <NON-ASCII-TO> <ASCII-TO> Envelope-Downgraded: To: <NON-ASCII-TO> <ASCII-TO>
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<ASCII-CC>>
Date: DATE Date: DATE
MAIL_BODY MAIL_BODY
Figure 10: Downgraded header upgraded message Figure 10: Display technique 2: decoded message
As a result, in this simple example, all headers are preserved. As a result, in this simple example, all original header fields are
displayed in the original form.
A.3. Downgrading example 2 B.4. Downgrading example 2
In many cases, the sender wants to use Non-ASCII address and the In many cases, the sender wants to use non-ASCII address and the
recipient does not support UTF8SMTP and does not have Non-ASCII recipient does not support UTF8SMTP and does not have non-ASCII
address. address.
o The sender address is "NON-ASCII-FROM" which is Non-ASCII address. o The sender address is "NON-ASCII-FROM" which is non-ASCII address.
Its ASCII alternative is "ASCII-FROM". Its ASCII alternative is "ASCII-FROM".
o The "To" address is "ASCII-TO" which is ASCII only. o The "To" address is "ASCII-TO" which is ASCII only.
o The Subject header is "UTF8-SUBJECT" which contains Non-ASCII o The Subject header is "NON-ASCII-SUBJECT" which contains non-ASCII
characters. characters.
Original UTF8SMTP message SMTP session Original UTF8SMTP message SMTP session
MAIL From: <NON-ASCII-FROM> ALT-ADDRESS <ASCII-FROM> MAIL From: <NON-ASCII-FROM> ALT-ADDRESS <ASCII-FROM>
RCPT TO: <ASCII-TO> RCPT TO: <ASCII-TO>
------------------------------------------------------------- -------------------------------------------------------------
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: UTF8-SUBJECT Subject: NON-ASCII-SUBJECT
From: <NON-ASCII-FROM<ASCII-FROM>> From: <NON-ASCII-FROM<ASCII-FROM>>
To: <ASCII-TO> To: <ASCII-TO>
Date: DATE Date: DATE
MAIL_BODY MAIL_BODY
Figure 11: Original UTF8SMTP message 2 Figure 11: Original UTF8SMTP message 2
In this example, SMTP session is downgradable. Figure 12 shows SMTP In this example, SMTP session is downgradable. Figure 12 shows SMTP
downgrading. downgraded example.
After SMTP Downgrading
MAIL From: <ASCII-FROM> MAIL From: <ASCII-FROM>
RCPT TO: <ASCII-TO> RCPT TO: <ASCII-TO>
------------------------------------------------------------- -------------------------------------------------------------
Envelope-Downgraded: From: <NON-ASCII-FROM> <ASCII-FROM> Envelope-Downgraded: From: <RFC2047(NON-ASCII-FROM)> <ASCII-FROM>
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: UTF8-SUBJECT Subject: NON-ASCII-SUBJECT
From: <NON-ASCII-FROM<ASCII-FROM>> From: <NON-ASCII-FROM<ASCII-FROM>>
To: <ASCII-TO> To: <ASCII-TO>
Date: DATE Date: DATE
MAIL_BODY MAIL_BODY
Figure 12: SMTP Downgraded UTF8SMTP message 2 Figure 12: SMTP Downgraded UTF8SMTP message 2
After SMTP downgrading, header downgrading is performed. Final After SMTP downgrading, header downgrading is performed. The
downgraded messages are shown in Figure 13. downgraded example is shown in Figure 13.
Result of the header downgrading.
Downgraded: Envelope-Downgraded: From: Envelope-Downgraded: From: <RFC2047(NON-ASCII-FROM)> <ASCII-FROM>
MIME(<NON-ASCII-FROM>) <ASCII-FROM>
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: RFC2047(UTF-8_SUBJECT)
Downgraded: From: MIME(<NON-ASCII-FROM<ASCII-FROM>>) Downgraded: From: RFC2047(<NON-ASCII-FROM <ASCII-FROM>>)
From: <ASCII-FROM> From: <ASCII-FROM>
To: <ASCII-TO> To: <ASCII-TO>
Date: DATE Date: DATE
MAIL_BODY MAIL_BODY
Figure 13: Header downgraded message 2 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 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
Email: yone@jprs.co.jp Email: yone@jprs.co.jp
 End of changes. 131 change blocks. 
345 lines changed or deleted 523 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/