One item left out of Seth’s text is that due to MBPs who act in this fashion, these SPF evaluation failures will (understandably) not show up in DMARC reports, and the domain owner may not have visibility for these failures. However, the text also puts the onus on the domain owner instead of the MBP. The text could be altered to instead suggest that MBPs who deploy DMARC should not utilize the outcome of SPF in this fashion. If the domain owner wants to protect their domain, and has no idea if the MBP supports DMARC properly (presuming they also have an enforcing policy), is it more or less advisable to use “-all” with your SPF record?
I’d be curious to see the Venn diagram of MBPs who implement SPF in this fashion, and also fully support DMARC. I feel like the MBPs who I’ve encountered deploying an SPF check in this way had not at the time supported DMARC. -- Alex Brotman Sr. Engineer, Anti-Abuse & Messaging Policy Comcast From: dmarc <dmarc-boun...@ietf.org> On Behalf Of Seth Blank Sent: Sunday, March 31, 2024 7:38 PM To: Murray S. Kucherawy <superu...@gmail.com> Cc: dmarc@ietf.org Subject: 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: s...@valimail.com<mailto:s...@valimail.com> [https://hosted-packages.s3.us-west-1.amazonaws.com/Valimail+Logo.png] 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 <superu...@gmail.com<mailto:superu...@gmail.com>> wrote: On Sun, Mar 31, 2024 at 3:28 PM Richard Clayton <rich...@highwayman.com<mailto:rich...@highwayman.com>> wrote: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In message <CAOZAAfP9tXi80Fi=ZkgPpGwHo1fDbdSOZwVcnuPDbbc2xQd- 7...@mail.gmail.com<mailto:7...@mail.gmail.com>>, Seth Blank <seth=40valimail....@dmarc.ietf.org<mailto:40valimail....@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<mailto:dmarc@ietf.org> https://www.ietf.org/mailman/listinfo/dmarc<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/dmarc__;!!CQl3mcHX2A!Er4si3rg3N5KnUebouOY2UdPZYKtSg5FWlKPTfAyMdBbEvZxLikFJWUDCbbyQXGMsefJCNIeeWWHe-T1FcHrYkCzX7CZsYzpt6k$>
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
