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

From: David Bürgin <[email-masked]>
Date: Sun, 23 May 2021 12:25:59 +0200

Section 4 of RFC 8601 contains the following paragraph:

    Most known message authentication methods focus on a particular
    identifier to evaluate.  SPF differs in that it can yield a result
    based on more than one identifier; specifically, SPF can evaluate the
    RFC5321.HELO parameter or the RFC5321.MailFrom parameter.  When
    generating this field to report those results, only the parameter
    that yielded the result is included.

The final sentence is unclear to me. Suppose I’m running an SPF
component that evaluates *both* RFC5321.HELO and RFC5321.MailFrom, as
recommended by RFC 7208. I would like to record the results for both
parameters in either of the following (equivalent) forms:

1)

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

2)

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

A subsequent component could then use these results as input to some
spam score, for example.

Are the above forms allowed? If not, why not? What requirement does the
sentence ‘When generating this field to report those results, only the
parameter that yielded the result is included.’ refer to?

Thank you!

-- 
David

---

From: "John Levine" <[email-masked]>
Date: 23 May 2021 13:53:54 -0400

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

That is wrong.  One A-R per pass through the MTA, please.

>  spf=pass smtp.mailfrom=example.com

You can do that if you want.

>A subsequent component could then use these results as input to some

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.

R's,
John

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 24 May 2021 19:01:00 +0200

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

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

> accurate spam signal.  But if it doesn't exist, there is no SPF record so SPF

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