I think I finally understand the complexities of this issue. SPF is two different validations, largely unrelated.
Test One: A connection comes in and a server asserts a HELO name. Before proceeding, the recipient was to check if the HELO name is plausible or fraudulent. One way to do this would be to forward-confirm the HELO DNS name to the source IP. An alternate method is to use SPF to see if the SPF policy says that the HELO domain can send from the Source IP. I do not understand why the domain owner would be able to configure the SPF policy but not the host name in DNS. Perhaps for organizations with 1000s of servers, creating a DNS entry for each machine seemed onerous. In practice, the large organizations do have DNS entries for each server, and they encourage others to do the same. A recipient who gets a FAIL result from this HELO test could decide to reject the connection without ever proceeding to MAILFROM. This is why the specification suggests testing HELO before MAILFROM. We know that internal host names, such as "mail.example.local", will fail both of these tests because the local domain cannot be published in DNS. I expect that any attempt to require a PASS from this test will encounter an unacceptable number of false positives, so I do not see it as particularly useful. But the option exists. Test Two: If the conversation proceeds past HELO to MAILFROM, then the second validation is performed: Is the Source IP is authorized to send on behalf of the SMTP domain? When the SMTP address is null, then postmaster@HeloDomain serves as a proxy for performing this test. We have two different tests, and two paths for performing the second test. Organizations have the choice of whether to implement one, both, or neither test. But the two tests are complementary, not mutually exclusive. HELO test violations will have nothing to do with message flow path, since the test only examines whether the adjacent server name can be plausibly linked to the adjacent IP address. A DKIM signature is not a third way of answering this question, because a DKIM signature cannot be reliably associated with the server that applied the signature. Nor do I think we want a third solution to this question. Consequently, the HEL:O test is unrelated to DMARC. The SMTP Address test is appropriate to DMARC, whether it is evaluated using a supplied name or a derived name based on postmaster@helodomain. DF
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
