No one has demonstrated that if someone has implemented SPF (RFC 7208) without worrying about DMARC that there are any associated problems for DMARC. Anything else about SPF is out of scope for this working group.
Scott K On Tuesday, February 9, 2021 10:13:37 PM EST Douglas Foster wrote: > The chairs can introduce another topic whenever they want. This does not > seem like a pre-requisite to any of the other pending topics. > > My interest is interoperability: We want recipient requirements and > sender compliance measures to align. > > RFC 7208 says that recipients MAY want to use SPF HELO and SPF MAILFROM > together. An argument can be made that this is not necessary: SPF > MAILFROM shows that the server is authorized to send messages for the > specific domain in the MAILFROM, while SPF HELO says only that the server > is authorized to send message for the server domain and an unknowable set > of other domains. Therefore a PASS from SPF MAILFROM should make SPF HELO > unnecessary and redundant. Does either the DMARC document or the SPF > document say this anywhere? > > RFC 7208 can be misunderstood to suggest that SPF MAILFROM and SPF HELO are > equivalent and interchangeable, which they are not, for the reason just > mentioned. Shouldn't we also make this clear? > > Senders are motivated to ensure that their mail is delivered, which makes > them interested in all of the factors which can maximize delivery and > minimize rejection. SPF HELO might be one of those reasons. Do we > mention this as an additional measure that senders might want to consider, > or do we keep silent? > > Todd's assertion is that SPF HELO will cause an excessive number of false > positives. I share Todd's expectation that this will be true, but I have > no data on that point yet. I am just beginning to collect that data, > because it seems like an interesting question. > > A second assumption is that no significant recipients are evaluating SPF > MAILFROM and SPF HELO together in a way that would be of interest to > senders. This may also be true, but I don't think this is something that > can be tested. > > A third assumption is that the current behavior related to SPF HELO will > continue indefinitely. > > To maximize interoperability: > - Recipients can be encouraged to ignore SPF HELO as unnecessary and the > likely source of false positives. > - Senders can be encouraged to ensure SPF HELO compliance to prevent false > positives. > > That interoperability outcome seems worth some comment in our final > document, since it created the confusion that led to ticket #1. > > The original question and these comments are exclusively about the SPF side > of the DMARC evaluation, which presumes that the DKIM signature is missing > or invalid. I was neither proposing a new block algorithm nor proposing a > new allow algorithm. But I do think that we need to anticipate how people > are likely to use our documents, with the goal of minimizing incompatible > interpretations. Ale's question demonstrates that such interpretation > problems are possible, even on a small and well-informed sample set. > > DF > > DF > > On Mon, Feb 8, 2021 at 9:50 AM Todd Herr <todd.herr= > > 40valimail....@dmarc.ietf.org> wrote: > > On Sun, Feb 7, 2021 at 7:35 AM Douglas Foster < > > > > dougfoster.emailstanda...@gmail.com> 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:* todd.h...@valimail.com > > *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 > > dmarc@ietf.org > > https://www.ietf.org/mailman/listinfo/dmarc _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
