Re: [dmarc-ietf] SPF follies, WGLC editorial review of draft-ietf-dmarc-dmarcbis-30

It is a very common issue that companies want DMARC, but their security
teams believe an SPF hard fail is more secure, and then all sorts of actual
operational issues slam in. It ends up being lots of work to convince those
security teams otherwise.

I think it is desirable to state that this issue is known, and with respect
to DMARC a hard fail can have unintended consequences. Operationally for
DMARC, anything that is not an SPF pass is treated the same, so a hard fail
is not a stronger signal if you wish to implement DMARC with a policy that
is not none.

There are two M3AAWG documents that do call out explicit issues and best
practice, so I won’t push strongly that this should be in the document. But
since there’s already text that’s so close, why not update it to cover this
more explicitly?

S, participating, after just having this conversation the other week

Seth Blank | Chief Technology Officer
Email: seth@valimail.com

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.

On Sun, Mar 31, 2024 at 18:47 Murray S. Kucherawy <superuser@gmail.com>
wrote:

> On Sun, Mar 31, 2024 at 3:28 PM Richard Clayton <richard@highwayman.com>
> wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> In message <CAOZAAfP9tXi80Fi=ZkgPpGwHo1fDbdSOZwVcnuPDbbc2xQd-
>> 7A@mail.gmail.com>, Seth Blank <seth=40valimail.com@dmarc.ietf.org>
>> writes
>>
>> >    Some Mail Receiver architectures implement SPF in advance of any
>> >    DMARC operations. This means that an SPF hard fail ("-") prefix on
>> >    a sender's SPF mechanism, such as "-all", could cause that
>> >    rejection to go into effect early in handling, causing message
>> >    rejection before any DMARC processing takes place, and DKIM has a
>> >    chance to validate the message instead of SPF. Operators choosing
>> >    to use "-all" to terminate SPF records should be aware of this.
>>
>> I understood what this said thus far ... but I wonder what it is doing
>> in a document about DMARC.   Some architectures may reject email from
>> IPs listed in the PBL ... again nothing to do with DMARC. This isn't a
>> document on how to improve deliverability is it ?
>>
>
> I don't understand the link being made here between operational details
> and deliverability.  I understand this to be pointing out that if you do
> any short circuiting, DMARC can't be evaluated.  That includes any early
> rejection, be that based on SPF results, DKIM signature failures, domain
> reputation rejections, or anything of the sort.
>
> Mind you, I'm a little worried about anyone that plans to rely seriously
> on DMARC yet to whom this isn't relatively obvious.  You need those results
> before DMARC can even begin, and the DKIM result comes only after the body
> arrives.
>
> -MSK, p11g
> _______________________________________________
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>