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

[Scott Kitterman <[e-mail]>]

On March 18, 2024 3:15:42 AM UTC, "Murray S. Kucherawy" <[e-mail]> wrote:
>On Mon, Mar 18, 2024 at 1:08 PM Dotzero <[e-mail]> wrote:
>
>>
>> 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..
>>
>>
>It's a false positive in the sense that the result is not what the Domain
>Owner probably wanted to have happen.
>
>It is not a false positive in that the technology did exactly what it was
>supposed to do; i.e., this is not a bug.
>
>We should just be clear about this.
>
>-MSK, p11g

I agree.  I think John's proposed text is appropriate for this.

Scott K