Subject: [marf] [Technical Errata Reported] RFC6652 (6579)

From: RFC Errata System <[email-masked]>
Date: Tue, 11 May 2021 07:51:12 -0700 (PDT)

The following errata report has been submitted for RFC6652,
"Sender Policy Framework (SPF) Authentication Failure Reporting Using the Abuse Reporting Format".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6579

--------------------------------------
Type: Technical
Reported by: Benjamin Schwarze <[email-masked]>

Section: 3.

Original Text
-------------
spf-rp-tag = "rp=" 1*12DIGIT "/" 1*12DIGIT

Corrected Text
--------------
spf-rp-tag = "rp=" "100" / 1*2DIGIT

Notes
-----
As explained in paragraph 3, the value of the "rp" modifier should be an integer value between 0 and 100. However, the specified abnf does not fit this requirement.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC6652 (draft-ietf-marf-spf-reporting-11)
--------------------------------------
Title               : Sender Policy Framework (SPF) Authentication Failure Reporting Using the Abuse Reporting Format
Publication Date    : June 2012
Author(s)           : S. Kitterman
Category            : PROPOSED STANDARD
Source              : Messaging Abuse Reporting Format
Area                : Applications
Stream              : IETF
Verifying Party     : IESG

---

From: Ned Freed <[email-masked]>
Date: Tue, 11 May 2021 08:18:30 -0700 (PDT)

This one is ... interesting, in a pedantic sort of way.

The current ABNF is clearly incorrect; the question is how best to fix it.

The simplest fix is:

  spf-rp-tag = "rp=" 1*3DIGIT 

This conforms to the ABNF used for similar percentage values 
in related specifications. For example RFC 7489 defines pct as:

  dmarc-percent   = "pct" *WSP "=" *WSP
                       1*3DIGIT

Even though the pct value is restricted in the text to the
same 0-100 range as is allowed here.

But this allows values outside the allowed range, as well as leading zeros. The
fix suggested in the report restricts things to the allowed range:

But it doesn't deal with the leading zero issue. And it now disallows things
like "001" that were allowed before, and which do specify an in-range value.

If you also want to eliminate leading zeros, then you need something like:

  spf-rp-tag = "rp=" ("100" / ([%x31-39] DIGIT))

Of course there are other ways to do it, but I don't think there are
any that involve fewer terminals.

As to what implementations do, my guess is most call whatever integer parser
they have handy, and then check to see if the result is in range. This probably
means they are tolerant of leading zeros - although I guess it's faintly
possible that a value with a leading zero will be interpreted in base 8 - and
some probably allow a leading +/-.

And finally, there's the question of whether this is a correction or an update.
I think 1*3DIGIT clearly qualifies as a correction given that's what is in other
RFCs, but the more restrictive you get the closer you are to this being
an update.

Anyway, my recommendation is to go with 1*3DIGIT for now, although I don't
feel strongly about it.

				Ned

> As explained in paragraph 3, the value of the "rp" modifier should be an
> integer value between 0 and 100. However, the specified abnf does not fit this
> requirement.

> _______________________________________________
> marf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/marf

---

From: "John R. Levine" <[email-masked]>
Date: 11 May 2021 12:10:58 -0400

> RFCs, but the more restrictive you get the closer you are to this being

The current ABNF has two values separated by a slash, which doesn't match 
the text at all.  I'm inclined to go with 1*3DIGIT because I agree that 
implementations will use some version of atoi() and leading zeros don't 
matter.

Has anyone ever implemented this?  The text says to ignore ra= in include=
records but says nothing about redirect= records.  Is that deliberate? 
What happens in the common case that the redirect target is not a 
hostname?

>> Original Text

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 11 May 2021 23:09:36 -0400

On Tuesday, May 11, 2021 11:18:30 AM EDT Ned Freed wrote:
> But this allows values outside the allowed range, as well as leading zeros.
> The fix suggested in the report restricts things to the allowed range:
> 
> they have handy, and then check to see if the result is in range. This
> probably means they are tolerant of leading zeros - although I guess it's
> faintly possible that a value with a leading zero will be interpreted in
> base 8 - and some probably allow a leading +/-.
> 
> And finally, there's the question of whether this is a correction or an
> update. I think 1*3DIGIT clearly qualifies as a correction given that's
> what is in other RFCs, but the more restrictive you get the closer you are
> to this being an update.
> 

I think that's reasonable.

Scott K
> > integer value between 0 and 100. However, the specified abnf does not fit
> > this requirement.
> > 
> > Instructions:
> > -------------
> > Title               : Sender Policy Framework (SPF) Authentication Failure
> > Reporting Using the Abuse Reporting Format Publication Date    : June
> > 2012
> > Author(s)           : S. Kitterman

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 11 May 2021 23:14:10 -0400

On Tuesday, May 11, 2021 12:10:58 PM EDT John R. Levine wrote:
> > what is in other RFCs, but the more restrictive you get the closer you
> > are to this being an update.
> 

Although I don't remember for sure, it probably was deliberate.  When include 
and redirect were designed the intent was that one would use redirect to 
aggregate SPF record content within an ADMD, so an ra= in a redirect target 
would generally be in within the same ADMD and reasonable to use.  Include was 
meant to be used for external senders authorized to send for the domain, so 
using ra= from a include target would likely be some other ADMDs ra and thus 
should be skipped.

I won't swear that was the thinking when I wrote 6652, but given the history, 
I think that's likely.

Scott K

> >> Title               : Sender Policy Framework (SPF) Authentication
> >> Failure Reporting Using the Abuse Reporting Format Publication Date    :
> >> June 2012
> >> Author(s)           : S. Kitterman
> John Levine, [email-masked], Primary Perpetrator of "The Internet for
> Dummies", Please consider the environment before reading this e-mail.
> https://jl.ly