RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 9 records.

Status: Reported (5)

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: 5227
Status: Reported
Type: Technical

Reported By: David Garfield
Date Reported: 2018-01-04

Section 5.5 says:

   The <ip>'s name is looked up using this procedure:

   o  Perform a DNS reverse-mapping for <ip>: Look up the corresponding
      PTR record in "in-addr.arpa." if the address is an IPv4 address
      and in "ip6.arpa." if it is an IPv6 address.

   o  For each record returned, validate the domain name by looking up
      its IP addresses.  To prevent DoS attacks, the PTR processing
      limits defined in Section 4.6.4 MUST be applied.  If they are
      exceeded, processing is terminated and the mechanism does not
      match.

   o  If <ip> is among the returned IP addresses, then that domain name
      is validated.

   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.  If a
   DNS error occurs while doing the PTR RR lookup, then this mechanism
   fails to match.  If a DNS error occurs while doing an A RR lookup,
   then that domain name is skipped and the search continues.

   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.

   For example, "mail.example.com" is within the domain "example.com",
   but "mail.bad-example.com" is not.

It should say:

   The <ip>'s name is looked up using this procedure:

   o  Perform a DNS reverse-mapping for <ip>: Look up the corresponding
      PTR record in "in-addr.arpa." if the address is an IPv4 address
      and in "ip6.arpa." if it is an IPv6 address.

   Check all 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 domain name can be validated.  If no
   domain name can be found, or if none of the domain names match or
   are a subdomain of the <target-name>, this mechanism fails to
   match.  If a DNS error occurs while doing the PTR RR lookup, then
   this mechanism fails to match.

   This mechanism may match if

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

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

   For example, "mail.example.com" is within the domain "example.com",
   but "mail.bad-example.com" is not.


   The domain names received must also be validated for the mechanism
   to match.

   o For each matched record, validate the domain name by looking up
      its IP addresses.  To prevent DoS attacks, the PTR processing
      limits defined in Section 4.6.4 MUST be applied.  If they are
      exceeded, processing is terminated and the mechanism does not
      match.

   o  If <ip> is among the returned IP addresses, then that domain name
      is validated.

   If a DNS error occurs while doing an A RR lookup, then that domain
   name is skipped and the search continues.


   The mechanism matches if a domain name is found that properly
   matches the target name and can be properly validated.  While these
   tests can be done in either order, performing the match before
   validating prevents needless DNS queries being performed.

Notes:

As specified, the RFC calls for all names to be validated, even those that can be immediately discarded because they do not match. The RFC should call for the local-only operation to be done first. While it may be argued that the RFC doesn't require the order, implementers shouldn't be misled.

My corrected text probably needs editorial work.

I have not fixed errata 4751 in my corrected text.

Errata ID: 5228
Status: Reported
Type: Technical

Reported By: David Garfield
Date Reported: 2018-01-04

Section 5.5 says:

   Note: This mechanism is slow, it is not as reliable as other
   mechanisms in cases of DNS errors, and it places a large burden on
   the .arpa name servers.  If used, proper PTR records have to be in
   place for the domain's hosts and the "ptr" mechanism SHOULD be one of
   the last mechanisms checked.  After many years of SPF deployment
   experience, it has been concluded that it is unnecessary and more
   reliable alternatives should be used instead.  It is, however, still
   in use as part of the SPF protocol, so compliant check_host()
   implementations MUST support it.

It should say:

   Note: This mechanism is not as reliable as other
   mechanisms in cases of DNS errors.
   If used, proper PTR records have to be in
   place for the domain's hosts and the "ptr" mechanism SHOULD be one of
   the last mechanisms checked.  After many years of SPF deployment
   experience, it has been concluded that it is unnecessary and more
   reliable alternatives should be used instead.  It is, however, still
   in use as part of the SPF protocol, so compliant check_host()
   implementations MUST support it.

Notes:

I have not reflowed the text so it can be more clear what I changed.

This mechanism is slow

In fact, if all the DNS records are in place, Errata 5227 is accounted
for, and the single PTR query is discounted, this mechanism produces
no more additional DNS queries than mechanism "a". I.e. it produces
one A (or AAAA) query. It is not slow.

it places a large burden on the .arpa name servers

In fact, it requires 1 PTR query, for however many ptr mechanisms are
in the SPF record. Further, most mail servers already do this PTR
query, to report the information on the "Received" line. Even if a
seperate daemon is used to the SPF check, the data should already be
in a local caching name server.

Errata ID: 5436
Status: Reported
Type: Technical

Reported By: Peter Occil
Date Reported: 2018-07-23

Throughout the document, when it says:

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

It should say:

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

Notes:

As specified, 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.) The corrected ABNF better follows practice in implementations.

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