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

[Dotzero <[e-mail]>]

On Sun, Mar 17, 2024 at 9:36 PM John Levine <[e-mail]> wrote:

> 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.
>

I have a problem with this 2nd paragraph and believe it is factually
incorrect. The Domain Owner has in fact authorized the message(s) as a
result of an overly permissive approach. I would suggest that in fact any
resulting DMARC pass is technically NOT a false positive because it is
authorized by the overly permissive approach..

Michael Hammer