Re: [dmarc-ietf] DMARCbis WGLC - Issue 135 - What To Say About Too-Permissive/Third-Party SPF and Where To Say It?

[John Levine <[e-mail]>]

Tightened up a little, reworded in view of the fact that your own
mail provider (M*r*s*ft) may let people spoof you through shared IP ranges.


>11.X  External Mail Sender Cross-Domain Forgery

Add this to 11.1 Authentication Methods


Both of the email authentication methods that underlie DMARC provide
some assurance that an email was transmitted by an MTA which is
authorized to do so. SPF policies map domain names to sets of
authorized MTAs [ref to RFC 7208, section 11.4]. Verified DKIM
signatures indicate that an email was transmitted by an MTA with
access to a private key that matches the published DKIM key record.

Whenever mail is sent, there is a risk that an overly permissive source
may send mail which will receive a DMARC pass result that was not, in
fact, authorized by the Domain Owner. These false positives may lead
to issues when systems interpret DMARC pass results to indicate
a message is in some way authentic. They also allow such unauthorized
senders to evade the Domain Owner's requested message handling for
authentication failures.

The only method to avoid this risk is to ensure that no unauthorized
source can add DKIM signatures to the domain's mail or transmit mail
which will evaluate as SPF pass. If nonetheless domain owner wishes to
include a permissive source in a domain's SPF record, the source can
be excluded from DMARC consideration by using the '?' qualifier on the
SPF record mechanism associated with that source.

R's,
John