draft-ietf-eai-frmwrk-4952bis-05.txt   draft-ietf-eai-frmwrk-4952bis-06.txt 
Email Address Internationalization J. Klensin Email Address Internationalization J. Klensin
(EAI) (EAI)
Internet-Draft Y. Ko Internet-Draft Y. Ko
Obsoletes: RFCs 4952, 5504, 5825 ICU Obsoletes: RFCs 4952, 5504, 5825 ICU
(if approved) August 22, 2010 (if approved) August 23, 2010
Intended status: Informational Intended status: Informational
Expires: February 23, 2011 Expires: February 24, 2011
Overview and Framework for Internationalized Email Overview and Framework for Internationalized Email
draft-ietf-eai-frmwrk-4952bis-05 draft-ietf-eai-frmwrk-4952bis-06
Abstract Abstract
Full use of electronic mail throughout the world requires that Full use of electronic mail throughout the world requires that
(subject to other constraints) people be able to use close variations (subject to other constraints) people be able to use close variations
on their own names (written correctly in their own languages and on their own names (written correctly in their own languages and
scripts) as mailbox names in email addresses. This document scripts) as mailbox names in email addresses. This document
introduces a series of specifications that define mechanisms and introduces a series of specifications that define mechanisms and
protocol extensions needed to fully support internationalized email protocol extensions needed to fully support internationalized email
addresses. These changes include an SMTP extension and extension of addresses. These changes include an SMTP extension and extension of
skipping to change at page 1, line 44 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on February 23, 2011. This Internet-Draft will expire on February 24, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 34 skipping to change at page 3, line 34
7.3. SMTP Service Extension for DSNs . . . . . . . . . . . . . 12 7.3. SMTP Service Extension for DSNs . . . . . . . . . . . . . 12
8. Downgrading before and after SMTP Transactions . . . . . . . . 12 8. Downgrading before and after SMTP Transactions . . . . . . . . 12
8.1. Downgrading before or during Message Submission . . . . . 13 8.1. Downgrading before or during Message Submission . . . . . 13
8.2. Downgrading or Other Processing After Final SMTP 8.2. Downgrading or Other Processing After Final SMTP
Delivery . . . . . . . . . . . . . . . . . . . . . . . . . 14 Delivery . . . . . . . . . . . . . . . . . . . . . . . . . 14
9. Downgrading in Transit . . . . . . . . . . . . . . . . . . . . 14 9. Downgrading in Transit . . . . . . . . . . . . . . . . . . . . 14
10. User Interface and Configuration Issues . . . . . . . . . . . 15 10. User Interface and Configuration Issues . . . . . . . . . . . 15
10.1. Choices of Mailbox Names and Unicode Normalization . . . . 15 10.1. Choices of Mailbox Names and Unicode Normalization . . . . 15
11. Additional Issues . . . . . . . . . . . . . . . . . . . . . . 16 11. Additional Issues . . . . . . . . . . . . . . . . . . . . . . 16
11.1. Impact on URIs and IRIs . . . . . . . . . . . . . . . . . 16 11.1. Impact on URIs and IRIs . . . . . . . . . . . . . . . . . 16
11.2. Use of Email Addresses as Identifiers . . . . . . . . . . 16 11.2. Use of Email Addresses as Identifiers . . . . . . . . . . 17
11.3. Encoded Words, Signed Messages, and Downgrading . . . . . 17 11.3. Encoded Words, Signed Messages, and Downgrading . . . . . 17
11.4. LMTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 11.4. LMTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
11.5. Other Uses of Local Parts . . . . . . . . . . . . . . . . 18 11.5. Other Uses of Local Parts . . . . . . . . . . . . . . . . 18
11.6. Non-Standard Encapsulation Formats . . . . . . . . . . . . 18 11.6. Non-Standard Encapsulation Formats . . . . . . . . . . . . 18
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
13. Security Considerations . . . . . . . . . . . . . . . . . . . 18 13. Security Considerations . . . . . . . . . . . . . . . . . . . 18
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
15.1. Normative References . . . . . . . . . . . . . . . . . . . 20 15.1. Normative References . . . . . . . . . . . . . . . . . . . 20
15.2. Informative References . . . . . . . . . . . . . . . . . . 22 15.2. Informative References . . . . . . . . . . . . . . . . . . 22
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 26 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 26
A.1. Changes between -00 and -01 . . . . . . . . . . . . . . . 26 A.1. Changes between -00 and -01 . . . . . . . . . . . . . . . 26
A.2. Changes between -01 and -02 . . . . . . . . . . . . . . . 26 A.2. Changes between -01 and -02 . . . . . . . . . . . . . . . 26
A.3. Changes between -02 and -03 . . . . . . . . . . . . . . . 27 A.3. Changes between -02 and -03 . . . . . . . . . . . . . . . 27
A.4. Changes between -03 and -04 . . . . . . . . . . . . . . . 28 A.4. Changes between -03 and -04 . . . . . . . . . . . . . . . 28
A.5. Changes between -04 and -05 . . . . . . . . . . . . . . . 28 A.5. Changes between -04 and -05 . . . . . . . . . . . . . . . 28
A.6. Changes between -05 and -06 . . . . . . . . . . . . . . . 28
1. Introduction 1. Introduction
Note in Draft and to RFC Editor: The keyword represented in this Note in Draft and to RFC Editor: The keyword represented in this
document by "UTF8SMTPbis" (and in the XML source by &EAISMTPkeyword;) document by "UTF8SMTPbis" (and in the XML source by &EAISMTPkeyword;)
is a placeholder. The actual keyword will be assigned when the is a placeholder. The actual keyword will be assigned when the
standards track SMTP extension in this series [RFC5336bis-SMTP] is standards track SMTP extension in this series [RFC5336bis-SMTP] is
approved for publication and should be substituted here. This approved for publication and should be substituted here. This
paragraph should be treated as normative reference to that SMTP paragraph should be treated as normative reference to that SMTP
extension draft, creating a reference hold until it is approved by extension draft, creating a reference hold until it is approved by
skipping to change at page 4, line 42 skipping to change at page 4, line 42
coded into the display name is invisible in the message envelope and, coded into the display name is invisible in the message envelope and,
for many purposes, is not part of the address at all. for many purposes, is not part of the address at all.
This document is an update of RFC 4952 [RFC4952]; it reflects This document is an update of RFC 4952 [RFC4952]; it reflects
additional issues, shared terminology, and some architectural changes additional issues, shared terminology, and some architectural changes
identified since that document was published. identified since that document was published.
The pronouns "he" and "she" are used interchangeably to indicate a The pronouns "he" and "she" are used interchangeably to indicate a
human of indeterminate gender. human of indeterminate gender.
The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
and "MAY" in this document are to be interpreted as described in RFC "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
2119 [RFC2119]. document are to be interpreted as described in BCP 14, RFC 2119
[RFC2119]. Although this document is Informational, those
requirements are consistent with requirements specified in the
Standards Track documents in this set as described in Section 5.
2. Role of This Specification 2. Role of This Specification
This document presents the overview and framework for an approach to This document presents the overview and framework for an approach to
the next stage of email internationalization. This new stage the next stage of email internationalization. This new stage
requires not only internationalization of addresses and header requires not only internationalization of addresses and header
fields, but also associated transport and delivery models. A prior fields, but also associated transport and delivery models. A prior
version of this specification, RFC 4952 [RFC4952], also provided an version of this specification, RFC 4952 [RFC4952], also provided an
introduction to a series of experimental protocols [RFC5335] introduction to a series of experimental protocols [RFC5335]
[RFC5336] [RFC5337] [RFC5504] [RFC5721] [RFC5738] [RFC5825]. This [RFC5336] [RFC5337] [RFC5504] [RFC5721] [RFC5738] [RFC5825]. This
skipping to change at page 7, line 14 skipping to change at page 7, line 17
message delivery programs or agents, and mechanisms for retrieving message delivery programs or agents, and mechanisms for retrieving
messages are all "behind" the final delivery MTA and hence are not messages are all "behind" the final delivery MTA and hence are not
part of the SMTP transport or delivery process. part of the SMTP transport or delivery process.
4.2. Address Character Sets 4.2. Address Character Sets
In this document, an address is "all-ASCII", or just an "ASCII In this document, an address is "all-ASCII", or just an "ASCII
address", if every character in the address is in the ASCII character address", if every character in the address is in the ASCII character
repertoire [ASCII]; an address is "non-ASCII", or an "i18n-address", repertoire [ASCII]; an address is "non-ASCII", or an "i18n-address",
if any character is not in the ASCII character repertoire. Such if any character is not in the ASCII character repertoire. Such
addresses may be restricted in other ways, but those restrictions are addresses MAY be restricted in other ways, but those restrictions are
not relevant to this definition. The term "all-ASCII" is also not relevant to this definition. The term "all-ASCII" is also
applied to other protocol elements when the distinction is important, applied to other protocol elements when the distinction is important,
with "non-ASCII" or "internationalized" as its opposite. with "non-ASCII" or "internationalized" as its opposite.
The umbrella term to describe the email address internationalization The umbrella term to describe the email address internationalization
specified by this document and its companion documents is specified by this document and its companion documents is
"UTF8SMTPbis". "UTF8SMTPbis".
[[anchor3: Note in Draft: Keyword to be changed before publication.]] [[anchor3: Note in Draft: Keyword to be changed before publication.]]
For example, an address permitted by this specification is referred For example, an address permitted by this specification is referred
to as a "UTF8SMTPbis (compliant) address". to as a "UTF8SMTPbis (compliant) address".
skipping to change at page 9, line 5 skipping to change at page 9, line 8
occurs when an SMTP server returns a reply code indicating a fatal occurs when an SMTP server returns a reply code indicating a fatal
error (a "5yz" code) or persistently returns a temporary failure error (a "5yz" code) or persistently returns a temporary failure
error (a "4yz" code). The other involves accepting the message error (a "4yz" code). The other involves accepting the message
during SMTP processing and then generating a message to the sender, during SMTP processing and then generating a message to the sender,
typically known as a "Non-delivery Notification" or "NDN". Current typically known as a "Non-delivery Notification" or "NDN". Current
practice often favors rejection over NDNs because of the reduced practice often favors rejection over NDNs because of the reduced
likelihood that the generation of NDNs will be used as a spamming likelihood that the generation of NDNs will be used as a spamming
technique. The latter, NDN, case is unavoidable if an intermediate technique. The latter, NDN, case is unavoidable if an intermediate
MTA accepts a message that is then rejected by the next-hop server. MTA accepts a message that is then rejected by the next-hop server.
A sender may also explicitly request message receipts [RFC3461] that A sender MAY also explicitly request message receipts [RFC3461] that
raise the same issues for these internationalization extensions as raise the same issues for these internationalization extensions as
NDNs. NDNs.
5. Overview of the Approach and Document Plan 5. Overview of the Approach and Document Plan
This set of specifications changes both SMTP and the character This set of specifications changes both SMTP and the character
encoding of email message headers to permit non-ASCII characters to encoding of email message headers to permit non-ASCII characters to
be represented directly. Each important component of the work is be represented directly. Each important component of the work is
described in a separate document. The document set, whose members described in a separate document. The document set, whose members
are described below, also contains informational documents whose are described below, also contains informational documents whose
skipping to change at page 10, line 47 skipping to change at page 11, line 5
this work. this work.
1. Email addresses enter subsystems (such as a user interface) that 1. Email addresses enter subsystems (such as a user interface) that
may perform charset conversions or other encoding changes. When may perform charset conversions or other encoding changes. When
the left hand side of the address includes characters outside the the left hand side of the address includes characters outside the
US-ASCII character repertoire, use of ASCII-compatible encoding US-ASCII character repertoire, use of ASCII-compatible encoding
(ACE) [RFC3492] [RFC5890] on the right hand side is discouraged (ACE) [RFC3492] [RFC5890] on the right hand side is discouraged
to promote consistent processing of characters throughout the to promote consistent processing of characters throughout the
address. address.
2. An SMTP relay must 2. An SMTP relay MUST
* Either recognize the format explicitly, agreeing to do so via * Either recognize the format explicitly, agreeing to do so via
an ESMTP option, or an ESMTP option, or
* Reject the message or, if necessary, return a non-delivery * Reject the message or, if necessary, return a non-delivery
notification message, so that the sender can make another notification message, so that the sender can make another
plan. plan.
3. If the message cannot be forwarded because the next-hop system 3. If the message cannot be forwarded because the next-hop system
cannot accept the extension it MUST be rejected or a non-delivery cannot accept the extension it MUST be rejected or a non-delivery
skipping to change at page 11, line 46 skipping to change at page 11, line 51
the user will inevitably, if only occasionally, see them rather than the user will inevitably, if only occasionally, see them rather than
"native" characters and will find that discomfiting or astonishing. "native" characters and will find that discomfiting or astonishing.
Similarly, if different codings are used for mail transport and Similarly, if different codings are used for mail transport and
message bodies, the user is particularly likely to be surprised, if message bodies, the user is particularly likely to be surprised, if
only as a consequence of the long-established "things leak" only as a consequence of the long-established "things leak"
principle. The only practical way to avoid these sources of principle. The only practical way to avoid these sources of
discomfort, in both the medium and the longer term, is to have the discomfort, in both the medium and the longer term, is to have the
encodings used in transport be as similar to the encodings used in encodings used in transport be as similar to the encodings used in
message headers and message bodies as possible. message headers and message bodies as possible.
When email local parts are internationalized, they should be When email local parts are internationalized, they SHOULD be
accompanied by arrangements for the message headers to be in the accompanied by arrangements for the message headers to be in the
fully internationalized form. That form should presumably use UTF-8 fully internationalized form. That form SHOULD presumably use UTF-8
rather than ASCII as the base character set for the contents of rather than ASCII as the base character set for the contents of
header fields (protocol elements such as the header field names header fields (protocol elements such as the header field names
themselves are unchanged and remain entirely in ASCII). For themselves are unchanged and remain entirely in ASCII). For
transition purposes and compatibility with legacy systems, this can transition purposes and compatibility with legacy systems, this can
done by extending the traditional MIME encoding models for non-ASCII done by extending the traditional MIME encoding models for non-ASCII
characters in headers [RFC2045] [RFC2231]. However, the target is characters in headers [RFC2045] [RFC2231]. However, the target is
fully internationalized message headers, as discussed in fully internationalized message headers, as discussed in
[RFC5335bis-Hdrs] and not an extended and painful transition. [RFC5335bis-Hdrs] and not an extended and painful transition.
7.3. SMTP Service Extension for DSNs 7.3. SMTP Service Extension for DSNs
skipping to change at page 12, line 30 skipping to change at page 12, line 35
[RFC3461]. [RFC3461].
8. Downgrading before and after SMTP Transactions 8. Downgrading before and after SMTP Transactions
An important issue with these extensions is how to handle An important issue with these extensions is how to handle
interactions between systems that support non-ASCII addresses and interactions between systems that support non-ASCII addresses and
legacy systems that expect ASCII. There is, of course, no problem legacy systems that expect ASCII. There is, of course, no problem
with ASCII-only systems sending to those that can handle with ASCII-only systems sending to those that can handle
internationalized forms because the ASCII forms are just a proper internationalized forms because the ASCII forms are just a proper
subset. But, when systems that support these extensions send mail, subset. But, when systems that support these extensions send mail,
they may include non-ASCII addresses for senders, receivers, or both they MAY include non-ASCII addresses for senders, receivers, or both
and might also provide non-ASCII header information other than and might also provide non-ASCII header information other than
addresses. If the extension is not supported by the first-hop system addresses. If the extension is not supported by the first-hop system
(SMTP server accessed by the Submission server acting as an SMTP (SMTP server accessed by the Submission server acting as an SMTP
client), message originating systems should be prepared to either client), message originating systems SHOULD be prepared to either
send conventional envelopes and message headers or to return the send conventional envelopes and message headers or to return the
message to the originating user so the message may be manually message to the originating user so the message may be manually
downgraded to the traditional form, possibly using encoded words downgraded to the traditional form, possibly using encoded words
[RFC2047] in the message headers. Of course, such transformations [RFC2047] in the message headers. Of course, such transformations
imply that the originating user or system must have ASCII-only imply that the originating user or system must have ASCII-only
addresses available for all senders and recipients. Mechanisms by addresses available for all senders and recipients. Mechanisms by
which such addresses may be found or identified are outside the scope which such addresses may be found or identified are outside the scope
of these specifications as are decisions about the design of of these specifications as are decisions about the design of
originating systems such as whether any required transformations are originating systems such as whether any required transformations are
made by the user, the originating MUA, or the Submission server. made by the user, the originating MUA, or the Submission server.
A somewhat more complex situation arises when the first-hop system A somewhat more complex situation arises when the first-hop system
supports these extensions but some subsequent server in the SMTP supports these extensions but some subsequent server in the SMTP
transmission chain does not. It is important to note that most cases transmission chain does not. It is important to note that most cases
of that situation with forward-pointing addresses will be the result of that situation with forward-pointing addresses will be the result
of configuration errors: especially if it hosts non-ASCII addresses, of configuration errors: especially if it hosts non-ASCII addresses,
a final delivery MTA that accepts these extensions should not be a final delivery MTA that accepts these extensions SHOULD NOT be
configured with lower-preference MX hosts that do not. When the only configured with lower-preference MX hosts that do not. When the only
non-ASCII address being transmitted is backward-pointing (e.g., in an non-ASCII address being transmitted is backward-pointing (e.g., in an
SMTP MAIL command), recipient configuration can not help in general. SMTP MAIL command), recipient configuration can not help in general.
On the other hand, alternate, all-ASCII, addresses for senders are On the other hand, alternate, all-ASCII, addresses for senders are
those most likely to be authoritatively known by the submission those most likely to be authoritatively known by the submission
environment or the sender herself. Consequently, if an intermediate environment or the sender herself. Consequently, if an intermediate
SMTP relay that requires these extensions then discovers that the SMTP relay that requires these extensions then discovers that the
next system in the chain does not support them, it will have little next system in the chain does not support them, it will have little
choice other than to reject or return the message. choice other than to reject or return the message.
skipping to change at page 15, line 46 skipping to change at page 16, line 4
constrained to using only those addresses permitted by RFC 5321. The constrained to using only those addresses permitted by RFC 5321. The
local parts of those addresses MAY be made up of any ASCII characters local parts of those addresses MAY be made up of any ASCII characters
except the control characters that 5321 prohibits, although some of except the control characters that 5321 prohibits, although some of
them MUST be quoted as specified there. It is notable in an them MUST be quoted as specified there. It is notable in an
internationalization context that there is a long history on some internationalization context that there is a long history on some
systems of using overstruck ASCII characters (a character, a systems of using overstruck ASCII characters (a character, a
backspace, and another character) within a quoted string to backspace, and another character) within a quoted string to
approximate non-ASCII characters. This form of internationalization approximate non-ASCII characters. This form of internationalization
was permitted by RFC 821 [RFC0821] but is prohibited by RFC 5321 was permitted by RFC 821 [RFC0821] but is prohibited by RFC 5321
because it requires a backspace character (a prohibited C0 control). because it requires a backspace character (a prohibited C0 control).
The practice SHOULD be phased out as this extension becomes widely The practice SHOULD be phased out as this extension becomes widely
deployed but backward-compatibility considerations may require that deployed but backward-compatibility considerations may require that
it continue to be recognized. it continue to be recognized.
For the particular case of EAI mailbox names, special attention must For the particular case of EAI mailbox names, special attention MUST
be paid to Unicode normalization [Unicode-UAX15], in part because be paid to Unicode normalization [Unicode-UAX15], in part because
Unicode strings may be normalized by other processes independent of Unicode strings may be normalized by other processes independent of
what a mail protocol specifies (this is exactly analogous to what may what a mail protocol specifies (this is exactly analogous to what may
happen with quoting and dequoting in traditional addresses). happen with quoting and dequoting in traditional addresses).
Consequently, the following principles are offered as advice to those Consequently, the following principles are offered as advice to those
who are selecting names for mailboxes: who are selecting names for mailboxes:
o In general, it is wise to support addresses in Normalized form, o In general, it is wise to support addresses in Normalized form,
using either Normalization Form NFC and, except in unusual using either Normalization Form NFC and, except in unusual
circumstances, NFKC. circumstances, NFKC.
skipping to change at page 17, line 41 skipping to change at page 17, line 47
may contain, when decrypted, header fields that use the RFC 2047 may contain, when decrypted, header fields that use the RFC 2047
encoding; such messages cannot be 'fully' upgraded without access to encoding; such messages cannot be 'fully' upgraded without access to
cryptographic keys. cryptographic keys.
Similar issues may arise if messages are signed and then subsequently Similar issues may arise if messages are signed and then subsequently
downgraded, e.g., as discussed in Section 8.1, and then an attempt is downgraded, e.g., as discussed in Section 8.1, and then an attempt is
made to upgrade them to the original form and then verify the made to upgrade them to the original form and then verify the
signatures. Even the very subtle changes that may result from signatures. Even the very subtle changes that may result from
algorithms to downgrade and then upgrade again may be sufficient to algorithms to downgrade and then upgrade again may be sufficient to
invalidate the signatures if they impact either the primary or MIME invalidate the signatures if they impact either the primary or MIME
bodypart headers. When signatures are present, downgrading must be bodypart headers. When signatures are present, downgrading MUST be
performed with extreme care if at all. performed with extreme care if at all.
11.4. LMTP 11.4. LMTP
LMTP [RFC2033] may be used as part of the final delivery agent. In LMTP [RFC2033] may be used as part of the final delivery agent. In
such cases, LMTP may be arranged to deliver the mail to the mail such cases, LMTP may be arranged to deliver the mail to the mail
store. The mail store may not have UTF8SMTPbis capability. LMTP may store. The mail store may not have UTF8SMTPbis capability. LMTP may
need to be updated to deal with these situations. need to be updated to deal with these situations.
11.5. Other Uses of Local Parts 11.5. Other Uses of Local Parts
skipping to change at page 19, line 42 skipping to change at page 19, line 49
user ameliorates the potential problem somewhat as compared to what user ameliorates the potential problem somewhat as compared to what
it would be if the relationships were changed in transit. it would be if the relationships were changed in transit.
The new UTF-8 header and message formats might also raise, or The new UTF-8 header and message formats might also raise, or
aggravate, another known issue. If the model creates new forms of an aggravate, another known issue. If the model creates new forms of an
'invalid' or 'malformed' message, then a new email attack is created: 'invalid' or 'malformed' message, then a new email attack is created:
in an effort to be robust, some or most agents will accept such in an effort to be robust, some or most agents will accept such
message and interpret them as if they were well-formed. If a filter message and interpret them as if they were well-formed. If a filter
interprets such a message differently than the MUA used by the interprets such a message differently than the MUA used by the
recipient, then it may be possible to create a message that appears recipient, then it may be possible to create a message that appears
acceptable under the filter's interpretation but should be rejected acceptable under the filter's interpretation but that should be
under the interpretation given to it by that MUA. Such attacks rejected under the interpretation given to it by that MUA. Such
already exist for existing messages and encoding layers, e.g., attacks already exist for existing messages and encoding layers,
invalid MIME syntax, invalid HTML markup, and invalid coding of e.g., invalid MIME syntax, invalid HTML markup, and invalid coding of
particular image types. particular image types.
In addition, email addresses are used in many contexts other than In addition, email addresses are used in many contexts other than
sending mail, such as for identifiers under various circumstances sending mail, such as for identifiers under various circumstances
(see Section 11.2). Each of those contexts will need to be (see Section 11.2). Each of those contexts will need to be
evaluated, in turn, to determine whether the use of non-ASCII forms evaluated, in turn, to determine whether the use of non-ASCII forms
is appropriate and what particular issues they raise. is appropriate and what particular issues they raise.
This work will clearly affect any systems or mechanisms that are This work will clearly affect any systems or mechanisms that are
dependent on digital signatures or similar integrity protection for dependent on digital signatures or similar integrity protection for
skipping to change at page 28, line 16 skipping to change at page 28, line 21
o Several minor editorial changes. o Several minor editorial changes.
o Added a discussion of the relationship to the base email, MIME, o Added a discussion of the relationship to the base email, MIME,
and IDNA specifications. and IDNA specifications.
A.5. Changes between -04 and -05 A.5. Changes between -04 and -05
o Several more minor editorial changes. o Several more minor editorial changes.
A.6. Changes between -05 and -06
o Corrections to more precisely reflect RFC 2119 language
requirements and closely-related issues..
Authors' Addresses Authors' Addresses
John C KLENSIN John C KLENSIN
1770 Massachusetts Ave, #322 1770 Massachusetts Ave, #322
Cambridge, MA 02140 Cambridge, MA 02140
USA USA
Phone: +1 617 491 5735 Phone: +1 617 491 5735
EMail: john-ietf@jck.com EMail: john-ietf@jck.com
 End of changes. 21 change blocks. 
23 lines changed or deleted 33 lines changed or added

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