Email Authentication for Internationalized Mail
updates
Extracted elements (15)
DMARC is not currently a Standards Track protocol, so this specification offers advice rather than requirements for DMARC. Updates to DMARC sections are described as guidance rather than normative mandates.
Every U-label is equivalent to an A-label, so in principle the choice of label format will not cause ambiguities. In practice, consistent use of label formats makes it more likely that code for mail senders and receivers interoperates.
DKIM key records do not contain domain names, so there is no change to their specification under internationalized mail.
DKIM relaxed header canonicalization converts header field names from uppercase to lowercase. Field names are restricted to printable ASCII per RFC 5322, so this case conversion remains ASCII case conversion and is unaffected by internationalization.
SPF macros %{s} and %{l} expand the local part of the sender's mailbox. If the local part contains non-ASCII characters, terms including %{s} or %{l} do not match anything, because non-ASCII local parts cannot be used as DNS labels.
All U-labels MUST be converted to A-labels before being used for an SPF validation. This includes labels in the name used for the original DNS lookup and those used in macro expansion of domain-spec.
DMARC policy record email addresses in the 'rua' and 'ruf' tags must still be conventional (ASCII) addresses, not internationalized addresses, since a policy record can be used for both internationalized and conventional mail.
For DMARC, all U-labels in the RFC5322.From address domain are converted to A-labels before further processing. This updates Section 6.6.1 of RFC 7489.
For internationalized message header fields, IDNs in the d=, i=, and s= tags of a DKIM-Signature header field SHOULD be represented as U-labels to provide improved consistency with other header fields. A-labels remain valid to allow transition from older software.
Section 4.3 of RFC 7208 states that all IDNs in an SPF DNS record MUST be A-labels; this rule is unchanged since any SPF record can be used to authorize either EAI or conventional mail.
Since the EHLO command precedes the server response that tells whether the server supports the SMTPUTF8 extension, an IDN host name in EHLO MUST be represented as A-labels.
Strings stored in DNS records remain ASCII. When a domain name found in a mail header field includes U-labels, those labels MUST be translated to A-labels before being looked up in the DNS.
When computing or verifying the hash in a DKIM signature, the hash MUST use the domain name in the format it occurs in the header field (either U-label or A-label, matching the header).
The updates to SPF, DKIM, and DMARC are intended to allow those specifications to work as reliably on internationalized mail as on ASCII mail, so that spam and phishing filters using them can work more reliably on internationalized mail. No new threats are introduced.
The ABNF for dkim-safe-char in internationalized messages is extended to permit non-ASCII UTF-8 characters (UTF8-2, UTF8-3, UTF8-4 from RFC 3629) without quoting, in addition to the original printable ASCII ranges %x21-3A, %x3C, %x3E-7E.