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: [email protected] 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 <[email protected]> wrote: > On Sun, Mar 31, 2024 at 3:28 PM Richard Clayton <[email protected]> > wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> In message <CAOZAAfP9tXi80Fi=ZkgPpGwHo1fDbdSOZwVcnuPDbbc2xQd- >> [email protected]>, Seth Blank <[email protected]> >> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
