RFC 6531 Proposed Standard Transport

SMTP Extension for Internationalized Email

This document specifies an SMTP extension for transport and delivery of email messages with internationalized email addresses or header information. [STANDARDS-TRACK]

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
J. Yao, W. Mao
Read it
rfc-editor.org · errata · DOI

Replaces RFC 5336: SMTP Extension for Internationalized Email Addresses.

Normative requirements

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

1.1 Terminology

  • MUSTStrings referred to in this document, including ASCII strings, MUST be expressed in UTF-8.

3.1 Framework for the Internationalization Extension

  • MUST NOTIn order to permit future (although unanticipated) extensions, the EHLO response MUST NOT contain any parameters for this keyword.
  • MUSTThe SMTPUTF8-aware SMTP client MUST ignore any parameters if they appear for this keyword; that is, the SMTPUTF8-aware SMTP client MUST behave as if the parameters do not appear.
  • MUSTIf an SMTP server includes SMTPUTF8 in its EHLO response, it MUST be fully compliant with this version of this specification.
  • OPTIONALOne OPTIONAL parameter, SMTPUTF8, is added to the MAIL command.
  • OPTIONALOne OPTIONAL parameter, SMTPUTF8, is added to the VERIFY (VRFY) and EXPAND (EXPN) commands.
  • MUSTServers offering this extension MUST provide support for, and announce, the 8BITMIME extension [RFC6152].

3.2 The SMTPUTF8 Extension

  • MUSTAn SMTP server that announces the SMTPUTF8 extension MUST be prepared to accept a UTF-8 string [RFC3629] in any position in which RFC 5321 specifies that a <mailbox> can appear.
  • MUSTAny domain name to be looked up in the DNS MUST conform to and be processed as specified for Internationalizing Domain Names in Applications (IDNA) [RFC5890].
  • MUSTWhen doing lookups, the SMTPUTF8-aware SMTP client or server MUST either use a Unicode-aware DNS library, or transform the internationalized domain name to A-label form (i.e., a fully- qualified domain name that contains one or more A-labels but no U-labels) as specified in RFC 5890 [RFC5890].
  • MAYAn SMTP client that receives the SMTPUTF8 extension keyword in response to the EHLO command MAY transmit mailbox names within SMTP commands as internationalized strings in UTF-8 form.
  • MAYIt MAY send a UTF-8 header [RFC6532] (which may also include mailbox names in
  • MAYIt MAY transmit the domain parts of mailbox names within SMTP commands or the message header as A-labels or U-labels [RFC5890].
  • MUST NOTIf the SMTPUTF8 SMTP extension is not offered by the SMTP server, the SMTPUTF8-aware SMTP client MUST NOT transmit an internationalized email address and MUST NOT transmit a mail message containing internationalized mail headers as described in RFC 6532 [RFC6532] at any level within its MIME structure [RFC2045].
  • MAYo If it is a Message Submission Agent (MSA) [RFC6409] [RFC5598], it MAY choose its own way to deal with this scenario using the wide discretion for changing addresses or otherwise fixing up and transforming messages allowed by RFC 6409.
  • SHOULDo If it is not an MSA or is an MSA and does not choose to transform the message to one that does not require the SMTPUTF8 extension, it SHOULD reject the message.
  • MUSTIf the latter choice is made, the notification process MUST conform to the requirements of RFC 5321, RFC 3464 [RFC3464], and RFC 6533 [RFC6533].
  • MAYo As specified in Section 2.2.3 of RFC 5321, an SMTP client with additional information and/or knowledge of special circumstances MAY choose to requeue the message and try later and/or try an alternate MX host as specified in that section.
  • MUSTIf an SMTPUTF8-aware SMTP server advertises the Delivery Status Notification (DSN) [RFC3461] extension, it MUST implement RFC 6533 [RFC6533].

3.3 Extended Mailbox Address Syntax

  • MUST NOTThat string MUST NOT contain any of the ASCII graphics or control characters.

3.4 MAIL Command Parameter Usage

  • MUSTIf the envelope or message being sent requires the capabilities of the SMTPUTF8 extension, the SMTPUTF8-aware SMTP client MUST supply the SMTPUTF8 parameter with the MAIL command.
  • MUSTIf this parameter is provided, it MUST not accept a value.
  • SHOULD NOTIf the SMTPUTF8-aware SMTP client is aware that neither the envelope nor the message being sent requires any of the SMTPUTF8 extension capabilities, it SHOULD NOT supply the SMTPUTF8 parameter with the MAIL command.

3.5 Non-ASCII Addresses and Reply-Codes

  • MUST NOTAn SMTPUTF8-aware SMTP client MUST NOT send an internationalized message to an SMTP server that does not support SMTPUTF8.

3.6 Body Parts and SMTP Extensions

  • MAYThe SMTPUTF8 extension MAY be used as follows (assuming it is appropriate given the body content):

3.7 Additional ESMTP Changes and Clarifications

  • SHOULDWhen RFC 5321 specifies a domain name, the internationalized domain name SHOULD be in U-label form if the SMTPUTF8 extension is supported; otherwise, it SHOULD be in A-label form.

3.7.1 The Initial SMTP Exchange

  • MUSTSince the SMTP client cannot know whether the SMTP server supports SMTPUTF8 until after it receives the response to the EHLO, the SMTPUTF8-aware SMTP client MUST send only ASCII (LDH label or A-label [RFC5890]) domains in the EHLO command.
  • MUSTIf the SMTPUTF8-aware SMTP server provides domain names in the EHLO response, they MUST be in the form of LDH labels or A-labels.

3.7.2 Mail eXchangers

  • SHOULDIf multiple DNS MX records are used to specify multiple servers for a domain (as described in Section 5 of RFC 5321 [RFC5321]), it is strongly advised that all or none of them SHOULD support the SMTPUTF8

3.7.3 Trace Information

  • SHOULDWhen an SMTPUTF8-aware SMTP server adds a trace field to a message that was or will be transmitted with the SMTPUTF8 parameter included in the MAIL commands, that server SHOULD use the U-label form for internationalized domain names in the new trace field.

3.7.4.1 MAIL Command

  • MUSTIf an SMTP client follows this specification and sends any MAIL commands containing the SMTPUTF8 parameter, the SMTPUTF8-aware SMTP server is permitted to use UTF-8 characters in the email address associated with 251 and 551 reply-codes, and the SMTP client MUST be able to accept and process them.
  • MUST NOTIf a given MAIL command does not include the SMTPUTF8 parameter, the SMTPUTF8-aware SMTP server MUST NOT return a 251 or 551 response containing a non-ASCII mailbox.
  • MUSTInstead, it MUST transform such responses into 250 or 550 responses that do not contain non-ASCII addresses.

3.7.4.2 VRFY and EXPN Commands and the SMTPUTF8 Parameter

  • SHOULDcommands SHOULD only be used after the SMTP client sees the EHLO response with the SMTPUTF8 keyword.
  • MUSTAn SMTP client that conforms to this specification MUST accept and correctly process replies to the VRFY and EXPN commands that contain UTF-8 strings.
  • MUST NOTHowever, an SMTPUTF8-aware SMTP server MUST NOT use UTF-8 strings in replies if the SMTP client does not specifically allow such replies by transmitting this parameter with the VRFY and EXPN commands.
  • MUSTIf the reply to a VRFY or EXPN command requires a UTF-8 string, but the SMTP client did not use the SMTPUTF8 parameter, then the SMTPUTF8-aware SMTP server MUST use either the reply-code 252 or 550.
  • MAYIf a normal success response (i.e., 250) is returned, the response MAY include the full name of the user and MUST include the mailbox of the user.
  • MUSTIt MUST be in either of the following forms:
  • MUST NOTSMTPUTF8-aware SMTP servers MUST NOT include non-ASCII characters in replies except in the limited cases specifically permitted in this section.

5 Security Considerations

  • SHALLMechanisms to automatically and quickly provide the origin or ownership of an internationalized email address SHALL be implemented for use by log readers that cannot easily read non-ASCII information.

Every current email RFC