draft-ietf-eai-downgrade-06.txt   draft-ietf-eai-downgrade-07.txt 
Email Address Internationalization Y. YONEYA, Ed. Email Address Internationalization K. Fujiwara, Ed.
(EAI) K. Fujiwara, Ed. (EAI) Y. YONEYA, Ed.
Internet-Draft JPRS Internet-Draft JPRS
Intended status: Experimental February 14, 2008 Intended status: Experimental March 13, 2008
Expires: August 17, 2008 Expires: September 14, 2008
Downgrading mechanism for Email Address Internationalization Downgrading mechanism for Email Address Internationalization
draft-ietf-eai-downgrade-06.txt draft-ietf-eai-downgrade-07.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 August 17, 2008. This Internet-Draft will expire on September 14, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). 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
skipping to change at page 2, line 17 skipping to change at page 2, line 17
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
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 . . . . . . . . . . . . . . . . . . . . . 12
8.1. Trivial downgrading . . . . . . . . . . . . . . . . . . . 13 8.1. Trivial downgrading . . . . . . . . . . . . . . . . . . . 12
8.2. 7bit transport consideration . . . . . . . . . . . . . . 13
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
11. Change History . . . . . . . . . . . . . . . . . . . . . . . . 15 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 . . . . . . . . . . 16
11.7. draft-ietf-eai-downgrade: Version 04 . . . . . . . . . . . 16 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
12. Normative References . . . . . . . . . . . . . . . . . . . . . 17 12. Normative References . . . . . . . . . . . . . . . . . . . . . 17
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 18 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 19
A.1. Downgrading example 1 . . . . . . . . . . . . . . . . . . 18 A.1. Downgrading example 1 . . . . . . . . . . . . . . . . . . 19
A.2. Downgrading example 2 . . . . . . . . . . . . . . . . . . 21 A.2. Downgrading example 2 . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
Intellectual Property and Copyright Statements . . . . . . . . . . 24 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,
skipping to change at page 7, line 34 skipping to change at page 7, line 34
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 non-ASCII mail address in the envelope
with its specified alternative ASCII address and preserve the 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 xtest 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 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
skipping to change at page 12, line 43 skipping to change at page 12, line 43
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).
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
Downgrading is an alternative to rejection for delivering messages Downgrading is an alternative to rejection for delivering messages
which require UTF8SMTP support to a server which does not provide which require UTF8SMTP support to 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
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.
8.1. Trivial downgrading
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 E-mail message does not contain non-ASCII addresses
in SMTP Envelope and its header fields. But it is not deliverable in SMTP Envelope and its header fields. But it is not deliverable
via UTF8SMTP un-aware MTA. Implementing full spec downgrading may be via UTF8SMTP un-aware MTA. Implementing full spec downgrading may be
hard, but trivial downgrading saves mail messages without using non- hard, but trivial downgrading saves mail messages without using non-
ASCII addresses. ASCII addresses.
8.2. 7bit transport consideration
The SMTP client may confront a SMTP server which does not support the
8BITMIME SMTP extension [RFC1652]. The server does not support
"8bit" or "binary" data. Implementers need to consider to replace
"8bit" data to be "base64" or "quoted-printable" encoded form and
reflect it to "Content-Transfer-Encoding" header field. If the body
contains multiple MIME parts, this conversion must be performed 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
Author/change controller: IETF Author/change controller: IETF
skipping to change at page 17, line 33 skipping to change at page 17, line 38
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 11.9. draft-ietf-eai-downgrade: Version 06
o Moved decoding downgraded messages as a separate document o Moved decoding downgraded messages as a separate document
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
o Fixed some typos
o Added a text about 7bit transport
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-11 (work in
progress), January 2008. 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-09 (work in progress), draft-ietf-eai-utf8headers-09 (work in progress),
February 2008. February 2008.
[RFC1652] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D.
Crocker, "SMTP Service Extension for 8bit-MIMEtransport",
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)
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
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
skipping to change at page 19, line 21 skipping to change at page 19, line 30
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".
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 shown in Figure 4. In this
example, the To: recipient's session is fucused. example, the To: recipient's session is focused.
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"
skipping to change at page 23, line 25 skipping to change at page 24, line 25
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 9: Downgraded message (example 2)
Authors' Addresses Authors' Addresses
Yoshiro YONEYA (editor) Kazunori Fujiwara (editor)
JPRS JPRS
Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda
Chiyoda-ku, Tokyo 101-0065 Chiyoda-ku, Tokyo 101-0065
Japan Japan
Phone: +81 3 5215 8451 Phone: +81 3 5215 8451
Email: yone@jprs.co.jp Email: fujiwara@jprs.co.jp
Kazunori Fujiwara (editor) Yoshiro YONEYA (editor)
JPRS JPRS
Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda
Chiyoda-ku, Tokyo 101-0065 Chiyoda-ku, Tokyo 101-0065
Japan Japan
Phone: +81 3 5215 8451 Phone: +81 3 5215 8451
Email: fujiwara@jprs.co.jp Email: yone@jprs.co.jp
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2008). 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
 End of changes. 20 change blocks. 
33 lines changed or deleted 54 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/