One document matched: draft-ietf-eai-popimap-downgrade-06.xml
<?xml version="1.0" encoding="US-ASCII" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]
<?rfc sortrefs="yes" ?>
<?rfc rfcedstyle="yes" ?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc toc='yes'?>
<rfc category="std" ipr="trust200902" docName="draft-ietf-eai-popimap-downgrade-06.txt">
<front>
<title abbrev="POP/IMAP Downgrade">
Post-delivery Message Downgrading for Internationalized Email Messages
</title>
<author initials="K.F." surname="Fujiwara" fullname="Kazunori Fujiwara">
<organization abbrev="JPRS">Japan Registry Services Co., Ltd.</organization>
<address>
<postal>
<street>Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda</street>
<city>Chiyoda-ku</city>
<region>Tokyo</region>
<code>101-0065</code>
<country>Japan</country>
</postal>
<phone>+81 3 5215 8451</phone>
<email>fujiwara@wide.ad.jp, fujiwara@jprs.co.jp</email>
</address>
</author>
<date day="9" month="July" year="2012" />
<area>Applications</area>
<workgroup>Email Address Internationalization (EAI)</workgroup>
<keyword>EAI</keyword>
<keyword>Email Address Internationalization</keyword>
<keyword>Downgrade</keyword>
<keyword>MAIL</keyword>
<abstract>
<t>
The Email Address Internationalization (SMTPUTF8) extension allows
UTF-8 characters in mail header fields.
Upgraded POP and IMAP servers support internationalized Email messages.
If a POP/IMAP client does not support Email Address Internationalization,
POP/IMAP servers cannot send Internationalized Email Headers to the client
and cannot remove the message.
To avoid the situation,
this document describes a conversion mechanism
for internationalized Email messages to be in traditional message format.
In the process, message elements
requiring internationalized treatment are recoded or removed
and receivers are able to know that they received messages containing such
elements even if they cannot treat the internationalized elements.
</t>
</abstract>
</front>
<middle>
<section title="Introduction" anchor="intro">
<section title="Problem statement">
<t>
Traditional (legacy) mail systems, which are defined by <xref target="RFC5322" />,
allow only ASCII characters in mail header field values.
The SMTPUTF8 extension
(<xref target="RFC6530" /> and
<xref target="RFC6532" />)
allow raw UTF-8 in those mail header fields.
</t>
<t>
If a header field contains non-ASCII strings,
POP/IMAP servers cannot send Internationalized Email Headers to
legacy clients
and, because they have no obvious or standardized way to explain what
is going on to those clients, cannot even safely discard the message.
</t>
</section>
<section title="Possible solutions">
<t>
There
are four plausible approaches to the problem, with the preferred
one depending on the particular circumstances and relationship
among the delivery SMTP server, the mail store, the POP or IMAP
server, and the users and their MUA clients:
<list style="numbers">
<t>If the delivery MTA has sufficient knowledge about the POP
and/or IMAP servers and clients being used, the message
may be rejected as undeliverable.</t>
<t>The message may be downgraded by the POP or IMAP server,
in a way that preserves maximum information at the
expense of some complexity.</t>
<t>Some intermediate downgrading may be applied that balances
more information loss against lower complexity and greater
ease of implementation.</t>
<t>The POP or IMAP server may fabricate a message whose
intent is to notify the client that an internationalized
message is waiting but cannot be delivered until an
upgraded client is available.</t>
</list>
</t>
</section>
<section title="Approach taken in this specification">
<t> This specification describes the second of those options. It
is worth noticing that, at least in the general case, none of
these options preserve sufficient information to guarantee that
it is possible to reply to an incoming message without loss of
information, so the choice may be considered to be among "least
bad" options.</t>
<t>This message downgrading mechanism converts mail header fields to an
all-ASCII representation. The POP/IMAP servers can use the
downgrading mechanism and send the Internationalized Email message as
a traditional form.
Receivers can know they received some internationalized messages or some unknown/broken messages.
</t>
<t>
<xref target="RFC6532" />
allows UTF-8 characters to be used in
mail header fields and MIME header fields.
The message downgrading mechanism specified here describes
the conversion method
from the internationalized messages that are defined in
<xref target="RFC6530" />, and
<xref target="RFC6532" />
to the traditional email messages
defined in
<xref target="RFC5322" />.
</t>
<t>
This document provides a precise definition of the
minimum-information-loss message downgrading process.
</t>
<t>
Downgrading consists of the following three parts:
<vspace blankLines="1" />
<list style="symbols">
<t>New header field definitions</t>
<t>Email header field downgrading</t>
<t>MIME header field downgrading</t>
</list>
</t>
<t>
In <xref target="downgradedheader" /> of this document,
header fields starting with "Downgraded-" are introduced.
They preserve the information that appeared in the original
header fields.
</t>
<t>
Email header field downgrading is described in <xref target="HeaderDowngrading" />.
It generates ASCII-only header fields.
</t>
<t>
The definition of MIME header fields in Internationalized Email Messages
is described in <xref target="RFC6532" />.
MIME header field downgrading is described in <xref target="MIMEheaderdowngrading" />.
It generates ASCII-only MIME header fields.
</t>
<t>
Displaying downgraded messages that originally contained
internationalized header fields is out of scope of this
document. A POP/IMAP client which does not support UTF8
extension does not know internationalized message format
described in <xref target="RFC6532" />.
</t>
</section>
</section>
<section title="Terminology">
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
in this document are to be interpreted as described in RFC
2119 <xref target="RFC2119" />.
</t>
<t>
All specialized terms used in this specification are defined in the
Overview and Framework for Internationalized Email
<xref target="RFC6530" />, in the mail message specifications <xref target="RFC5322" />, or in the MIME documents
<xref target="RFC2045" /> <xref target="RFC2047" /> <xref target="RFC2183" /> <xref target="RFC2231" />.
The terms "ASCII address", "non-ASCII address", "SMTPUTF8", "message", "internationalized message"
are used with the definitions from <xref target="RFC6530" />.
The term "non-ASCII string"
is used with the definitions from <xref target="RFC6532" />.
</t>
</section>
<section title="New Header Fields Definition" anchor="downgradedheader">
<t>
New header fields are defined to preserve
information that appeared in non-ASCII strings in header
fields of the incoming message. The values of the new
fields holds the original header field value in encoded
form. The revised header field syntax is specified as
follows:
</t>
<figure>
<artwork>
<![CDATA[
fields =/ downgraded
downgraded = "Downgraded-Message-Id:" unstructured CRLF /
"Downgraded-Resent-Message-Id:" unstructured CRLF /
"Downgraded-In-Reply-To:" unstructured CRLF /
"Downgraded-References:" unstructured CRLF /
"Downgraded-Original-Recipient:" unstructured CRLF /
"Downgraded-Final-Recipient:" unstructured CRLF
]]>
</artwork>
</figure>
<t>To preserve a header field in a "Downgraded-" header field:
<list style="numbers">
<t>Generate a new header field.
<list style="symbols">
<t>The field name is a concatenation of "Downgraded-" and the original field name.</t>
<t>The initial new field value is the original header field value.</t>
</list>
</t>
<t>
Treat the initial new header field value as if it were unstructured,
and then apply <xref target="RFC2047" /> encoding with charset
UTF-8 as necessary so that the resulting new header field value
is completely in ASCII.
</t>
<t>
Remove the original header field.
</t>
</list>
</t>
</section>
<section title="Email Header Fields Downgrading" anchor="HeaderDowngrading">
<t>
This section defines the conversion method to ASCII for each header field
that may contain non-ASCII strings.
</t>
<t>
<xref target="RFC6532" /> expands
"Received:" header fields;
<xref target="RFC5322" /> describes ABNF elements
<mailbox>, <word>, <comment>, <unstructured>;
<xref target="RFC2045" /> describes ABNF element <value>.
</t>
<section title="Downgrading Method for Each ABNF Element" anchor="DowngradeElements">
<t>
Header field downgrading is defined below for each ABNF element.
Converting the header field terminates when no non-ASCII strings
remain in the header field.
</t>
<section title="<UNSTRUCTURED> Downgrading" anchor="element:unstructured">
<t>If the header field has an <unstructured> field that
contains non-ASCII strings,
apply <xref target="RFC2047" /> encoding with charset UTF-8.
</t></section>
<section title="<WORD> Downgrading" anchor="element:word">
<t>If the header field has any <word>
fields that contain non-ASCII strings,
apply <xref target="RFC2047" /> encoding with charset UTF-8.
</t></section>
<section title="<COMMENT> Downgrading" anchor="element:comment">
<t>If the header field has any <comment>
fields that contain non-ASCII strings,
apply <xref target="RFC2047" /> encoding with charset UTF-8.
</t></section>
<section title="<MIME-VALUE> Downgrading" anchor="element:mimevalue">
<t>If the header field has any <value> elements defined by <xref target="RFC2045" />
and the elements contain non-ASCII strings,
encode the <value> elements
according to <xref target="RFC2231" /> with charset UTF-8 and
leave the language information empty.
If the <value> element is <quoted-string>
and it contains <CFWS> outside the DQUOTE,
remove the <CFWS> before this conversion.
</t></section>
<section title="<DISPLAY-NAME> Downgrading" anchor="element:display-name">
<t>
If the header field has any <address>
(<mailbox> or <group>) elements and
they have <display-name> elements that contain non-ASCII strings,
encode the <display-name> elements
according to <xref target="RFC2047" /> with charset UTF-8.
DISPLAY-NAME downgrading is the same algorithm as WORD downgrading.
</t></section>
<section title="<GROUP> Downgrading" anchor="element:group">
<t>
<group> is defined in Section 3.4 of <xref target="RFC5322" />.
The <group> elements may contain <mailbox>s which contain non-ASCII addresses.
</t>
<t>
If the header field has any <group> elements that contain <mailbox> elements, and those <mailbox> elements in turn contain non-ASCII addresses,
rewrite each <group> element as
<figure>
<artwork>
<![CDATA[
display-name ENCODED_WORD " :;"
]]>
</artwork>
</figure>
where the <ENCODED_WORD> is the original <group-list> encoded
according to <xref target="RFC2047" />.
</t>
</section>
<section title="<MAILBOX> Downgrading" anchor="element:mailbox">
<t>The <mailbox> elements have no equivalent format for non-ASCII addresses.
If the header field has any <mailbox> elements that contain non-ASCII strings in their <addr-spec> element,
rewrite each <addr-spec> element to ASCII-only format.
The <addr-spec> element that contains non-ASCII strings may appear in two forms as:
</t>
<figure>
<artwork>
<![CDATA[
"<" addr-spec ">"
addr-spec
]]>
</artwork>
</figure>
<t>
Rewrite both as:
</t>
<figure>
<artwork>
<![CDATA[
ENCODED-WORD " :;"
]]>
</artwork>
</figure>
<t>where the <ENCODED-WORD> is the original <addr-spec> encoded
according to <xref target="RFC2047" />.
</t>
</section>
<section title="ENCAPSULATION Downgrading">
<t>
Encapsulate the header field in a "Downgraded-" header field as
described in <xref target="downgradedheader" />
as a last resort.</t>
<t>Applying this procedure to "Received:" header field is
prohibited. ENCAPSULATION Downgrading is allowed for
"Message-ID", "In-Reply-To:", "References:",
"Original-Recipient" and "Final-Recipient" header fields.
</t>
</section>
<section title="<TYPED-ADDRESS> Downgrading"><t>
If the header field contains <utf-8-type-addr>
and the <utf-8-type-addr> contains raw non-ASCII strings,
it is in utf-8-address form. Convert it to utf-8-addr-xtext form.
Those forms are described in <xref target="RFC6533" />.
COMMENT downgrading is also performed in this case.
If the address type is unrecognized and the header field contains non-ASCII strings,
then fall back to using ENCAPSULATION downgrading on the entire header field.
</t>
</section>
</section>
<section title="Downgrading Method for Each Header Field" anchor="DowngradeEachHeader">
<t>
<xref target="RFC4021" /> establishes a registry of header fields.
This section describes the downgrading method for each header field.
</t>
<t>
If the whole mail header field does not contain non-ASCII strings,
email header field downgrading is not required.
Each header field's downgrading method is described below.
</t>
<section title="Address Header Fields That Contain <address>s"
anchor="header:address">
<t>
<?rfc subcompact="yes" ?>
<vspace blankLines="1" />
<list style="hanging">
<t hangText="From:" />
<t hangText="Sender:" />
<t hangText="To:" />
<t hangText="Cc:" />
<t hangText="Bcc:" />
<t hangText="Reply-To:" />
<t hangText="Resent-From:" />
<t hangText="Resent-Sender:" />
<t hangText="Resent-To:" />
<t hangText="Resent-Cc:" />
<t hangText="Resent-Bcc:" />
<t hangText="Resent-Reply-To:" />
<t hangText="Return-Path:" />
<t hangText="Disposition-Notification-To:" />
</list>
<?rfc subcompact="no" ?>
</t>
<t>
If the header field contains <group> elements
that contain non-ASCII addresses,
perform <COMMENT> downgrading, <DISPLAY-NAME> downgrading, and <GROUP> downgrading.
</t>
<t>
If the header field contains <mailbox> elements
that contain non-ASCII addresses,
perform <COMMENT> downgrading, <DISPLAY-NAME> downgrading, and <MAILBOX> downgrading.
</t>
<t>
This procedure may generate empty <group> elements in "From:", "Sender:" and "Reply-To:" header fields.
<xref target="I-D.leiba-5322upd-from-group" /> updates <xref target="RFC5322" />
to allow (empty) <group> elements in "From:", "Sender:" and "Reply-To:" header fields.
</t>
</section>
<section title="Address Header Fields with Typed Addresses"
anchor="header:typedaddress">
<t>
<?rfc subcompact="yes" ?>
<vspace blankLines="1" />
<list style="hanging">
<t hangText="Original-Recipient:" />
<t hangText="Final-Recipient:" />
</list>
<?rfc subcompact="no" ?>
</t>
<t>If the header field contains non-ASCII strings, perform <TYPED-ADDRESS> downgrading.
</t></section>
<section title="Downgrading Non-ASCII in Comments"
anchor="header:comments">
<t>
<?rfc subcompact="yes" ?>
<vspace blankLines="1" />
<list style="hanging">
<t hangText="Date:" />
<t hangText="Resent-Date:" />
<t hangText="MIME-Version:" />
<t hangText="Content-ID:" />
<t hangText="Content-Transfer-Encoding:" />
<t hangText="Content-Language:" />
<t hangText="Accept-Language:" />
<t hangText="Auto-Submitted:" />
</list>
<?rfc subcompact="no" ?>
</t>
<t>These header fields do not contain non-ASCII strings except in comments.
If the header field contains UTF-8 characters in comments, perform <COMMENT> downgrading.
</t></section>
<section title="Message-ID Header Fields" anchor="header:msgid">
<t>
<?rfc subcompact="yes" ?>
<vspace blankLines="1" />
<list style="hanging">
<t hangText="Message-ID:" />
<t hangText="Resent-Message-ID:" />
<t hangText="In-Reply-To:" />
<t hangText="References:" />
</list>
<?rfc subcompact="no" ?>
</t>
<t>Perform ENCAPSULATION Downgrading.</t>
</section>
<section title="Received Header Field" anchor="header:received">
<t>
<?rfc subcompact="yes" ?>
<vspace blankLines="1" />
<list style="hanging">
<t hangText="Received:" />
</list>
<?rfc subcompact="no" ?>
<vspace blankLines="1" />
If the FOR clause contains a non-ASCII address,
remove the FOR clause from the header field.
Comments may contain non-ASCII strings, Perform <COMMENT> downgrading.
Other parts should not contain non-ASCII strings.
</t>
</section>
<section title="MIME Content Header Fields" anchor="header:mime">
<t>
<?rfc subcompact="yes" ?>
<vspace blankLines="1" />
<list style="hanging">
<t hangText="Content-Type:" />
<t hangText="Content-Disposition:" />
</list>
<?rfc subcompact="no" ?>
<vspace blankLines="1" />
Perform <MIME-VALUE> downgrading and <COMMENT> downgrading.
</t>
</section>
<section title="Non-ASCII in <unstructured>" anchor="header:unstructured">
<t>
<?rfc subcompact="yes" ?>
<vspace blankLines="1" />
<list style="hanging">
<t hangText="Subject:" />
<t hangText="Comments:" />
<t hangText="Content-Description:" />
</list>
<?rfc subcompact="no" ?>
<vspace blankLines="1" />
Perform <UNSTRUCTURED> downgrading.
</t>
</section>
<section title="Non-ASCII in <phrase>" anchor="header:phrase"><t>
<list style="hanging">
<t hangText="Keywords:" />
</list>
Perform <WORD> downgrading.
</t></section>
<section title="Other Header Fields" anchor="header:undefined">
<t>There are other header fields that contain non-ASCII strings.
They are user-defined and missing from this document,
or future defined header fields. They are treated as
"Optional Fields" and their field values are treated as
unstructured described in Section 3.6.8 of <xref
target="RFC5322" />.</t>
<t>Perform <UNSTRUCTURED> downgrading.</t>
<t>If the software understands the header field's structure and a downgrading
algorithm other than UNSTRUCTURED is applicable, that software SHOULD use
that algorithm; UNSTRUCTURED downgrading is used as a last resort.</t>
<t>Mailing list header fields (those that start in "List-")
are part of this category.</t>
</section>
</section>
</section>
<section title="MIME Body-Part Header Field Downgrading" anchor="MIMEheaderdowngrading">
<t>
MIME body-part header fields may contain non-ASCII strings
<xref target="RFC6532" />.
This section defines the conversion method to ASCII-only header fields
for each MIME header field that contains non-ASCII strings.
Parse the message body's MIME structure at all levels and
check each MIME header field to see whether it contains non-ASCII strings.
If the header field contains non-ASCII strings in the header field value,
the header field is a target of the MIME body-part header field's downgrading.
Each MIME header field's downgrading method is described below.
COMMENT downgrading, MIME-VALUE downgrading, and UNSTRUCTURED downgrading
are described in <xref target="HeaderDowngrading" />.
<list style="hanging">
<t hangText="Content-ID:">
<vspace />
The "Content-ID:" header field does not contain non-ASCII strings
except in comments. If the header field contains
UTF-8 characters in comments, perform <COMMENT> downgrading.
</t>
<t hangText="Content-Type:" />
<t hangText="Content-Disposition:">
<vspace />
Perform <MIME-VALUE> downgrading and
<COMMENT> downgrading.
</t>
<t hangText="Content-Description:">
Perform <UNSTRUCTURED> downgrading.
</t>
</list>
</t>
</section>
<section title="Security Considerations" anchor="security">
<t>
The purpose of post-delivery message downgrading is to allow
POP/IMAP servers to deliver internationalized messages
to traditional POP/IMAP clients
and permit the clients to display those messages.
Users who receive such messages can know that they were
internationalized.
It does not permit receivers to read the messages in their
original form and, in general, will not permit generating
replies, at least without significant user intervention.
</t>
<t>
A downgraded message's header fields contain ASCII characters only.
But they still contain MIME-encapsulated header fields that contain
non-ASCII strings. Furthermore, the body part may contain UTF-8 characters.
Implementations parsing Internet messages need
to accept UTF-8 body parts and UTF-8 header fields that are MIME-encoded.
Thus, this document inherits the security considerations of
MIME-encoded header fields (<xref target="RFC2047" /> and
<xref target="RFC3629" />).
</t>
<t>
Rewriting header fields increases the opportunities for
undetected spoofing by malicious senders.
However, the rewritten header field values are
preserved in equivalent MIME form
or in newly defined header fields which traditional MUAs do not care.
</t>
<t>
The techniques described here invalidate methods that depend
on digital signatures over any part of the message,
which includes the top-level header fields and body-part header fields.
Depending on the specific message being downgraded, at least the
following techniques are likely to break: DomainKeys Identified
Mail (DKIM), and possibly S/MIME and Pretty Good Privacy (PGP).
Receivers may know they need to update their MUAs, or they don't care.
</t>
<t>
While information in any email header field should usually be treated with
some suspicion, current email systems commonly employ various
mechanisms and protocols to make the information more trustworthy.
Information in the new Downgraded-* header fields is
not inspected by MUAs, and may be even less trustworthy
than the traditional header fields.
Note that the Downgraded-* header fields could have been inserted with malicious intent
(and with content unrelated to the traditional header fields),
however traditional MUAs do not parse Downgraded-* header fields.
</t>
<t>
In addition, if an Authentication-Results header
field <xref target="RFC5451" /> is present,
traditional MUAs may treat that the digital signatures are valid.
</t>
<t>
See the "Security Considerations" section in <xref target="I-D.leiba-5322upd-from-group"/> and <xref target="RFC6530"/> for more discussion.
</t>
</section>
<section title="Implementation Notes">
<section title="RFC 2047 Encoding">
<t>
While <xref target="RFC2047" /> has a specific algorithm to deal with whitespace in
adjacent encoded words, there are a number of deployed implementations
that fail to implement the algorithm correctly. As a result, whitespace
behavior is somewhat unpredictable in practice when multiple encoded words
are used. While RFC 5322 states that implementations SHOULD limit lines
to not more than 78 characters, implementations MAY choose to allow
overly long encoded words in order to work around faulty <xref target="RFC2047" />
implementations. Implementations that choose to do so SHOULD have an
optional mechanism to limit line length to 78 characters.
</t>
</section>
</section>
<section title="IANA Considerations" anchor="iana">
<t>
[[RFC Editor: Please change "should now be" and "should
be" to "have been" when the IANA actions are complete.]]
</t>
<t>
<xref target="RFC5504" /> registered many "Downgraded-" header fields
and requested that
'IANA will refuse registration of all field names that start with
"Downgraded-", to avoid possible conflict with the procedure
for unknown header fields' preservation
described in Section 3.3 of <xref target="RFC5504" />.'
However <xref target="RFC6530" /> obsoleted
<xref target="RFC5504" /> and this document does not use
all "Downgraded-" header fields registered by <xref target="RFC5504" />.
</t>
<t>
The following header fields should be registered in the
Permanent Message Header Field registry, in accordance with the
procedures set out in <xref target="RFC3864" />.
<?rfc subcompact="yes" ?>
<vspace blankLines="1" />
<list style="hanging">
<t hangText="Header field name:">Downgraded-Message-Id</t>
<t hangText="Applicable protocol:">mail</t>
<t hangText="Status:">standard</t>
<t hangText="Author/change controller:">IETF</t>
<t hangText="Specification document(s):">This document (<xref target="downgradedheader" />)</t>
</list>
<vspace blankLines="1" />
<list style="hanging">
<t hangText="Header field name:">Downgraded-In-Reply-To</t>
<t hangText="Applicable protocol:">mail</t>
<t hangText="Status:">standard</t>
<t hangText="Author/change controller:">IETF</t>
<t hangText="Specification document(s):">This document (<xref target="downgradedheader" />)</t>
</list>
<vspace blankLines="1" />
<list style="hanging">
<t hangText="Header field name:">Downgraded-References</t>
<t hangText="Applicable protocol:">mail</t>
<t hangText="Status:">standard</t>
<t hangText="Author/change controller:">IETF</t>
<t hangText="Specification document(s):">This document (<xref target="downgradedheader" />)</t>
</list>
<vspace blankLines="1" />
<list style="hanging">
<t hangText="Header field name:">Downgraded-Original-Recipient</t>
<t hangText="Applicable protocol:">mail</t>
<t hangText="Status:">standard</t>
<t hangText="Author/change controller:">IETF</t>
<t hangText="Specification document(s):">This document (<xref target="downgradedheader" />)</t>
</list>
<vspace blankLines="1" />
<list style="hanging">
<t hangText="Header field name:">Downgraded-Final-Recipient</t>
<t hangText="Applicable protocol:">mail</t>
<t hangText="Status:">standard</t>
<t hangText="Author/change controller:">IETF</t>
<t hangText="Specification document(s):">This document (<xref target="downgradedheader" />)</t>
</list>
<?rfc subcompact="no" ?>
</t>
</section>
<section title="Acknowledgements">
<t>
This document draws heavily from the experimental in-transit
message downgrading procedure described in RFC 5504
<xref target="RFC5504"/>. The contribution of the co-author
of that earlier document, Y. Yoneya, are gratefully
acknowledged.
Significant comments and suggestions were received from John
Klensin, Barry Leiba, Randall Gellens, Pete Resnick, Martin J. Durst,
and other WG participants.
</t>
</section>
<section title="Change History">
<t>
[[RFC Editor: Please remove this section prior to publication.]]
</t>
<t>
This section is used for tracking the update of this document. Will be
removed after finalize.
</t>
<section title="Version 00">
<t>
<list style="symbols">
<t>Initial version</t>
<t>Imported header field downgrading from RFC 5504</t>
</list>
</t>
</section>
<section title="Version 01">
<t>
<list style="symbols">
<t>same as Version 00</t>
</list>
</t>
</section>
<section title="Version 02">
<t>
<list style="symbols">
<t>Added updating RFC 5322 to allow <group> syntax in From: and Sender</t>
<t>Added GROUP Downgrading</t>
</list>
</t>
</section>
<section title="Version 03">
<t>
<list style="symbols">
<t>Replaced <utf8-addr-spec> with <addr-spec></t>
<t>Added updating RFC 5322 to allow <group> syntax in From: and Sender</t>
<t>Added one sentence in Security considerations</t>
<t>Updated IANA considerations</t>
</list>
</t>
</section>
<section title="Version 04">
<t>
<list style="symbols">
<t>Removed "Internationalized Address removed" from GROUP and MAILBOX downgrading</t>
<t>Updated "Updating RFC 5322"</t>
<t>Compacted new header field definition</t>
<t>Compacted security considerations</t>
<t>Updated IANA considerations to remove obsoleting header fields that are registered by RFC 5504</t>
<t>Added a discussion of alternate downgrading models for the
POP and IMAP cases.</t>
<t>Incorporated a large number of editorial changes to improve clarity.</t>
</list>
</t>
</section>
<section title="Version 05">
<t>
<list style="symbols">
<t>Some text corrections</t>
<t>Terminology change: only to use non-ASCII address, non-ASCII message, non-ASCII string and imported them from RFC 6530 and RFC 6532</t>
<t>Replace "non-ASCII character" with "non-ASCII string"</t>
<t>Removed 5.1.1. RECEIVED Downgrading: It's </t>
</list>
</t>
</section>
<section title="Version 06">
<t>
<list style="symbols">
<t>Removed "Updating RFC 5322"</t>
<t>Added reference to draft-leiba-5322upd-from-group</t>
</list>
</t>
</section>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2045" ?>
<?rfc include="reference.RFC.2047" ?>
<?rfc include="reference.RFC.2119" ?>
<?rfc include="reference.RFC.2183" ?>
<?rfc include="reference.RFC.2231" ?>
<?rfc include="reference.RFC.3629" ?>
<?rfc include="reference.RFC.3864" ?>
<?rfc include="reference.RFC.4021" ?>
<?rfc include="reference.RFC.5322" ?>
<?rfc include="reference.RFC.6530" ?>
<?rfc include="reference.RFC.6532" ?>
<?rfc include="reference.RFC.6533" ?>
<?rfc include="reference.I-D.draft-leiba-5322upd-from-group-01" ?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.5451" ?>
<?rfc include="reference.RFC.5504" ?>
</references>
<section title="Examples">
<section title="Downgrading Example">
<t>
This appendix shows an message downgrading example.
Consider a received mail message where:
<list style="symbols">
<t>
The sender address is a non-ASCII address, "NON-ASCII-LOCAL@example.com". Its display-name is "DISPLAY-LOCAL".
</t>
<t>
The "To:" header field contains two non-ASCII addresses, "NON-ASCII-REMOTE1@example.net" and "NON-ASCII-REMOTE2@example.com" Its display-names are "DISPLAY-REMOTE1" and "DISPLAY-REMOTE2".
</t>
<t>
The "Cc:" header field contains a non-ASCII address, "NON-ASCII-REMOTE3@example.org".
Its display-name is "DISPLAY-REMOTE3".
</t>
<t>Four display names contain non-ASCII characters.</t>
<t>
The Subject header field is "NON-ASCII-SUBJECT", which contains non-ASCII strings.
</t>
<t>
The "Message-Id:" header field contains "NON-ASCII-MESSAGE_ID",
which contains non-ASCII strings.
</t>
<t>
There is an unknown header field "X-Unknown-Header" which contains non-ASCII strings.
</t>
</list>
</t>
<t>
<figure title="Received message in a mail drop" anchor="example-originaleaismtpsession">
<artwork>
<![CDATA[
Return-Path: <NON-ASCII-LOCAL@example.com>
Received: from ... by ... for <NON-ASCII-REMOTE1@example.net>
Received: from ... by ... for <NON-ASCII-REMOTE1@example.net>
From: DISPLAY-LOCAL <NON-ASCII-LOCAL@example.com>
To: DISPLAY-REMOTE1 <NON-ASCII-REMOTE1@example.net>,
DISPLAY-REMOTE2 <NON-ASCII-REMOTE2@example.com>
Cc: DISPLAY-REMOTE3 <NON-ASCII-REMOTE3@example.org>
Subject: NON-ASCII-SUBJECT
Date: DATE
Message-Id: NON-ASCII-MESSAGE_ID
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-Unknown-Header: NON-ASCII-CHARACTERS
MAIL_BODY
]]>
</artwork>
</figure>
</t>
<t>
The downgraded message is shown in
<xref target="example-downgrading" />.
"Return-Path:", "From:", "To:" and "Cc:" header fields are rewritten.
"Subject:" and "X-Unknown-Header:" header fields are encoded
using <xref target="RFC2047" />.
"Message-Id:" header field is encapsulated as
"Downgraded-Message-Id:" header field.
<figure title="Downgraded message" anchor="example-downgrading">
<artwork>
<![CDATA[
Return-Path: =?UTF-8?Q?NON-ASCII-LOCAL@example.com?= :;
Received: from ... by ...
Received: from ... by ...
From: =?UTF-8?Q?DISPLAY-LOCAL?=
=?UTF-8?Q?NON-ASCII-LOCAL@example.com?= :;
To: =?UTF-8?Q?DISPLAY-REMOTE1?=
=?UTF-8?Q?NON-ASCII-REMOTE1@example.net?= :;,
=?UTF-8?Q?DISPLAY-REMOTE2?=
=?UTF-8?Q?NON-ASCII-REMOTE2@example.com?= :;,
Cc: =?UTF-8?Q?DISPLAY-REMOTE3?=
=?UTF-8?Q?NON-ASCII-REMOTE3@example.org?= :;
Subject: =?UTF-8?Q?NON-ASCII-SUBJECT?=
Date: DATE
Downgraded-Message-Id: =?UTF-8?Q?MESSAGE_ID?=
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-Unknown-Header: =?UTF-8?Q?NON-ASCII-CHARACTERS?=
MAIL_BODY
]]>
</artwork>
</figure>
</t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:08:59 |