Re: RFC 8601, clarification needed
Alessandro Vesely <[email protected]>
| Newsgroups | gmane.ietf.smtp |
|---|---|
| Message-ID | <[email protected]> |
On Sun 23/May/2021 19:53:54 +0200 John Levine wrote: > It appears that David Bürgin <[email protected]> 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 [email protected] https://www.ietf.org/mailman/listinfo/ietf-smtp