RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 16 records.

Status: Verified (2)

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

Note: This RFC has been updated by RFC 7372, RFC 8553, RFC 8616

Source of RFC: spfbis (app)

Errata ID: 5436
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Peter Occil
Date Reported: 2018-07-23
Verifier Name: Alexey Melnikov
Date Verified: 2018-11-26

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: 6721
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Ale Vesely
Date Reported: 2021-10-25
Verifier Name: Murray Kucherawy
Date Verified: 2021-11-09

Section 8.4 says:

       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:

       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

Notes:

In addition, RFC 7208 does not give an example of rejection based on the HELO argument.

Status: Reported (9)

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

Note: This RFC has been updated by RFC 7372, RFC 8553, RFC 8616

Source of RFC: spfbis (app)

Errata ID: 4751
Status: Reported
Type: Technical
Publication Format(s) : TEXT

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
Publication Format(s) : TEXT

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
Publication Format(s) : TEXT

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: 5550
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Borislav Petrov
Date Reported: 2018-11-09

Section 2.3. says:

   Note that requirements for the domain presented in the EHLO or HELO
   command are not always clear to the sending party, and SPF verifiers
   have to be prepared for the identity to be an IP address literal (see
   [RFC5321], Section 4.1.3) or simply be malformed.  This SPF check can
   only be performed when the "HELO" string is a valid, multi-label
   domain name.

Notes:

It looks like that those who have HELO <IP Address> or <malformed> will have result "none" (and pass) but those that have HELO <hostname> and have not yet published their hostname (A record) as allowed sender will get fail. This becomes a very common case for all messages which are DSNs. The whole idea that it is better to have your HELO malformed than a valid hostname which identifies the system is wrong. The point is to fight spam but you actually make it easier for spammers to just have the EHLO malformed and send with <> reverse-path rather than having some proper EHLO/HELO which is subject to other verifications like rDNS, etc.

Errata ID: 5843
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Jesus Donaldo Osornio
Date Reported: 2019-08-22

Section 9.1 says:

Received-SPF: pass (mybox.example.org: domain of
    myname@example.com designates 192.0.2.1 as permitted sender)
       receiver=mybox.example.org; client-ip=192.0.2.1;
       mechanism=ip4:192.0.2.1; envelope-from="myname@example.com";
       helo=foo.example.com;

It should say:

Received-SPF: pass (mybox.example.org: domain of
    myname@example.com designates 192.0.2.1 as permitted sender)
       receiver=mybox.example.org; client-ip=192.0.2.1;
       mechanism="ip4:192.0.2.1"; envelope-from="myname@example.com";
       helo=foo.example.com;

Notes:

There's an error in the last example of this section:
By the definition of key-value-pair, a "value" can only be a dot-atom or a quoted-string.
The string ip4:192.0.2.1 in the mechanism key is not a legal dot-atom, so it should be surrounded by double quotes, to be a quoted-string instead

Errata ID: 6216
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: David Bürgin
Date Reported: 2020-06-26

Section A.4 says:

ptr._spf.example.com.  SPF  "v=spf1 -ptr +all"

It should say:

ptr._spf.example.com.  TXT  "v=spf1 -ptr:example.com +all"

Notes:

The example in appendix A.4, 'Multiple Requirements Example', does not
work as intended.

In the example, the SPF record at ptr._spf.example.com contains the
directive '-ptr'.

When this directive is evaluated, the <target-name> is equal to
'ptr._spf.example.com'. An input <ip> such as 192.0.2.10, which has a
PTR record pointing to 'example.com', will fail to match, as that domain
is not equal to nor a subdomain of 'ptr._spf.example.com'. In other
words, given the DNS setup of appendix A, there are no inputs that
fulfil the requirement for matching this ptr mechanism.

The example can be fixed by supplying an appropriate <domain-spec>:
replace '-ptr' with '-ptr:example.com'.

Errata ID: 6595
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Benjamin Schwarze
Date Reported: 2021-06-03

Section 4.6.4 says:

As described at the end of Section 11.1, there may be cases where it
is useful to limit the number of "terms" for which DNS queries return
either a positive answer (RCODE 0) with an answer count of 0, or a
"Name Error" (RCODE 3) answer.  These are sometimes collectively
referred to as "void lookups".  SPF implementations SHOULD limit
"void lookups" to two.  An implementation MAY choose to make such a
limit configurable.  In this case, a default of two is RECOMMENDED.
Exceeding the limit produces a "permerror" result.

It should say:

-- Addition to the original paragraph --

ADMDs should be aware that the void lookup limit can easily be exceeded by using sender-specific macros ("s", "l", "o", "i", "h") in more than 2 terms.

The following example will lead to an permerror in the most implementations if the <ip> is not found in any of the lists:
  v=spf1 exists:%{ir}.list1.example.net exists:%{ir}.list2.example.net exists:%{ir}.list3.example.net -all

Notes:

In addition to the above suggestion, I still see a contradiction between the "void lookup limit" and the "exists" mechanism. The functionality of "exists" includes (in my opinion) the negative response (RCODE 3). But the "void lookup limit" allows this to occur only twice. This limits the use of "exists" very much.

Admittedly: I have no good idea how to solve this. :-)

Errata ID: 4841
Status: Reported
Type: Editorial
Publication Format(s) : TEXT

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.

Errata ID: 6433
Status: Reported
Type: Editorial
Publication Format(s) : TEXT

Reported By: Kaspar Etter
Date Reported: 2021-02-17

Section 3 says:

   Each SPF record is placed in the DNS tree at the owner name it
   pertains to, not in a subdomain under the owner name.  This is
   similar to how SRV records [RFC2782] are done.

It should say:

   Each SPF record is placed in the DNS tree at the owner name it
   pertains to, not in a subdomain under the owner name.  This is
   different from how SRV records [RFC2782] are done.

Notes:

SRV records are placed at specific subdomains, which is not the case for SPF records. (I've chosen Editorial instead of Technical because the meaning of this paragraph should be clear from the context and thus this feels more like a typo.)

Status: Held for Document Update (2)

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

Note: This RFC has been updated by RFC 7372, RFC 8553, RFC 8616

Source of RFC: spfbis (app)

Errata ID: 4001
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT

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
Publication Format(s) : TEXT

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 (3)

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

Note: This RFC has been updated by RFC 7372, RFC 8553, RFC 8616

Source of RFC: spfbis (app)

Errata ID: 4081
Status: Rejected
Type: Technical
Publication Format(s) : TEXT

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
Publication Format(s) : TEXT

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.

Errata ID: 6432
Status: Rejected
Type: Technical
Publication Format(s) : TEXT

Reported By: Kaspar Etter
Date Reported: 2021-02-17
Rejected by: Barry Leiba
Date Rejected: 2021-02-17

Section 4.4 says:

In accordance with how the records are published (see Section 3
above), a DNS query needs to be made for the <domain> name, querying
for type TXT only.

It should say:

?

Notes:

Request for clarification: Are CNAME indirections allowed or, in other words, do they have to be followed during record lookup? If yes, do they count towards the DNS lookup limits as defined in section 4.6.4? If yes, the following sentence has to be adapted as well: "SPF implementations MUST limit the total number of those terms to 10 during SPF evaluation, to avoid unreasonable load on the DNS." If the answer to the first question is no, then this should be made clear in section 4.4.

Please note that whether using CNAMEs is a good or bad idea is irrelevant to my question. I also know that you can't add a CNAME record to an apex domain but SPF is not limited to such domains. I assume the answer/consensus will be the same for the initial, `a`, `include`, `exists` and `redirect` lookups. If not, this should also be clarified, of course.
--VERIFIER NOTES--
Errata reports are not the place to ask questions. An appropriate mailing list on which to discuss SPF is the <ietf-smtp> list.

Report New Errata



Advanced Search