RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 10 records.

Status: Verified (1)

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

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.

Status: Reported (9)

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
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.)

Report New Errata