I don't see any justification for using HELO unless the SMTP address is null. If the SPF RFC says otherwise, this should be corrected. Proving that the server domain can be tied to the IP address does nothing to prove that the SMTP address can be tied to the Source IP.
For DMARC, HELO is only useful if the message's From domain and the server's HELO domain are aligned. A high percentage of email domains use servers from a different DNS domain, so this will only be true on an exception basis.. Consequently, software products that apply DKIM signatures to messages MUST be able to them to automatic messages as well. Once developers provide MTA and mailstore products which service the needs of hosted domains, then users of non-hosted domains will be able to sign their automatic messages as well. Ergo, any supposed need for HELO with DMARC will go away. DF On Sun, Jan 31, 2021 at 11:52 AM John R Levine <[email protected]> wrote: > On Sun, 31 Jan 2021, Alessandro Vesely wrote: > > One way to interpret RFC 7489 is that you can put dmarc=pass based on > the > > helo identity *only if* MAIL FROM is null. > > That would be consistent with 7489. > > Sec 3.1.2 says > > Note that the RFC5321.HELO identity is not typically used in the > context of DMARC (except when required to "fake" an otherwise null > reverse-path), even though a "pure SPF" implementation according to > [SPF] would check that identifier. > > But then 4.1 says > > o [SPF], which can authenticate both the domain found in an [SMTP] > HELO/EHLO command (the HELO identity) and the domain found in an > SMTP MAIL command (the MAIL FROM identity). DMARC uses the result > of SPF authentication of the MAIL FROM identity. Section 2.4 of > [SPF] describes MAIL FROM processing for cases in which the MAIL > command has a null path. > > That section of 7208 says that if there's a null bounce address, SPF > pretends that the MAIL FROM was postmaster@HELO. > > If we want, we can say not to use the SPF HELO identity, but that would be > an incompatible change to 7489 and I suspect would not match what most > DMARC checking code does. > > Regards, > John Levine, [email protected], Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. https://jl.ly > > _______________________________________________ > dmarc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
