Email Address Internationalization Y. YONEYA, Ed.
(EAI) K. Fujiwara, Ed.
Internet-Draft JPRS
Intended status: Experimental Mar 5, 2007
Expires: September 6, 2007
Downgrading mechanism for Email Address Internationalization
draft-ietf-eai-downgrade-03.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
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
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 6, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
Traditional mail systems handle only US-ASCII characters in SMTP
envelope and mail header fields. The Email Address
Internationalization is implemented by allowing UTF-8 characters in
SMTP envelope and mail header fields (UTF8SMTP). To deliver Non-
ASCII mail address via UTF8SMTP non-compliant environment, some sort
of converting mechanism (i.e. downgrading) is required. This
document describes requirements for downgrading, SMTP downgrading,
YONEYA & Fujiwara Expires September 6, 2007 [Page 1]
Internet-Draft UTF8SMTP Downgrade Mar 2007
Email header downgrading and implementation consideration.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Downgrade Requirements . . . . . . . . . . . . . . . . . . . . 3
3.1. Timing and conditions of downgrading . . . . . . . . . . . 3
3.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4
4. Downgraded header . . . . . . . . . . . . . . . . . . . . . . 4
5. SMTP Downgrading . . . . . . . . . . . . . . . . . . . . . . . 5
6. Email header Downgrading . . . . . . . . . . . . . . . . . . . 6
6.1. Downgrading address headers . . . . . . . . . . . . . . . 7
7. Upgrading downgraded header . . . . . . . . . . . . . . . . . 7
8. Implementation consideration . . . . . . . . . . . . . . . . . 8
9. Security considerations . . . . . . . . . . . . . . . . . . . 8
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
12. Change History . . . . . . . . . . . . . . . . . . . . . . . . 9
12.1. draft-yoneya-ima-downgrade: Version 00 . . . . . . . . . . 9
12.2. draft-yoneya-ima-downgrade: Version 01 . . . . . . . . . . 9
12.3. draft-ietf-eai-downgrade: Version 00 . . . . . . . . . . . 9
12.4. draft-ietf-eai-downgrade: Version 01 . . . . . . . . . . . 9
12.5. draft-ietf-eai-downgrade: Version 02 . . . . . . . . . . . 9
12.6. draft-ietf-eai-downgrade: Version 03 . . . . . . . . . . . 9
13. Normative References . . . . . . . . . . . . . . . . . . . . . 10
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 10
A.1. Downgrading example 1 . . . . . . . . . . . . . . . . . . 10
A.2. Upgrading example . . . . . . . . . . . . . . . . . . . . 13
A.3. Downgrading example 2 . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 18
YONEYA & Fujiwara Expires September 6, 2007 [Page 2]
Internet-Draft UTF8SMTP Downgrade Mar 2007
1. Introduction
Traditional mail systems which are defined by [RFC2821] and [RFC2822]
allow US-ASCII characters in SMTP envelope and mail header field
bodies. The UTF8SMTP proposal [I-D.ietf-eai-framework],
[I-D.ietf-eai-utf8headers] and [I-D.ietf-eai-smtpext] allows UTF-8
characters in SMTP envelope and mail header field bodies.
Carrying Non-ASCII mail address from sender to recipients requires
all components on the mail delivery route are UTF8SMTP compliant.
Otherwise Non-ASCII mail address can't be delivered. To solve the
problem, this document describes downgrading mechanism that enables
delivering Non-ASCII mail address by converting it to corresponding
US-ASCII representation on current mail delivery system. Not only
SMTP envelope, but also Non-ASCII characters in mail header fields
MUST be converted to US-ASCII.
Downgrading in UTF8SMTP consists from following two parts:
o SMTP Downgrading
o Email header Downgrading
Decoding downgraded envelope/message is called 'Upgrading' in this
document. Each downgrading mechanism has corresponding upgrading
mechanism.
In this document, requirements for downgrading are described in
Section 3, SMTP Downgrading is described in Section 5, and Email
header Downgrading is described in Section 6.
This document assumes that MIME headers are not extended to use UTF-8
characters because it is not clearly defined in
[I-D.ietf-eai-utf8headers].
2. Terminology
Terminology for this document is defined in [I-D.ietf-eai-framework].
3. Downgrade Requirements
3.1. Timing and conditions of downgrading
Followings are timing and conditions of downgrading.
YONEYA & Fujiwara Expires September 6, 2007 [Page 3]
Internet-Draft UTF8SMTP Downgrade Mar 2007
Timing: SMTP client detects that SMTP server doesn't support
"UTF8SMTP" option at EHLO. [I-D.ietf-eai-smtpext]
Conditions: SMTP client detects that non-ASCII characters are
included in the SMTP envelope or mail header fields in the SMTP
DATA.
3.2. Requirements
Followings are requirements of downgrading.
1. Downgrading should be performed only once.
2. "Upgrading MUST be performed (if at all) when it is known that a
subsequent downgrade will not be needed. This could mean that
the upgrading is delayed until the recipient MUA processes the
message."
3. Downgrading and upgrading must be automated.
4. Downgrading and upgrading should be easy and lightweight as it is
possible to do with MTA like 8BITMIME encapsulation.
5. Downgrade and upgrade method must be defined clearly.
6. Downgrading and upgrading should preserve all header information.
7. Downgrading should support SPF and DKIM.
8. Downgrading occurrence should be recorded.
4. Downgraded header
To preserve all header information, new generic encapsulation header
is required. The new header is required, and it is specified as
"Downgraded". It has two fields. The first field is the
encapsulated header name. The second field contains the encapsulated
header value which is encoded by [RFC2047] with UTF-8 tag. The
header field syntax is specified as follows:
fields =/ downgraded
downgraded = "Downgraded:" [CFWS] field-name ":" dvalue CRLF
field-name = 1*ftext
ftext = %d33-57 / %d59-126 ; printable ASCII except ":"
dvalue = 1*any-ascii
any-ascii = %d32-126
Any headers can be preserved in Downgraded: header. The "dvalue"
field is encoded by [RFC2047]. "Downgraded header decoding" means
that generating new header whose header name is "field-name" field
that retrieving preserved field-name and dvalue decoded by [RFC2047].
To preserve SMTP envelope downgraded information, another new header
is required, and it is specified as "Envelope-Downgraded". Details
are described in Section 5. The header field syntax is specified as
YONEYA & Fujiwara Expires September 6, 2007 [Page 4]
Internet-Draft UTF8SMTP Downgrade Mar 2007
follows:
fields =/ edowngraded
edowngraded = "Envelope-Downgraded:" [CFWS] field-name ":" value CRLF
field-name = "From" / "To"
value = CFWS "<" uPath ">" CFWS "<" Mailbox ">" CFWS
; Mailbox is defined in RFC 2821, section 4.1.2
; uPath is defined in [I-D.ietf-eai-smtpext]
5. SMTP Downgrading
Downgrading MUST be performed for each SMTP recipient address.
Target of downgrading elements in SMTP envelope are below:
o MAIL FROM:
o RCPT TO:
Downgrading in SMTP envelope uses ALT-ADDRESS parameter proposed in
[I-D.ietf-eai-smtpext]. An address is downgradable if the address is
US-ASCII address or the address has US-ASCII address specified by
ALT-ADDRESS parameter.
If the return address in the envelope ("MAIL FROM:") is not
downgradable, downgrading fails.
One SMTP session may contain multiple recipients. Downgrading SHOULD
be performed for each SMTP recipient address individually. First,
split a multiple recipients session to each sessions. If the
recipient address is downgradable, the SMTP session to the recipient
is downgradable.
When MUA/MTA is transferring mail and finding its envelope contains
Non-ASCII addresses, it MUST decide to bounce or downgrade if
receiving MTA is UTF8SMTP non-compliant.
Even if no downgrading is performed for envelope from/to, MUA/MTA
MUST downgrade mail header fields including non-ASCII characters or
bounce. This is described in Section 6.
Downgrading MTA replaces Non-ASCII mail address with specified
alternative US-ASCII address. Also MTA preserves original
information using "Envelope-Downgraded" header defined in Section 4
with From or To field name.
YONEYA & Fujiwara Expires September 6, 2007 [Page 5]
Internet-Draft UTF8SMTP Downgrade Mar 2007
Envelope-Downgraded: From: <Non-ASCII-FROM> <US-ASCII-FROM>
Envelope-Downgraded: To: <Non-ASCII-TO> <US-ASCII-TO>
Note that when downgrading, not to disclose whole recipient address,
MUA/MTA SHOULD make SMTP connection per each recipient address.
Also note that by appending "Envelope-Downgraded:" headers, MUA/MTA
MUST perform Email header Downgrading described in Section 6.
NOTE: ORCPT
ESMTP ORCPT parameter is used for Delivery Status Notifications
(DSNs) [RFC3461]. ORCPT parameters contain mail addresses. After
extending ORCPT parameter to support Non-ASCII mail addresses, ORCPT
parameter downgrading should be defined here.
Case study: SPF check
SPF checks domain name of the envelope from and SMTP connection IP
address. If ALT-ADDRESS domain name is Punycode/IDNA form of Non-
ASCII domainname, it will be compatible with current SPF. In this
case, SPF check will be performed correctly. Otherwise, more
detailed consideration is required.
6. Email header Downgrading
This section defines conversion method to US-ASCII for each header
which may contain Non-ASCII characters. If the whole mail header
does not contain Non-ASCII characters, email header downgrading is
not required. Otherwise, email header downgrading checks each header
whether it contains UTF-8 characters or not. If the header contains
UTF-8 characters, convert the header in a suitable method for of each
header. Each header's downgrading method is described below:
From, To, CC, Reply-To, Return-Path:
The header field body is composed of single or multiple angle-
addr/addr-spec fields defined in [I-D.ietf-eai-utf8headers].
If the header has no 'angle-addr' or 'utf8-addr-spec' which
contains UTF-8 characters, only "display-name" part contains UTF-8
characters, encode the header by [RFC2047] with UTF-8 tag and
replace it.
Otherwise, preserve the header in "Downgraded:" header and
generate US-ASCII only header defined in Section 6.1, replace the
original header with the generated US-ASCII only header. When
this address header downgrading fails, this downgrading fails and
the mail MUST be bounced.
YONEYA & Fujiwara Expires September 6, 2007 [Page 6]
Internet-Draft UTF8SMTP Downgrade Mar 2007
Subject:
Encode the header by [RFC2047] with UTF-8 tag and replace it.
Message-ID:, Date:, In-Reply-To:
"ID"s and "Date"s does not contain UTF-8 characters.
Received:
If the FOR clause contains UTF-8 addresses, the header must be
downgraded. In this case, preserve the header in "Downgraded:"
header and remove the FOR clause in the header.
other headers:
All other headers which contains UTF-8 characters are preserved in
Downgraded: header and removed.
Downgraded headers should be inserted or replaced at the same
position of the original header.
6.1. Downgrading address headers
This procedure targets "From:", "To:", "CC:", "Reply-To:", "Return-
Path:" headers which contains Originator/Destination address(es).
1. Extract every field and downgrade each 'mailbox'/'angle-
addr'/'utf8-addr-spec'.
If the Non-ASCII address is in utf8-addr-spec form, then the
header downgrading fails because the form has no alt-address.
"mailbox" is defined as "DISPLAY NAME angle-addr" in
[I-D.ietf-eai-utf8headers]. The "DISPLAY NAME" field should be
encoded by [RFC2047] with UTF-8 tag, if necessary.
UTF8SMTP angle-addr defined in [I-D.ietf-eai-utf8headers]
consists of 3 forms. Downgrading method is defined for each
form.
1. <US-ASCII>
US-ASCII is used as is.
2. <Non-ASCII>
This email header downgrading fails because this header is
not downgradable.
3. <Non-ASCII<US-ASCII>>
Non-ASCII mail address with sender-specified US-ASCII address
is replaced as <US-ASCII>.
7. Upgrading downgraded header
Upgrading downgraded header is described below:
o Check if the mail header contains 'Downgraded:' headers.
Otherwise, upgrading is not required.
YONEYA & Fujiwara Expires September 6, 2007 [Page 7]
Internet-Draft UTF8SMTP Downgrade Mar 2007
o Perform "Downgraded header decoding" for each "Downgraded:"
headers and replace the 'Downgraded:' header with its decoded
header.
* If the decoded header is an address header described in
Section 6.1,
+ Generate ASCII only header described in Section 6.1 from the
decoded header.
+ Remove the header line which is the same with the generated
ASCII only header. (REQUIRE HEADER NORMALIZATION)
* If the decoded header is a "Received:" header,
+ Removing the 'FOR' clause from the decoded header generates
ASCII only header.
+ Remove the header line which is the same with the generated
header. (REQUIRE HEADER NORMALIZATION)
o If each mail header has [RFC2047] encoded part and which encoding
is "UTF-8", it may be a downgraded header, so decode it.
8. Implementation consideration
UTF8SMTP compliant MUA MUST implement downgrading mechanism for
sending.
MUA MAY encode UTF-8 in Subject header with the same encoding of body
part while downgrading.
UTF8SMTP compliant MUA MUST upgrade downgraded mail and MUST show
Non-ASCII mail addresses on display.
9. Security considerations
See "Security considerations" section in [I-D.ietf-eai-framework] for
more discussion.
10. IANA Considerations
IANA is requested to add the "Envelope-Downgraded:", and
"Downgraded:" new headers to the registry with the entries pointing
to this specification for its definition.
11. Acknowledgements
John Klensin, Harald Alvestrand, Chris Newman, Charles Lindsey,
Marcos Sanz, Alexey Melnikov and JET members.
YONEYA & Fujiwara Expires September 6, 2007 [Page 8]
Internet-Draft UTF8SMTP Downgrade Mar 2007
12. Change History
This section is used for tracking the update of this document. Will
be removed after finalize.
12.1. draft-yoneya-ima-downgrade: Version 00
o Initial version
o Followed draft-yeh-ima-utf8headers-00 and draft-yao-smtpext-00
12.2. draft-yoneya-ima-downgrade: Version 01
o Document structure was changed
o Followed draft-yeh-ima-utf8headers-01 and draft-yao-smtpext-02
o Downgrading requirements were added
o SMTP DATA encapsulation method was proposed
o Downgrading examples was provided
12.3. draft-ietf-eai-downgrade: Version 00
o Followed draft-yeh-ima-utf8headers-01 and
draft-ietf-eai-smtpext-00
o No header downgrading method was proposed
o Header encapsulation method was proposed
12.4. draft-ietf-eai-downgrade: Version 01
o Followed draft-ietf-eai-utf8headers-00
o Header conversion and encapsulation method was merged
o Header conversion method was defined in detail
12.5. draft-ietf-eai-downgrade: Version 02
o Followed draft-ietf-eai-utf8headers-01 and
draft-ietf-eai-smtpext-01
o Specification about algorithmic generated address is removed
o No header downgrading method was removed
o SMTP DATA encapsulation method was removed
12.6. draft-ietf-eai-downgrade: Version 03
o Followed draft-ietf-eai-utf8headers-03 and
draft-ietf-eai-smtpext-03
o Downgraded: and Envelope-Downgraded: headers definition was added
o Mail header downgrading method was refined
o Examples in Appendix A were refined
YONEYA & Fujiwara Expires September 6, 2007 [Page 9]
Internet-Draft UTF8SMTP Downgrade Mar 2007
13. Normative References
[I-D.ietf-eai-dsn]
Newman, C., "International Delivery and Disposition
Notifications", draft-ietf-eai-dsn-00 (work in progress),
January 2007.
[I-D.ietf-eai-framework]
Klensin, J. and Y. Ko, "Overview and Framework for
Internationalized Email", draft-ietf-eai-framework-05
(work in progress), February 2007.
[I-D.ietf-eai-scenarios]
Alvestrand, H., "UTF-8 Mail: Scenarios",
draft-ietf-eai-scenarios-01 (work in progress), June 2006.
[I-D.ietf-eai-smtpext]
Yao, J. and W. Mao, "SMTP extension for internationalized
email address", draft-ietf-eai-smtpext-03 (work in
progress), February 2007.
[]
Yeh, J., "Internationalized Email Headers",
draft-ietf-eai-utf8headers-03 (work in progress),
March 2007.
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
Part Three: Message Header Extensions for Non-ASCII Text",
RFC 2047, November 1996.
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001.
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
April 2001.
[RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service
Extension for Delivery Status Notifications (DSNs)",
RFC 3461, January 2003.
Appendix A. Examples
A.1. Downgrading example 1
This section shows a SMTP Downgrading example. Consider a
downgradable mail message.
YONEYA & Fujiwara Expires September 6, 2007 [Page 10]
Internet-Draft UTF8SMTP Downgrade Mar 2007
o The sender address is "NON-ASCII-FROM" which is Non-ASCII address.
Its ASCII alternative is "ASCII-FROM".
o The "To" address is "NON-ASCII-TO" which is Non-ASCII address.
Its ASCII alternative is "ASCII-TO".
o The "CC" address is "NON-ASCII-CC" which is Non-ASCII address.
Its ASCII alternative address is "ASCII-CC".
o The Subject header is "UTF8-SUBJECT" which contains Non-ASCII
characters.
Original UTF8SMTP message SMTP session
MAIL From: <NON-ASCII-FROM> ALT-ADDRESS <ASCII-FROM>
RCPT TO: <NON-ASCII-TO> ALT-ADDRESS <ASCII-TO>
RCPT TO: <NON-ASCII-CC> ALT-ADDRESS <ASCII-CC>
-------------------------------------------------------------
Message-Id: MESSAGE_ID
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Subject: UTF8-SUBJECT
From: <NON-ASCII-FROM<ASCII-FROM>>
To: <NON-ASCII-TO<ASCII-TO>>
CC: <NON-ASCII-CC<ASCII-CC>>
Date: DATE
MAIL_BODY
Figure 3: Original UTF8SMTP message
In this example, there are two sessions, one is To:, the other is
CC:. Both sessions are downgradable. Figure 4 shows To: session
downgrading.
YONEYA & Fujiwara Expires September 6, 2007 [Page 11]
Internet-Draft UTF8SMTP Downgrade Mar 2007
After SMTP Downgrading
MAIL From: <ASCII-FROM>
RCPT TO: <ASCII-TO>
-------------------------------------------------------------
Envelope-Downgraded: From: <NON-ASCII-FROM> <ASCII-FROM>
Envelope-Downgraded: To: <NON-ASCII-TO> <ASCII-TO>
Message-Id: MESSAGE_ID
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Subject: UTF8-SUBJECT
From: <NON-ASCII-FROM<ASCII-FROM>>
To: <NON-ASCII-TO<ASCII-TO>>
CC: <NON-ASCII-CC<ASCII-CC>>
Date: DATE
MAIL_BODY
Figure 4: SMTP Downgraded UTF8SMTP message
After SMTP downgrading, header downgrading is performed. Final
downgraded messages are shown in Figure 5.
Result of the header downgrading.
Downgraded: Envelope-Downgraded: From:
MIME(<NON-ASCII-FROM>) <ASCII-FROM>
Downgraded: Envelope-Downgraded: To:
MIME(<NON-ASCII-TO>) <ASCII-TO>
Message-Id: MESSAGE_ID
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Subject: MIME(UTF-8_SUBJECT)
Downgraded: From: MIME(<NON-ASCII-FROM<ASCII-FROM>>)
From: <ASCII-FROM>
Downgraded: To: MIME(<NON-ASCII-TO<ASCII-TO>>)
To: <ASCII-TO>
Downgraded: CC: MIME(<NON-ASCII-CC<ASCII-CC>>)
To: <ASCII-CC>
Date: DATE
MAIL_BODY
YONEYA & Fujiwara Expires September 6, 2007 [Page 12]
Internet-Draft UTF8SMTP Downgrade Mar 2007
Figure 5: Header downgraded message
MIME() stands for [RFC2047] encoding.
A.2. Upgrading example
This example shows upgrading process of Figure 5.
First, check 'Downgraded:' header existence. The UTF8SMTP downgraded
message has 'Downgraded:' headers.
Select 'Downgraded:' headers.
Downgraded: Envelope-Downgraded: From:
MIME(<NON-ASCII-FROM>) <ASCII-FROM>
Downgraded: Envelope-Downgraded: To:
MIME(<NON-ASCII-TO>) <ASCII-TO>
Downgraded: From: MIME(<NON-ASCII-FROM<ASCII-FROM>>)
Downgraded: To: MIME(<NON-ASCII-TO<ASCII-TO>>)
Downgraded: CC: MIME(<NON-ASCII-CC<ASCII-CC>>)
Figure 6: Upgrading: selecting Downgraded headers
This example has five Downgraded headers.
Decode 'Downgraded:' headers.
Envelope-Downgraded: From: <NON-ASCII-FROM> <ASCII-FROM>
Envelope-Downgraded: To: <NON-ASCII-TO> <ASCII-TO>
From: <NON-ASCII-FROM<ASCII-FROM>>
To: <NON-ASCII-TO<ASCII-TO>>
CC: <NON-ASCII-CC<ASCII-CC>>
Figure 7: Upgrading: upgraded Downgraded headers
Apply address header downgrading to the decoded header.
From: <ASCII-FROM>
To: <ASCII-TO>
CC: <ASCII-CC>
Figure 8: Upgrading: downgraded upgraded Downgraded headers
YONEYA & Fujiwara Expires September 6, 2007 [Page 13]
Internet-Draft UTF8SMTP Downgrade Mar 2007
Remove the header line which is the same with the downgraded line.
Downgraded: Envelope-Downgraded: From:
MIME(<NON-ASCII-FROM>) <ASCII-FROM>
Downgraded: Envelope-Downgraded: To:
MIME(<NON-ASCII-TO>) <ASCII-TO>
Message-Id: MESSAGE_ID
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Subject: MIME(UTF-8_SUBJECT)
Downgraded: From: MIME(<NON-ASCII-FROM<ASCII-FROM>>)
Downgraded: To: MIME(<NON-ASCII-TO<ASCII-TO>>)
Downgraded: CC: MIME(<NON-ASCII-CC<ASCII-CC>>)
Date: DATE
MAIL_BODY
Figure 9: Upgrading: 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.
Envelope-Downgraded: From: <NON-ASCII-FROM> <ASCII-FROM>
Envelope-Downgraded: To: <NON-ASCII-TO> <ASCII-TO>
Message-Id: MESSAGE_ID
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Subject: UTF-8_SUBJECT
From: <NON-ASCII-FROM<ASCII-FROM>>
To: <NON-ASCII-TO<ASCII-TO>>
CC: <NON-ASCII-CC<ASCII-CC>>
Date: DATE
MAIL_BODY
Figure 10: Downgraded header upgraded message
As a result, in this simple example, all headers are preserved.
YONEYA & Fujiwara Expires September 6, 2007 [Page 14]
Internet-Draft UTF8SMTP Downgrade Mar 2007
A.3. Downgrading example 2
In many cases, the sender wants to use Non-ASCII address and the
recipient does not support UTF8SMTP and does not have Non-ASCII
address.
o The sender address is "NON-ASCII-FROM" which is Non-ASCII address.
Its ASCII alternative is "ASCII-FROM".
o The "To" address is "ASCII-TO" which is ASCII only.
o The Subject header is "UTF8-SUBJECT" which contains Non-ASCII
characters.
Original UTF8SMTP message SMTP session
MAIL From: <NON-ASCII-FROM> ALT-ADDRESS <ASCII-FROM>
RCPT TO: <ASCII-TO>
-------------------------------------------------------------
Message-Id: MESSAGE_ID
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Subject: UTF8-SUBJECT
From: <NON-ASCII-FROM<ASCII-FROM>>
To: <ASCII-TO>
Date: DATE
MAIL_BODY
Figure 11: Original UTF8SMTP message 2
In this example, SMTP session is downgradable. Figure 12 shows SMTP
downgrading.
YONEYA & Fujiwara Expires September 6, 2007 [Page 15]
Internet-Draft UTF8SMTP Downgrade Mar 2007
After SMTP Downgrading
MAIL From: <ASCII-FROM>
RCPT TO: <ASCII-TO>
-------------------------------------------------------------
Envelope-Downgraded: From: <NON-ASCII-FROM> <ASCII-FROM>
Message-Id: MESSAGE_ID
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Subject: UTF8-SUBJECT
From: <NON-ASCII-FROM<ASCII-FROM>>
To: <ASCII-TO>
Date: DATE
MAIL_BODY
Figure 12: SMTP Downgraded UTF8SMTP message 2
After SMTP downgrading, header downgrading is performed. Final
downgraded messages are shown in Figure 13.
Result of the header downgrading.
Downgraded: Envelope-Downgraded: From:
MIME(<NON-ASCII-FROM>) <ASCII-FROM>
Message-Id: MESSAGE_ID
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Subject: MIME(UTF-8_SUBJECT)
Downgraded: From: MIME(<NON-ASCII-FROM<ASCII-FROM>>)
From: <ASCII-FROM>
To: <ASCII-TO>
Date: DATE
MAIL_BODY
Figure 13: Header downgraded message 2
This downgraded message's header part contains ASCII characters only.
But it still contains MIME encapsulated subject header which contains
UTF-8 characters. And more, the body part contains UTF-8 message.
"ascii user" needs to accept UTF-8 mail body and UTF-8 subject which
YONEYA & Fujiwara Expires September 6, 2007 [Page 16]
Internet-Draft UTF8SMTP Downgrade Mar 2007
is MIME encoded.
Authors' Addresses
Yoshiro YONEYA (editor)
JPRS
Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda
Chiyoda-ku, Tokyo 101-0065
Japan
Phone: +81 3 5215 8451
Email: yone@jprs.co.jp
Kazunori Fujiwara (editor)
JPRS
Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda
Chiyoda-ku, Tokyo 101-0065
Japan
Phone: +81 3 5215 8451
Email: fujiwara@jprs.co.jp
YONEYA & Fujiwara Expires September 6, 2007 [Page 17]
Internet-Draft UTF8SMTP Downgrade Mar 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
YONEYA & Fujiwara Expires September 6, 2007 [Page 18]
