[dmarc-ietf] DMARC exceptions

[Douglas Foster <[e-mail]>]

DMARC is an imperfect tool, as evidenced by the mailing list problem, among
others.  DMARCbis has failed to integrate RFC7489 with RFC 7960, because it
provides no discussion of the circumstances where an evaluator should
override the DMARC result.  I believe DMARCbis needs a discussion about the
appropriate scope and characteristics of local policy.  I have developed an
initial draft of proposed language for that section, which appears below

Doug Foster


x. Exceptions / Local Policy

A DMARC disposition policy communicates the domain owner’s recommendation
for handling of messages which fail to authenticate.     By definition,
this recommendation cannot take into consideration the local interest of
specific receivers, or the specific flow path of any specific message.   As
a result, evaluators should anticipate the need to implement local policy
exceptions that override the DMARC recommended disposition when
appropriate.   These exceptions can be considered in two groups:   policy
overrides and authentication overrides.   This section discusses some
expected override scenarios, without intending to be comprehensive, so that
product implementers can create appropriate exception structures for these
and similar possible situations.

x.1 Policy Overrides

x.1.1 Override p=none

A disposition policy of “none” indicates that the domain owner suspects
that some evaluators may receive some legitimate and wanted messages which
lack authentication when received.   The evaluator may reasonably conclude
that its risk of allowing a message which maliciously impersonates the
domain is much greater than the risk of hindering a
legitimate-but-unauthenticated message from the domain.   In such cases,
the local policy will override p=none and handle the domain with
p=quarantine or p=reject.

x.1.2 Override missing PSL=Y

Some PSDs have implemented DMARC policies in accordance with RFC 9901,
without a PSL tag because that RFC assumed that organizational domain
determination would be provided by the PSL.   Particularly during the early
rollout of this specification, evaluators should use the PSL to identify
DMARC policies which are intended to be treated as PSL=Y even though the
PSD’s policy has not yet been updated to include the PSD=Y tag.

x.1.3 Override strict alignment

A domain may publish aspf=s or adkim=s incorrectly, which the evaluator
will detect when legitimate and wanted messages produce a DMARC Fail
result, even though they would produce Pass using relaxed alignment.   In
this case, the evaluator overrides the strict alignment rules in the
published policy and applies a local policy of relaxed alignment.

x.2 Authentication Overrides

An Authentication Override provides alternate authentication when a message
is acceptable but the DMARC algorithm produces a result of Fail.   To
ensure that the exception does not create a vulnerability, the rule should
include at least one verified identifier with a value that indicates the
trusted message source, often coupled with unverified identifiers with
specific values the further narrow scope of the rule.

x.2.1 Mailing List messages

Mailing Lists typically add content to the Subject or Body, and replace the
Mail From address, while forwarding a message.   As a result, the
RFC5322.From address of the author can no longer produce SPF Pass or DKIM
Pass.   If list messages are received directly, without secondary
forwarding, an exception rule can typically use the Mail From address of
the list coupled with a result of SPF Pass on that address.  If the message
is received after secondary forwarding, the rule might be based on a DKIM
signature matching the list domain and a List-ID header with the list
identity.   The specific parameters will vary based on the list
characteristics and the message flow between the list and the evaluator.

x.2.2 SPF Distrust

SPF Pass is designed on the assumption that a submitting server does not
have multiple tenant domains, or does not allow domain tenants to
impersonate each other.   Some shared tenancy environments have difficulty
ensuring that this assumption is valid, weakening trust in a result of
DMARC Pass based on SPF Pass.   When an evaluator has determined that
messages from a particular domain are reliably signed, and that the SPF
policy includes an environment with weak controls, the evaluator may
implement a local policy to reject or quarantine unsigned messages from
that domain, even if the messages produce SPF PASS

x.2.3 Non-malicious impersonators

Some legitimate network services provide services to individual clients
from many domains, and generate messages on behalf of those individual
clients using the client’s email address.   These messages fail DMARC
authentication because they originate outside control of the client’s
domain owner.  While the intent of DMARC is to encourage such services to
identify their email differently, not all legitimate senders have done
so.   As with Mailing List messages, an evaluator will typically need to
replace DMARC authentication with a local policy which allows the message
based on Mail From address, SPF Pass, and the acceptable RFC5322.From
domains to which the rule applies.