On Tue 02/Feb/2021 01:11:22 +0100 Douglas Foster wrote:
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.
That is the method described as iprev in Section 2.7.3 of RFC 8601, a.k.a.
Forward-confirmed reverse DNS (FCrDNS). Like many other authentication
methods, it is not considered by DMARC.
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.
To configure reverse DNS one needs a delegation of the relevant arpa subdomain,
which ISPs don't routinely provide. By contrast, A, AAA, MX, and TXT records
can be defined by every domain owner. In theory, each label having any of A,
AAA, or MX resource records, deserves an SPF record as well.
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.
Google, for one, don't care to define an SPF record for every server. DMARC's
discarding the result of helo verification is certainly not an incentive.
A recipient who gets a FAIL result from this HELO test could decide to
reject the connection without ever proceeding to MAILFROM.
Rejecting EHLO can be problematic, since the command does not start a mail
transaction. Implementations may delay 5xx replies until MAIL or RCPT commands.
[...]
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.
To /require/ a pass on helo is very different from /discarding/ a pass on helo.
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.
Testing postmaster@HeloDomain is exactly the same test done for helo. When the
SMTP address is null, then the test is not performed.
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 HELO 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.
That makes no sense. There is no difference between evaluating HELO and
evaluating "a derived name based on postmaster@helodomain". It is an HELO test
in both cases. Either it is reliable or it is not. Asserting that a test is
reliable only when there are no other means to authenticate a message is an
idiosyncrasy.
Best
Ale
--
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
