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

[Scott Kitterman <[e-mail]>]

On Tuesday, May 11, 2021 12:10:58 PM EDT John R. Levine wrote:
> > This one is ... interesting, in a pedantic sort of way.
> > 
> > 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.
> 
> 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?

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

> >> 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
> >> 
> >> _______________________________________________
> >> marf mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/marf
> > 
> > _______________________________________________
> > marf mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/marf
> 
> Regards,
> John Levine, [e-mail], Primary Perpetrator of "The Internet for
> Dummies", Please consider the environment before reading this e-mail.
> https://jl.ly