SMTP Extension for Internationalized Email
obsoletes
- rfc-5336 — SMTP Extension for Internationalized Email Addresses
Extracted elements (26)
ASCII-only messages SHOULD be sent without the SMTPUTF8 extension because next-hop servers may not support it, and during early deployment the risk of transmission failure is high. The long-term advantage of casting ASCII characters as UTF-8 is enabling pure-Unicode environments, but the near-term cost is real.
The SMTPUTF8 parameter for VRFY/EXPN is scoped per-command (not session-wide) to allow servers to use UTF-8 replies safely only when the client has explicitly signaled acceptance, preventing confusion in non-SMTPUTF8-aware clients that might mishandle UTF-8 in replies.
The SMTPUTF8 extension is valid on the submission port (RFC 6409) and may also be used with LMTP (RFC 2033). When used, the WITH clause in trace fields MUST use the appropriate UTF8SMTP/UTF8LMTP protocol type values.
When doing DNS lookups for internationalized domain names, the SMTPUTF8-aware client or server MUST either use a Unicode-aware DNS library or transform the domain to A-label form. U-label form is SHOULD-level preferred in trace fields when SMTPUTF8 is active.
When multiple DNS MX records specify multiple servers for a domain, it is strongly advised that all or none of them SHOULD support the SMTPUTF8 extension. Mixed support can cause unexpected rejections during failures, perceived by users as serious reliability issues.
An SMTP server announcing SMTPUTF8 MUST be prepared to accept a UTF-8 string in any position where RFC 5321 specifies a mailbox can appear. Any domain name looked up in DNS MUST conform to IDNA (RFC 5890) processing.
An SMTPUTF8-aware SMTP server MUST NOT use UTF-8 strings in VRFY/EXPN replies if the client did not transmit the SMTPUTF8 parameter. If UTF-8 is required but not permitted, the server MUST use reply-code 252 or 550 (with enhanced code X.6.8).
If a MAIL command does not include the SMTPUTF8 parameter, an SMTPUTF8-aware server MUST NOT return 251 or 551 responses containing non-ASCII mailboxes; it MUST transform such responses into 250 or 550 responses without non-ASCII addresses.
If an SMTPUTF8-aware SMTP server advertises the DSN extension (RFC 3461), it MUST implement RFC 6533 (Internationalized Delivery Status and Disposition Notifications).
If the envelope or message requires SMTPUTF8 capabilities, the SMTPUTF8-aware SMTP client MUST supply the SMTPUTF8 parameter with the MAIL command. If neither the envelope nor message requires SMTPUTF8 capabilities, it SHOULD NOT supply the parameter.
If the SMTPUTF8 extension is not offered by the server, an SMTPUTF8-aware client MUST NOT transmit an internationalized email address and MUST NOT transmit a mail message containing internationalized headers at any level within its MIME structure.
Servers offering the SMTPUTF8 extension MUST provide support for, and announce, the 8BITMIME extension (RFC 6152). SMTPUTF8-aware clients MUST use BODY=8BITMIME when sending internationalized messages.
SMTPUTF8-aware SMTP servers MUST NOT include non-ASCII characters in replies except in the limited cases specifically permitted: 251/551 replies when SMTPUTF8 is in the MAIL command, and VRFY/EXPN replies when the client uses the SMTPUTF8 parameter.
The EHLO response MUST NOT contain any parameters for the SMTPUTF8 keyword. An SMTPUTF8-aware SMTP client MUST ignore any parameters that appear for this keyword and MUST behave as if they do not appear.
The SMTPUTF8-aware SMTP client MUST send only ASCII (LDH label or A-label) domains in the EHLO command, since it cannot know server SMTPUTF8 support before receiving the EHLO response. EHLO responses from SMTPUTF8-aware servers MUST also use LDH labels or A-labels.
When an SMTPUTF8-aware client or relay cannot transmit an internationalized message to a non-supporting server and is not an MSA choosing transformation, it SHOULD reject the message. Non-delivery notifications MUST conform to RFC 5321, RFC 3464, and RFC 6533.
Reply-code 553 is used when RCPT rejects an internationalized address requiring ASCII; reply-code 550 when MAIL rejects one. Enhanced status code X.6.7 ('Non-ASCII addresses not permitted for that sender/recipient') accompanies these when enhanced codes are supported.
Reply-code 554 with enhanced status code X.6.9 is used when a message is rejected after the DATA command's final '.' because one or more recipients cannot accept internationalized headers. X.6.8 indicates a UTF-8 reply is required but forbidden by the client.
The SMTPUTF8 SMTP service extension is identified by the EHLO keyword 'SMTPUTF8' with no parameter values. Its presence signals full compliance with RFC 6531, enabling UTF-8 internationalized addresses in MAIL and RCPT commands.
IANA added eight entries to the WITH Protocol Types sub-registry: UTF8SMTP, UTF8SMTPA, UTF8SMTPS, UTF8SMTPSA (ESMTP variants with SMTPUTF8, AUTH, and/or STARTTLS) and UTF8LMTP, UTF8LMTPA, UTF8LMTPS, UTF8LMTPSA (LMTP variants).
IANA added 'SMTPUTF8' to the SMTP Service Extensions registry (Mail Parameters), with description 'Internationalized email address' and reference RFC 6531.
IANA updated the SMTP Enhanced Status Code registry with three new codes from RFC 6531: X.6.7 (non-ASCII addresses not permitted, basic codes 550/553), X.6.8 (UTF-8 reply required but not permitted by client, basic codes 252/550/553), and X.6.9 (UTF-8 header message cannot be transferred, basic code 550). X.6.10 is deprecated as a duplicate of X.6.8.
Internationalized email addresses will appear in SMTP transaction logs, trouble ticket systems, and monitoring tools. Systems must be extended to support full UTF-8 or provide adequate ASCII-mapping mechanisms to avoid data loss and to allow security teams to quickly identify and read internationalized addresses during incident response.
Mechanisms 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, addressing the need for security teams tracking incidents via logs.
Extended ABNF rules: sub-domain is extended with U-label; atext is extended with UTF8-non-ascii; qtextSMTP is extended with UTF8-non-ascii; esmtp-value is extended with UTF8-non-ascii. These extend RFC 5321 mailbox syntax to permit non-ASCII characters.
The MAIL command line maximum length is increased by 10 characters to accommodate the optional SMTPUTF8 parameter. The SMTPUTF8 parameter takes no value. VRFY and EXPN commands are extended with an optional 'SMTPUTF8' parameter (no value) to signal UTF-8 reply acceptance.