On Sun, Feb 7, 2021 at 7:35 AM Douglas Foster < [email protected]> wrote:
> "We have a lot of other topics" is the wrong reason to call for > consensus. The important question is "Ale, have we addressed your > concerns?" > > I agree with many that for DMARC, our primary interest is whether SPF > validation of MAILFROM produces a PASS. > That's only partially correct. For DMARC, the SPF validation of MAILFROM must produce a PASS and the identifier must align with the RFC5322.From header domain. Absent both the PASS verdict and the alignment, the <policy_evaluated> section of the aggregate report will show "fail" for SPF, even if the <results> bit of the <auth_results> section shows "pass" in the <spf> sub-section. > However, I also see that a cautious recipient may choose to also require > SPF HELO = PASS and / or fcDNS HELO = PASS ( VERIFIED ). Getting a PASS > on these multiple criteria increases the confidence in the PASS result, but > also increases the likelihood of ambiguous results and false rejects. > Therefore: > - Recipients need to be cautious about enforcing rules so strictly that > sender configuration errors produce unwanted disposition decisions. > - Senders need to be careful to ensure that they configure their policy > to produce both SPF MAILFROM = PASS and SPF HELO=PASS. > The likelihood of a HELO identifier both passing an SPF check and aligning with the RFC5322.From identifier is, I would venture, so small as to be immeasurable for shared services such as ESPs, mailing list servers, and the like. Perhaps they could eventually be convinced of a need to publish SPF records, but that wouldn't do much of anything to change the <policy_evaluated> results for DMARC. Getting an SPF pass verdict alone for these identifiers isn't enough to alter the DMARC validation results; the identifiers must align, too. From a practical standpoint, I don't believe SPF MAILFROM=pass/SPF EHLO=fail would be useful information to mailbox providers for the significant volume of mail routing to their customers from shared services; I get quite a lot of such mail to my Gmail mailbox each day, wanted mail that is correctly routed to my Inbox. Beyond all that, though, SPF can fail for both the MAILFROM and the EHLO identifier on any given message, but if the message is DKIM signed in a way that aligns with the RFC5322.From domain and the DKIM validation check passes, then the message will correctly be described as having gotten a DMARC pass verdict. We've spent quite a lot of time on this list discussing authentication checks that can, by themselves, result in a DMARC pass verdict, but that cannot, by themselves, result in a DMARC fail verdict. A message has to fail SPF validation/alignment checks and DKIM validation/alignment checks in order to fail DMARC. I am not suggesting that the DMARC spec be updated to require that both SPF and DKIM both pass and align in order for DMARC to pass, because while I believe it to be best practice for senders to align both SPF and DKIM identifiers, I believe it would cause too much breakage in existing running code and sender configurations to be worth it to mandate such things. > Altogether, I think some wordsmithing is needed to communicate those > points. I do not have such wording at this moment, but will begin > thinking about what I would propose. Perhaps those who are anxious to > move on will be able to produce text sooner. > > I have also raised a concern about the inadequacy of reporting these > results, since "Recevied-SPF: pass" is currently a compliant header. We > can defer this issue to a later ticket, but we need to be thinking about > the problem. If this requires no change, I would like some discussion of > why that might be the case. > > > What the message recipient does with all this authentication information is left as a local policy decision, a decision that is likely to be made using more data points than just the SPF, DKIM, and DMARC validation verdicts. The DMARC spec does not mandate that a message passing DMARC checks be accepted, nor does it mandate that a message failing DMARC checks be rejected, even in the relevant policy published by the domain owner is "p=reject", and I am absolutely not suggesting that the DMARC spec be written in such a way as to mandate such behaviors. In my opinion, the text that should appear in the DMARC spec to sum up these points is "A DMARC pass verdict means only that the message can be reliably associated by the recipient with the identity on which the DMARC validation check was performed, and a DMARC fail verdict means that it cannot be so associated." -- *Todd Herr* | Sr. Technical Program Manager *e:* [email protected] *p:* 703.220.4153 ` 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.
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
