On Sun 23/May/2021 19:53:54 +0200 John Levine wrote:
It appears that David Bürgin <dbuergin(_at_)gluet(_dot_)ch> 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
--
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp