RFC 6532 Proposed Standard Internationalization

Internationalized Email Headers

Internet mail was originally limited to 7-bit ASCII. MIME added support for the use of 8-bit character sets in body parts, and also defined an encoded-word construct so other character sets could be used in certain header field values. However, full internationalization of electronic mail requires additional enhancements to allow the use of Unicode, including characters outside the ASCII repertoire, in mail addresses as well as direct use of Unicode in header fields like "From:", "To:", and "Subject:", without requ

Status
Proposed Standard. On the standards track and stable enough to implement against. Most of the email stack stays at this level permanently.
Published
February 2012
Authors
A. Yang, S. Steele, N. Freed
Read it
rfc-editor.org · errata · DOI

Replaces RFC 5335: Internationalized Email Headers.

Normative requirements

Every sentence in this RFC carrying an RFC 2119 keyword, with the section it came from. 4 must, 4 should, 2 may.

3.1 UTF-8 Syntax and Normalization

  • SHOULDSee [RFC5198] for a discussion of Unicode normalization; normalization form NFC [UNF] SHOULD be used.
  • SHOULD NOTThe NFKC normalization form [UNF] SHOULD NOT be used because it may lose information that is needed to correctly spell some names in some unusual circumstances.

3.3 Use of 8-bit UTF-8 in Message-IDs

  • MAYImplementers of Message-ID generation algorithms MAY prefer to restrain their output to ASCII since that has some advantages, such as when constructing "In-reply-to:" and "References:" header fields in mailing-list threads where some senders use internationalized addresses and others do not.

3.6 Use of MIME Encoded-Words

  • SHOULD NOTAccordingly, encoded-words SHOULD NOT be used when generating header fields for messages employing this extension.
  • MAYAgents MAY, when incorporating material from another message, convert encoded-word use to direct use of UTF-8.
  • MUST NOTProcessors that elect to decode encoded-words MUST NOT generate syntactically invalid fields.

3.7 The message/global Media Type

  • MUSTInternationalized messages in this format MUST only be transmitted as authorized by [RFC6531] or within a non-SMTP environment that supports these messages.
  • MUSTIf an object of this type is sent to a 7-bit-only system, it MUST have an appropriate content-transfer-encoding applied.
  • SHOULDAn 8-bit or binary content-transfer- encoding SHOULD be used unless this media type is sent over a 7-bit-only transport.

4 Security Considerations

  • MUSTAs specified in [RFC5322], each line of characters MUST be no more than 998 octets, excluding the CRLF.

Every current email RFC