Subject: [spfbis] Question regarding RFC 7208

From: Peter Occil <[email-masked]>
Date: Sun, 22 Jul 2018 15:24:59 -0400

RFC 7208 includes the following ABNF for the Received-SPF header field:

    header-field     = "Received-SPF:" [CFWS] result FWS [comment FWS]
                          [ key-value-list ] CRLF

As specified, however, this ABNF doesn't allow a header field value like result-FWS-comment with no FWS or key-value-list following it, a header field value which occurs very often in Received-SPF header fields I see in practice.  (Note that FWS must contain at least one white space.)

An ABNF like the following would better follow practice in implementations.

    header-field     = "Received-SPF:" [CFWS] result [ FWS comment ]
                          [ FWS key-value-list ] [FWS] CRLF

Is a header field parser allowed to be so robust as to use the latter ABNF to parse the Received-SPF header field?  Is a correction to use that ABNF within the scope of an erratum to RFC 7208?

(In addition, many cases I've seen include an IPv6 address in the client-ip parameter, which includes colons, without that address being a "quoted-string" or fitting the production "dot-atom".  But this issue can wait until I get answers on the main issue I raised in this message.)

--Peter

---

From: "John Levine" <[email-masked]>
Date: 22 Jul 2018 16:08:14 -0400

>                          [ FWS key-value-list ] [FWS] CRLF

While we can have a theological argument about whether the problem is
that the spec doesn't describe the protocol or the programmers didn't follow
the spec, I agree that this ABNF seems more likely to match what people would
consider to be reasonable syntax.

>Is a header field parser allowed to be so robust as to use the latter ABNF to parse the Received-SPF header field?  Is a correction to use that ABNF within the scope of an erratum to RFC 7208?

We are not the protocol police.  You can do whatever you want.
Adjusting your code to handle common benign sender mistakes is often a
good idea.

>(In addition, many cases I've seen include an IPv6 address in the client-ip parameter, which includes colons, without that address being a "quoted-string"
>or fitting the production "dot-atom".  But this issue can wait until I get answers on the main issue I raised in this message.)

I think that's a bug in the spec, due to forgetting that dot-atom doesn't include colons.

R's,
John