draft-ietf-eai-downgrade-07.txt   draft-ietf-eai-downgrade-08.txt 
Email Address Internationalization K. Fujiwara, Ed. Email Address Internationalization K. Fujiwara, Ed.
(EAI) Y. YONEYA, Ed. (EAI) Y. YONEYA, Ed.
Internet-Draft JPRS Internet-Draft JPRS
Intended status: Experimental March 13, 2008 Intended status: Experimental July 14, 2008
Expires: September 14, 2008 Expires: January 15, 2009
Downgrading mechanism for Email Address Internationalization Downgrading mechanism for Email Address Internationalization
draft-ietf-eai-downgrade-07.txt draft-ietf-eai-downgrade-08.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 14, 2008. This Internet-Draft will expire on January 15, 2009.
Copyright Notice
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 rejecting
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
mechanism for Email Address Internationalization. Note that this is mechanism for Email Address Internationalization. Note that this is
a way to downgrade, not tunnel. There is no associated up-conversion a way to downgrade, not tunnel. There is no associated up-conversion
mechanism, although internationalized email clients might use mechanism, although internationalized email clients might use
original internationalized addresses or other data when displaying or original internationalized addresses or other data when displaying or
replying to downgraded messages. replying to downgraded messages.
Table of Contents Table of Contents
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
4.1. Path element downgrading . . . . . . . . . . . . . . . . 7
4.2. ORCPT downgrading . . . . . . . . . . . . . . . . . . . . 8
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 . . . . . . . . . . . . . . . . . . . 12 7. Security considerations . . . . . . . . . . . . . . . . . . . 12
8. Implementation notes . . . . . . . . . . . . . . . . . . . . . 12 8. Implementation notes . . . . . . . . . . . . . . . . . . . . . 13
8.1. Trivial downgrading . . . . . . . . . . . . . . . . . . . 12 8.1. Trivial downgrading . . . . . . . . . . . . . . . . . . . 13
8.2. 7bit transport consideration . . . . . . . . . . . . . . 13 8.2. 7bit transport consideration . . . . . . . . . . . . . . 13
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
11. Change History . . . . . . . . . . . . . . . . . . . . . . . . 16 11. Change History . . . . . . . . . . . . . . . . . . . . . . . . 16
11.1. draft-yoneya-ima-downgrade: Version 00 . . . . . . . . . 16 11.1. draft-yoneya-ima-downgrade: Version 00 . . . . . . . . . 16
11.2. draft-yoneya-ima-downgrade: Version 01 . . . . . . . . . 16 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 . . . . . . . . . . 17
11.7. draft-ietf-eai-downgrade: Version 04 . . . . . . . . . . 17 11.7. draft-ietf-eai-downgrade: Version 04 . . . . . . . . . . 17
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 11.9. draft-ietf-eai-downgrade: Version 06 . . . . . . . . . . 17
11.10. draft-ietf-eai-downgrade: Version 07 . . . . . . . . . . 17 11.10. draft-ietf-eai-downgrade: Version 07 . . . . . . . . . . 18
12. Normative References . . . . . . . . . . . . . . . . . . . . . 17 11.11. draft-ietf-eai-downgrade: Version 08 . . . . . . . . . . 18
12. Normative References . . . . . . . . . . . . . . . . . . . . . 18
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 19 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 19
A.1. Downgrading example 1 . . . . . . . . . . . . . . . . . . 19 A.1. Downgrading example 1 . . . . . . . . . . . . . . . . . . 19
A.2. Downgrading example 2 . . . . . . . . . . . . . . . . . . 22 A.2. Downgrading example 2 . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
Intellectual Property and Copyright Statements . . . . . . . . . . 25 Intellectual Property and Copyright Statements . . . . . . . . . . 25
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,
the message cannot be delivered unless every system in the delivery the message cannot be delivered unless every system in the delivery
path supports UTF8SMTP. To avoid bouncing such messages when a path supports UTF8SMTP. This document describes a downgrading
server is encountered which does not support the UTF8SMTP extension, mechanism to avoid rejection of such messages when a server which
this document describes a downgrading mechanism. Downgrading a does not support the UTF8SMTP extension is encountered. Downgrading
message converts envelope and header fields to an all-ASCII mechanism converts envelope and header fields to an all-ASCII
representation. representation.
[I-D.ietf-eai-utf8headers] allows UTF-8 characters to be used in mail [I-D.ietf-eai-utf8headers] allows UTF-8 characters to be used in mail
header fields and MIME header fields. The downgrading mechanism header fields and MIME header fields. The downgrading mechanism
specified here converts mail header fields and MIME header fields to specified here converts mail header fields and MIME header fields to
ASCII. ASCII.
This document does not change any protocols except by defining new This document does not change any protocols except by defining new
header fields. It describes the conversion method from the header fields. It describes the conversion method from the
internationalized email envelopes/messages which are defined in internationalized email envelopes/messages which are defined in
skipping to change at page 4, line 7 skipping to change at page 4, line 7
This document tries to define the downgrading process clearly and it This document tries to define the downgrading process clearly and it
preserves the original information as much as possible. preserves the original information as much as possible.
Downgrading in UTF8SMTP consists of the following four parts: Downgrading in UTF8SMTP consists of the following four parts:
o New header fields definition o New header fields definition
o SMTP downgrading o SMTP downgrading
o Email header fields downgrading o Email header fields downgrading
o MIME header fields downgrading o MIME header fields downgrading
In Section 3, many header fields starting with "downgraded" are In Section 3, many header fields starting with "Downgraded-" are
introduced. They preserve the original envelope information and the introduced. They preserve the original envelope information and the
original header fields. original header fields.
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].
skipping to change at page 7, line 11 skipping to change at page 7, line 11
with charset='UTF-8'. To preserve space characters, the whole with charset='UTF-8'. To preserve space characters, the whole
header field value which include space characters SHOULD be header field value which include space characters SHOULD be
encoded. encoded.
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 <reverse-path> of MAIL FROM command
o RCPT TO: o <forward-path> of RCPT TO command
o ORCPT parameter o ORCPT parameter of RCPT TO command
Downgrading the SMTP envelope uses ALT-ADDRESS parameter defined in 4.1. Path element downgrading
[I-D.ietf-eai-smtpext]. An address is downgradable if the address is
non-ASCII address and has ASCII address specified by ALT-ADDRESS Downgrading the <path> of MAIL FROM and RCPT TO commands uses ALT-
parameter. Since only non-ASCII addresses are downgradable, ADDRESS parameter defined in [I-D.ietf-eai-smtpext]. A SMTP command
specifying an ALT-ADDRESS value for an all-ASCII address is invalid is downgradable if the <path> contains non-ASCII address and the
for use with this specification, and no interpretation is assigned to command has an ALT-ADDRESS parameter which specifies an ASCII
it. This restriction allows for future extension of the address. Since only non-ASCII addresses are downgradable, specifying
specification even though no such extensions are currently an ALT-ADDRESS value for an all-ASCII address is invalid for use with
anticipated. this specification, and no interpretation is assigned to it. This
restriction allows for future extension of the specification even
though no such extensions are currently anticipated.
Note that even if no downgrading is performed on the envelope, Note that even if no downgrading is performed on the envelope,
message header fields and message body MIME header fields that message header fields and message body MIME header fields that
contain non-ASCII characters MUST be downgraded. This is described contain non-ASCII characters MUST be downgraded. This is described
in Section 5 and Section 6. in Section 5 and Section 6.
When downgrading, replace each non-ASCII mail address in the envelope When downgrading, replace each <path> which contains non-ASCII mail
with its specified alternative ASCII address and preserve the address with its specified alternative ASCII address and preserve the
original information using "Downgraded-Mail-From" and "Downgraded- original information using "Downgraded-Mail-From" and "Downgraded-
Rcpt-To" header fields as defined in Section 3. Before replacing, Rcpt-To" header fields as defined in Section 3. Before replacing,
decode the ALT-ADDRESS parameter value because it is encoded as xtext decode the ALT-ADDRESS parameter value because it is encoded as xtext
[RFC3461]. [RFC3461].
To avoid disclosing recipient addresses, the downgrading process MUST To avoid disclosing recipient addresses, the downgrading process MUST
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 As a result of the recipient address downgrading, the domain part of
address is downgraded. The ORCPT parameter is used for DSN the recipient address prior to downgrading might be different from
[RFC3461]. If the ORCPT parameter contains an "utf-8" address and the domain part of the new recipient address. If the result of
the address contains non-ASCII characters, the ORCPT parameter MUST address resolution for the domain part of the new recipient address
be converted to utf-8-addr-xtext form or utf-8-addr-unitext form contains the server at the connection destination of the SMTP session
which are described in [I-D.ietf-eai-dsn]. for the recipient address prior to downgrading, 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.
As a result of the recipient address replacement, the domain part of 4.2. ORCPT downgrading
the original recipient address may not equal to the domain part of
the new recipient address. If the result of address resolution for The "RCPT TO" command can have an ORCPT parameter if the DSN
the domain part of the new recipient address contains the server at extension [RFC3461] is supported. If the ORCPT parameter contains an
the connection destination of the SMTP session for the original "utf-8" address and the address contains non-ASCII characters, the
recipient address, the SMTP connection is valid for the new recipient ORCPT parameter MUST be converted to utf-8-addr-xtext form or utf-8-
address. Otherwise, the downgrading process MUST NOT send the addr-unitext form which are described in [I-D.ietf-eai-dsn].
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>.
skipping to change at page 12, line 9 skipping to change at page 12, line 16
Content-Disposition: Content-Disposition:
Perform MIME-VALUE downgrading. Perform MIME-VALUE downgrading.
Content-Description: Content-Description:
Perform 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. Furthermore, the body
part may contain UTF-8 message. The recipients need to accept part may contain UTF-8 characters. Implementations parsing
UTF-8 mail body and UTF-8 header fields which is MIME encoded. Internet messages need to accept UTF-8 body parts and UTF-8 header
fields which are 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 Addresses that do not appear in the message headers may appear in
listed on Bcc or group address. Those undisclosed addresses are the RCPT commands to an SMTP server for a number of reasons.
used only in the Envelope. Copying information from the Envelope Copying information from the Envelope into headers risks
into headers risks inadvertent information disclosure (not just inadvertent information disclosure (see [RFC2821] and Section 4).
about addresses). See Section 4 for instructions on recipient
address handling.
o The techniques described here invalidates methods that depend on o The techniques described here invalidates methods that depend on
digital signatures over the envelope or any part of the message digital signatures over the envelope or any part of the message
which includes the top-level header or body part headers. which includes the top-level header or body part headers.
Depending on the specific message being downgraded, DKIM Depending on the specific message being downgraded, DKIM
especially, but also possibly S/MIME, PGP, and similar techniques especially, but also possibly S/MIME, PGP, and similar techniques
are all likely to 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-")
avoid information loss, then the risk of having those headers to avoid information loss, 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, if the Downgraded headers are dropped, there is no possibility of
there is no possibility of reconstructing the original information reconstructing the original information at any point (before,
at any point (before, during, or after delivery). during, or after delivery).
See "Security considerations" section in [RFC4952] for more See "Security considerations" section in [RFC4952] for more
discussion. discussion.
8. Implementation notes 8. Implementation notes
8.1. Trivial downgrading 8.1. Trivial downgrading
Downgrading is an alternative to rejection for delivering messages Downgrading is an alternative to avoid the rejection of messages
which require UTF8SMTP support to a server which does not provide which require UTF8SMTP support by a server which does not provide
this. Implementing the full specification of this document is this. Implementing the full specification of this document is
desirable, but a partial implementation is also possible. desirable, but a partial implementation is also possible.
If a partial downgrading implementation confronts an unsupported If a partial downgrading implementation confronts an unsupported
downgrading target, the implementation MUST NOT send the message to downgrading target, the implementation MUST NOT send the message to a
server which does not support UTF8SMTP. Instead, it MUST reject the server which does not support UTF8SMTP. Instead, it MUST reject the
message or generate a notification of non-deliverability. message or generate a notification of non-deliverability.
A partial downgrading, Trivial downgrading is discussed. It does not A partial downgrading, Trivial downgrading is discussed. It does not
support non-ASCII addresses in SMTP envelope and address header support non-ASCII addresses in SMTP envelope and address header
fields, unknown header fields downgrading, the MIME body part headers fields, unknown header fields downgrading, the MIME body part headers
downgrading. It supports downgrading. It supports
o some simple header fields downgrading: Subject o some simple header fields downgrading: Subject
o comments and display name downgrading: From, To, CC o comments and display name downgrading: From, To, Cc
o trace header field downgrading: Received o trace header field downgrading: Received
Otherwise, the downgrading fails. Otherwise, the downgrading fails.
Trivial downgrading targets mail messages which are generated by Trivial downgrading targets mail messages which are generated by
UTF8SMTP aware MUAs and contain non-ASCII characters in comments, UTF8SMTP aware MUAs and contain non-ASCII characters in comments,
display names, unstructured parts without using non-ASCII E-mail display names, unstructured parts without using non-ASCII E-mail
addresses. This E-mail message does not contain non-ASCII addresses addresses. This mail message does not contain non-ASCII E-mail
in SMTP Envelope and its header fields. But it is not deliverable addresses in the SMTP Envelope and its header fields. But it is not
via UTF8SMTP un-aware MTA. Implementing full spec downgrading may be deliverable via a UTF8SMTP un-aware SMTP server. Implementing full
hard, but trivial downgrading saves mail messages without using non- specification downgrading may be hard, but trivial downgrading saves
ASCII addresses. mail messages without using non-ASCII addresses.
8.2. 7bit transport consideration 8.2. 7bit transport consideration
The SMTP client may confront a SMTP server which does not support the The SMTP client may encounter a SMTP server which does not support
8BITMIME SMTP extension [RFC1652]. The server does not support the 8BITMIME SMTP extension [RFC1652]. The server does not support
"8bit" or "binary" data. Implementers need to consider to replace "8bit" or "binary" data. Implementers need to consider converting
"8bit" data to be "base64" or "quoted-printable" encoded form and "8bit" data to "base64" or "quoted-printable" encoded form and adjust
reflect it to "Content-Transfer-Encoding" header field. If the body the "Content-Transfer-Encoding" header field accordingly. If the
contains multiple MIME parts, this conversion must be performed for body contains multiple MIME parts, this conversion must be performed
each MIME part according to [RFC2045]. for each MIME part according to [RFC2045].
9. IANA Considerations 9. IANA Considerations
IANA is requested to register the following header fields in the IANA is requested to register the following header fields in the
Permanent Message Header Field Repository, in accordance with the Permanent Message Header Field Repository, in accordance with the
procedures set out in [RFC3864]. procedures set out in [RFC3864].
Header field name: Downgraded-Mail-From Header field name: Downgraded-Mail-From
Applicable protocol: mail Applicable protocol: mail
Status: experimental Status: experimental
skipping to change at page 15, line 34 skipping to change at page 15, line 40
Status: experimental Status: experimental
Author/change controller: IETF Author/change controller: IETF
Specification document(s): This document (Section 3) Specification document(s): This document (Section 3)
Header field name: Downgraded-Return-Path Header field name: Downgraded-Return-Path
Applicable protocol: mail Applicable protocol: mail
Status: experimental Status: experimental
Author/change controller: IETF Author/change controller: IETF
Specification document(s): This document (Section 3) Specification document(s): This document (Section 3)
And more, IANA is requested to reserve all the field names that start Furthermore, IANA is requested to reserve all the field names that
by "Downgraded-" for unknown header fields downgrading described in start with "Downgraded-" for unknown header fields downgrading
Section 3.3, in accordance with the procedures set out in [RFC3864]. described in Section 3.3, in accordance with the procedures set out
in [RFC3864].
Header field name: Names which starts by "Downgraded-" Header field name: Names which starts by "Downgraded-"
Applicable protocol: mail Applicable protocol: mail
Status: experimental Status: experimental
Author/change controller: IETF Author/change controller: IETF
Specification document(s): This document (Section 3) Specification document(s): This document (Section 3)
10. Acknowledgements 10. Acknowledgements
Significant comments and suggestions were received from John Klensin, Significant comments and suggestions were received from John Klensin,
skipping to change at page 17, line 43 skipping to change at page 18, line 10
o Added a text to UNSTRUCTURED downgrading o Added a text to UNSTRUCTURED downgrading
o Added "replacing SMTP connection" if necessary to SMTP o Added "replacing SMTP connection" if necessary to SMTP
downgrading. downgrading.
o fixed examples o fixed examples
11.10. draft-ietf-eai-downgrade: Version 07 11.10. draft-ietf-eai-downgrade: Version 07
o Fixed some typos o Fixed some typos
o Added a text about 7bit transport o Added a text about 7bit transport
11.11. draft-ietf-eai-downgrade: Version 08
o Comments from the working group last call (wording)
12. Normative References 12. Normative References
[I-D.ietf-eai-dsn] [I-D.ietf-eai-dsn]
Newman, C. and A. Melnikov, "Internationalized Delivery Newman, C. and A. Melnikov, "Internationalized Delivery
Status and Disposition Notifications", Status and Disposition Notifications",
draft-ietf-eai-dsn-06 (work in progress), January 2008. 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-11 (work in email address", draft-ietf-eai-smtpext-13 (work in
progress), January 2008. progress), July 2008.
[I-D.ietf-eai-utf8headers] [I-D.ietf-eai-utf8headers]
Yeh, J., "Internationalized Email Headers", Yang, A., "Internationalized Email Headers",
draft-ietf-eai-utf8headers-09 (work in progress), draft-ietf-eai-utf8headers-12 (work in progress),
February 2008. July 2008.
[RFC1652] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. [RFC1652] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D.
Crocker, "SMTP Service Extension for 8bit-MIMEtransport", Crocker, "SMTP Service Extension for 8bit-MIMEtransport",
RFC 1652, July 1994. RFC 1652, July 1994.
[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)
skipping to change at page 19, line 13 skipping to change at page 19, line 33
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. Examples Appendix A. Examples
A.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 where:
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 a
ASCII address. Its ASCII alternative is "ASCII-local@example.com" non-ASCII address. Its ASCII alternative is
and its display-name is "DISPLAY-local". "ASCII-local@example.com" 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 a
ASCII address. Its ASCII alternative is non-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 a 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".
o Three display-names contains non-ASCII characters. o Three display-names contain 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 Assuming the "To:" recipient's MTA (example.net) does not support
UTF8SMTP. UTF8SMTP.
o assume Cc: recipient's MTA (example.org) supports UTF8SMTP. o assuming the "Cc:" recipient's MTA (example.org) supports
The example SMTP envelope/message is shown in Figure 4. In this UTF8SMTP.
example, the To: recipient's session is focused. The example SMTP envelope/message is shown in Figure 1. In this
example, the "To:" recipient's session is the focus.
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
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>
Date: DATE Date: DATE
MAIL_BODY MAIL_BODY
Figure 4: Original envelope/message (example 1) Figure 1: 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
is CC:. The SMTP downgrading treats To: session downgrading. other is "Cc:". The SMTP downgrading treats To: session downgrading.
Figure 5 shows SMTP downgraded example. Figure 2 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>_?=
=?UTF-8?Q?<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>_?=
=?UTF-8?Q?<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>
Date: DATE Date: DATE
MAIL_BODY MAIL_BODY
Figure 5: SMTP Downgraded envelope/message (example 1) Figure 2: 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 3. 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>_?=
=?UTF-8?Q?<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>_?=
=?UTF-8?Q?<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?=
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_?= Downgraded-From: =?UTF-8?Q?DISPLAY-local_<NON-ASCII-local@example.com_?=
=?UTF-8?Q?<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 3: Downgraded message (example 1)
A.2. Downgrading example 2 A.2. 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 and the
recipient does not support UTF8SMTP and does not have non-ASCII recipient is a traditional mail user. The SMTP server handing mail
address. for the recipient and/or the recipient's MUA does not support
o The sender address is "NON-ASCII-local@example.com" which is non- UTF8SMTP extension. Consider a mail message where:
ASCII address. Its ASCII alternative is o The sender address is "NON-ASCII-local@example.com" which is a
non-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-
characters. ASCII characters.
The second example envelope/message is shown in Figure 7. The second example envelope/message is shown in Figure 4.
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 7: Original message (example 2) Figure 4: Original message (example 2)
In this example, SMTP session is downgradable. Figure 8 shows SMTP In this example, SMTP session is downgradable. Figure 5 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>_?=
?=UTF8?Q?<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 8: SMTP Downgraded envelope/message (example 2) Figure 5: 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 9. downgraded example is shown in Figure 6.
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>_?=
=?UTF8?Q?<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_<NON-ASCII-local@example.com_?= Downgraded-From: =?UTF-8?Q?DISPLAY-local_<NON-ASCII-local@example.com_?=
=?UTF-8?Q?<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 9: Downgraded message (example 2) Figure 6: Downgraded message (example 2)
Authors' Addresses Authors' Addresses
Kazunori Fujiwara (editor) Kazunori Fujiwara (editor)
JPRS JPRS
Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda
Chiyoda-ku, Tokyo 101-0065 Chiyoda-ku, Tokyo 101-0065
Japan Japan
Phone: +81 3 5215 8451 Phone: +81 3 5215 8451
skipping to change at page 25, line 44 skipping to change at line 1074
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 52 change blocks. 
125 lines changed or deleted 133 lines changed or added

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