Draft: draft-ietf-dmarc-dmarcbis-01

Commentary: Undid removal of references to RFC5322.From . We 'll worry about that when RFC5322bis is released .
The Sender Policy Framework (RFC7208) and DomainKeys Identified Mail
(RFC6376) protocols provide domain-level authentication which is not
directly associated with the domain in the visible From: header, and
DMARC builds on those protocols.  Using DMARC, Domain Owners that
originate email can publish a DNS TXT record with their email
authentication policies, preferred handling for mail that fails
authentication checks, and request reports about email use of the
domain name.
As with SPF and DKIM, DMARC authentication checks result in verdicts
of "pass" or "fail".  A DMARC pass verdict requires not only that SPF
or DKIM pass for the message in question, but also that the domain
validated by the SPF or DKIM check is aligned with the domain in the
visible From: header.  In the DMARC protocol, two domains are said to
be "in alignment" if they have the same Organizational Domain
(a.k.a., relaxed alignment) or they are identical (a.k.a., strict
alignment).
A DMARC pass result indicates only that the domain in the visible
From: header has been authenticated in that message; there is no
explicit or implied value assertion attributed to a message that
receives such a verdict.  A mail-receiving organization that performs
a DMARC validation check on inbound mail can choose to use the result
and the published assessment by the originating domain for message
handling to inform its mail handling decision for that message.  For
a mail-receiving organization supporting DMARC, a message that passes
validation is part of a message stream that is reliably associated
with the domain owner.  Therefore reputation assessment of that
stream by the mail-receiving organization does not need to be
encumbered by accounting for unauthorized use of the domain.  A
message that fails this validation cannot reliably be associated with
the aligned domain and its reputation.
The Sender Policy Framework (RFC7208) and DomainKeys Identified Mail
(RFC6376) protocols provide domain-level authentication which is not
directly associated with the RFC5322.From domain, and DMARC builds on
those protocols.  Using DMARC, Domain Owners that originate email can
publish a DNS TXT record with their email authentication policies,
preferred handling for mail that fails authentication checks, and
request reports about email use of the domain name.
As with SPF and DKIM, DMARC authentication checks result in verdicts
of "pass" or "fail".  A DMARC pass verdict requires not only that SPF
or DKIM pass for the message in question, but also that the domain
validated by the SPF or DKIM check is aligned with the RFC5322.From
domain.  In the DMARC protocol, two domains are said to be "in
alignment" if they have the same Organizational Domain (a.k.a.,
relaxed alignment) or they are identical (a.k.a., strict alignment).
A DMARC pass result indicates only that the RFC5322.From domain has
been authenticated in that message; there is no explicit or implied
value assertion attributed to a message that receives such a verdict.
A mail-receiving organization that performs a DMARC validation check
on inbound mail can choose to use the result and the published
assessment by the originating domain for message handling to inform
its mail handling decision for that message.  For a mail-receiving
organization supporting DMARC, a message that passes validation is
part of a message stream that is reliably associated with the domain
owner.  Therefore reputation assessment of that stream by the mail-
receiving organization does not need to be encumbered by accounting
for unauthorized use of the domain.  A message that fails this
validation cannot reliably be associated with the aligned domain and
its reputation.
DMARC does not attempt to solve all problems with spoofed or
otherwise fraudulent email.  In particular, it does not address the
use of visually similar domain names ("cousin domains") or abuse of
the visible From: header human-readable <display-name>.
DMARC does not attempt to solve all problems with spoofed or
otherwise fraudulent email.  In particular, it does not address the
use of visually similar domain names ("cousin domains") or abuse of
the RFC5322.From human-readable <display-name>.
DMARC authenticates use of the visible From: header domain by
requiring that it match (be aligned with) an Authenticated
Identifier.  The visible From: header domain was selected as the
central identity of the DMARC mechanism because it is a required
message header field and therefore guaranteed to be present in
compliant messages, and most Mail User Agents (MUAs) represent the
visible From: header field as the originator of the message and
render some or all of this header field's content to end users.
DMARC authenticates use of the RFC5322.From domain by requiring that
it match (be aligned with) an Authenticated Identifier.  The
RFC5322.From domain was selected as the central identity of the DMARC
mechanism because it is a required message header field and therefore
guaranteed to be present in compliant messages, and most Mail User
Agents (MUAs) represent the RFC5322.From header field as the
originator of the message and render some or all of this header
field's content to end users.
It is important to note that Identifier Alignment cannot occur with a
message that is not valid per RFC5322, particularly one with a
malformed, absent, or repeated visible From: header field, since in
that case there is no reliable way to determine a DMARC policy that
applies to the message.  Accordingly, DMARC operation is predicated
on the input being a valid RFC5322 message object, and handling of
such non-compliant cases is outside of the scope of this
specification.  Further discussion of this can be found in extract-
author-domain.
It is important to note that Identifier Alignment cannot occur with a
message that is not valid per RFC5322, particularly one with a
malformed, absent, or repeated RFC5322.From header field, since in
that case there is no reliable way to determine a DMARC policy that
applies to the message.  Accordingly, DMARC operation is predicated
on the input being a valid RFC5322 message object, and handling of
such non-compliant cases is outside of the scope of this
specification.  Further discussion of this can be found in extract-
author-domain.
Each of the underlying authentication technologies that DMARC takes
as input yields authenticated domains as their outputs when they
succeed.  From the perspective of DMARC, each can be operated in a
"strict" mode or a "relaxed" mode.  A Domain Owner would normally
select strict mode if it wanted Mail Receivers to apply DMARC
processing only to messages bearing an visible From: header domain
exactly matching the domains those mechanisms will verify.  Relaxed
mode can be used when the operator also wishes to affect message
flows bearing subdomains of the verified domains.
Each of the underlying authentication technologies that DMARC takes
as input yields authenticated domains as their outputs when they
succeed.  From the perspective of DMARC, each can be operated in a
"strict" mode or a "relaxed" mode.  A Domain Owner would normally
select strict mode if it wanted Mail Receivers to apply DMARC
processing only to messages bearing an RFC5322.From domain exactly
matching the domains those mechanisms will verify.  Relaxed mode can
be used when the operator also wishes to affect message flows bearing
subdomains of the verified domains.
In relaxed mode, the Organizational Domains of both the RFC6376-
authenticated signing domain (taken from the value of the "d=" tag in
the signature) and that of the visible From: header domain must be
equal if the identifiers are to be considered aligned.  In strict
mode, only an exact match between both of the Fully Qualified Domain
Names (FQDNs) is considered to produce Identifier Alignment.
To illustrate, in relaxed mode, if a validated DKIM signature
successfully verifies with a "d=" domain of "example.com", and the
visible From: header address is "alerts@news.example.com", the DKIM
"d=" domain and the visible From: header domain are considered to be
"in alignment".  In strict mode, this test would fail, since the "d="
domain does not exactly match the FQDN of the address.
In relaxed mode, the Organizational Domains of both the RFC6376-
authenticated signing domain (taken from the value of the "d=" tag in
the signature) and that of the RFC5322.From domain must be equal if
the identifiers are to be considered aligned.  In strict mode, only
an exact match between both of the Fully Qualified Domain Names
(FQDNs) is considered to produce Identifier Alignment.
To illustrate, in relaxed mode, if a validated DKIM signature
successfully verifies with a "d=" domain of "example.com", and the
RFC5322.From address is "alerts@news.example.com", the DKIM "d="
domain and the RFC5322.From domain are considered to be "in
alignment".  In strict mode, this test would fail, since the "d="
domain does not exactly match the FQDN of the address.
In relaxed mode, the RFC7208-authenticated domain and visible From:
header domain must have the same Organizational Domain.  In strict
mode, only an exact DNS domain match is considered to produce
Identifier Alignment.
For example, if a message passes an SPF check with an
RFC5321.MailFrom domain of "cbg.bounces.example.com", and the address
portion of the visible From: header field contains
"payments@example.com", the Authenticated RFC5321.MailFrom domain
identifier and the visible From: header domain are considered to be
"in alignment" in relaxed mode, but not in strict mode.  In order for
the two identifiers to be considered "in alignment" in strict mode,
the domain parts would have to be identical.
In relaxed mode, the RFC7208-authenticated domain and RFC5322.From
domain must have the same Organizational Domain.  In strict mode,
only an exact DNS domain match is considered to produce Identifier
Alignment.
For example, if a message passes an SPF check with an
RFC5321.MailFrom domain of "cbg.bounces.example.com", and the address
portion of the RFC5322.From header field contains
"payments@example.com", the Authenticated RFC5321.MailFrom domain
identifier and the RFC5322.From domain are considered to be "in
alignment" in relaxed mode, but not in strict mode.  In order for the
two identifiers to be considered "in alignment" in strict mode, the
domain parts would have to be identical.
If in the future DMARC is extended to include the use of other
authentication mechanisms, the extensions will need to allow for
domain identifier extraction so that alignment with the visible From:
header domain can be verified.
If in the future DMARC is extended to include the use of other
authentication mechanisms, the extensions will need to allow for
domain identifier extraction so that alignment with the RFC5322.From
domain can be verified.
DMARC's filtering function is based on whether the visible From:
header field domain is aligned with (matches) an authenticated domain
name from SPF or DKIM.  When a DMARC policy is published for the
domain name found in the visible From: header field, and that domain
name is not validated through SPF or DKIM, the handling of that
message can be affected by that DMARC policy when delivered to a
participating receiver.
DMARC's filtering function is based on whether the RFC5322.From
domain is aligned with (matches) an authenticated domain name from
SPF or DKIM.  When a DMARC policy is published for the domain name
found in the RFC5322.From header field, and that domain name is not
validated through SPF or DKIM, the handling of that message can be
affected by that DMARC policy when delivered to a participating
receiver.
One of the most obvious points of security scrutiny for DMARC is the
choice to focus on an identifier, namely the visible From: header
address, which is part of a body of data that has been trivially
forged throughout the history of email.
The absence of a single, properly formed visible From: header field
renders the message invalid.  Handling of such a message is outside
of the scope of this specification.
One of the most obvious points of security scrutiny for DMARC is the
choice to focus on an identifier, namely the RFC5322.From address,
which is part of a body of data that has been trivially forged
throughout the history of email.
The absence of a single, properly formed RFC5322.From header field
renders the message invalid.  Handling of such a message is outside
of the scope of this specification.
A Mail Receiver implementing the DMARC mechanism SHOULD make a best-
effort attempt to adhere to the Domain Owner's published DMARC policy
when a message fails the DMARC test.  Since email streams can be
complicated (due to forwarding, existing visible From: header domain-
spoofing services, etc.), Mail Receivers MAY deviate from a Domain
Owner's published policy during message processing and SHOULD make
available the fact of and reason for the deviation to the Domain
Owner via feedback reporting, specifically using the "PolicyOverride"
feature of the aggregate report (see the DMARC reporting documents).
A Mail Receiver implementing the DMARC mechanism SHOULD make a best-
effort attempt to adhere to the Domain Owner's published DMARC policy
when a message fails the DMARC test.  Since email streams can be
complicated (due to forwarding, existing RFC5322.From domain-spoofing
services, etc.), Mail Receivers MAY deviate from a Domain Owner's
published policy during message processing and SHOULD make available
the fact of and reason for the deviation to the Domain Owner via
feedback reporting, specifically using the "PolicyOverride" feature
of the aggregate report (see the DMARC reporting documents).
Domain Owner DMARC preferences are stored as DNS TXT records in
subdomains named "_dmarc".  For example, the Domain Owner of
"example.com" would post DMARC preferences in a TXT record at
"_dmarc.example.com".  Similarly, a Mail Receiver wishing to query
for DMARC preferences regarding mail with an visible From: header
domain of "example.com" would issue a TXT query to the DNS for the
subdomain of "_dmarc.example.com".  The DNS-located DMARC preference
data will hereafter be called the "DMARC record".
Domain Owner DMARC preferences are stored as DNS TXT records in
subdomains named "_dmarc".  For example, the Domain Owner of
"example.com" would post DMARC preferences in a TXT record at
"_dmarc.example.com".  Similarly, a Mail Receiver wishing to query
for DMARC preferences regarding mail with an RFC5322.From domain of
"example.com" would issue a TXT query to the DNS for the subdomain of
"_dmarc.example.com".  The DNS-located DMARC preference data will
hereafter be called the "DMARC record".
The domain in the visible From: header field is extracted as the
domain to be evaluated by DMARC.  If the domain is encoded with UTF-
8, the domain name must be converted to an A-label, as described in
Section 2.3 of RFC5890, for further processing.
The case of a syntactically valid multi-valued visible From: header
field presents a particular challenge.  The process in this case is
to apply the DMARC check using each of those domains found in the
visible From: header field as the Author Domain and apply the most
strict policy selected among the checks that fail.
The domain in the RFC5322.From header field is extracted as the
domain to be evaluated by DMARC.  If the domain is encoded with UTF-
8, the domain name must be converted to an A-label, as described in
Section 2.3 of RFC5890, for further processing.
The case of a syntactically valid multi-valued RFC5322.From header
field presents a particular challenge.  The process in this case is
to apply the DMARC check using each of those domains found in the
RFC5322.From header field as the Author Domain and apply the most
strict policy selected among the checks that fail.
For example, an attacker who controls the SPF record for
"evil.example.com" can send mail with an visible From: header field
containing "foo@example.com" that can pass both authentication and
the DMARC check against "example.com".
For example, an attacker who controls the SPF record for
"evil.example.com" can send mail with an RFC5322.From header field
containing "foo@example.com" that can pass both authentication and
the DMARC check against "example.com".
A common attack in messaging abuse is the presentation of false
information in the display-name portion of the visible From: header
field.  For example, it is possible for the email address in that
field to be an arbitrary address or domain name, while containing a
well-known name (a person, brand, role, etc.) in the display name,
intending to fool the end user into believing that the name is used
legitimately.  The attack is predicated on the notion that most
common MUAs will show the display name and not the email address when
both are available.
A common attack in messaging abuse is the presentation of false
information in the display-name portion of the RFC5322.From header
field.  For example, it is possible for the email address in that
field to be an arbitrary address or domain name, while containing a
well-known name (a person, brand, role, etc.) in the display name,
intending to fool the end user into believing that the name is used
legitimately.  The attack is predicated on the notion that most
common MUAs will show the display name and not the email address when
both are available.