7Internet Engineering Task Force (IETF) J. Klensin
8Request for Comments: 6530 Y. Ko
9Obsoletes: 4952, 5504, 5825 February 2012
10Category: Standards Track
14 Overview and Framework for Internationalized Email
18 Full use of electronic mail throughout the world requires that
19 (subject to other constraints) people be able to use close variations
20 on their own names (written correctly in their own languages and
21 scripts) as mailbox names in email addresses. This document
22 introduces a series of specifications that define mechanisms and
23 protocol extensions needed to fully support internationalized email
24 addresses. These changes include an SMTP extension and extension of
25 email header syntax to accommodate UTF-8 data. The document set also
26 includes discussion of key assumptions and issues in deploying fully
27 internationalized email. This document is a replacement for RFC
28 4952; it reflects additional issues identified since that document
33 This is an Internet Standards Track document.
35 This document is a product of the Internet Engineering Task Force
36 (IETF). It represents the consensus of the IETF community. It has
37 received public review and has been approved for publication by the
38 Internet Engineering Steering Group (IESG). Further information on
39 Internet Standards is available in Section 2 of RFC 5741.
41 Information about the current status of this document, any errata,
42 and how to provide feedback on it may be obtained at
43 http://www.rfc-editor.org/info/rfc6530.
47 Copyright (c) 2012 IETF Trust and the persons identified as the
48 document authors. All rights reserved.
50 This document is subject to BCP 78 and the IETF Trust's Legal
51 Provisions Relating to IETF Documents
52 (http://trustee.ietf.org/license-info) in effect on the date of
53 publication of this document. Please review these documents
54 carefully, as they describe your rights and restrictions with respect
58Klensin & Ko Standards Track [Page 1]
60RFC 6530 Internationalized Email Framework February 2012
63 to this document. Code Components extracted from this document must
64 include Simplified BSD License text as described in Section 4.e of
65 the Trust Legal Provisions and are provided without warranty as
66 described in the Simplified BSD License.
68 This document may contain material from IETF Documents or IETF
69 Contributions published or made publicly available before November
70 10, 2008. The person(s) controlling the copyright in some of this
71 material may not have granted the IETF Trust the right to allow
72 modifications of such material outside the IETF Standards Process.
73 Without obtaining an adequate license from the person(s) controlling
74 the copyright in such materials, this document may not be modified
75 outside the IETF Standards Process, and derivative works of it may
76 not be created outside the IETF Standards Process, except to format
77 it for publication as an RFC or to translate it into languages other
114Klensin & Ko Standards Track [Page 2]
116RFC 6530 Internationalized Email Framework February 2012
121 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
122 2. Role of This Specification . . . . . . . . . . . . . . . . . . 4
123 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5
124 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
125 4.1. Mail User and Mail Transfer Agents . . . . . . . . . . . . 6
126 4.2. Address Character Sets . . . . . . . . . . . . . . . . . . 7
127 4.3. User Types . . . . . . . . . . . . . . . . . . . . . . . . 7
128 4.4. Messages . . . . . . . . . . . . . . . . . . . . . . . . . 8
129 4.5. Mailing Lists . . . . . . . . . . . . . . . . . . . . . . 8
130 4.6. Conventional Message and Internationalized Message . . . . 8
131 4.7. Undeliverable Messages, Notification, and Delivery
132 Receipts . . . . . . . . . . . . . . . . . . . . . . . . . 8
133 5. Overview of the Approach and Document Plan . . . . . . . . . . 9
134 6. Review of Experimental Results . . . . . . . . . . . . . . . . 9
135 7. Overview of Protocol Extensions and Changes . . . . . . . . . 10
136 7.1. SMTP Extension for Internationalized Email Address . . . . 10
137 7.2. Transmission of Email Header Fields in UTF-8 Encoding . . 11
138 7.3. SMTP Service Extension for DSNs . . . . . . . . . . . . . 12
139 8. Downgrading before and after SMTP Transactions . . . . . . . . 12
140 8.1. Downgrading before or during Message Submission . . . . . 13
141 8.2. Downgrading or Other Processing after Final SMTP
142 Delivery . . . . . . . . . . . . . . . . . . . . . . . . . 14
143 9. Downgrading in Transit . . . . . . . . . . . . . . . . . . . . 15
144 10. User Interface and Configuration Issues . . . . . . . . . . . 15
145 10.1. Choices of Mailbox Names and Unicode Normalization . . . . 15
146 11. Additional Issues . . . . . . . . . . . . . . . . . . . . . . 17
147 11.1. Impact on URIs and IRIs . . . . . . . . . . . . . . . . . 17
148 11.2. Use of Email Addresses as Identifiers . . . . . . . . . . 17
149 11.3. Encoded Words, Signed Messages, and Downgrading . . . . . 18
150 11.4. Other Uses of Local Parts . . . . . . . . . . . . . . . . 18
151 11.5. Non-Standard Encapsulation Formats . . . . . . . . . . . . 19
152 12. Key Changes from the Experimental Protocols and Framework . . 19
153 13. Security Considerations . . . . . . . . . . . . . . . . . . . 19
154 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
155 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
156 15.1. Normative References . . . . . . . . . . . . . . . . . . . 21
157 15.2. Informative References . . . . . . . . . . . . . . . . . . 22
170Klensin & Ko Standards Track [Page 3]
172RFC 6530 Internationalized Email Framework February 2012
177 In order to use internationalized email addresses, it is necessary to
178 internationalize both the domain part and the local part of email
179 addresses. The domain part of email addresses is already
180 internationalized [RFC5890], while the local part is not. Without
181 the extensions specified in this document, the mailbox name is
182 restricted to a subset of 7-bit ASCII [RFC5321]. Though MIME
183 [RFC2045] enables the transport of non-ASCII data, it does not
184 provide a mechanism for internationalized email addresses. In RFC
185 2047 [RFC2047], MIME defines an encoding mechanism for some specific
186 message header fields to accommodate non-ASCII data. However, it
187 does not permit the use of email addresses that include non-ASCII
188 characters. Without the extensions defined here, or some equivalent
189 set, the only way to incorporate non-ASCII characters in any part of
190 email addresses is to use RFC 2047 coding to embed them in what RFC
191 5322 [RFC5322] calls the "display name" (known as a "name phrase" or
192 by other terms elsewhere) of the relevant header fields. Information
193 coded into the display name is invisible in the message envelope and,
194 for many purposes, is not part of the address at all.
196 This document is a replacement for RFC 4952 [RFC4952]; it reflects
197 additional issues, shared terminology, and some architectural changes
198 identified since that document was published. It obsoletes that
199 document. The experimental descriptions of in-transit downgrading
200 [RFC5504] [RFC5825] are now irrelevant and no longer needed due to
201 the changes discussed in Section 12. The RFC Editor is requested to
202 move all three of those documents to Historic.
204 The pronouns "he" and "she" are used interchangeably to indicate a
205 human of indeterminate gender.
207 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
208 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
209 document are to be interpreted as described in BCP 14, RFC 2119
2122. Role of This Specification
214 This document presents the overview and framework for an approach to
215 the next stage of email internationalization. This new stage
216 requires not only internationalization of addresses and header
217 fields, but also associated transport and delivery models. A prior
218 version of this specification, RFC 4952 [RFC4952], also provided an
219 introduction to a series of experimental protocols [RFC5335]
220 [RFC5336] [RFC5337] [RFC5504] [RFC5721] [RFC5738] [RFC5825]. This
221 revised form provides overview and conceptual information for the
222 Standards Track successors of a subset of those protocols. Details
226Klensin & Ko Standards Track [Page 4]
228RFC 6530 Internationalized Email Framework February 2012
231 of the documents and the relationships among them appear in Section 5
232 and a discussion of what was learned from the experimental protocols
233 and their implementations appears in Section 6.
235 Taken together, these specifications provide the details for a way to
236 implement and support internationalized email. The document itself
237 describes how the various elements of email internationalization fit
238 together and the relationships among the primary specifications
239 associated with message transport, header formats, and handling.
241 This document, and others that comprise the collection described
242 above, assume a reasonable familiarity with the basic Internet
243 electronic mail specifications and terminology [RFC5321] [RFC5322]
244 and the MIME [RFC2045] and 8BITMIME [RFC6152] ones as well. While
245 not strictly required to implement this specification, a general
246 familiarity with the terminology and functions of IDNA [RFC5890]
247 [RFC5891] [RFC5892] [RFC5893] [RFC5894] are also assumed.
251 Internationalizing Domain Names in Applications (IDNA) [RFC5890]
252 permits internationalized domain names, but deployment has not yet
253 reached most users. One of the reasons for this is that we do not
254 yet have fully internationalized naming schemes. Domain names are
255 just one of the various names and identifiers that are required to be
256 internationalized. In many contexts, until more of those identifiers
257 are internationalized, internationalized domain names alone have
260 Email addresses are prime examples of why it is not good enough to
261 just internationalize the domain name. As most observers have
262 learned from experience, users strongly prefer email addresses that
263 resemble names or initials to those involving seemingly meaningless
264 strings of letters or numbers. Unless the entire email address can
265 use familiar characters and formats, users will perceive email as
266 being culturally unfriendly. If the names and initials used in email
267 addresses can be expressed in the native languages and writing
268 systems of the users, the Internet will be perceived as more natural,
269 especially by those whose native language is not written in a subset
270 of a Roman-derived script.
272 Internationalization of email addresses is not merely a matter of
273 changing the SMTP envelope; or of modifying the "From:", "To:", and
274 "Cc:" header fields; or of permitting upgraded Mail User Agents
275 (MUAs) to decode a special coding and respond by displaying local
276 characters. To be perceived as usable, the addresses must be
277 internationalized and handled consistently in all of the contexts in
278 which they occur. This requirement has far-reaching implications:
282Klensin & Ko Standards Track [Page 5]
284RFC 6530 Internationalized Email Framework February 2012
287 collections of patches and workarounds are not adequate. Even if
288 they were adequate, a workaround-based approach may result in an
289 assortment of implementations with different sets of patches and
290 workarounds having been applied with consequent user confusion about
291 what is actually usable and supported. Instead, we need to build a
292 fully internationalized email environment, focusing on permitting
293 efficient communication among those who share a language and writing
294 system. That, in turn, implies changes to the mail header
295 environment to permit those header fields that are appropriately
296 internationalized to utilize the full range of Unicode characters, an
297 SMTP extension to permit UTF-8 [RFC3629] [RFC5198] mail addressing
298 and delivery of those extended header fields, support for
299 internationalization of delivery and service notifications [RFC3461]
300 [RFC3464], and (finally) a requirement for support of the 8BITMIME
301 SMTP extension [RFC6152] so that all of these can be transported
302 through the mail system without having to overcome the limitation
303 that header fields do not have content-transfer-encodings.
307 This document assumes a reasonable understanding of the protocols and
308 terminology of the core email standards as documented in RFC 5321
309 [RFC5321] and RFC 5322 [RFC5322].
3114.1. Mail User and Mail Transfer Agents
313 Much of the description in this document depends on the abstractions
314 of "Mail Transfer Agent" ("MTA") and "Mail User Agent" ("MUA").
315 However, it is important to understand that those terms and the
316 underlying concepts postdate the design of the Internet's email
317 architecture and the application of the "protocols on the wire"
318 principle to it. That email architecture, as it has evolved, and
319 that "on the wire" principle have prevented any strong and
320 standardized distinctions about how MTAs and MUAs interact on a given
321 origin or destination host (or even whether they are separate).
323 However, the term "final delivery MTA" is used in this document in a
324 fashion equivalent to the term "delivery system" or "final delivery
325 system" of RFC 5321. This is the SMTP server that controls the
326 format of the local parts of addresses and is permitted to inspect
327 and interpret them. It receives messages from the network for
328 delivery to mailboxes or for other local processing, including any
329 forwarding or aliasing that changes envelope addresses, rather than
330 relaying. From the perspective of the network, any local delivery
331 arrangements such as saving to a message store, handoff to specific
332 message delivery programs or agents, and mechanisms for retrieving
333 messages are all "behind" the final delivery MTA and hence are not
334 part of the SMTP transport or delivery process.
338Klensin & Ko Standards Track [Page 6]
340RFC 6530 Internationalized Email Framework February 2012
3434.2. Address Character Sets
345 In this document, an address is "all-ASCII", or just an "ASCII
346 address", if every character in the address is in the ASCII character
347 repertoire [ASCII]; an address is "non-ASCII", or an "i18n-address",
348 if any character is not in the ASCII character repertoire. Such
349 addresses MAY be restricted in other ways, but those restrictions are
350 not relevant to this definition. The term "all-ASCII" is also
351 applied to other protocol elements when the distinction is important,
352 with "non-ASCII" or "internationalized" as its opposite.
354 The umbrella term to describe the email address internationalization
355 specified by this document and its companion documents is "SMTPUTF8".
356 For example, an address permitted by this specification is referred
357 to as a "SMTPUTF8 (compliant) address".
359 Please note that, according to the definitions given here, the set of
360 all "all-ASCII" addresses and the set of all "non-ASCII" addresses
361 are mutually exclusive. The set of all addresses permitted when
362 SMTPUTF8 appears is the union of these two sets.
366 An "ASCII user" (i) exclusively uses email addresses that contain
367 ASCII characters only, and (ii) cannot generate recipient addresses
368 that contain non-ASCII characters.
370 An "internationalized email user" has one or more non-ASCII email
371 addresses, or is able to generate recipient addresses that contain
372 non-ASCII characters. Such a user may have ASCII addresses too; if
373 the user has more than one email account and a corresponding address,
374 or more than one alias for the same address, he or she has some
375 method to choose which address to use on outgoing email. Note that
376 under this definition, it is not possible to tell from an ASCII
377 address if the owner of that address is an internationalized email
378 user or not. (A non-ASCII address implies a belief that the owner of
379 that address is an internationalized email user.) There is no such
380 thing as an "internationalized email user message"; the term applies
381 only to users and their agents and capabilities. In particular, the
382 use of non-ASCII, and hence presumably internationalized, message
383 content is an integral part of the MIME specifications [RFC2045] and
384 does not require these extensions (although it is compatible with
394Klensin & Ko Standards Track [Page 7]
396RFC 6530 Internationalized Email Framework February 2012
401 A "message" is sent from one user (the sender) using a particular
402 email address to one or more other recipient email addresses (often
403 referred to just as "users" or "recipient users").
407 A "mailing list" is a mechanism whereby a message may be distributed
408 to multiple recipients by sending it to one recipient address. An
409 agent (typically not a human being) at that single address then
410 causes the message to be redistributed to the target recipients.
411 This agent sets the envelope return address of the redistributed
412 message to a different address from that of the original single
413 recipient message. Using a different envelope return address
414 (reverse-path) causes error (and other automatically generated)
415 messages to go to an error-handling address.
417 Special provisions for managing mailing lists that might contain non-
418 ASCII addresses are discussed in a document that is specific to that
419 topic [RFC5983] and its expected successor [RFC5983bis-MailingList].
4214.6. Conventional Message and Internationalized Message
423 o A conventional message is one that does not use any extension
424 defined in the SMTP extension document [RFC6531] or in the
425 UTF8header document [RFC6532] in this set of specifications, and
426 is strictly conformant to RFC 5322 [RFC5322].
428 o An internationalized message is a message utilizing one or more of
429 the extensions defined in this set of specifications, so that it
430 is no longer conformant to the traditional specification of an
431 email message or its transport.
4334.7. Undeliverable Messages, Notification, and Delivery Receipts
435 As specified in RFC 5321, a message that is undeliverable for some
436 reason is expected to result in notification to the sender. This can
437 occur in either of two ways. One, typically called "Rejection",
438 occurs when an SMTP server returns a reply code indicating a fatal
439 error (a "5yz" code) or persistently returns a temporary failure
440 error (a "4yz" code). The other involves accepting the message
441 during SMTP processing and then generating a message to the sender,
442 typically known as a "Non-delivery Notification" or "NDN". Current
443 practice often favors rejection over NDNs because of the reduced
444 likelihood that the generation of NDNs will be used as a spamming
445 technique. The latter, NDN, case is unavoidable if an intermediate
446 MTA accepts a message that is then rejected by the next-hop server.
450Klensin & Ko Standards Track [Page 8]
452RFC 6530 Internationalized Email Framework February 2012
455 A sender MAY also explicitly request message receipts [RFC3461] that
456 raise the same issues for these internationalization extensions as
4595. Overview of the Approach and Document Plan
461 This set of specifications changes both SMTP and the character
462 encoding of email message headers to permit non-ASCII characters to
463 be represented directly. Each important component of the work is
464 described in a separate document. The document set, whose members
465 are described below, also contains Informational documents whose
466 purpose is to provide implementation suggestions and guidance for the
469 In addition to this document, the following documents make up this
470 specification and provide advice and context for it.
472 o SMTP extension. The SMTP extension document [RFC6531] provides an
473 SMTP extension (as provided for in RFC 5321) for internationalized
476 o Email message headers in UTF-8. The email message header document
477 [RFC6532] essentially updates RFC 5322 to permit some information
478 in email message headers to be expressed directly by Unicode
479 characters encoded in UTF-8 when the SMTP extension described
480 above is used. This document, possibly with one or more
481 supplemental ones, will also need to address the interactions with
482 MIME, including relationships between SMTPUTF8 and internal MIME
483 headers and content types.
485 o Extensions to delivery status and notification handling to adapt
486 to internationalized addresses [RFC6533].
488 o Forthcoming documents will specify extensions to the IMAP protocol
489 [RFC3501] to support internationalized message headers
490 [RFC5738bis-IMAP], parallel extensions to the POP protocol
491 [RFC5721] [RFC5721bis-POP3], and some common properties of the two
4946. Review of Experimental Results
496 The key difference between this set of protocols and the experimental
497 set that preceded them [RFC5335] [RFC5336] [RFC5337] [RFC5504]
498 [RFC5721] [RFC5738] [RFC5825] is that the earlier group provided a
499 mechanism for in-transit downgrading of messages (described in detail
500 in RFC 5504). That mechanism permitted, and essentially required,
501 that each non-ASCII address be accompanied by an all-ASCII
502 equivalent. That, in turn, raised security concerns associated with
506Klensin & Ko Standards Track [Page 9]
508RFC 6530 Internationalized Email Framework February 2012
511 pairing of addresses that could not be authenticated. It also
512 introduced the first incompatible change to Internet mail addressing
513 in many years, raising concerns about interoperability issues if the
514 new address forms "leaked" into legacy email implementations. After
515 examining experience with the earlier, experimental, predecessors of
516 these specifications, the working group that produced them concluded
517 that the advantages of in-transit downgrading, were it feasible
518 operationally, would be significant enough to overcome those
521 That turned out not to be the case, with interoperability problems
522 among initial implementations. Prior to starting on the work that
523 led to this set of specifications, the WG concluded that the
524 combination of requirements and long-term implications of that
525 earlier model were too complex to be satisfactory and that work
526 should move ahead without it.
528 The other significant change to the protocols themselves is that the
529 SMTPUTF8 keyword is now required as an SMTP client announcement if
530 the extension is needed; in the experimental version, only the server
531 announcement that an extended envelope and/or content were permitted
5347. Overview of Protocol Extensions and Changes
5367.1. SMTP Extension for Internationalized Email Address
538 An SMTP extension, "SMTPUTF8", is specified as follows:
540 o Permits the use of UTF-8 strings in email addresses, both local
541 parts and domain names.
543 o Permits the selective use of UTF-8 strings in email message
544 headers (see Section 7.2).
546 o Requires that the server advertise the 8BITMIME extension
547 [RFC6152] and that the client support 8-bit transmission so that
548 header information can be transmitted without using a special
549 content-transfer-encoding.
551 Some general principles affect the development decisions underlying
554 1. Email addresses enter subsystems (such as a user interface) that
555 may perform charset conversions or other encoding changes. When
556 the local part of the address includes characters outside the
557 ASCII character repertoire, use of ASCII-compatible encoding
558 (ACE) [RFC3492] [RFC5890] in the domain part is discouraged to
562Klensin & Ko Standards Track [Page 10]
564RFC 6530 Internationalized Email Framework February 2012
567 promote consistent processing of characters throughout the
570 2. An SMTP relay MUST
572 * Either recognize the format explicitly, agreeing to do so via
575 * Reject the message or, if necessary, return a non-delivery
576 notification message, so that the sender can make another
579 3. If the message cannot be forwarded because the next-hop system
580 cannot accept the extension, it MUST be rejected or a non-
581 delivery message MUST be generated and sent.
583 4. In the interest of interoperability, charsets other than UTF-8
584 are prohibited in mail addresses and message headers being
585 transmitted over the Internet. There is no practical way to
586 identify multiple charsets properly with an extension similar to
587 this without introducing great complexity.
589 Conformance to the group of standards specified here for email
590 transport and delivery requires implementation of the SMTP extension
591 specification and the UTF-8 header specification. If the system
592 implements IMAP or POP, it MUST conform to the internationalized IMAP
593 [RFC5738bis-IMAP] or POP [RFC5721bis-POP3] specifications
5967.2. Transmission of Email Header Fields in UTF-8 Encoding
598 There are many places in MUAs or in a user presentation in which
599 email addresses or domain names appear. Examples include the
600 conventional "From:", "To:", or "Cc:" header fields; "Message-ID:"
601 and "In-Reply-To:" header fields that normally contain domain names
602 (but that may be a special case); and in message bodies. Each of
603 these must be examined from an internationalization perspective. The
604 user will expect to see mailbox and domain names in local characters,
605 and to see them consistently. If non-obvious encodings, such as
606 protocol-specific ACE variants, are used, the user will inevitably,
607 if only occasionally, see them rather than "native" characters and
608 will find that discomfiting or astonishing. Similarly, if different
609 codings are used for mail transport and message bodies, the user is
610 particularly likely to be surprised, if only as a consequence of the
611 long-established "things leak" principle. The only practical way to
612 avoid these sources of discomfort, in both the medium and the longer
613 term, is to have the encodings used in transport be as similar to the
614 encodings used in message headers and message bodies as possible.
618Klensin & Ko Standards Track [Page 11]
620RFC 6530 Internationalized Email Framework February 2012
623 When email local parts are internationalized, they SHOULD be
624 accompanied by arrangements for the message headers to be in the
625 fully internationalized form. That form SHOULD use UTF-8 rather than
626 ASCII as the base character set for the contents of header fields
627 (protocol elements such as the header field names themselves are
628 unchanged and remain entirely in ASCII). For transition purposes and
629 compatibility with legacy systems, this can be done by extending the
630 traditional MIME encoding models for non-ASCII characters in headers
631 [RFC2045] [RFC2231], but even these should be based on UTF-8, rather
632 than other encodings, if at all possible [RFC6055]. However, the
633 target is fully internationalized message headers, as discussed in
634 [RFC6532] and not an extended and painful transition.
6367.3. SMTP Service Extension for DSNs
638 The existing Delivery Status Notifications (DSNs) specification
639 [RFC3461], which is a Draft Standard, is limited to ASCII text in the
640 machine-readable portions of the protocol. "International Delivery
641 and Disposition Notifications" [RFC6533] adds a new address type for
642 international email addresses so an original recipient address with
643 non-ASCII characters can be correctly preserved even after
644 downgrading. If an SMTP server advertises both the SMTPUTF8 and the
645 DSN extension, that server MUST implement internationalized DSNs
646 including support for the ORCPT parameter specified in RFC 3461
6498. Downgrading before and after SMTP Transactions
651 An important issue with these extensions is how to handle
652 interactions between systems that support non-ASCII addresses and
653 legacy systems that expect ASCII. There is, of course, no problem
654 with ASCII-only systems sending to those that can handle
655 internationalized forms because the ASCII forms are just a proper
656 subset. But, when systems that support these extensions send mail,
657 they MAY include non-ASCII addresses for senders, receivers, or both
658 and might also provide non-ASCII header information other than
659 addresses. If the extension is not supported by the first-hop system
660 (i.e., the SMTP server accessed by the submission server acting as an
661 SMTP client), message-originating systems SHOULD be prepared to
662 either send conventional envelopes and message headers or to return
663 the message to the originating user so the message may be manually
664 downgraded to the traditional form, possibly using encoded words
665 [RFC2047] in the message headers. Of course, such transformations
666 imply that the originating user or system must have ASCII-only
667 addresses available for all senders and recipients. Mechanisms by
668 which such addresses may be found or identified are outside the scope
674Klensin & Ko Standards Track [Page 12]
676RFC 6530 Internationalized Email Framework February 2012
679 of these specifications as are decisions about the design of
680 originating systems such as whether any required transformations are
681 made by the user, the originating MUA, or the submission server.
683 A somewhat more complex situation arises when the first-hop system
684 supports these extensions but some subsequent server in the SMTP
685 transmission chain does not. It is important to note that most cases
686 of that situation with forward-pointing addresses will be the result
687 of configuration errors: especially if it hosts non-ASCII addresses,
688 a final delivery MTA that accepts these extensions SHOULD NOT be
689 configured with lower-preference MX hosts that do not. When the only
690 non-ASCII address being transmitted is backward-pointing (e.g., in an
691 SMTP MAIL command), recipient configuration cannot help in general.
692 On the other hand, alternate, all-ASCII addresses for senders are
693 those most likely to be authoritatively known by the submission
694 environment or the sender herself. Consequently, if an intermediate
695 SMTP relay that requires these extensions then discovers that the
696 next system in the chain does not support them, it will have little
697 choice other than to reject or return the message.
699 As discussed above, downgrading to an ASCII-only form may occur
700 before or during the initial message submission. It might also occur
701 after the delivery to the final delivery MTA in order to accommodate
702 message stores, IMAP or POP servers, or clients that have different
703 capabilities than the delivery MTA. These cases are discussed in the
7068.1. Downgrading before or during Message Submission
708 The IETF has traditionally avoided specifying the precise behavior of
709 MUAs to provide maximum flexibility in the associated user
710 interfaces. The SMTP standard [RFC5321], Section 6.4, gives wide
711 latitude to MUAs and submission servers as to what might be supplied
712 by the user as long as the result conforms with "on the wire"
713 standards once it is injected into the public Internet. In that
714 tradition, the discussion in the remainder of Section 8 is provided
715 as general guidance rather than normative requirements.
717 Messages that require these extensions will sometimes be transferred
718 to a system that does not support these extensions; it is likely that
719 the most common cases will involve the combination of ASCII-only
720 forward-pointing addresses with a non-ASCII backward-pointing one.
721 Until the extensions described here have been universally implemented
722 in the Internet email environment, senders who prefer to use non-
723 ASCII addresses (or raw UTF-8 characters in header fields), even when
724 their intended recipients use and expect all-ASCII ones, will need to
725 be especially careful about the error conditions that can arise. The
730Klensin & Ko Standards Track [Page 13]
732RFC 6530 Internationalized Email Framework February 2012
735 risks are especially great in environments in which non-delivery
736 messages (or other indications from submission servers) are routinely
739 Perhaps obviously, the most convenient time to find an ASCII address
740 corresponding to an internationalized address is at the originating
741 MUA or closely associated systems. This can occur either before the
742 message is sent or after the internationalized form of the message is
743 rejected. It is also the most convenient time to convert a message
744 from the internationalized form into conventional ASCII form or to
745 generate a non-delivery message to the sender if either is necessary.
746 At that point, the user has a full range of choices available,
747 including changing backward-pointing addresses, contacting the
748 intended recipient out of band for an alternate address, consulting
749 appropriate directories, arranging for translation of both addresses
750 and message content into a different language, and so on. While it
751 is natural to think of message downgrading as optimally being a fully
752 automated process, we should not underestimate the capabilities of a
753 user of at least moderate intelligence who wishes to communicate with
756 In this context, one can easily imagine modifications to message
757 submission servers (as described in RFC 6409 [RFC6409]) so that they
758 would perform downgrading operations or perhaps even upgrading ones.
759 Such operations would permit receiving messages with one or more of
760 the internationalization extensions discussed here and adapting the
761 outgoing message, as needed, to respond to the delivery or next-hop
762 environment the submission server encounters.
7648.2. Downgrading or Other Processing after Final SMTP Delivery
766 When an email message is received by a final delivery MTA, it is
767 usually stored in some form. Then it is retrieved either by software
768 that reads the stored form directly or by client software via some
769 email retrieval mechanisms such as POP or IMAP.
771 The SMTP extension described in Section 7.1 provides protection only
772 in transport. It does not prevent MUAs and email retrieval
773 mechanisms that have not been upgraded to understand
774 internationalized addresses and UTF-8 message headers from accessing
775 stored internationalized emails.
777 Since the final delivery MTA (or, to be more specific, its
778 corresponding mail storage agent) cannot safely assume that agents
779 accessing email storage will always be capable of handling the
780 extensions proposed here, it MAY downgrade internationalized emails,
781 specially identify messages that utilize these extensions, or both.
782 If either or both of these actions were to be taken, the final
786Klensin & Ko Standards Track [Page 14]
788RFC 6530 Internationalized Email Framework February 2012
791 delivery MTA SHOULD include a mechanism to preserve or recover the
792 original internationalized forms without information loss.
793 Preservation of that information is necessary to support access by
794 SMTPUTF8-aware agents.
7969. Downgrading in Transit
798 The base SMTP specification (Section 2.3.11 of RFC 5321 [RFC5321])
799 states that "due to a long history of problems when intermediate
800 hosts have attempted to optimize transport by modifying them, the
801 local-part MUST be interpreted and assigned semantics only by the
802 host specified in the domain part of the address". This is not a new
803 requirement; equivalent statements appeared in specifications in 2001
804 [RFC2821] and even in 1989 [RFC1123].
806 Adherence to this rule means that a downgrade mechanism that
807 transforms the local part of an email address cannot be utilized in
808 transit. It can only be applied at the endpoints, specifically by
809 the MUA or submission server or by the final delivery MTA.
811 One of the reasons for this rule has to do with legacy email systems
812 that embed mail routing information in the local part of the address
813 field. Transforming the email address destroys such routing
814 information. There is no way a server other than the final delivery
815 server can know, for example, whether the local part of
816 user%foo@example.com is a route ("user" is reached via "foo") or
817 simply a local address.
81910. User Interface and Configuration Issues
821 Internationalization of addresses and message headers, especially in
822 combination with variations on character coding that are inherent to
823 Unicode, may make careful choices of addresses and careful
824 configuration of servers and DNS records even more important than
825 they are for traditional Internet email. It is likely that, as
826 experience develops with the use of these protocols, it will be
827 desirable to produce one or more additional documents that offer
828 guidance for configuration and interfaces. A document that discusses
829 issues with MUAs, especially with regard to downgrading, is expected
830 to be developed. The subsections below address some other issues.
83210.1. Choices of Mailbox Names and Unicode Normalization
834 It has long been the case that the email syntax permits choices about
835 mailbox names that are unwise in practice, if one actually intends
836 the mailboxes to be accessible to a broad range of senders. The most
837 often cited examples involve the use of case-sensitivity and tricky
838 quoting of embedded characters in mailbox local parts. These
842Klensin & Ko Standards Track [Page 15]
844RFC 6530 Internationalized Email Framework February 2012
847 deliberately unusual constructions are permitted by the protocols,
848 and servers are expected to support them. Although they can provide
849 value in special cases, taking advantage of them is almost always bad
850 practice unless the intent is to create some form of security by
853 In the absence of these extensions, SMTP clients and servers are
854 constrained to using only those addresses permitted by RFC 5321. The
855 local parts of those addresses MAY be made up of any ASCII characters
856 except the control characters that RFC 5321 prohibits, although some
857 of them MUST be quoted as specified there. It is notable in an
858 internationalization context that there is a long history on some
859 systems of using overstruck ASCII characters (a character, a
860 backspace, and another character) within a quoted string to
861 approximate non-ASCII characters. This form of internationalization
862 was permitted by RFC 821 [RFC0821] but is prohibited by RFC 5321
863 because it requires a backspace character (a prohibited C0 control).
864 Because RFC 5321 (and its predecessor, RFC 2821) prohibit the use of
865 this character in ASCII mailbox names and it is even more problematic
866 (for canonicalization and normalization reasons) in non-ASCII
867 strings, backspace MUST NOT appear in SMTPUTF8 mailbox names.
869 For the particular case of mailbox names that contain non-ASCII
870 characters in the local part, domain part, or both, special attention
871 MUST be paid to Unicode normalization [Unicode-UAX15], in part
872 because Unicode strings may be normalized by other processes
873 independent of what a mail protocol specifies (this is exactly
874 analogous to what may happen with quoting and dequoting in
875 traditional addresses). Consequently, the following principles are
876 offered as advice to those who are selecting names for mailboxes:
878 o In general, it is wise to support addresses in Normalized form,
879 using at least Normalization Form NFC. Except in circumstances in
880 which NFKC would map characters together that the parties
881 responsible for the destination mail server would prefer to be
882 kept distinguishable, supporting the NFKC-conformant form would
883 yield even more predictable behavior for the typical user.
885 o It will usually be wise to support other forms of the same local-
886 part string, either as aliases or by normalization of strings
887 reaching the delivery server: the sender should not be depended
888 upon to send the strings in normalized form.
898Klensin & Ko Standards Track [Page 16]
900RFC 6530 Internationalized Email Framework February 2012
903 o Stated differently and in more specific terms, the rules of the
904 protocol for local-part strings essentially provide that:
906 * Unnormalized strings are valid, but sufficiently bad practice
907 that they may not work reliably on a global basis. Servers
908 should not depend on clients to send normalized forms but
909 should be aware that procedures on client machines outside the
910 control of the MUA may cause normalized strings to be sent
911 regardless of user intent.
913 * C0 (and presumably C1) controls (see The Unicode Standard
914 [Unicode]) are prohibited, the first in RFC 5321 and the second
915 by an obvious extension from it [RFC5198].
917 * Other kinds of punctuation, spaces, etc., are risky practice.
918 Perhaps they will work, and SMTP receiver code is required to
919 handle them without severe errors (even if such strings are not
920 accepted in addresses to be delivered on that server), but
921 creating dependencies on them in mailbox names that are chosen
922 is usually a bad practice and may lead to interoperability
927 This section identifies issues that are not covered, or not covered
928 comprehensively, as part of this set of specifications, but that will
929 require ongoing review as part of deployment of email address and
930 header internationalization.
93211.1. Impact on URIs and IRIs
934 The mailto: schema [RFC6068], and the discussion of it in the
935 Internationalized Resource Identifier (IRI) specification [RFC3987],
936 may need to be modified when this work is completed and standardized.
93811.2. Use of Email Addresses as Identifiers
940 There are a number of places in contemporary Internet usage in which
941 email addresses are used as identifiers for individuals, including as
942 identifiers to Web servers supporting some electronic commerce sites
943 and in some X.509 certificates [RFC5280]. These documents do not
944 address those uses, but it is reasonable to expect that some
945 difficulties will be encountered when internationalized addresses are
946 first used in those contexts, many of which cannot even handle the
947 full range of addresses permitted today.
954Klensin & Ko Standards Track [Page 17]
956RFC 6530 Internationalized Email Framework February 2012
95911.3. Encoded Words, Signed Messages, and Downgrading
961 One particular characteristic of the email format is its persistency:
962 MUAs are expected to handle messages that were originally sent
963 decades ago and not just those delivered seconds ago. As such, MUAs
964 and mail filtering software, such as that specified in Sieve
965 [RFC5228], will need to continue to accept and decode header fields
966 that use the "encoded word" mechanism [RFC2047] to accommodate non-
967 ASCII characters in some header fields. While extensions to both
968 POP3 [RFC1939] and IMAP [RFC3501] have been defined that include
969 automatic upgrading of messages that carry non-ASCII information in
970 encoded form -- including RFC 2047 decoding -- of messages by the
971 POP3 [RFC5721bis-POP3] or IMAP [RFC5738bis-IMAP] server, there are
972 message structures and MIME content-types for which that cannot be
973 done or where the change would have unacceptable side effects.
975 For example, message parts that are cryptographically signed, using
976 e.g., S/MIME [RFC5751] or Pretty Good Privacy (PGP) [RFC3156], cannot
977 be upgraded from the RFC 2047 form to normal UTF-8 characters without
978 breaking the signature. Similarly, message parts that are encrypted
979 may contain, when decrypted, header fields that use the RFC 2047
980 encoding; such messages cannot be 'fully' upgraded without access to
983 Similar issues may arise if messages are signed and then subsequently
984 downgraded, e.g., as discussed in Section 8.1, and then an attempt is
985 made to upgrade them to the original form and then verify the
986 signatures. Even the very subtle changes that may result from
987 algorithms to downgrade and then upgrade again may be sufficient to
988 invalidate the signatures if they impact either the primary or MIME
989 body part headers. When signatures are present, downgrading must be
990 performed with extreme care if at all.
99211.4. Other Uses of Local Parts
994 Local parts are sometimes used to construct domain labels, e.g., the
995 local part "user" in the address user@domain.example could be
996 converted into a host name user.domain.example with its Web space at
997 <http://user.domain.example> and the catch-all addresses
998 any.thing.goes@user.domain.example.
1000 Such schemes are obviously limited by, among other things, the SMTP
1001 rules for domain names, and will not work without further
1002 restrictions for other local parts. Whether those limitations are
1003 relevant to these specifications is an open question. It may be
1004 simply another case of the considerable flexibility accorded to
1005 delivery MTAs in determining the mailbox names they will accept and
1006 how they are interpreted.
1010Klensin & Ko Standards Track [Page 18]
1012RFC 6530 Internationalized Email Framework February 2012
101511.5. Non-Standard Encapsulation Formats
1017 Some applications use formats similar to the application/mbox format
1018 [RFC4155] instead of the message/digest form defined in RFC 2046,
1019 Section 5.1.5 [RFC2046] to transfer multiple messages as single
1020 units. Insofar as such applications assume that all stored messages
1021 use the message/rfc822 format described in RFC 2046, Section 5.2.1
1022 [RFC2046] with ASCII message headers, they are not ready for the
1023 extensions specified in this series of documents, and special
1024 measures may be needed to properly detect and process them.
102612. Key Changes from the Experimental Protocols and Framework
1028 The original framework for internationalized email addresses and
1029 headers was described in RFC 4952 and a subsequent set of
1030 experimental protocol documents. Those relationships are described
1031 in Section 3. The key architectural difference between the
1032 experimental specifications and this newer set is that the earlier
1033 specifications supported in-transit downgrading. Those mechanisms
1034 included the definition of syntax and functions to support passing
1035 alternate, all-ASCII addresses with the non-ASCII ones as well as
1036 special headers to indicate the downgraded status of messages. Those
1037 features were eliminated after experimentation indicated that they
1038 were more complex and less necessary than had been assumed earlier.
1039 Those issues are described in more detail in Sections 6 and 9.
104113. Security Considerations
1043 Any expansion of permitted characters and encoding forms in email
1044 addresses raises some risks. There have been discussions on so
1045 called "IDN-spoofing" or "IDN homograph attacks". These attacks
1046 allow an attacker (or "phisher") to spoof the domain or URLs of
1047 businesses or other entities. The same kind of attack is also
1048 possible on the local part of internationalized email addresses. It
1049 should be noted that the proposed fix involving forcing all displayed
1050 elements into normalized lowercase works for domain names in URLs,
1051 but not for email local parts since those are case sensitive.
1053 Since email addresses are often transcribed from business cards and
1054 notes on paper, they are subject to problems arising from confusable
1055 characters (see [RFC4690]). These problems are somewhat reduced if
1056 the domain associated with the mailbox is unambiguous and supports a
1057 relatively small number of mailboxes whose names follow local system
1058 conventions. They are increased with very large mail systems in
1059 which users can freely select their own addresses.
1066Klensin & Ko Standards Track [Page 19]
1068RFC 6530 Internationalized Email Framework February 2012
1071 The internationalization of email addresses and message headers must
1072 not leave the Internet less secure than it is without the required
1073 extensions. The requirements and mechanisms documented in this set
1074 of specifications do not, in general, raise any new security issues.
1076 They do require a review of issues associated with confusable
1077 characters -- a topic that is being explored thoroughly elsewhere
1078 (see, e.g., RFC 4690 [RFC4690]) -- and, potentially, some issues with
1079 UTF-8 normalization, discussed in RFC 3629 [RFC3629], and other
1080 transformations. Normalization and other issues associated with
1081 transformations and standard forms are also part of the subject of
1082 work described elsewhere [RFC5198] [RFC5893] [RFC6055].
1084 Some issues specifically related to internationalized addresses and
1085 message headers are discussed in more detail in the other documents
1086 in this set. However, in particular, caution should be taken that
1087 any "downgrading" mechanism, or use of downgraded addresses, does not
1088 inappropriately assume authenticated bindings between the
1089 internationalized and ASCII addresses. This potential problem can be
1090 mitigated somewhat by enforcing the expectation that most or all such
1091 transformations will be performed prior to final delivery by systems
1092 that are presumed to be under the administrative control of the
1093 sending user (as opposed to being performed in transit by entities
1094 that are not under the administrative control of the sending user).
1096 The new UTF-8 header and message formats might also raise, or
1097 aggravate, another known issue. If the model creates new forms of an
1098 'invalid' or 'malformed' message, then a new email attack is created:
1099 in an effort to be robust, some or most agents will accept such
1100 messages and interpret them as if they were well-formed. If a filter
1101 interprets such a message differently than the MUA used by the
1102 recipient, then it may be possible to create a message that appears
1103 acceptable under the filter's interpretation but that should be
1104 rejected under the interpretation given to it by that MUA. Such
1105 attacks already have occurred for existing messages and encoding
1106 layers, e.g., invalid MIME syntax, invalid HTML markup, and invalid
1107 coding of particular image types.
1109 In addition, email addresses are used in many contexts other than
1110 sending mail, such as for identifiers under various circumstances
1111 (see Section 11.2). Each of those contexts will need to be
1112 evaluated, in turn, to determine whether the use of non-ASCII forms
1113 is appropriate and what particular issues they raise.
1115 This work will clearly affect any systems or mechanisms that are
1116 dependent on digital signatures or similar integrity protection for
1117 email message headers (see also the discussion in Section 11.3).
1118 Many conventional uses of PGP and S/MIME are not affected since they
1122Klensin & Ko Standards Track [Page 20]
1124RFC 6530 Internationalized Email Framework February 2012
1127 are used to sign body parts but not message headers. On the other
1128 hand, the developing work on DomainKeys Identified Mail (DKIM)
1129 [RFC5863] will eventually need to consider this work, and vice versa:
1130 while this specification does not address or solve the issues raised
1131 by DKIM and other signed header mechanisms, the issues will have to
1132 be coordinated and resolved eventually if the two sets of protocols
1133 are to coexist. In addition, to the degree to which email addresses
1134 appear in PKI (Public Key Infrastructure) certificates [RFC5280],
1135 standards addressing such certificates will need to be upgraded to
1136 address these internationalized addresses. Those upgrades will need
1137 to address questions of spoofing by look-alikes of the addresses
1142 This document is an update to, and derived from, RFC 4952. This
1143 document would have been impossible without the work and
1144 contributions acknowledged in it. The present document benefited
1145 significantly from discussions in the IETF EAI working group and
1146 elsewhere after RFC 4952 was published, especially discussions about
1147 the experimental versions of other documents in the internationalized
1148 email collection, and from RFC errata on RFC 4952 itself.
1150 Special thanks are due to Ernie Dainow for careful reviews and
1151 suggested text in this version and to several IESG members for a
1152 careful review and specific suggestions.
115615.1. Normative References
1158 [ASCII] American National Standards Institute (formerly United
1159 States of America Standards Institute), "USA Code for
1160 Information Interchange", ANSI X3.4-1968, 1968.
1162 ANSI X3.4-1968 has been replaced by newer versions with
1163 slight modifications, but the 1968 version remains
1164 definitive for the Internet.
1166 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1167 Requirement Levels", BCP 14, RFC 2119, March 1997.
1169 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
1170 10646", STD 63, RFC 3629, November 2003.
1172 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
1178Klensin & Ko Standards Track [Page 21]
1180RFC 6530 Internationalized Email Framework February 2012
1183 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
1186 [RFC5890] Klensin, J., "Internationalized Domain Names for
1187 Applications (IDNA): Definitions and Document Framework",
1188 RFC 5890, August 2010.
1190 [RFC6152] Klensin, J., Freed, N., Rose, M., and D. Crocker, "SMTP
1191 Service Extension for 8-bit MIME Transport", STD 71,
1192 RFC 6152, March 2011.
1194 [RFC6531] Yao, J. and W. Mao, "SMTP Extension for Internationalized
1195 Email Address", RFC 6531, February 2012.
1197 [RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized
1198 Email Headers", RFC 6532, February 2012.
1200 [RFC6533] Hansen, T., Newman, C., and A. Melnikov,
1201 "Internationalized Delivery Status and Disposition
1202 Notifications", RFC 6533, February 2012.
120415.2. Informative References
1207 Fujiwara, K., "Post-delivery Message Downgrading for
1208 Internationalized Email Messages", Work in Progress,
1211 [RFC0821] Postel, J., "Simple Mail Transfer Protocol", STD 10,
1212 RFC 821, August 1982.
1214 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application
1215 and Support", STD 3, RFC 1123, October 1989.
1217 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3",
1218 STD 53, RFC 1939, May 1996.
1220 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
1221 Extensions (MIME) Part One: Format of Internet Message
1222 Bodies", RFC 2045, November 1996.
1224 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
1225 Extensions (MIME) Part Two: Media Types", RFC 2046,
1228 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
1229 Part Three: Message Header Extensions for Non-ASCII Text",
1230 RFC 2047, November 1996.
1234Klensin & Ko Standards Track [Page 22]
1236RFC 6530 Internationalized Email Framework February 2012
1239 [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded
1240 Word Extensions: Character Sets, Languages, and
1241 Continuations", RFC 2231, November 1997.
1243 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
1246 [RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler,
1247 "MIME Security with OpenPGP", RFC 3156, August 2001.
1249 [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service
1250 Extension for Delivery Status Notifications (DSNs)",
1251 RFC 3461, January 2003.
1253 [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format
1254 for Delivery Status Notifications", RFC 3464,
1257 [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode
1258 for Internationalized Domain Names in Applications
1259 (IDNA)", RFC 3492, March 2003.
1261 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
1262 4rev1", RFC 3501, March 2003.
1264 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource
1265 Identifiers (IRIs)", RFC 3987, January 2005.
1267 [RFC4155] Hall, E., "The application/mbox Media Type", RFC 4155,
1270 [RFC4690] Klensin, J., Faltstrom, P., Karp, C., and IAB, "Review and
1271 Recommendations for Internationalized Domain Names
1272 (IDNs)", RFC 4690, September 2006.
1274 [RFC4952] Klensin, J. and Y. Ko, "Overview and Framework for
1275 Internationalized Email", RFC 4952, July 2007.
1277 [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network
1278 Interchange", RFC 5198, March 2008.
1280 [RFC5228] Guenther, P. and T. Showalter, "Sieve: An Email Filtering
1281 Language", RFC 5228, January 2008.
1283 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
1284 Housley, R., and W. Polk, "Internet X.509 Public Key
1285 Infrastructure Certificate and Certificate Revocation List
1286 (CRL) Profile", RFC 5280, May 2008.
1290Klensin & Ko Standards Track [Page 23]
1292RFC 6530 Internationalized Email Framework February 2012
1295 [RFC5335] Yang, A., "Internationalized Email Headers", RFC 5335,
1298 [RFC5336] Yao, J. and W. Mao, "SMTP Extension for Internationalized
1299 Email Addresses", RFC 5336, September 2008.
1301 [RFC5337] Newman, C. and A. Melnikov, "Internationalized Delivery
1302 Status and Disposition Notifications", RFC 5337,
1305 [RFC5504] Fujiwara, K. and Y. Yoneya, "Downgrading Mechanism for
1306 Email Address Internationalization", RFC 5504, March 2009.
1308 [RFC5721] Gellens, R. and C. Newman, "POP3 Support for UTF-8",
1309 RFC 5721, February 2010.
1312 Gellens, R., Newman, C., Yao, J., and K. Fujiwara, "POP3
1313 Support for UTF-8", Work in Progress, November 2011.
1315 [RFC5738] Resnick, P. and C. Newman, "IMAP Support for UTF-8",
1316 RFC 5738, March 2010.
1319 Resnick, P., Ed., Newman, C., Ed., and S. Shen, Ed., "IMAP
1320 Support for UTF-8", Work in Progress, December 2011.
1322 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
1323 Mail Extensions (S/MIME) Version 3.2 Message
1324 Specification", RFC 5751, January 2010.
1326 [RFC5825] Fujiwara, K. and B. Leiba, "Displaying Downgraded Messages
1327 for Email Address Internationalization", RFC 5825,
1330 [RFC5863] Hansen, T., Siegel, E., Hallam-Baker, P., and D. Crocker,
1331 "DomainKeys Identified Mail (DKIM) Development,
1332 Deployment, and Operations", RFC 5863, May 2010.
1334 [RFC5891] Klensin, J., "Internationalized Domain Names in
1335 Applications (IDNA): Protocol", RFC 5891, August 2010.
1337 [RFC5892] Faltstrom, P., "The Unicode Code Points and
1338 Internationalized Domain Names for Applications (IDNA)",
1339 RFC 5892, August 2010.
1346Klensin & Ko Standards Track [Page 24]
1348RFC 6530 Internationalized Email Framework February 2012
1351 [RFC5893] Alvestrand, H. and C. Karp, "Right-to-Left Scripts for
1352 Internationalized Domain Names for Applications (IDNA)",
1353 RFC 5893, August 2010.
1355 [RFC5894] Klensin, J., "Internationalized Domain Names for
1356 Applications (IDNA): Background, Explanation, and
1357 Rationale", RFC 5894, August 2010.
1359 [RFC5983] Gellens, R., "Mailing Lists and Internationalized Email
1360 Addresses", RFC 5983, October 2010.
1362 [RFC5983bis-MailingList]
1363 Levine, J. and R. Gellens, "Mailing Lists and UTF-8
1364 Addresses", Work in Progress, December 2011.
1366 [RFC6055] Thaler, D., Klensin, J., and S. Cheshire, "IAB Thoughts on
1367 Encodings for Internationalized Domain Names", RFC 6055,
1370 [RFC6068] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto'
1371 URI Scheme", RFC 6068, October 2010.
1373 [RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail",
1374 STD 72, RFC 6409, November 2011.
1376 [Unicode] The Unicode Consortium. The Unicode Standard, Version
1377 6.0.0, defined by:, "The Unicode Standard, Version 6.0.0",
1378 (Mountain View, CA: The Unicode Consortium, 2011. ISBN
1379 978-1-936213-01-6).,
1380 <http://www.unicode.org/versions/Unicode6.0.0/>.
1383 The Unicode Consortium, "Unicode Standard Annex #15:
1384 Unicode Normalization Forms", September 2010,
1385 <http://www.unicode.org/reports/tr15/>.
1402Klensin & Ko Standards Track [Page 25]
1404RFC 6530 Internationalized Email Framework February 2012
1410 1770 Massachusetts Ave, #322
1414 Phone: +1 617 491 5735
1415 EMail: john-ietf@jck.com
1419 112-202 Malgeunachim APT. Nae-dong
1420 Seo-gu, Daejeon 302-981
1423 EMail: yangwooko@gmail.com
1458Klensin & Ko Standards Track [Page 26]