draft-ietf-eai-downgrade-05.txt   draft-ietf-eai-downgrade-06.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 November 18, 2007 Intended status: Experimental February 14, 2008
Expires: May 21, 2008 Expires: August 17, 2008
Downgrading mechanism for Email Address Internationalization Downgrading mechanism for Email Address Internationalization
draft-ietf-eai-downgrade-05.txt draft-ietf-eai-downgrade-06.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 May 21, 2008. This Internet-Draft will expire on August 17, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
Abstract Abstract
Traditional mail systems handle only ASCII characters in SMTP Traditional mail systems handle only ASCII characters in SMTP
envelope and mail header fields. The Email Address envelope and mail header fields. The Email Address
Internationalization (UTF8SMTP) extension allows UTF-8 characters in Internationalization (UTF8SMTP) extension allows UTF-8 characters in
SMTP envelope and mail header fields. To avoid bouncing SMTP envelope and mail header fields. To avoid bouncing
internationalized Email messages when a server in the delivery path internationalized Email messages when a server in the delivery path
does not support the UTF8SMTP extension, some sort of converting does not support the UTF8SMTP extension, some sort of converting
mechanism is required. This document describes a downgrading mechanism is required. This document describes a downgrading
skipping to change at page 2, line 22 skipping to change at page 2, line 22
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. New header fields definition . . . . . . . . . . . . . . . . . 5 3. New header fields definition . . . . . . . . . . . . . . . . . 5
3.1. Envelope information preservation headers . . . . . . . . 5 3.1. Envelope information preservation headers . . . . . . . . 5
3.2. Address header field preservation headers . . . . . . . . 5 3.2. Address header field preservation headers . . . . . . . . 5
3.3. Unknown header fields preservation headers . . . . . . . . 6 3.3. Unknown header fields preservation headers . . . . . . . . 6
4. SMTP Downgrading . . . . . . . . . . . . . . . . . . . . . . . 7 4. SMTP Downgrading . . . . . . . . . . . . . . . . . . . . . . . 7
5. Email header fields downgrading . . . . . . . . . . . . . . . 8 5. Email header fields downgrading . . . . . . . . . . . . . . . 8
5.1. Downgrading method for each header field . . . . . . . . . 9 5.1. Downgrading method for each header field . . . . . . . . . 9
6. MIME body part headers downgrading . . . . . . . . . . . . . . 11 6. MIME body part headers downgrading . . . . . . . . . . . . . . 11
7. Security considerations . . . . . . . . . . . . . . . . . . . 11 7. Security considerations . . . . . . . . . . . . . . . . . . . 12
8. Implementation notes . . . . . . . . . . . . . . . . . . . . . 12 8. Implementation notes . . . . . . . . . . . . . . . . . . . . . 12
8.1. Trivial downgrading . . . . . . . . . . . . . . . . . . . 12 8.1. Trivial downgrading . . . . . . . . . . . . . . . . . . . 13
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
11. Change History . . . . . . . . . . . . . . . . . . . . . . . . 15 11. Change History . . . . . . . . . . . . . . . . . . . . . . . . 15
11.1. draft-yoneya-ima-downgrade: Version 00 . . . . . . . . . . 15 11.1. draft-yoneya-ima-downgrade: Version 00 . . . . . . . . . . 16
11.2. draft-yoneya-ima-downgrade: Version 01 . . . . . . . . . . 15 11.2. draft-yoneya-ima-downgrade: Version 01 . . . . . . . . . . 16
11.3. draft-ietf-eai-downgrade: Version 00 . . . . . . . . . . . 16 11.3. draft-ietf-eai-downgrade: Version 00 . . . . . . . . . . . 16
11.4. draft-ietf-eai-downgrade: Version 01 . . . . . . . . . . . 16 11.4. draft-ietf-eai-downgrade: Version 01 . . . . . . . . . . . 16
11.5. draft-ietf-eai-downgrade: Version 02 . . . . . . . . . . . 16 11.5. draft-ietf-eai-downgrade: Version 02 . . . . . . . . . . . 16
11.6. draft-ietf-eai-downgrade: Version 03 . . . . . . . . . . . 16 11.6. draft-ietf-eai-downgrade: Version 03 . . . . . . . . . . . 16
11.7. draft-ietf-eai-downgrade: Version 04 . . . . . . . . . . . 16 11.7. draft-ietf-eai-downgrade: Version 04 . . . . . . . . . . . 16
11.8. draft-ietf-eai-downgrade: Version 05 . . . . . . . . . . . 17 11.8. draft-ietf-eai-downgrade: Version 05 . . . . . . . . . . . 17
11.9. draft-ietf-eai-downgrade: Version 06 . . . . . . . . . . . 17
12. Normative References . . . . . . . . . . . . . . . . . . . . . 17 12. Normative References . . . . . . . . . . . . . . . . . . . . . 17
Appendix A. Displaying downgraded message . . . . . . . . . . . . 18 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 18
A.1. Displaying technique 1 . . . . . . . . . . . . . . . . . . 18 A.1. Downgrading example 1 . . . . . . . . . . . . . . . . . . 18
A.2. Displaying technique 2 . . . . . . . . . . . . . . . . . . 19 A.2. Downgrading example 2 . . . . . . . . . . . . . . . . . . 21
Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
B.1. Downgrading example 1 . . . . . . . . . . . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . . . . 24
B.2. Displaying example . . . . . . . . . . . . . . . . . . . . 22
B.2.1. Displaying technique 1 example . . . . . . . . . . . . 23
B.2.2. Displaying technique 2 example . . . . . . . . . . . . 24
B.3. Downgrading example 2 . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28
Intellectual Property and Copyright Statements . . . . . . . . . . 30
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 ASCII characters in SMTP envelope and mail header field values. allow ASCII characters in SMTP envelope and mail header field values.
The UTF8SMTP extension [RFC4952], [I-D.ietf-eai-utf8headers] and The UTF8SMTP extension [RFC4952], [I-D.ietf-eai-utf8headers] and
[I-D.ietf-eai-smtpext] allows UTF-8 characters in SMTP envelope and [I-D.ietf-eai-smtpext] allows UTF-8 characters in SMTP envelope and
mail header field values. mail header field values.
If an envelope address or header field contains non-ASCII characters, If an envelope address or header field contains non-ASCII characters,
skipping to change at page 4, line 21 skipping to change at page 4, line 21
The SMTP downgrading is described in Section 4. It generates ASCII The SMTP downgrading is described in Section 4. It generates ASCII
only envelope information from an UTF8SMTP envelope. only envelope information from an UTF8SMTP envelope.
The Email header fields downgrading is described in Section 5. It The Email header fields downgrading is described in Section 5. It
generates ASCII only header fields. generates ASCII only header fields.
The MIME header fields are expanded in [I-D.ietf-eai-utf8headers]. The MIME header fields are expanded in [I-D.ietf-eai-utf8headers].
The MIME header fields downgrading is described in Section 6. It The MIME header fields downgrading is described in Section 6. It
generates ASCII only MIME header fields. generates ASCII only MIME header fields.
Decoding downgraded message is described in Appendix A. This
mechanism is for use by internationalized email clients. Once a
message has been downgraded, there is no up-conversion which can be
applied on the SMTP delivery path.
2. Terminology 2. Terminology
The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
and "MAY" in this document are to be interpreted as described in RFC "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
All specialized terms used in this specification are defined in the All specialized terms used in this specification are defined in the
EAI overview [RFC4952] or in [RFC2821][RFC2822], MIME documents EAI overview [RFC4952] or in [RFC2821][RFC2822], MIME documents
[RFC2045] [RFC2047] [RFC2183] [RFC2231]. The terms "ASCII address", [RFC2045] [RFC2047] [RFC2183] [RFC2231]. The terms "ASCII address",
"internationalized email address", "non-ASCII address", "i18mail "internationalized email address", "non-ASCII address", "i18mail
address", "UTF8SMTP", "message" and "mailing list" are used with the address", "UTF8SMTP", "message" and "mailing list" are used with the
definitions from [RFC4952] document. definitions from [RFC4952] document.
This document depends on [I-D.ietf-eai-smtpext], This document depends on [I-D.ietf-eai-smtpext],
[I-D.ietf-eai-utf8headers], and [I-D.ietf-eai-dsn]. Key words used [I-D.ietf-eai-utf8headers], and [I-D.ietf-eai-dsn]. Key words used
skipping to change at page 5, line 8 skipping to change at page 5, line 7
non-ASCII character. non-ASCII character.
An "UTF8SMTP envelope" has Email originator/recipient addresses An "UTF8SMTP envelope" has Email originator/recipient addresses
expanded by [I-D.ietf-eai-smtpext] and [I-D.ietf-eai-dsn]. expanded by [I-D.ietf-eai-smtpext] and [I-D.ietf-eai-dsn].
An "UTF8SMTP message" is Email messages expanded by An "UTF8SMTP message" is Email messages expanded by
[I-D.ietf-eai-utf8headers]. [I-D.ietf-eai-utf8headers].
3. New header fields definition 3. New header fields definition
New header fields starting with "downgraded" are defined here to New header fields starting with "Downgraded-" are defined here to
preserve those original envelope and header values which contain preserve those original envelope and header values which contain
UTF-8 characters. During downgrading, one new "downgraded" header UTF-8 characters. During downgrading, one new "Downgraded-" header
field is added for each original envelope or header field which field is added for each original envelope or header field which
cannot be passed as-is to a server which does not support UTF8SMTP. cannot be passed as-is to a server which does not support UTF8SMTP.
The original envelope or header field is removed or altered. Only The original envelope or header field is removed or rewritten. Only
those envelope and header fields which contain non-ASCII characters those envelope and header fields which contain non-ASCII characters
are affected. The result of this process is a message which is are affected. The result of this process is a message which is
compliant with existing email specifications [RFC2821] and [RFC2822]. compliant with existing email specifications [RFC2821] and [RFC2822].
The original internationalized information can be retrieved by The original internationalized information can be retrieved by
examining the "downgraded" header fields which were added. Even examining the "Downgraded-" header fields which were added. Even
though the information is not lost, the original message cannot be though the information is not lost, the original message cannot be
perfectly reconstructed. Hence, downgrading is a one-way process. perfectly reconstructed. Hence, downgrading is a one-way process.
However, an internationalized client might use the information in the However, an internationalized client might use the information in the
"downgraded" header fields when processing a downgraded message, for "Downgraded-" header fields when processing a downgraded message, for
example, such as displaying or composing a reply. example, such as displaying or composing a reply.
3.1. Envelope information preservation headers 3.1. Envelope information preservation headers
Two headers "Downgraded-Mail-From:" and "Downgraded-Rcpt-To:" are Two headers "Downgraded-Mail-From:" and "Downgraded-Rcpt-To:" are
defined to preserve SMTP envelope downgraded information. SMTP defined to preserve SMTP envelope downgraded information. SMTP
envelope downgraded information consists of the original non-ASCII envelope downgraded information consists of the original non-ASCII
address and the downgraded all-ASCII address. The header field address and the downgraded all-ASCII address. The header field
syntax is specified as follows: syntax is specified as follows:
skipping to change at page 6, line 42 skipping to change at page 6, line 41
fields =/ unknown-downgraded-headers ":" unstructued CRLF fields =/ unknown-downgraded-headers ":" unstructued CRLF
unknown-downgraded-headers = "Downgraded-" original-header-field-name unknown-downgraded-headers = "Downgraded-" original-header-field-name
original-header-field-name = field-name original-header-field-name = field-name
field-name = 1*ftext field-name = 1*ftext
ftext = %d33-57 / ; Any character except ftext = %d33-57 / ; Any character except
%d59-126 ; controls, SP, and %d59-126 ; controls, SP, and
; ":". ; ":".
Encapsulating a header field in a Downgraded header field is defined Encapsulating a header field in a "Downgraded-" header field is
as: defined as:
1. Generate new Downgraded header whose value is the original header 1. Generate new "Downgraded-" header whose value is the original
field value. header field value.
2. Encode the generated header field value according to [RFC2047]
with charset='UTF-8'. To preserve space characters, the whole
header field value which include space characters SHOULD be
encoded.
2. Encode the generated header field according to [RFC2047] with
charset='UTF-8'.
3. Remove the original header field. 3. Remove the original header field.
4. SMTP Downgrading 4. SMTP Downgrading
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 o ORCPT parameter
skipping to change at page 8, line 5 skipping to change at page 7, line 48
NOT add "Downgraded-Rcpt-To:" header if the SMTP downgrading targets NOT add "Downgraded-Rcpt-To:" header if the SMTP downgrading targets
multiple recipients. See Section 7 for more detail. multiple recipients. See Section 7 for more detail.
The "RCPT TO" command may have an ORCPT parameter when the recipient The "RCPT TO" command may have an ORCPT parameter when the recipient
address is downgraded. The ORCPT parameter is used for DSN address is downgraded. The ORCPT parameter is used for DSN
[RFC3461]. If the ORCPT parameter contains an "utf-8" address and [RFC3461]. If the ORCPT parameter contains an "utf-8" address and
the address contains non-ASCII characters, the ORCPT parameter MUST the address contains non-ASCII characters, the ORCPT parameter MUST
be converted to utf-8-addr-xtext form or utf-8-addr-unitext form be converted to utf-8-addr-xtext form or utf-8-addr-unitext form
which are described in [I-D.ietf-eai-dsn]. which are described in [I-D.ietf-eai-dsn].
As a result of the recipient address replacement, the domain part of
the original recipient address may not equal to the domain part of
the new recipient address. If the result of address resolution for
the domain part of the new recipient address contains the server at
the connection destination of the SMTP session for the original
recipient address, the SMTP connection is valid for the new recipient
address. Otherwise, the downgrading process MUST NOT send the
downgraded message to the new recipient address via the connection
and MUST try to send the downgraded message to the new recipient
address.
5. Email header fields downgrading 5. Email header fields downgrading
This section defines the conversion method to ASCII for each header This section defines the conversion method to ASCII for each header
field which may contain non-ASCII characters. field which may contain non-ASCII characters.
[I-D.ietf-eai-utf8headers] expands Received: header fields, [RFC2822] [I-D.ietf-eai-utf8headers] expands Received: header fields, [RFC2822]
ABNF elements <mailbox>, <word>, <comment>, <unstructured>, [RFC2045] ABNF elements <mailbox>, <word>, <comment>, <unstructured>, [RFC2045]
ABNF element <value>. ABNF element <value>.
Header field downgrading is defined below for each ABNF element. Header field downgrading is defined below for each ABNF element.
Downgrading an unknown header field is also defined as ENCAPSULATION Downgrading an unknown header field is also defined as ENCAPSULATION
downgrading. Converting the header field terminates when no non- downgrading. Converting the header field terminates when no non-
ASCII characters remain in the header field. ASCII characters remain in the header field.
RECEIVED downgrading: If the header field name is "Received:" and RECEIVED downgrading: If the header field name is "Received:" and
the FOR clause contains a non-ASCII addresses, remove the FOR the FOR clause contains a non-ASCII addresses, remove the FOR
clause from the header field. The other part except in the clause from the header field. The other part does not contain
comments does not contain non-ASCII values. non-ASCII values.
UNSTRUCTURED downgrading: If the header field has an <unstructured> UNSTRUCTURED downgrading: If the header field has an <unstructured>
field which contains non-ASCII characters, encode the field field which contains non-ASCII characters, encode the field
according to [RFC2047] with charset='UTF-8'. according to [RFC2047] with charset='UTF-8'. To preserve space
characters, the whole header field value which include space
characters SHOULD be encoded.
WORD downgrading: If the header field has any <word> fields which WORD downgrading: If the header field has any <word> fields which
contains non-ASCII characters, encode the fields according to contains non-ASCII characters, encode the fields according to
[RFC2047] with charset='UTF-8'. [RFC2047] with charset='UTF-8'.
COMMENT downgrading: If the header field has any <comment> fields COMMENT downgrading: If the header field has any <comment> fields
which contains non-ASCII characters, encode the fields according which contains non-ASCII characters, encode the fields according
to [RFC2047] with charset='UTF-8'. to [RFC2047] with charset='UTF-8'.
MIME-VALUE downgrading: If the header field has any <value> MIME-VALUE downgrading: If the header field has any <value>
skipping to change at page 9, line 38 skipping to change at page 10, line 4
5.1. Downgrading method for each header field 5.1. Downgrading method for each header field
Header fields are listed in [RFC4021]. This section describes the Header fields are listed in [RFC4021]. This section describes the
downgrading method for each header field. downgrading method for each header field.
If the whole mail header field does not contain non-ASCII characters, If the whole mail header field does not contain non-ASCII characters,
email header field downgrading is not required. Each header field's email header field downgrading is not required. Each header field's
downgrading method is described below. downgrading method is described below.
o Address header fields which contain <mailbox>s o Address header fields which contain <mailbox>s
From: From:
Sender: Sender:
Reply-To: Reply-To:
To: To:
Cc: Cc:
Bcc: Bcc:
Resent-From: Resent-From:
Resent-Sender: Resent-Sender:
Resent-To: Resent-To:
Resent-Cc: Resent-Cc:
Return-Path: Return-Path:
If the header field contains <mailbox> elements which contains If the header field contains <mailbox> elements which contains
non-ASCII addresses, preserve the header field in a downgraded non-ASCII addresses, preserve the header field in a downgraded
header before the conversion. Then do COMMENT downgrading, header before the conversion. Then perform COMMENT downgrading,
DISPLAY-NAME downgrading and MAILBOX downgrading. DISPLAY-NAME downgrading and MAILBOX downgrading.
o Downgrading Non-ASCII in comments o Downgrading Non-ASCII in comments
Date: Date:
Message-ID: Message-ID:
In-Reply-To: In-Reply-To:
References: References:
Resent-Date: Resent-Date:
Resent-Message-ID: Resent-Message-ID:
MIME-Version: MIME-Version:
Content-ID: Content-ID:
These header fields do not contain non-ASCII characters except in These header fields do not contain non-ASCII characters except in
comments. If the header contains UTF-8 characters in comments, do comments. If the header contains UTF-8 characters in comments,
COMMENT downgrading. perform COMMENT downgrading.
o Trace header fields o Trace header fields
Received: Received:
do COMMENT downgrading and do RECEIVED downgrading. perform COMMENT downgrading and perform RECEIVED downgrading.
o MIME Content header fields o MIME Content header fields
Content-Type: Content-Type:
Content-Disposition: Content-Disposition:
Do MIME-VALUE downgrading. Perform MIME-VALUE downgrading.
o Non-ASCII in <unstructured> o Non-ASCII in <unstructured>
Subject: Subject:
Comments: Comments:
Content-Description: Content-Description:
Do UNSTRUCTURED downgrading. Perform UNSTRUCTURED downgrading.
o Non-ASCII in <unstructured> or <phrase> o Non-ASCII in <unstructured> or <phrase>
Keywords: Keywords:
Do WORD downgrading. Perform WORD downgrading.
o Other header fields o Other header fields
All other header fields which contains non-ASCII characters are All other header fields which contains non-ASCII characters are
user-defined, missing from this draft or future defined header user-defined, missing from this draft or future defined header
fields. Do ENCAPSULATION downgrading as a last resort. fields. Perform ENCAPSULATION downgrading as a last resort.
6. MIME body part headers downgrading 6. MIME body part headers downgrading
MIME body part header fields may contain non-ASCII characters MIME body part header fields may contain non-ASCII characters
[I-D.ietf-eai-utf8headers]. This section defines the conversion [I-D.ietf-eai-utf8headers]. This section defines the conversion
method to ASCII only header fields for each MIME header field which method to ASCII only header fields for each MIME header field which
contains non-ASCII characters. Parse the message body's MIME contains non-ASCII characters. Parse the message body's MIME
structure for all levels and check each MIME header field whether it structure for all levels and check each MIME header field whether it
contains non-ASCII characters. If the header field contains non- contains non-ASCII characters. If the header field contains non-
ASCII characters in the header value, the header is a target of the ASCII characters in the header value, the header is a target of the
MIME body part headers downgrading. Each MIME header field's MIME body part headers downgrading. Each MIME header field's
downgrading method is described below. COMMENT downgrading, MIME- downgrading method is described below. COMMENT downgrading, MIME-
VALUE downgrading, UNSTRUCTURED downgrading are described in VALUE downgrading, UNSTRUCTURED downgrading are described in
Section 5. Section 5.
Content-ID: Content-ID:
The Content-ID: header does not contain non-ASCII characters The Content-ID: header does not contain non-ASCII characters
except in comments. If the header contains UTF-8 characters in except in comments. If the header contains UTF-8 characters in
comments, do COMMENT downgrading. comments, perform COMMENT downgrading.
Content-Type: Content-Type:
Content-Disposition: Content-Disposition:
Do MIME-VALUE downgrading. Perform MIME-VALUE downgrading.
Content-Description: Content-Description:
Do UNSTRUCTURED downgrading. Perform UNSTRUCTURED downgrading.
7. Security considerations 7. Security considerations
o A Downgraded message's header fields contain ASCII characters o A Downgraded message's header fields contain ASCII characters
only. But they still contain MIME encapsulated header fields only. But they still contain MIME encapsulated header fields
which contains non-ASCII UTF-8 characters. And more, the body which contains non-ASCII UTF-8 characters. And more, the body
part may contain UTF-8 message. The recipients need to accept part may contain UTF-8 message. The recipients need to accept
UTF-8 mail body and UTF-8 header fields which is MIME encoded. UTF-8 mail body and UTF-8 header fields which is MIME encoded.
o Rewriting headers increases the opportunities for undetected o Rewriting headers increases the opportunities for undetected
spoofing. spoofing.
o Recipients addresses can be undisclosed if those addresses are o Recipients addresses can be undisclosed if those addresses are
listed on Bcc or group address. Those undisclosed addresses are listed on Bcc or group address. Those undisclosed addresses are
used only in the Envelope. Copying information from the Envelope used only in the Envelope. Copying information from the Envelope
into headers risks inadvertent information disclosure (not just into headers risks inadvertent information disclosure (not just
about addresses). See Section 4 for instructions on recipient about addresses). See Section 4 for instructions on recipient
address handling. address handling.
skipping to change at page 12, line 16 skipping to change at page 12, line 23
spoofing. spoofing.
o Recipients addresses can be undisclosed if those addresses are o Recipients addresses can be undisclosed if those addresses are
listed on Bcc or group address. Those undisclosed addresses are listed on Bcc or group address. Those undisclosed addresses are
used only in the Envelope. Copying information from the Envelope used only in the Envelope. Copying information from the Envelope
into headers risks inadvertent information disclosure (not just into headers risks inadvertent information disclosure (not just
about addresses). See Section 4 for instructions on recipient about addresses). See Section 4 for instructions on recipient
address handling. address handling.
o The techniques described here invalidates methods that depend on o The techniques described here invalidates methods that depend on
signatures over the envelope or any part of the message which digital signatures over the envelope or any part of the message
includes the top-level header or body part headers. Depending on which includes the top-level header or body part headers.
the specific message being downgraded, DKIM especially, but also Depending on the specific message being downgraded, DKIM
possibly S/MIME, PGP, and similar techniques are all likely to especially, but also possibly S/MIME, PGP, and similar techniques
break. are all likely to break.
o Many gateways and servers on the Internet will discard headers o Many gateways and servers on the Internet will discard headers
with which they are not familiar. To the extent to which the with which they are not familiar. To the extent to which the
downgrade procedures depend on new headers (e.g., "Downgraded") to downgrade procedures depend on new headers (e.g., "Downgraded") to
avoid information loss, then the risk of having those headers avoid information loss, then the risk of having those headers
dropped and its implications must be identified. In particular, dropped and its implications must be identified. In particular,
it appears to me that, if the Downgraded headers are dropped, it appears to me that, if the Downgraded headers are dropped,
there is no possibility of reconstructing the original information there is no possibility of reconstructing the original information
at any point (before, during, or after delivery). at any point (before, during, or after delivery).
skipping to change at page 17, line 16 skipping to change at page 17, line 25
o fixed examples o fixed examples
* ALT-ADDRESS parameter mistake * ALT-ADDRESS parameter mistake
* RFC2047(x) notation was changed to encoded-word format * RFC2047(x) notation was changed to encoded-word format
o Added implementation consideration section and trivial downgrading o Added implementation consideration section and trivial downgrading
o Downgraded: and Envelope-Downgraded: headers are separated for o Downgraded: and Envelope-Downgraded: headers are separated for
each original headers. each original headers.
o Removed list-* header fields downgrading o Removed list-* header fields downgrading
o Changed the way of writing the header field downgrading section o Changed the way of writing the header field downgrading section
11.9. draft-ietf-eai-downgrade: Version 06
o Moved decoding downgraded messages as a separate document
o Added a text to UNSTRUCTURED downgrading
o Added "replacing SMTP connection" if necessary to SMTP
downgrading.
o fixed examples
12. Normative References 12. Normative References
[I-D.ietf-eai-dsn] [I-D.ietf-eai-dsn]
Newman, C. and A. Melnikov, "International Delivery and Newman, C. and A. Melnikov, "Internationalized Delivery
Disposition Notifications", draft-ietf-eai-dsn-05 (work in Status and Disposition Notifications",
progress), November 2007. draft-ietf-eai-dsn-06 (work in progress), January 2008.
[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-09 (work in email address", draft-ietf-eai-smtpext-11 (work in
progress), November 2007. progress), January 2008.
[I-D.ietf-eai-utf8headers] [I-D.ietf-eai-utf8headers]
Yeh, J., "Internationalized Email Headers", Yeh, J., "Internationalized Email Headers",
draft-ietf-eai-utf8headers-07 (work in progress), draft-ietf-eai-utf8headers-09 (work in progress),
September 2007. February 2008.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996. 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 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
skipping to change at page 18, line 25 skipping to change at page 18, line 43
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90, RFC 3864, Procedures for Message Header Fields", BCP 90, RFC 3864,
September 2004. September 2004.
[RFC4021] Klyne, G. and J. Palme, "Registration of Mail and MIME [RFC4021] Klyne, G. and J. Palme, "Registration of Mail and MIME
Header Fields", RFC 4021, March 2005. Header Fields", RFC 4021, March 2005.
[RFC4952] Klensin, J. and Y. Ko, "Overview and Framework for [RFC4952] Klensin, J. and Y. Ko, "Overview and Framework for
Internationalized Email", RFC 4952, July 2007. Internationalized Email", RFC 4952, July 2007.
Appendix A. Displaying downgraded message Appendix A. Examples
A perfect reverse-function of the downgrading does not exist because
the encoding defined in [RFC2047] is not exactly reversible. The
restoration of the downgrading should be done once at the final
destination of the downgraded message such as MUAs or IMAP servers.
This document describes the restoration methods as displaying
technique.
Displaying downgraded message is mostly retrieved by MIME decoding
according to [RFC2047] and [RFC2231]. Result of MIME decoding,
downgraded header fields are still in Downgraded-*: header fields,
but the header field values are MIME decoded. These decoded
Downgraded-*: header fields contain the original header field values
and the recipient can read them. But the recipient's MUA cannot use
the original header fields automatically.
Additionally, MUAs can process 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' name. 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 field, generate new header field
which field name is the original header name and the field value
is the decoded header field value.
* If the header is an address header described in Section 5,
+ Generate ASCII only header fields defined in Section 5 from
the decoded header fields without re-generating
Downgraded-*: header fields.
+ Remove the header field which is the same with the generated
ASCII only header from the header fields. This comparison
requires considerations for foldings and [RFC2047] encoded
parts.
Appendix B. Examples
B.1. Downgrading example 1 A.1. Downgrading example 1
This section shows an SMTP Downgrading example. Consider a mail This section shows an SMTP Downgrading example. Consider a mail
message. message.
o The sender address is "NON-ASCII-local@example.com" which is non- o The sender address is "NON-ASCII-local@example.com" which is non-
ASCII address. Its ASCII alternative is "ASCII-local@example.com" ASCII address. Its ASCII alternative is "ASCII-local@example.com"
and its display-name is "DISPLAY-local". and its display-name is "DISPLAY-local".
o The "To" address is "NON-ASCII-remote1@example.net" which is non- o The "To" address is "NON-ASCII-remote1@example.net" which is non-
ASCII address. Its ASCII alternative is ASCII address. Its ASCII alternative is
"ASCII-remote1@example.net" and its display-name is "DISPLAY- "ASCII-remote1@example.net" and its display-name is "DISPLAY-
remote1". remote1".
o The "CC" address is non-ASCII address o The "CC" address is non-ASCII address
"NON-ASCII-remote2@example.org" without alternative ASCII address. "NON-ASCII-remote2@example.org" without alternative ASCII address.
Its display-name is "DISPLAY-remote2". Its display-name is "DISPLAY-remote2".
skipping to change at page 20, line 5 skipping to change at page 19, line 24
Its display-name is "DISPLAY-remote2". Its display-name is "DISPLAY-remote2".
o Three display-names contains non-ASCII characters. o Three display-names contains non-ASCII characters.
o The Subject header is "NON-ASCII-SUBJECT" which contains non-ASCII o The Subject header is "NON-ASCII-SUBJECT" which contains non-ASCII
characters. characters.
o assume To: recipient's MTA (example.net) does not support o assume To: recipient's MTA (example.net) does not support
UTF8SMTP. UTF8SMTP.
o assume Cc: recipient's MTA (example.org) supports UTF8SMTP. o assume Cc: recipient's MTA (example.org) supports UTF8SMTP.
The example SMTP envelope/message is showin in Figure 4. In this The example SMTP envelope/message is showin in Figure 4. In this
example, the To: recipient's session is fucused. example, the To: recipient's session is fucused.
MAIL From: <NON-ASCII-local@example.com> MAIL FROM: <NON-ASCII-local@example.com>
ALT-ADDRESS=ASCII-local@example.com ALT-ADDRESS=ASCII-local@example.com
RCPT TO: <NON-ASCII-remote1@example.net> RCPT TO: <NON-ASCII-remote1@example.net>
ALT-ADDRESS=ASCII-remote1@example.net ALT-ADDRESS=ASCII-remote1@example.net
RCPT TO: <NON-ASCII-remote2@example.org> RCPT TO: <NON-ASCII-remote2@example.org>
------------------------------------------------------------- -------------------------------------------------------------
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: NON-ASCII-SUBJECT Subject: NON-ASCII-SUBJECT
skipping to change at page 21, line 5 skipping to change at page 20, line 5
Date: DATE Date: DATE
MAIL_BODY MAIL_BODY
Figure 4: Original envelope/message (example 1) Figure 4: Original envelope/message (example 1)
In this example, there are two SMTP recipients, one is To:, the other In this example, there are two SMTP recipients, one is To:, the other
is CC:. The SMTP downgrading treats To: session downgrading. is CC:. The SMTP downgrading treats To: session downgrading.
Figure 5 shows SMTP downgraded example. Figure 5 shows SMTP downgraded example.
MAIL From: <ASCII-local@example.com> MAIL FROM: <ASCII-local@example.com>
RCPT TO: <ASCII-remote1@example.net> RCPT TO: <ASCII-remote1@example.net>
------------------------------------------------------------- -------------------------------------------------------------
Downgraded-Mail-From: =?UTF-8?Q?<NON-ASCII-local@example.com>?= Downgraded-Mail-From: =?UTF-8?Q?<NON-ASCII-local@example.com>_?=
<ASCII-local@example.com> =?UTF-8?Q?<ASCII-local@example.com>?=
Downgraded-Rcpt-To: =?UTF-8?Q?<NON-ASCII-remote1@example.net>?= Downgraded-Rcpt-To: =?UTF-8?Q?<NON-ASCII-remote1@example.net>_?=
<ASCII-remote1@example.net> =?UTF-8?Q?<ASCII-remote1@example.net>?=
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: NON-ASCII-SUBJECT Subject: NON-ASCII-SUBJECT
From: DISPLAY-local <NON-ASCII-local@example.com From: DISPLAY-local <NON-ASCII-local@example.com
<ASCII-local@example.com>> <ASCII-local@example.com>>
To: DISPLAY-remote1 <NON-ASCII-remote1@example.net To: DISPLAY-remote1 <NON-ASCII-remote1@example.net
<ASCII-remote1@example.net>> <ASCII-remote1@example.net>>
CC: DISPLAY-remote2 <NON-ASCII-remote2@example.org> CC: DISPLAY-remote2 <NON-ASCII-remote2@example.org>
skipping to change at page 22, line 6 skipping to change at page 21, line 6
MAIL_BODY MAIL_BODY
Figure 5: SMTP Downgraded envelope/message (example 1) Figure 5: SMTP Downgraded envelope/message (example 1)
After SMTP downgrading, header fields downgrading is performed. After SMTP downgrading, header fields downgrading is performed.
Final downgraded message is shown in Figure 6. Return-Path header Final downgraded message is shown in Figure 6. Return-Path header
will be added by the final destination MTA. will be added by the final destination MTA.
Return-Path: <ASCII-local@example.com> Return-Path: <ASCII-local@example.com>
Downgraded-Mail-From: =?UTF-8?Q?<NON-ASCII-local@example.com>?= Downgraded-Mail-From: =?UTF-8?Q?<NON-ASCII-local@example.com>_?=
<ASCII-local@example.com> =?UTF-8?Q?<ASCII-local@example.com>?=
Downgraded-Rcpt-To: =?UTF-8?Q?<NON-ASCII-remote1@example.net>?= Downgraded-Rcpt-To: =?UTF-8?Q?<NON-ASCII-remote1@example.net>_?=
<ASCII-remote1@example.net> =?UTF-8?Q?<ASCII-remote1@example.net>?=
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?Q?NON-ASCII-SUBJECT?= Subject: =?UTF-8?Q?NON-ASCII-SUBJECT?=
Downgraded-From: =?UTF-8?Q?DISPLAY-local?=
=?UTF-8?Q?<NON-ASCII-local@example.com?= <ASCII-local@example.com>>
From: =?UTF-8?Q?DISPLAY-local?= <ASCII-local@example.com> From: =?UTF-8?Q?DISPLAY-local?= <ASCII-local@example.com>
Downgraded-From: =?UTF-8?Q?DISPLAY-local_<NON-ASCII-local@example.com_?=
=?UTF-8?Q?<ASCII-local@example.com>>?=
To: =?UTF-8?Q?DISPLAY-remote1?= <ASCII-remote1@example.net> To: =?UTF-8?Q?DISPLAY-remote1?= <ASCII-remote1@example.net>
Downgraded-To: =?UTF-8?Q?DISPLAY-remote1?= Downgraded-To: =?UTF-8?Q?DISPLAY-remote1_?=
=?UTF-8?Q?<NON-ASCII-remote1@example.net?= <ASCII-remote1@example.net>> =?UTF-8?Q?<NON-ASCII-remote1@example.net_<ASCII-remote1@example.net>>?=
CC: =?UTF-8?Q?DISPLAY-remote2?= Internationalized address CC: =?UTF-8?Q?DISPLAY-remote2?= Internationalized address
=?UTF-8?Q?NON-ASCII-remote2@example.org?= removed:; =?UTF-8?Q?NON-ASCII-remote2@example.org?= removed:;
Downgraded-CC: =?UTF-8?Q?DISPLAY-remote2?= Downgraded-CC: =?UTF-8?Q?DISPLAY-remote2_?=
=?UTF-8?Q?<NON-ASCII-remote2@example.org>?= =?UTF-8?Q?<NON-ASCII-remote2@example.org>?=
Date: DATE Date: DATE
MAIL_BODY MAIL_BODY
Figure 6: Downgraded message (example 1) Figure 6: Downgraded message (example 1)
B.2. Displaying example A.2. Downgrading example 2
Figure 7 shows MIME decoded message of Figure 6.
Return-Path: <ASCII-local@example.com>
Downgraded-Mail-From: <NON-ASCII-local@example.com>
<ASCII-local@example.com>
Downgraded-Rcpt-To: <NON-ASCII-remote1@example.net>
<ASCII-remote1@example.net>
Message-Id: MESSAGE_ID
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Subject: NON-ASCII-SUBJECT
Downgraded-From: DISPLAY-local<NON-ASCII-local@example.com
<ASCII-local@example.com>>
From: DISPLAY-local <ASCII-local@example.com>
Downgraded-To: DISPLAY-remote1<NON-ASCII-remote1@example.net
<ASCII-remote1@example.net>>
To: DISPLAY-remote1 <ASCII-remote1@example.net>
Downgraded-CC: DISPLAY-remote2<NON-ASCII-remote2@example.org>
CC: DISPLAY-remote2 Internationalized address
NON-ASCII-remote2@example.org removed:;
Date: DATE
MAIL_BODY
Figure 7: MIME decoded message
B.2.1. Displaying technique 1 example
After removing 'Downgraded-' from decoded 'Downgraded-*:' header
fields
Return-Path: <ASCII-local@example.com>
Downgraded-Mail-From: <NON-ASCII-local@example.com>
<ASCII-local@example.com>
Downgraded-Rcpt-To: <NON-ASCII-remote1@example.net>
<ASCII-remote1@example.net>
Message-Id: MESSAGE_ID
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Subject: NON-ASCII-SUBJECT
From: DISPLAY-local<NON-ASCII-local@example.com
<ASCII-local@example.com>>
From: DISPLAY-local <ASCII-local@example.com>
To: DISPLAY-remote1<NON-ASCII-remote1@example.net
<ASCII-remote1@example.net>>
To: DISPLAY-remote1 <ASCII-remote1@example.net>
CC: DISPLAY-remote2<NON-ASCII-remote2@example.org>
CC: DISPLAY-remote2 Internationalized address
NON-ASCII-remote2@example.org removed:;
Date: DATE
MAIL_BODY
Figure 8: Displaying technique 1
B.2.2. Displaying technique 2 example
This example shows displaying process of Appendix A.2 for Figure 6.
First, check downgraded address header fields existence.
Downgraded-From: =?UTF-8?Q?DISPLAY-local?=
=?UTF-8?Q?<NON-ASCII-local@example.com?= <ASCII-local@example.com>>
Downgraded-To: =?UTF-8?Q?DISPLAY-remote1?=
=?UTF-8?Q?<NON-ASCII-remote1@example.net?= <ASCII-remote1@example.net>>
Downgraded-CC: =?UTF-8?Q?DISPLAY-remote2?=
=?UTF-8?Q?<NON-ASCII-remote2@example.org>?=
Figure 9: Displaying technique 2: selecting downgraded address header
fields
Then, decode MIME encoded parts.
Downgraded-From: DISPLAY-local<NON-ASCII-local@example.com
<ASCII-local@example.com>>
Downgraded-To: DISPLAY-remote1<NON-ASCII-remote1@example.net
<ASCII-remote1@example.net>>
Downgraded-CC: DISPLAY-remote2<NON-ASCII-remote2@example.org>
Figure 10: Displaying technique 2: decode downgraded address header
fields
Apply header fields downgrading to the decoded header without re-
generating Downgraded-*: header.
From: =?UTF-8?Q?DISPLAY-local?= <ASCII-local@example.com>
To: =?UTF-8?Q?DISPLAY-remote1?= <ASCII-remote1@example.net>
CC: =?UTF-8?Q?DISPLAY-remote2?= Internationalized address
=?UTF-8?Q?NON-ASCII-remote2@example.org?= removed:;
Figure 11: Displaying technique 2: downgraded decoded 'Downgraded-*:'
Remove the header fields which is the same with Figure 11 from
Figure 6.
Return-Path: <ASCII-local@example.com>
Downgraded-Mail-From: =?UTF-8?Q?<NON-ASCII-local@example.com>?=
<ASCII-local@example.com>
Downgraded-Rcpt-To: =?UTF-8?Q?<NON-ASCII-remote1@example.net>?=
<ASCII-remote1@example.net>
Message-Id: MESSAGE_ID
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Subject: =?UTF-8?Q?NON-ASCII-SUBJECT?=
Downgraded-From: =?UTF-8?Q?DISPLAY-local?=
=?UTF-8?Q?<NON-ASCII-local@example.com?= <ASCII-local@example.com>>
Downgraded-To: =?UTF-8?Q?DISPLAY-remote1?=
=?UTF-8?Q?<NON-ASCII-remote1@example.net?= <ASCII-remote1@example.net>>
Downgraded-CC: =?UTF-8?Q?DISPLAY-remote2?=
=?UTF-8?Q?<NON-ASCII-remote2@example.org>?=
Date: DATE
MAIL_BODY
Figure 12: Displaying technique 2: Removing duplicated headers
Decode each 'Downgraded' header and replace it with its decoded
header. If each mail header has [RFC2047] encoded part and which
encoding is "UTF-8", it is a downgraded header, so decode it.
Return-Path: <ASCII-local@example.com>
Downgraded-Mail-From: <NON-ASCII-local@example.com>
<ASCII-local@example.com>
Downgraded-Rcpt-To: <NON-ASCII-remote1@example.net>
<ASCII-remote1@example.net>
Message-Id: MESSAGE_ID
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Subject: NON-ASCII-SUBJECT
From: DISPLAY-local<NON-ASCII-local@example.com
<ASCII-local@example.com>>
To: DISPLAY-remote1<NON-ASCII-remote1@example.net
<ASCII-remote1@example.net>>
CC: DISPLAY-remote2<NON-ASCII-remote2@example.org>
Date: DATE
MAIL_BODY
Figure 13: Display technique 2: decoded message
As a result, in this simple example, all original header fields are
displayed in the original form.
B.3. Downgrading example 2
In many cases, the sender wants to use non-ASCII address, the In many cases, the sender wants to use non-ASCII address, 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-local@example.com" which is non- o The sender address is "NON-ASCII-local@example.com" which is non-
ASCII address. Its ASCII alternative is ASCII address. Its ASCII alternative is
"ASCII-local@example.com". It has a display-name "DISPLAY-local" "ASCII-local@example.com". It has a display-name "DISPLAY-local"
which contains non-ASCII characters. which contains non-ASCII characters.
o The "To" address is "ASCII-remote1@example.net" which is ASCII o The "To" address is "ASCII-remote1@example.net" which is ASCII
only. It has a display-name "DISPLAY-remote1" which contains non- only. It has a display-name "DISPLAY-remote1" which contains non-
ASCII characters. ASCII characters.
o The Subject header is "NON-ASCII-SUBJECT" which contains non-ASCII o The Subject header is "NON-ASCII-SUBJECT" which contains non-ASCII
characters. characters.
The second example envelope/message is shown in Figure 14. The second example envelope/message is shown in Figure 7.
MAIL From: <NON-ASCII-local@example.com> MAIL From: <NON-ASCII-local@example.com>
ALT-ADDRESS=ASCII-local@example.com ALT-ADDRESS=ASCII-local@example.com
RCPT TO: <ASCII-remote1@example.net> RCPT TO: <ASCII-remote1@example.net>
------------------------------------------------------------- -------------------------------------------------------------
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: NON-ASCII-SUBJECT Subject: NON-ASCII-SUBJECT
From: DISPLAY-local <NON-ASCII-local@example.com From: DISPLAY-local <NON-ASCII-local@example.com
<ASCII-local@example.com>> <ASCII-local@example.com>>
To: DISPLAY-remote1 <ASCII-remote1@example.net> To: DISPLAY-remote1 <ASCII-remote1@example.net>
Date: DATE Date: DATE
MAIL_BODY MAIL_BODY
Figure 14: Original message (example 2) Figure 7: Original message (example 2)
In this example, SMTP session is downgradable. Figure 15 shows SMTP In this example, SMTP session is downgradable. Figure 8 shows SMTP
downgraded envelope/message. downgraded envelope/message.
MAIL From: <ASCII-local@example.com> MAIL From: <ASCII-local@example.com>
RCPT TO: <ASCII-remote1@example.net> RCPT TO: <ASCII-remote1@example.net>
------------------------------------------------------------- -------------------------------------------------------------
Downgraded-Mail-From: =?UTF-8?Q?<NON-ASCII-local@example.com>?= Downgraded-Mail-From: =?UTF-8?Q?<NON-ASCII-local@example.com>_?=
<ASCII-local@example.com> ?=UTF8?Q?<ASCII-local@example.com>?=
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: NON-ASCII-SUBJECT Subject: NON-ASCII-SUBJECT
From: DISPLAY-local <NON-ASCII-local@example.com From: DISPLAY-local <NON-ASCII-local@example.com
<ASCII-local@example.com>> <ASCII-local@example.com>>
To: DISPLAY-remote1 <ASCII-remote1@example.net> To: DISPLAY-remote1 <ASCII-remote1@example.net>
Date: DATE Date: DATE
MAIL_BODY MAIL_BODY
Figure 15: SMTP Downgraded envelope/message (example 2) Figure 8: SMTP Downgraded envelope/message (example 2)
After SMTP downgrading, header fields downgrading is performed. The After SMTP downgrading, header fields downgrading is performed. The
downgraded example is shown in Figure 16. downgraded example is shown in Figure 9.
Return-Path: <ASCII-local@example.com> Return-Path: <ASCII-local@example.com>
Downgraded-Mail-From: =?UTF-8?Q?<NON-ASCII-local@example.com>?= Downgraded-Mail-From: =?UTF-8?Q?<NON-ASCII-local@example.com>_?=
<ASCII-local@example.com> =?UTF8?Q?<ASCII-local@example.com>?=
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?Q?NON-ASCII-SUBJECT?= Subject: =?UTF-8?Q?NON-ASCII-SUBJECT?=
Downgraded-From: =?UTF-8?Q?DISPLAY-local?= Downgraded-From: =?UTF-8?Q?DISPLAY-local_<NON-ASCII-local@example.com_?=
=?UTF-8?Q?<NON-ASCII-local@example.com?= <ASCII-local@example.com>> =?UTF-8?Q?<ASCII-local@example.com>>?=
From: =?UTF-8?Q?DISPLAY-local?= <ASCII-local@example.com> From: =?UTF-8?Q?DISPLAY-local?= <ASCII-local@example.com>
To: =?UTF-8?Q?DISPLAY-remote1?= <ASCII-remote1@example.net> To: =?UTF-8?Q?DISPLAY-remote1?= <ASCII-remote1@example.net>
Date: DATE Date: DATE
MAIL_BODY MAIL_BODY
Figure 16: Downgraded message (example 2) Figure 9: Downgraded message (example 2)
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 30, line 7 skipping to change at page 24, line 7
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
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 End of changes. 63 change blocks. 
290 lines changed or deleted 112 lines changed or added

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