I believe that most code is validating the MailFrom parameter if it is supplied, and validating the HELO name only if MAILFROM is null. This is based mostly on the way SPF has been discussed over the last 15 years, coupled with the observed behavior of a limited number of product implementations..
If we are to argue that HELO and MAILFROM tests are interchangeable, we have to deal with the situation where the domains are different and the results are different. SPF has 7 possible results, so there are 49 possible combinations of these two tests, 42 of which are divergent. (If we factor in NXDOMAIN as a separate result, which even RFC 7208 says is probably appropriate for HELO, the number of divergent results is even greater.) To merge the tests, we would need to define a winning result for all of the divergent result pairs, and then demonstrate that our winning result can be considered appropriate for all installations. Such an undertaking has not been attempted, and I cannot imagine it achieving consensus. The result needed for DMARC is the result I believe is actually being produced by most installations: The result is evaluated based on MAILFROM when it is not null, and evaluated using HELO domain when MAILFROM is null. Of course, using HELO as a proxy for MAILFROM only works for bounce messages being returned from installations hosting a single mail domain on a matching host domain. For everyone else, DMARC will only verify automatic messages that are signed with the From address domain. The DMARC specification should make this clear to the reader. - - - To correct an earlier comment of mine: fcDNS on HELO and SPF HELO tests can be used together quite effectively. fcDNS validates that the server is reporting a valid host name, limits the allowed results to a single DNS domain, and demonstrates that the domain being used for SPF HELO is the correct one. However, fcDNS does not demonstrate that the server is authorized to send mail. SPF defines the servers which are allowed to send mail for the domain, but may include IP addresses from other domains, either directly or through Include clauses. When the host name is verified with both fcDNS and SPF HELO, the evaluator knows that the server is in the reported domain and authorized by that domain to send mail. Note that this is also different from fcDNS on the Reverse DNS name, as reported with the "iprev" test result. We really do not have a way to report test results for the HELO name. It would seem desireable to add test result indicators for both fcDNS HELO and fcDNS SPF. Doug Foster . On Tue, Feb 2, 2021 at 2:54 PM John R Levine <jo...@taugh.com> wrote: > >> There is some commented out code to not pass a HELO result to DMARC, > don't > >> remember why I turned it off. > > > > I’m lost in a double negative here: did you turn off passing a HELO > result to > > DMARC, or did you turn off not passing a HELO result? > > The live code uses whichever result it has. The commented out code only > used a MAIL FROM result. > > >> Again, I believe this is typical of what DMARC validators do. It's > >> existing practice and I see no reason to change it. Can we stop now? > > > > If you found that you needed to turn off something that’s part of the > DMARC > > spec, it would be good to understand why. > > I believe that what I am doing matches the spec. > > Regards, > John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. https://jl.ly > _______________________________________________ > 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
