Overview and Framework for Internationalized Email
RFC 4952

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 05

Network Working Group                                         J. Klensin
Request for Comments: 4952
Category: Informational                                            Y. Ko
                                                                     ICU
                                                               July 2007

           Overview and Framework for Internationalized Email

Status of This Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   Full use of electronic mail throughout the world requires that people
   be able to use their own names, written correctly in their own
   languages and scripts, as mailbox names in email addresses.  This
   document introduces a series of specifications that define mechanisms
   and protocol extensions needed to fully support internationalized
   email addresses.  These changes include an SMTP extension and
   extension of email header syntax to accommodate UTF-8 data.  The
   document set also includes discussion of key assumptions and issues
   in deploying fully internationalized email.

Klensin & Ko                 Informational                      [Page 1]
RFC 4952                     EAI Framework                     July 2007

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Role of This Specification . . . . . . . . . . . . . . . .  3
     1.2.  Problem Statement  . . . . . . . . . . . . . . . . . . . .  3
     1.3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Overview of the Approach . . . . . . . . . . . . . . . . . . .  6
   3.  Document Plan  . . . . . . . . . . . . . . . . . . . . . . . .  6
   4.  Overview of Protocol Extensions and Changes  . . . . . . . . .  7
     4.1.  SMTP Extension for Internationalized Email Address . . . .  7
     4.2.  Transmission of Email Header Fields in UTF-8 Encoding  . .  8
     4.3.  Downgrading Mechanism for Backward Compatibility . . . . .  9
   5.  Downgrading before and after SMTP Transactions . . . . . . . . 10
     5.1.  Downgrading before or during Message Submission  . . . . . 10
     5.2.  Downgrading or Other Processing After Final SMTP
           Delivery . . . . . . . . . . . . . . . . . . . . . . . . . 11
   6.  Additional Issues  . . . . . . . . . . . . . . . . . . . . . . 11
     6.1.  Impact on URIs and IRIs  . . . . . . . . . . . . . . . . . 11
     6.2.  Interaction with Delivery Notifications  . . . . . . . . . 12
     6.3.  Use of Email Addresses as Identifiers  . . . . . . . . . . 12
     6.4.  Encoded Words, Signed Messages, and Downgrading  . . . . . 12
     6.5.  Other Uses of Local Parts  . . . . . . . . . . . . . . . . 13
     6.6.  Non-Standard Encapsulation Formats . . . . . . . . . . . . 13
   7.  Experimental Targets . . . . . . . . . . . . . . . . . . . . . 13
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 16
     11.2. Informative References . . . . . . . . . . . . . . . . . . 16

Klensin & Ko                 Informational                      [Page 2]
RFC 4952                     EAI Framework                     July 2007

1.  Introduction

   In order to use internationalized email addresses, we need to
   internationalize both the domain part and the local part of email
   addresses.  The domain part of email addresses is already
   internationalized [RFC3490], while the local part is not.  Without
   the extensions specified in this document, the mailbox name is
   restricted to a subset of 7-bit ASCII [RFC2821].  Though MIME
   [RFC2045] enables the transport of non-ASCII data, it does not
   provide a mechanism for internationalized email addresses.  In RFC
   2047 [RFC2047], MIME defines an encoding mechanism for some specific
   message header fields to accommodate non-ASCII data.  However, it
   does not permit the use of email addresses that include non-ASCII
   characters.  Without the extensions defined here, or some equivalent
   set, the only way to incorporate non-ASCII characters in any part of
   email addresses is to use RFC 2047 coding to embed them in what RFC
   2822 [RFC2822] calls the "display name" (known as a "name phrase" or
   by other terms elsewhere) of the relevant headers.  Information coded
   into the display name is invisible in the message envelope and, for
   many purposes, is not part of the address at all.

1.1.  Role of This Specification

   This document presents the overview and framework for an approach to
   the next stage of email internationalization.  This new stage