One document matched: draft-ietf-eai-downgraded-display-02.xml
<?xml version="1.0"?>
<!-- $Id: draft-ietf-eai-downgraded-display-02.xml,v 1.16 2009/09/08 06:51:59 fujiwara Exp $ -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY % rfc2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY % rfc2045 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2045.xml'>
<!ENTITY % rfc2047 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2047.xml'>
<!ENTITY % rfc2183 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2183.xml'>
<!ENTITY % rfc2231 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2231.xml'>
<!ENTITY % rfc5321 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5321.xml'>
<!ENTITY % rfc5322 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5322.xml'>
<!ENTITY % rfc3461 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3461.xml'>
<!ENTITY % rfc3864 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3864.xml'>
<!ENTITY % rfc4021 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4021.xml'>
<!ENTITY % rfc4952 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4952.xml'>
<!ENTITY % rfc5335 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5335.xml'>
<!ENTITY % rfc5336 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5336.xml'>
<!ENTITY % rfc5337 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5337.xml'>
<!ENTITY % rfc5504 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5504.xml'>
]>
<?rfc compact='yes'?>
<?rfc toc='yes'?>
<!-- Validator on -->
<?rfc strict="yes" ?>
<!-- Expand crefs and put them inline -->
<?rfc comments='yes' ?>
<?rfc inline='yes' ?>
<!-- RFC references as names, not numbers -->
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes" ?>
<rfc category="exp" ipr="trust200902" docName="draft-ietf-eai-downgraded-display-02.txt">
<!-- ipr: full2026 / noDerivativeWorks2026 / none -->
<front>
<title abbrev="Displaying Downgraded Messages">
Displaying Downgraded Messages for Email Address Internationalization
</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@jprs.co.jp</email>
</address>
</author>
<date month="Sep" day="8" year="2009" />
<area>Applications</area>
<workgroup>Email Address Internationalization (EAI)</workgroup>
<!-- <area ...>, <workgroup ...>, <keyword ...>, <keyword ...> <note..> -->
<abstract>
<t>
This document describes a method for displaying downgraded messages
which originally contained internationalized E-mail addresses or
internationalized header fields.
</t>
</abstract>
</front>
<middle>
<section title="Introduction" anchor="intro">
<t>
The Email Address Internationalization (UTF8SMTP) extension document set
<xref target="RFC4952" />
<xref target="RFC5336" />
<xref target="RFC5335" />
<xref target="RFC5337" />
expands Email address structure, syntax and Email header format.
To avoid rejection of internationalized Email messages,
the downgrading mechanism <xref target="RFC5504" />
converts an internationalized message to a traditional Email message
when a server in the delivery path does not support the UTF8SMTP extension.
The downgraded message is a traditional Email message,
except the message has "Downgraded-" header fields.
</t>
<t>
A perfect reverse-function of the downgrading does not exist
because the encoding defined in <xref target="RFC2047" /> is not exactly reversible
and Received header field downgrading may remove FOR clause information.
The restoration of the downgrading should be done once at the final
destination of the downgraded message such as MUAs or IMAP servers.
This document describes the restoration methods as displaying downgraded messages
in MUAs.
</t>
</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>
Specialized terms used in this specification are defined in the
EAI overview <xref target="RFC4952" /> or in
<xref target="RFC5321" /><xref target="RFC5322" />,
MIME documents
<xref target="RFC2045" />
<xref target="RFC2047" />
<xref target="RFC2183" />
<xref target="RFC2231" />.
</t>
<t>
This document depends on
<xref target="RFC5335" /> and
<xref target="RFC5504" />.
Key words used in these document are used in this document, too.
</t>
<t>
The term "non-ASCII" is an UTF-8 string which contains at least
one non-ASCII character.
</t>
<t>
The term "address header field" is used for a header field which
contains <mailbox> elements which is defined in <xref target="RFC5322" />.
"Address header fields" contain
"From", "Sender", "Reply-To", "To", "Cc", "Bcc", "Resent-From",
"Resent-Sender", "Resent-To", "Resent-Cc", "Return-Path" header fields.
</t>
<t>
An "UTF8SMTP message" is an Email messages expanded by
<xref target="RFC5335" />.
</t>
<t>
The term "MIME decode" is used for both "encoded-word" decoding defined by <xref target="RFC2047" /> and
MIME parameter value decoding defined by <xref target="RFC2231" />.
</t>
</section>
<section title="Consideration of displaying downgraded message" anchor="consieration">
<t>
Displaying downgraded message is mostly performed by MIME decoding
according to <xref target="RFC2047" /> and <xref target="RFC2231" />.
As a result of MIME decoding,
the header of the message still contains "Downgraded-" header fields,
but the header field bodies are MIME decoded.
These decoded "Downgraded-" header fields contain
the original header field name and the original header field values.
The recipient can read them.
But the recipient's MUA cannot use the original header fields automatically.
</t>
<t>
Additionally, A MUA can process "Downgraded-" header fields.
</t>
<t>
The easiest way to process "Downgraded-" header fields is to remove "Downgraded-" from the decoded "Downgraded-" header fields' names.
Then, the "address header fields" may be displayed twice,
one is from downgraded header field
and the other is from decoded "Downgraded-" header field.
Although it is very easy, it MUST NOT be used because of the following reasons.
<list style="symbols">
<t>
<xref target="RFC5322" /> section 3.6 defines number of times each field may occur in the header section of a message and the maximum number for "From", "Sender", "To", "Cc", "Bcc" header fields is 1.
It violates <xref target="RFC5322" />.
</t>
<t>
Users cannot distinguish which is the original downgraded header field and which is the generated header field.
</t>
<t>
The "Downgraded-" header field and corresponding header field may not have relations.
</t>
</list>
</t>
</section>
<section title="Displaying downgraded message" anchor="DecodingTechnique">
<t>
A MUA MAY decode and re-generate the original header fields of the message.
This procedure can be used to reverse the Downgrade process
but
will not construct exactly the original header fields in all cases.
</t>
<t>
Displaying downgraded message is implemented by the following steps.
<vspace blankLines="1"/>
<list style="hanging">
<t hangText="Input: ">
<vspace blankLines="0"/>
The input to this procedure is
the header of the message as received.
Copy the entire header into an edit space.
<vspace blankLines="1"/>
</t>
<t hangText="Step 1: ">
<vspace blankLines="0"/>
Select the "Address Header Fields' Preservation Header Fields" described in Section 3.2 of <xref target="RFC5504" /> in the edit space.
These header fields are
"Downgraded-From", "Downgraded-Sender",
"Downgraded-To", "Downgraded-Cc", "Downgraded-Bcc",
"Downgraded-Reply-To",
"Downgraded-Resent-From", "Downgraded-Resent-Sender",
"Downgraded-Resent-To", "Downgraded-Resent-Cc",
"Downgraded-Resent-Bcc", "Downgraded-Resent-Reply-To",
"Downgraded-Return-Path" and "Downgraded-Disposition-Notification-To" header fields.
<vspace blankLines="1"/>
</t>
<t hangText="Step 2: ">
<vspace blankLines="0"/>
For each header field from the output of Step 1, generate a new header field where the field name is the original header field name
and the field value is the result of MIME decoding header field value.
<vspace blankLines="1"/>
</t>
<t hangText="Step 3: ">
<vspace blankLines="0"/>
Apply "Email Header Fields Downgrading" defined in
section 5 of <xref target="RFC5504" />
to the output of Step 2
without re-generating "Downgraded-" header fields
and copy the output into a new space (hereafter, call it as a "comparison space").
<vspace blankLines="1"/>
</t>
<t hangText="Step 4: ">
<vspace blankLines="0"/>
Compare the header fields in the comparison space with the header
fields of the same name in the edit space.
Before this comparison, canonicalize each header field described below.
<vspace blankLines="1"/>
<list style="numbers">
<t>Unfold all header field continuation lines as described in <xref target="RFC5322" />.</t>
<t>Insert a space character before and after <mailbox-list> separator ","
if there is no space character.</t>
<t>Insert a space character before and after <comment>
if there is no space character.</t>
<t>Decode each <encoded-word> whose charset is 'UTF-8'.</t>
<t>Convert all sequences of one or more WSP characters to a single space
character. WSP characters here include those before and after a
line folding boundary.</t>
<t>Delete all WSP characters at the end of each unfolded header field value.</t>
<t>Delete any WSP characters remaining before and after the colon
separating the header field name from the header field value. The
colon separator MUST be retained.</t>
</list>
<vspace blankLines="1"/>
For each header field,
if the same header fields exist in the comparison space and in the edit space,
remove the original header field in the edit space and
the generated header field in the comparison space.
<vspace blankLines="1"/>
Remaining header fields in the comparison space may be
bogus or broken "Address Header Fields' Preservation Header Fields" origin.
<vspace blankLines="1"/>
</t>
<t hangText="Step 5: ">
<vspace blankLines="0"/>
Decode all MIME encoded header fields
according to <xref target="RFC2047" /> and <xref target="RFC2231" />
in the edit space.
<vspace blankLines="1"/>
</t>
<t hangText="Step 6:">
<vspace blankLines="0"/>
For each "Unknown Header Fields' Preservation Header Fields" described in section 3.3 of <xref target="RFC5504" />
and "Address Header Fields' Preservation Header Fields",
generate a new header field where the field name is the original header field name
and the field value is the result of MIME decoding header field value,
then replace the original "Downgraded-" header field by the generated header field in the edit space.
"Envelope Information Preservation Header Fields" are not targets of this step.
<vspace blankLines="1" />
</t>
</list>
</t>
<t>
The output of this procedure is an UTF8SMTP header in the edit space.
It will closely resemble the original header.
</t>
<t>
After this procedure, the MUA may decode MIME body part header fields
according to <xref target="RFC2047" /> and <xref target="RFC2231" />.
</t>
</section>
<section title="Security considerations" anchor="security">
<t>
While information in any email header should usually treated with
some suspicion, current email systems commonly employ various
mechanisms and protocols to make the information more trustworthy.
For example, an organization's boundary MTA can modify "From:" lines
so that messages arriving from outside the organization are easily
distinguishable from internal emails. As a result of rewriting,
the "Downgraded-From" header field may not be decoded.
</t>
<t>
A MUA may emphasize bogus or broken "Downgraded-" header fields in step 4 of <xref target="DecodingTechnique" />.
</t>
<t>
Hiding the information from the actual header fields when using the
"Downgraded-" header fields does not cause loss of information if
the comparison done in step 4 of <xref target="DecodingTechnique" />
is successful. To ensure that no information is lost, a MUA
SHOULD have a function that uses the actual message that was
received (with/without MIME decoding) to render the message.
</t>
<t>
See "Security considerations" section in <xref target="RFC5504" /> and <xref target="RFC4952"/> for more discussion.
</t>
</section>
<section title="IANA Considerations">
<t>
This document makes no requests for IANA action. This section can be
removed by the RFC Editor before publication.
</t>
</section>
<section title="Acknowledgements">
<t>
This document was separated from <xref target="RFC5504" />.
Both documents were developed in the EAI WG. Significant
comments and suggestions were received from John
Klensin, Harald Alvestrand, Chris Newman, Randall Gellens,
Charles Lindsey, Marcos Sanz, Alexey Melnikov, Frank
Ellermann, Edward Lewis, S. Moonesamy and JET members.
</t>
</section>
<section title="Change History">
<t>
This section is used for tracking the update of this document. Will be
removed after finalize.
</t>
<section title="draft-fujiwara-eai-downgraded-display: Version 00">
<t>
<list style="symbols">
<t>Initial version</t>
<t>It is separated from Appendix A of draft-ietf-eai-downgrade-05.txt</t>
</list>
</t>
</section>
<section title="draft-ietf-eai-downgraded-display: Version 00">
<t>
<list style="symbols">
<t>Submitted as a working group draft</t>
</list>
</t>
</section>
<section title="draft-ietf-eai-downgraded-display: Version 01">
<t>
<list style="symbols">
<t>Prohibited and removed Displaying Technique 1</t>
<t>Added new texts to Security Considerations</t>
</list>
</t>
</section>
<section title="draft-ietf-eai-downgraded-display: Version 02">
<t>
<list style="symbols">
<t>updated by comments from Chair's review and AD's review</t>
<t>Fixed references</t>
<t>Rewrote section 4 to be more comprehensible</t>
<t>Added bogus or broken "Downgraded-" header fields</t>
<t>Added sentences in Security considerations</t>
</list>
</t>
</section>
</section>
</middle>
<back>
<references title="Normative References">
&rfc4952;
&rfc5335;
&rfc5504;
&rfc2045;
&rfc2047;
&rfc2183;
&rfc2231;
&rfc5322;
&rfc2119;
</references>
<references title="Informative References">
&rfc5321;
&rfc5336;
&rfc5337;
</references>
<section title="Examples">
<t>
This section shows a example of displaying downgraded message.
First, an example of the original UTF8SMTP message and its downgraded message are
shown. They are the same as
"Example 1" of <xref target="RFC5504" />.
The example UTF8SMTP message is shown in <xref target="example-originaleaismtpsession" />.
</t>
<t>
<figure title="Original message" anchor="example-originaleaismtpsession">
<artwork>
<![CDATA[
Message-Id: MESSAGE_ID
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Subject: NON-ASCII-SUBJECT
From: DISPLAY-local <NON-ASCII-local@example.com
<ASCII-local@example.com>>
To: DISPLAY-remote1 <NON-ASCII-remote1@example.net
<ASCII-remote1@example.net>>
Cc: DISPLAY-remote2 <NON-ASCII-remote2@example.org>
Date: DATE
MAIL_BODY
]]>
</artwork>
</figure>
</t>
<t>
Delivered downgraded message is shown in <xref target="example-headerconversiondowngrading" />.
Return-Path header will be added by the final destination MTA.
<figure title="Downgraded message" anchor="example-headerconversiondowngrading">
<artwork>
<![CDATA[
Return-Path: <ASCII-local@example.com>
Downgraded-Mail-From: =?UTF-8?Q?<NON-ASCII-local@example.com_?=
=?UTF-8?Q?<ASCII-local@example.com>>?=
Downgraded-Rcpt-To: =?UTF-8?Q?<NON-ASCII-remote1@example.net_?=
=?UTF-8?Q?<ASCII-remote1@example.net>>?=
Message-Id: MESSAGE_ID
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Subject: =?UTF-8?Q?NON-ASCII-SUBJECT?=
From: =?UTF-8?Q?DISPLAY-local?= <ASCII-local@example.com>
Downgraded-From: =?UTF-8?Q?DISPLAY-local_<NON-ASCII-local@example.com_?=
=?UTF-8?Q?<ASCII-local@example.com>>?=
To: =?UTF-8?Q?DISPLAY-remote1?= <ASCII-remote1@example.net>
Downgraded-To: =?UTF-8?Q?DISPLAY-remote1_?=
=?UTF-8?Q?<NON-ASCII-remote1@example.net_<ASCII-remote1@example.net>>?=
Cc: =?UTF-8?Q?DISPLAY-remote2?= Internationalized address
=?UTF-8?Q?NON-ASCII-remote2@example.org?= removed:;
Downgraded-Cc: =?UTF-8?Q?DISPLAY-remote2_?=
=?UTF-8?Q?<NON-ASCII-remote2@example.org>?=
Date: DATE
MAIL_BODY
]]>
</artwork>
</figure>
</t>
<t>
<xref target="example-mimedecoded" /> shows MIME decoded message of
<xref target="example-headerconversiondowngrading" />.
The recipient can read the original From, To, Cc header fields as
Downgraded-From, Downgraded-To, Downgraded-Cc header fields.
<figure title="MIME decoded message" anchor="example-mimedecoded">
<artwork>
<![CDATA[
Return-Path: <ASCII-local@example.com>
Downgraded-Mail-From: <NON-ASCII-local@example.com
<ASCII-local@example.com>>
Downgraded-Rcpt-To: <NON-ASCII-remote1@example.net
<ASCII-remote1@example.net>>
Message-Id: MESSAGE_ID
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Subject: NON-ASCII-SUBJECT
From: DISPLAY-local <ASCII-local@example.com>
Downgraded-From: DISPLAY-local <NON-ASCII-local@example.com
<ASCII-local@example.com>>
To: DISPLAY-remote1 <ASCII-remote1@example.net>
Downgraded-To: DISPLAY-remote1 <NON-ASCII-remote1@example.net
<ASCII-remote1@example.net>>
Cc: DISPLAY-remote2 Internationalized address
NON-ASCII-remote2@example.org removed:;
Downgraded-Cc: DISPLAY-remote2 <NON-ASCII-remote2@example.org>
Date: DATE
MAIL_BODY
]]>
</artwork>
</figure>
<vspace blankLines="100"/>
</t>
<section title="Displaying example">
<t>
This example shows processes of
'Displaying downgraded message' for
<xref target="example-headerconversiondowngrading" />.
</t>
<t>
First, perform Step 1.
</t>
<t>
<figure title="Displaying: Output of Step 1" anchor="example-step1">
<artwork>
<![CDATA[
Downgraded-From: =?UTF-8?Q?DISPLAY-local_<NON-ASCII-local@example.com_?=
=?UTF-8?Q?<ASCII-local@example.com>>?=
Downgraded-To: =?UTF-8?Q?DISPLAY-remote1_?=
=?UTF-8?Q?<NON-ASCII-remote1@example.net_<ASCII-remote1@example.net>>?=
Downgraded-Cc: =?UTF-8?Q?DISPLAY-remote2_?=
=?UTF-8?Q?<NON-ASCII-remote2@example.org>?=
]]>
</artwork>
</figure>
</t>
<t>
Then, perform Step 2.
</t>
<t>
<figure title="Displaying: Output of Step 2" anchor="example-step2">
<artwork>
<![CDATA[
From: DISPLAY-local <NON-ASCII-local@example.com
<ASCII-local@example.com>>
To: DISPLAY-remote1 <NON-ASCII-remote1@example.net
<ASCII-remote1@example.net>>
Cc: DISPLAY-remote2 <NON-ASCII-remote2@example.org>
]]>
</artwork>
</figure>
</t>
<t>
Perform Step 3.
</t>
<t>
<figure title="Displaying: Output of Step 3" anchor="example-step3">
<artwork>
<![CDATA[
From: =?UTF-8?Q?DISPLAY-local?= <ASCII-local@example.com>
To: =?UTF-8?Q?DISPLAY-remote1?= <ASCII-remote1@example.net>
Cc: =?UTF-8?Q?DISPLAY-remote2?= Internationalized address
=?UTF-8?Q?NON-ASCII-remote2@example.org?= removed:;
]]>
</artwork>
</figure>
</t>
<t>
Perform Step 4. "From", "To", "Cc" header fields are removed in <xref target="example-step4" />.
</t>
<t>
<figure title="Displaying: Output of Step 4" anchor="example-step4">
<artwork>
<![CDATA[
Return-Path: <ASCII-local@example.com>
Downgraded-Mail-From: =?UTF-8?Q?<NON-ASCII-local@example.com_?=
=?UTF-8?Q?<ASCII-local@example.com>>?=
Downgraded-Rcpt-To: =?UTF-8?Q?<NON-ASCII-remote1@example.net_?=
=?UTF-8?Q?<ASCII-remote1@example.net>>?=
Message-Id: MESSAGE_ID
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Subject: =?UTF-8?Q?NON-ASCII-SUBJECT?=
Downgraded-From: =?UTF-8?Q?DISPLAY-local_<NON-ASCII-local@example.com_?=
=?UTF-8?Q?<ASCII-local@example.com>>?=
Downgraded-To: =?UTF-8?Q?DISPLAY-remote1?_?=
=?UTF-8?Q?<NON-ASCII-remote1@example.net_<ASCII-remote1@example.net>>?=
Downgraded-Cc: =?UTF-8?Q?DISPLAY-remote2_?=
=?UTF-8?Q?<NON-ASCII-remote2@example.org>?=
Date: DATE
MAIL_BODY
]]>
</artwork>
</figure>
</t>
<t>
Perform Step 5 and 6.
</t>
<t>
<figure title="Decoded message" anchor="displaytechnique2">
<artwork>
<![CDATA[
Return-Path: <ASCII-local@example.com>
Downgraded-Mail-From: <NON-ASCII-local@example.com
<ASCII-local@example.com>>
Downgraded-Rcpt-To: <NON-ASCII-remote1@example.net>
<ASCII-remote1@example.net>
Message-Id: MESSAGE_ID
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Subject: NON-ASCII-SUBJECT
From: DISPLAY-local <NON-ASCII-local@example.com
<ASCII-local@example.com>>
To: DISPLAY-remote1 <NON-ASCII-remote1@example.net
<ASCII-remote1@example.net>>
Cc: DISPLAY-remote2 <NON-ASCII-remote2@example.org>
Date: DATE
MAIL_BODY
]]>
</artwork>
</figure>
</t>
<t>
As a result, in this simple example, all original header fields are displayed in the original form.
Differences between <xref target="example-originaleaismtpsession" /> and <xref target="displaytechnique2" /> are Return-Path, Downgraded-Mail-From, Downgraded-Rcpt-To header fields only.
</t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:08:27 |