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

[Alessandro Vesely <[e-mail]>]

On Mon 18/Mar/2024 21:37:02 +0100 Scott Kitterman wrote:
> On March 18, 2024 6:40:54 PM UTC, Alessandro Vesely <[e-mail]> wrote:
>>On Mon 18/Mar/2024 09:14:26 +0100 Dotzero wrote:
>>> On Mon, Mar 18, 2024 at 2:38 AM John R Levine <[e-mail]> wrote:
>>>> On Sun, 17 Mar 2024, Dotzero wrote:
>>>>>> 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..
>>>> 
>>>> Seems to me we it depends on what you think "authorized" means.  My sense is I told you it's OK to send the message, yours seme to be that any host on an IP in the SPF record or anyone who steals your DKIM key is authorized by definition.
>>>> 
>>>> Is there some other wording that can make the difference clear?
>>> 
>>> Here's a quick stab at some modified wording for the second paragraph:
>>> 
>>> 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, intended by the Domain Owner. These results 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 intended message handling for
>>> authentication failures.
>>
>>
>>That's better.  At least it's formally correct.  Still, it is rather obscure for an average reader.
>>
>>The attempt to make this issue general, in the sense that it is valid for SPF and DKIM alike, makes no sense.  Stealing a DKIM key is not comparable to an overly permissive SPF record.
>>
>>The text should be terser and clearer, possibly with an example.
>
> No one said anything about stealing a DKIM key.


"anyone who steals your DKIM key is authorized by definition"
https://mailarchive.ietf.org/arch/msg/dmarc/h_ytb51KHHkQTyCMfGMs9NPXmQo


Best
Ale
--