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

[Alessandro Vesely <[e-mail]>]

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
--