]>
E-mail Authentication for Internationalized MailTaughannock NetworksPO Box 727Trumansburg14886NYstandards@taugh.comhttp://jl.lyApplications
e-mailinternationalization
SPF (RFC7208), DKIM (RFC6376), and DMARC (RFC7489) enable a domain owner
to publish e-mail authentication
and policy information in the DNS. In internationalized e-mail, domain
names can occur both as U-labels and A-labels.
This specification updates the SPF, DKIM, and DMARC specifications
to clarify which form of internationalized domain names to use
in those specifications.
SPF, DKIM, and
DMARC enable a domain owner to publish e-mail
authentication
and policy information in the DNS. SPF primarily publishes information
about what host addresses are authorized to send mail for a domain. DKIM
places cryptographic signatures on e-mail messages, with the validation
keys published in the DNS. DMARC publishes policy information related
to the domain in the From: header field of e-mail messages.
In conventional e-mail, all domain names are ASCII in all contexts so
there is no question about the representation of the domain names.
All internationalized domain names are represented as
A-labels in message header fields, in SMTP
sessions, and in the DNS.
Internationalized mail,
(generally called EAI for
E-mail Address Internationalization), allows U-labels in
SMTP sessions
and in message header fields.
Every U-label is equivalent to an A-label, so in principle the
choice of label format will not cause ambiguities. But in
practice, consistent use of label formats will make it more likely
that mail senders' and receivers' code interoperates.
Internationalized mail also allows UTF-8 encoded Unicode characters in
the local parts of mailbox names, which were historically only
ASCII.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14
when, and only when, they appear in all capitals, as shown here.
The term IDN, for Internationalized Domain Name, refers
to a domain name containing either U-labels or A-labels.
Since DMARC is not currently a standards track protocol,
this specification offers advice rather than requirements
for DMARC.
In headers in EAI mail messages, domain names that were restricted to ASCII
can be U-labels, and mailbox local parts can be UTF-8.
Header field names and other text intended primarily to be interpreted by computers
rather than read by people remains ASCII.
Strings stored in DNS records remain ASCII since there is no way to tell
whether a client retrieving a DNS record expects an EAI or an ASCII result.
When a domain name found in a mail header field includes U-labels, those labels
are translated to A-labels before being looked up in the DNS, as described
in .
SPF uses two identities from the
SMTP session, the host name in the EHLO command, and the domain
in the address in the MAIL FROM command.
Since the EHLO command precedes the server response that tells whether the server supports
the SMTPUTF8 extension, an IDN host name
MUST be represented as A-labels.
An IDN in MAIL FROM can be either U-labels or A-labels.
All U-labels MUST be converted to A-labels before being used for
an SPF validation. This includes both the original DNS lookup,
described in Section 3 of and the macro
expansion of domain-spec described in section 7. Section 4.3
of 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.
SPF macros %{s} and %{l} expand the local-part of the sender's mailbox.
If the local-part contains non-ASCII characters, terms that include
%{s} or %{l} do not match anything,
because non-ASCII local parts cannot
be used as the DNS labels the macros are intended to match.
Since these macros are rarely used, this is unlikely to be
an issue in practice.
DKIM specifies a mail header field that
contains a cryptographic message signature and a DNS record that
contains the validation key.
Section 2.11 of defines dkim-quoted-printable.
Its definition is modified in messages with internationalized header fields
so that non-ASCII
UTF-8 characters need not be quoted. The ABNF for dkim-safe-char in
those messages is replaced by the following, adding non-ASCII
UTF-8 characters from :
' - '~', non-ASCII
UTF8-2 =
UTF8-3 =
UTF8-4 =
]]>Section 3.5 of states that IDNs in the d=,
i=, and s= tags of a DKIM-Signature header field MUST be encoded as
A-labels.
This rule is relaxed only for
internationalized messages header fields so IDNs SHOULD
be represented as U-labels.
This provides improved consistency with other header fields.
(A-labels remain valid to allow a transition from older software.)
The set of allowable characters in the local-part of an i= tag is extended
in the same fashion as local parts of e-mail addresses as described in section 3.2 of
.
When computing or verifying the hash in a DKIM signature as described
in section 3.7, the hash MUST
use the domain name in the format it occurs in the header field.
Section 3.4.2 of describes relaxed header
canonicalization. Its first step converts all header field names
from upper case to lower case. Field names are restricted to printable
ASCII (see section 3.6.8) so this case conversion
remains ASCII case conversion.
DKIM key records, described in section 3.6.1, do not contain domain
names, so there is no change to their specification.
DMARC defines a policy language that
domain owners can specify for the domain of the address in a
RFC5322.From header field.
Section 6.6.1 specifies, somewhat imprecisely, how IDNs in the
RFC5322.From address domain are to
be handled. That section is updated to say that all U-labels in
the domain are converted to A-labels before further processing.
Section 7.1 is similarly updated to say that all U-labels
in domains being handled are converted to A-labels before further processing.
DMARC policy records, described in sections 6.3 and 7.1, can contain e-mail
addresses in the rua and ruf tags.
Since a policy record can be used for both internationalized and
conventional mail, those addresses still have to be conventional addresses,
not internationalized addresses.
This document makes no request of IANA.
E-mail is subject to a vast range of threats and abuses.
This document attempts to slightly mitigate some of them but does
not, as far as the author knows, add any new ones.
The updates to SPF, DKIM, and DMARC are intended to allow the respective
specifications work as reliably on internationalized mail as they do on
ASCII mail, so that applications that use them, such as some kinds of
spam and phish filtering, can work more reliably on internationalized mail.
&RFC2119;
&RFC8174;
&RFC3629;
&RFC5890;
&RFC5891;
&RFC6376;
&RFC6530;
&RFC6531;
&RFC5322;
&RFC6532;
&RFC7208;
&RFC7489;
more editorial nits
editorial nits
remove dangling A-R reference, add more i18nish and security goodness
minor edits per Alexey
update references
Relaxed canon, Typos
First WG version