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

["Murray S. Kucherawy" <[e-mail]>]

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