Draft: draft-ietf-dmarc-dmarcbis-01

Commentary: Sanity check and streamlining of document
DMARC permits the owner of an email author's domain name to enable
validation of the domain's use, to indicate the implication of failed
validation, and to request reports about use of the domain name.
Mail receiving organizations can use this information when evaluating
handling choices for incoming mail.
DMARC permits the owner of an email author's domain name to enable
validation of the domain's use, to indicate the Domain Owner's
severity of concern regarding failed validation, and to request
reports about use of the domain name.  Mail receiving organizations
can use this information when evaluating handling choices for
incoming mail.
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.
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.
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,
state their level of concern 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 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
severity of concern expresed by the Domain Owner for authentication
failures 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.
Email authentication technologies authenticate various (and
disparate) aspects of an individual message.  For example, RFC6376
authenticates the domain that affixed a signature to the message,
while RFC7208 can authenticate either the domain that appears in the
RFC5321.MailFrom (MAIL FROM) portion of RFC5322 or the RFC5321.EHLO/
HELO domain, or both.  These may be different domains, and they are
typically not visible to the end user.
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.
Email authentication technologies authenticate various (and
disparate) aspects of an individual message.  For example, DKIM
RFC6376 authenticates the domain that affixed a signature to the
message, while SPF RFC7208 can authenticate either the domain that
appears in the RFC5321.MailFrom (MAIL FROM) portion of RFC5322 or the
RFC5321.EHLO/ HELO domain, or both.  These may be different domains,
and they are typically not visible to the end user.
DMARC authenticates use of the RFC5322.From domain by requiring that
it have the same Organizational Domain (be aligned with) as 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.
Each of the underlying authentication technologies that DMARC takes
as input yields authenticated domains as their outputs when they
succeed.
DMARC requires Identifier Alignment based on the result of a DKIM
authentication because a message can bear a valid signature from any
domain, including domains used by a mailing list or even a bad actor.
Therefore, merely bearing a valid signature is not enough to infer
authenticity of the Author Domain.
To illustrate, 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".  However, a DKIM
signature bearing a value of "d=com" would never allow an "in
alignment" result, as "com" should appear on all public suffix lists
(see public-suffix-lists) and therefore cannot be an Organizational
Domain.
Note that a single email can contain multiple DKIM signatures, and it
is considered to be a DMARC "pass" if any DKIM signature is aligned
and verifies.
DMARC permits Identifier Alignment based on the result of an SPF
authentication.  As with DKIM, Identifier Alignement is determined
based on whether or not two domain's Organizational Domains are the
same.
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" because they have the same Organizational Domain
("example.com").
The reader should note that SPF alignment checks in DMARC rely solely
on the RFC5321.MailFrom domain.  This differs from section 2.3 of
RFC7208, which recommends that SPF checks be done on not only the
"MAIL FROM" but also on a separate check of the "HELO" identity.
In addition to Mediators, mail that is sent by authorized,
independent third parties might not be sent with Identifier
Alignment, also preventing a "pass" result.
Issues specific to the use of policy mechanisms alongside DKIM are
further discussed in RFC6377, particularly Section 5.2.
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.
DMARC's filtering function is based on whether the RFC5322.From
domain is aligned with (has the same Organizational Domain as) 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.
DMARC's feedback component involves the collection of information
about received messages claiming to be from the Organizational Domain
for periodic aggregate reports to the Domain Owner.  The parameters
and format for such reports are discussed in later sections of this
document.
DMARC's feedback component involves the collection of information
about received messages claiming to be from the Organizational Domain
for periodic aggregate reports to the Domain Owner.  The parameters
and format for such reports are discussed in another document.
Put simply, when a message reaches a DMARC-aware rMTA, a DNS query
will be initiated to determine if the author domain has published a
DMARC policy.  If a policy is found, the rMTA will use the results of
SPF and DKIM validation checks to determine the ultimate DMARC
authentication status.  The DMARC status can then factor into the
message handling decision made by the recipient's mail sytsem.
More details on specific actions for the parties involved can be
found in domain-owner-actions and mail-receiver-actions.
A Domain Owner advertises DMARC participation of one or more of its
domains by adding a DNS TXT record (described in dmarc-policy-record)
to those domains.  In doing so, Domain Owners make specific requests
of Mail Receivers regarding the handling of messages purporting to be
from one of the Domain Owner's domains and the provision of feedback
about those messages.
A Domain Owner advertises DMARC participation of one or more of its
domains by adding a DNS TXT record (described in dmarc-policy-record)
to those domains.  In doing so, Domain Owners indicate their severity
of concern regarding failed authentication for email messages making
use of their domain in the RFC5322.From header field as well as the
provision of feedback about those messages.  Mail Receivers in turn
can take into account the Domain Owner's severity of concern when
making handling decisions about email messages that fail DMARC
authentication checks.
Question: Does removal of a tag or tags, as proposed through other
tickets, constitute "a change to any existing tags", thus requiring
"a new version of DMARC"?
This section describes Domain Owner actions to fully implement the
DMARC mechanism.
Because DMARC relies on SPF RFC7208 and DKIM RFC6376, in order to
take full advantage of DMARC, a Domain Owner SHOULD first ensure that
SPF and DKIM authentication are properly configured.  The easiest
first step here is to choose a domain to use as the RFC5321.From
domain (i.e., the Return-Path domain) for its mail, one that aligns
with the Author Domain, and then publish an SPF policy in DNS for
that domain.
While it is possible to secure a DMARC pass verdict based on only SPF
or DKIM, it is commonly accepted best practice to ensure that both
authentication mechanisms are in place in order to guard against
failure of just one of them.  The Domain Owner SHOULD choose as a
DKIM-Signing domain (i.e., the d= domain in the DKIM-Signature
header) that aligns with the Author Domain and configure its system
to sign using that domain.
Proper consumption and analysis of DMARC aggregate reports is the key
to any successful DMARC deployment for a Domain Owner.  DMARC
aggregate reports, which are XML documents, contain valuable data for
the Domain Owner, showing sources of mail using the Author Domain.
Depending on how mature the Domain Owner's DMARC rollout is, some of
these sources could be legitimate ones that were overlooked during
the intial deployment of SPF and/or DKIM.
Because the aggregate reports are XML documents, it is strongly
advised that they be machine-parsed, so setting up a mailbox involves
more than just the physical creation of the mailbox.  Many third-
party services exist that will process DMARC aggregate reports, or
the Domain Owner can create its own set of tools.  No matter which
method is chosen, the ability to parse these reports and consume the
data contained in them will go a long way to ensuring a successful
deployment.
Once SPF, DKIM, and the aggregate reports mailbox are all in place,
it's time to publish a DMARC record.  For best results, Domain Owners
SHOULD start with "p=none", with the rua tag containg the mailbox
created in the previous step.
The reason for starting at "p=none" is to ensure that nothing's been
missed in the initial SPF and DKIM deployments.  In all but the most
trivial setups, it is possible for a Domain Owner to overlook a
server here or be unaware of a third party sending agreeement there.
Starting at "p=none", therefore, takes advantage of DMARC's aggregate
reporting function, with the Domain Owner using the reports to audit
its own mail streams.  Should any overlooked systems be found in the
reports, the Domain Owner can adjust the SPF record and/or configure
DKIM signing for those systems.
Once the Domain Owner is satisfied that it is properly authenticating
all of its mail, then it is time to decide if it is appropriate to
change the p= value in its DMARC record to p=quarantine or p=reject.
Depending on its cadence for sending mail, it may take many months of
consuming DMARC aggregate reports before a Domain Owner reaches the
point where it is sure that it is properly authenticating all of its
mail, and the decision on which p= value to use will depend on its
needs.
In order to be processed by DMARC, a message typically needs to
contain exactly one RFC5322.From domain (a single From: field with a
single domain in it).  Not all messages meet this requirement, and
the handling of those that are forbidden under RFC 5322 RFC5322 or
that contain no meaningful domains is outside the scope of this
document.
The case of a syntactically valid multi-valued RFC5322.From header
field presents a particular challenge.  When a single RFC5322.From
header field contains multiple addresses, it is possible that there
may be multiple domains used in those addresses.  The process in this
case is to only proceed with DMARC checking if the domain is
identical for all of the addresses in a multi-valued RFC5322.From
header field.  Multi-valued RFC5322.From header fields with multiple
domains MUST be exempt from DMARC checking.
For a Domain Owner, DMARC aggregate reports provide data about all
mailstreams making use of its domain in email, to include not only
illegitimate uses but also, and perhaps more importantly, all
legitimate uses.  Domain Owners can use aggregate reports to ensure
that all legitimate uses of their domain for sending email are
properly authenticated, and once they are, increase the severity of
concern expressed in the p= tag in their DMARC policy records from
none to quarantine to reject, if appropriate.  In turn, DMARC policy
records with p= tag values of 'quarantine' or 'reject' are higher
value signals to Mail Receivers, ones that can assist Mail Receivers
with handling decisions for a message in ways that p= tag values of
'none' cannot.
In order to ensure maximum usefulness for DMARC across the email
ecosystem, then, Mail Receivers MUST generate and send aggregate
reports with a frequency of at least once every 24 hours.
Mail Receivers MAY choose to accept email that fails the DMARC
mechanism check even if the Domain Owner has published a "reject"
policy.  Mail Receivers need to make a best effort not to increase
the likelihood of accepting abusive mail if they choose not to comply
with a Domain Owner's reject, against policy.  At a minimum, addition
of the Authentication-Results header field (see RFC8601) is
RECOMMENDED when delivery of failing mail is done.  When this is
done, the DNS domain name thus recorded MUST be encoded as an
A-label.
Mail Receivers are only obligated to report reject or quarantine
policy actions in aggregate feedback reports that are due to DMARC
policy.  They are not required to report reject or quarantine actions
that are the result of local policy.  If local policy information is
exposed, abusers can gain insight into the effectiveness and delivery
rates of spam campaigns.
Mail Receivers MAY choose to accept email that fails the DMARC
mechanism check even if the published Domain Owner Assessment Policy
is "reject".  Mail Receivers need to make a best effort not to
increase the likelihood of accepting abusive mail if they choose not
to honor the published Domain Owner Assessment Policy.  At a minimum,
addition of the Authentication-Results header field (see RFC8601) is
RECOMMENDED when delivery of failing mail is done.  When this is
done, the DNS domain name thus recorded MUST be encoded as an
A-label.
Mail Receivers are only obligated to report reject or quarantine
policy actions in aggregate feedback reports that are due to
published DMARC Domain Owner Assessment Policy.  They are not
required to report reject or quarantine actions that are the result
of local policy.  If local policy information is exposed, abusers can
gain insight into the effectiveness and delivery rates of spam
campaigns.
Mail Receivers SHOULD also implement reporting instructions of DMARC,
even in the absence of a request for DKIM reporting RFC6651 or SPF
reporting RFC6652.  Furthermore, the presence of such requests SHOULD
NOT affect DMARC reporting.
Mail Receivers MUST also implement reporting instructions of DMARC,
even in the absence of a request for DKIM reporting RFC6651 or SPF
reporting RFC6652.  Furthermore, the presence of such requests SHOULD
NOT affect DMARC reporting.
Domain owners, mediators, and mail receivers can all claim to
implement DMARC, but what that means will depend on their role in the
transmission of mail.  To remove any ambiguity from the claims, this
document specifies the following minimum criteria that must be met
for each agent to rightly claim to be "implementing DMARC".
While 'none' is a syntactically valid value for both the p and sp
tags, the practical value of either the p tag or sp tag being 'none'
means that the Domain Owner is still gathering information about mail
flows for the domain or sub-domains.  It is not yet ready to commit
to conveying a severity of concern for unauthenticated email using
its domain.
The Organizational Domain administrator should be careful not to
delegate control of subdomains if this is an issue.