Huh? Are you asserting that SPF MAILFROM and SPF HELO are interchangeable? They are not, but they can work together.
Some scenarios to illustrate: clientdomain.tld uses servers from hostingservice.tld the spf for hostingservice.tld allows only server "mail.hostingservice.tld" the spf ro clientdomain allows ANY server from hostingservice.tld Case 1 server= mail.hostingservice.tld SMTP = [email protected] FROM= [email protected] SPF HELO = PASS aligns with FROM, but this is not a valid alignment for DMARC PASS. Only SPF MAILFROM produces a correct result (SPF PASS but DMARC FAIL), because the client domain is not authorized to send messages for the hostingservice domain. Ergo: SPF HELO does not produce equivalent results to SPF MAILFROM Case 2 server = nonmail.hostingservice.tld SMTP = [email protected] FROM = [email protected] SPF MAILFROM = PASS and aligns with FROM, so it appears to be a DMARC PASS. But SPF HELO is a FAIL, because the SPF for HostingService.tld says that this server never sends mail. Ergo: SPF HELO can be used along with SPF MAILFROM to produce a more granular allow list then SPF MAILFROM alone. DF On Wed, Feb 10, 2021 at 9:43 AM Scott Kitterman <[email protected]> wrote: > No. Sigh. Let's try it again. > > Yes, one might actually use a HELO result for DMARC. It gives you the > same > result as if mail from is null. So what? > > No one has given us a case where an attacker could get a aligned SPF > result > based on HELO that they couldn't also get with mail from, so it doesn't > matter. > > By problem, I mean an actual problem. There aren't any. > > Scott K > > On February 10, 2021 9:49:46 AM UTC, Alessandro Vesely <[email protected]> > wrote: > >Just to clarify: > > > > > >On Wed 10/Feb/2021 05:19:38 +0100 Scott Kitterman wrote: > >> No one has demonstrated that if someone has implemented SPF (RFC > >7208) without > >> worrying about DMARC that there are any associated problems for > >DMARC. > > > > > >I think I did. OpenDMARC, for example, seems to read a single result, > >either > >Authentication-Results: or Received-SPF:, assuming that it contains the > >mfrom > >identity unless empty. Note that it has an option to disable SPF > >entirely, > >presumably as a means to tackle non-DMARC oriented SPF filters. > > > >Google apparently works similarly. Given a valid helo and a neutral > >mfrom, the > >spf= clause of its (ARC-)Authentication-Results: only reports the > >latter. That > >is to say, you need a non-RFC7208 compliant SPF filter to instruct > >DMARC. > > > > _______________________________________________ > dmarc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
