Skip to main content

RFC 6532 - Internationalized Email Headers

Document Information

  • RFC Number: 6532
  • Title: Internationalized Email Headers
  • Authors: A. Yang, S. Steele, N. Freed
  • Date: February 2012
  • Category: Standards Track
  • Obsoletes: RFC 5335
  • ISSN: 2070-1721

Abstract

This specification adds to the email header syntax described in RFC 5322 to accommodate the UTF-8 encoding. It also updates the rules for "message/global" to similar rules for "message/rfc822" to handle the Internationalized Email Headers.

Status of This Memo

This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6532.

Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.

Table of Contents

  1. Introduction
  2. Terminology
  3. Changes to RFC 5322
  4. Security Considerations
  5. IANA Considerations
  6. Acknowledgements
  7. References

1. Introduction

This document specifies an extension to the Internet Message Format [RFC5322] to allow the transmission of email headers that include non-ASCII characters. This specification allows UTF-8 [RFC3629] characters in most email header fields, including the Subject header field, the From header field, and the To header field.

This document obsoletes RFC 5335 [RFC5335].

2. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

The terms "UTF-8 string" or "UTF-8 character" are used to refer to Unicode characters, which may or may not be members of the ASCII subset, in UTF-8 [RFC3629], a standard Unicode Encoding Form.

3. Changes to RFC 5322

This specification extends the header syntax defined in RFC 5322 [RFC5322] to allow UTF-8 characters.

3.1. UTF-8 Syntax and Normalization

UTF-8 characters can be used in the header fields as defined in the following sections. All UTF-8 strings MUST be valid UTF-8.

3.2. Syntax Extensions to RFC 5322

The following rules are extended in ABNF [RFC5234] to allow UTF-8 characters.

VCHAR   =/  UTF8-non-ascii

ctext =/ UTF8-non-ascii

atext =/ UTF8-non-ascii

qtext =/ UTF8-non-ascii

text =/ UTF8-non-ascii

dtext =/ UTF8-non-ascii

Where UTF8-non-ascii is defined as any UTF-8 character that is not an ASCII character.

3.3. Use of 8-bit MIME in Headers

The 8-bit MIME extension [RFC6152] is used to allow 8-bit data in the body of the message. This specification extends that to allow 8-bit data in the headers as well.

3.4. Address Syntax

The syntax for email addresses is extended to allow UTF-8 characters in the local-part and the domain part.

3.5. Trace Field Syntax

Trace fields, such as Received, are extended to allow UTF-8 characters.

3.6. Message Header Body Syntax

The syntax for the message header is extended to allow UTF-8 characters in the field names and field bodies.

4. Security Considerations

The security considerations of RFC 5322 [RFC5322] and RFC 6530 [RFC6530] apply to this specification.

5. IANA Considerations

IANA has updated the registration of the "message/global" media type to reference this document.

6. Acknowledgements

The authors would like to thank the members of the EAI working group for their contributions to this document.

7. References

7.1. Normative References

  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 3629, November 2003.
  • [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
  • [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
  • [RFC6152] Klensin, J., Freed, N., Rose, M., and D. Crocker, "SMTP Service Extension for 8-bit MIME Transport", STD 71, RFC 6152, March 2011.

7.2. Informative References

  • [RFC5335] Yang, A., Ed., "Internationalized Email Headers", RFC 5335, September 2008.
  • [RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for Internationalized Email", RFC 6530, February 2012.

Authors' Addresses

Abel Yang TWNIC 4F-2, No. 2, Sec. 2, Jinshan S. Rd. Taipei 106 Taiwan

EMail: [email protected]

Shawn Steele Microsoft

EMail: [email protected]

Ned Freed Oracle 800 Royal Oaks Monrovia, CA 91016-6347 USA

EMail: [email protected]