RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 6 records.

Status: Reported (2)

RFC 7208, "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1", April 2014

Source of RFC: spfbis (app)

Errata ID: 4751

Status: Reported
Type: Technical

Reported By: Ken Mortimer
Date Reported: 2016-07-27

Section 5.5 says:

This mechanism matches if

o  the <target-name> is a subdomain of a validated domain name, or

o  the <target-name> and a validated domain name are the same.

It should say:

This mechanism matches if

o  a validated domain name is a subdomain of the <target-name>, or

o  the <target-name> and a validated domain name are the same.

Notes:

The first bullet point is in contradiction to the description of the ptr mechanism evaluation in the preceding paragraph:
"Check all validated domain names to see if they either match the <target-name> domain or are a subdomain of the <target-name> domain. If any do, this mechanism matches. If no validated domain name can be found, or if none of the validated domain names match or are a subdomain of the <target-name>, this mechanism fails to match."

Errata ID: 4841

Status: Reported
Type: Editorial

Reported By: Alessandro Vesely
Date Reported: 2016-10-25

Section 3.5. says:

      EXAMPLE.COM.          MX      10      A.EXAMPLE.COM
      *.EXAMPLE.COM.        MX      10      A.EXAMPLE.COM
      A.EXAMPLE.COM.        MX      10      A.EXAMPLE.COM
      *.A.EXAMPLE.COM.      MX      10      A.EXAMPLE.COM


It should say:

      EXAMPLE.COM.          MX      10      A.EXAMPLE.COM.
      *.EXAMPLE.COM.        MX      10      A.EXAMPLE.COM.
      A.EXAMPLE.COM.        MX      10      A.EXAMPLE.COM.
      *.A.EXAMPLE.COM.      MX      10      A.EXAMPLE.COM.

Notes:

This is an editorial errata, since it is a punctuation error.

It is not technical, because the example might have implied an $ORIGIN of "." or some other strange setting, while a normative reference --rfc 1035-- makes it very clear that "[d]omain names that end in a dot are called absolute, and are taken as complete." Hence no technical meaning is affected.

Status: Held for Document Update (2)

RFC 7208, "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1", April 2014

Source of RFC: spfbis (app)

Errata ID: 4001

Status: Held for Document Update
Type: Technical

Reported By: Jimmy Xu
Date Reported: 2014-05-27
Held for Document Update by: Pete Resnick
Date Held: 2014-06-04

Section A.4 says:

   example.com.           SPF  ( "v=spf1 "
                                 "-include:ip4._spf.%{d} "
                                 "-include:ptr._spf.%{d} "
                                 "+all" )
   ip4._spf.example.com.  SPF  "v=spf1 -ip4:192.0.2.0/24 +all"
   ptr._spf.example.com.  SPF  "v=spf1 -ptr +all"

It should say:

   example.com.           TXT  ( "v=spf1 "
                                 "-include:ip4._spf.%{d} "
                                 "-include:ptr._spf.%{d} "
                                 "+all" )
   ip4._spf.example.com.  TXT  "v=spf1 -ip4:192.0.2.0/24 +all"
   ptr._spf.example.com.  TXT  "v=spf1 -ptr +all"

Notes:

According to Section 14.1 and Appendix B, the use of DNS RR type SPF (99) has been removed from the protocol.

Errata ID: 4453

Status: Held for Document Update
Type: Editorial

Reported By: Seymour J. Metz
Date Reported: 2015-08-24
Held for Document Update by: Barry Leiba
Date Held: 2015-08-24

Section 5.6. "ip4" says:

  ip4-cidr-length  = "/" ("0" / %x31-39 0*1DIGIT) ; value range 0-32
  ip6-cidr-length  = "/" ("0" / %x31-39 0*2DIGIT) ; value range 0-128

It should say:

  ip4-cidr-length  = "/" (DIGIT / 
                          %x31-%x32 DIGIT /
                          %x33 %x30-%x32) ; value range 0-32

  ip6-cidr-length  = "/" ("0" /
                          %31-%39 0*1DIGIT /
                          "1" %30-%31 DIGIT /
                          "12" %30-%38) ; value range 0-128

Notes:

As written the ABNF matches ranges 0-99 and 0-999, not the ranges in the comments.
Note: I coded the ABNF the way that I did to avoid leading zeros.

----- Verifier Notes -----
This isn't documenting an error: the ABNF was specified as it was intentionally, using the comments to restrict the range. I'm marking this "Held for Document Update" in case we ever revise this and want to consider making the ABNF pickier.

Status: Rejected (2)

RFC 7208, "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1", April 2014

Source of RFC: spfbis (app)

Errata ID: 4081

Status: Rejected
Type: Technical

Reported By: D. Stussy
Date Reported: 2014-08-13
Rejected by: Barry Leiba
Date Rejected: 2014-08-14

Section 8.4 says:

(Paragraph 2):  if supported, the 5.7.1 enhanced status code
...

       550 5.7.1 SPF MAIL FROM check failed:
       550 5.7.1 The domain example.com explains:
       550 5.7.1 Please see http://www.example.com/mailpolicy.html

It should say:

if supported, the 5.7.7 enhanced status code
...

       550 5.7.7 SPF MAIL FROM check failed:
       550 5.7.7 The domain example.com explains:
       550 5.7.7 Please see http://www.example.com/mailpolicy.html

Notes:

5.7.1 generally refers to messages refused due to content or LOCAL policies.
5.7.7 refers to messages where there is an integrity problem.

5.7.7 is a better description for rejecting an unauthorized message due to the application of automatic checking criterion set by remote validation.

The author of this errata notes that the IANA is showing a pending addition to the enhanced codes to add SPF-specific error code 5.7.23 (in lieu of 5.7.1 or 5.7.7), but currently sees no valid RFC proposing it. The draft is located at: http://tools.ietf.org/html/draft-ietf-appsawg-email-auth-codes-07
--VERIFIER NOTES--
The code used was the clear choice of the working group, and can't be changed through the errata system.

Errata ID: 4082

Status: Rejected
Type: Technical

Reported By: D. Stussy
Date Reported: 2014-08-13
Rejected by: Barry Leiba
Date Rejected: 2014-08-14

Section 8.7 says:

...  If the message is rejected during the SMTP transaction for
this reason, the software SHOULD use an SMTP reply code of 550
and, if supported, the 5.5.2 enhanced status code ...

It should say:

...  If the message is rejected during the SMTP transaction for
this reason, the software SHOULD use an SMTP reply code of 550
and, if supported, the 5.7.8 enhanced status code ...

Notes:

5.5.2 refers to responses where there's an SMTP COMMAND syntax error.
5.7.8 refers to messages where authentication credentials are invalid.

5.7.8 is a better description for rejecting an unauthorized message due to the
application of invalid authentication credentials such as bad syntax in an SPF DNS record.

The author of this errata notes that the IANA is showing a pending addition to
the enhanced codes to add SPF-specific error code 5.7.24 (in lieu of 5.5.2 or
5.7.8), but currently sees no valid RFC proposing it. The draft is located at:
http://tools.ietf.org/html/draft-ietf-appsawg-email-auth-codes-07

The use of 5.5.2 here is misleading since the source of the error is not the
SMTP command stream.
--VERIFIER NOTES--
The code used was the clear choice of the working group, and can't be changed through the errata system.

Report New Errata



Search RFCs
Advanced Search
×