Re: [ietf-smtp] RFC 8601, clarification needed

[Alessandro Vesely <[e-mail]>]

On Sun 23/May/2021 19:53:54 +0200 John Levine wrote:
> It appears that David Bürgin <[e-mail]> said:
>>1)
>>
>> Authentication-Results: mail.example.org; spf=pass smtp.mailfrom=example.com
>> Authentication-Results: mail.example.org; spf=pass smtp.helo=mail.example.com
> 
> That is wrong.  One A-R per pass through the MTA, please.


It's one A-R per agent, actually.  If the results were obtained by different 
agents they wouldn't step on each other's header fields.


>> Authentication-Results: mail.example.org;
>>  spf=pass smtp.helo=mail.example.com;
>>  spf=pass smtp.mailfrom=example.com
> 
> You can do that if you want.


Right.  The following field, albeit syntactically correct, is excluded by the 
spec, which says «For SPF, the ptype used is "smtp", and the property is 
*either* "mailfrom" *or* "helo"» (my emphasis):

Authentication-Results: mail.example.org;
   spf=pass smtp.helo=mail.example.com smtp.mailfrom=example.com;


>> A subsequent component could then use these results as input to some
>> spam score, for example.
> 
> You could, although in practice the HELO check doesn't tell you anything useful
> except when it's used as a fallback due to a null MAIL FROM.  The useful HELO
> check is to see if it exists at all, with a nonexistent one being a close to 100%
> accurate spam signal.  But if it doesn't exist, there is no SPF record so SPF
> tells you nothing.


Those are two different ways to configure a host as a mail outlet.  Receivers 
that check the DNS entry often require the reverse to match, which RFC 8601 
calls iprev, a.k.a. forward-confirmed reverse DNS (FCrDNS).  Setting up SPF 
HELO is easier, as repeating the IP address in a TXT RR in the same zone would 
suffice; that is, for example:

mail.example.com. IN A 192.0.2.0
mail.example.com. IN TXT "v=spf1 +ip4:192.0.2.0 -all"

However, many mail receivers hold the belief that the HELO argument can be 
gamed more than other identifiers.  That misconception presumably originates 
from a wrong interpretation of RFC 5321 saying «However, if the verification 
fails, the server MUST NOT refuse to accept a message on that basis.» 
Considering HELO a second class identifier is incarnated in DMARC («Note that 
the RFC5321.HELO identity is not typically used in the context of DMARC»). 
Then, because some DMARC implementations which consume A-Rs are unable to 
consider multiple SPF results, many A-R producers limit themselves to reporting 
the smtp.mailfrom only.


Best
Ale
--