Re: [dmarc-ietf] Ticket #1 - SPF alignment

[Douglas Foster <[e-mail]>]

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