Sender Policy Framework

Errata published by the RFC Editor

RFCs do not change once published. However, the RFC Editor does accept errata for technical and editorial errors. Potential errata can be also submitted for consideration on the SPF discuss or devel lists.

The following list might be incomplete, check out the official RFC 4408 errata page.

• Typo: aParticipants in the IESG note
• Link to this page added (2007-11-06)

Errata approved by the council and/or by the RFC authors

• Add %v macro to ABNF grammar
• Undefined "uric" set
• Recommend an SMTP reply code for optional PermError rejections
• Received-SPF examples have incorrect syntax
• unknown-modifier is too greedy
• Empty domain spec on exp modifier
• PermError on invalid domains after macro expansion
• Miscellaneous confirmed typos

Add %v macro to ABNF grammar

Suggested wording:

The ABNF grammar in section 8.1 and appendix A are missing the letter "v". The macro-letter production should look like this:

  macro-letter     = "s" / "l" / "o" / "d" / "i" / "p" / "h" /
                     "c" / "r" / "t" / "v"

Rationale:

The %v macro is listed in the table of macros in section 8.1, and used in the examples.

Undefined uric set

Suggested wording:

Replace "uric" by "unreserved" in section 8.1.

Rationale:

uric was defined in RFC 2396, but later removed in RFC 3986. Because RFC 4408 has a normative reference to RFC 3986 (AKA STD 66) uric has to be replaced by a modern set of characters affected by the URL escaping for uppercased macros.

Reported by Julian and confirmed by Wayne.

Recommend an SMTP reply code for optional PermError rejections

Suggested wording:

 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 DSN code.

(to be added at the end of 2.5.7 in the style of the wording at the end of 2.5.6)

Rationale:

The PermError section in Wayne's first SPF I-D stated:

 A PermError result means that the domain's published records
 couldn't be correctly interpreted.  Checking software SHOULD
 reject the message.  If rejecting during SMTP transaction
 time, it SHOULD use an SMTP reply code of 550 and, if supported,
 the 5.5.2 DSN code.

This was removed later when the first SHOULD was identified as receiver policy.

However the second SHOULD recommends an appropriate reply code for receivers wishing to reject PermError. The issue was resolved in an appeal to the SPF Council proposing to use a similar wording as for FAIL, but the missing status code didn't make it again into the final draft.

Received-SPF examples use incorrect syntax

Suggested wording:

The examples in section 7 are incorrectly quoted, and should look like this:

  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;
      envelope-from="myname@example.com"; helo=foo.example.com;
  Received-SPF: Fail (mybox.example.org: domain of
                    myname@example.com does not designate
                    192.0.2.1 as permitted sender)
                    identity=mailfrom; client-ip=192.0.2.1;
                    envelope-from="myname@example.com";

Rationale:

In RFC4408, key-value-pair is defined as:

  key-value-pair   = key [CFWS] "=" ( dot-atom / quoted-string )

However, the examples look like this:

  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;
      envelope-from=<myname@example.com>; helo=foo.example.com;

Notice that envelope-from in both cases is NOT a dot-atom or quoted-string.

None of '<','>','@' are legal chars for dot-atom.

unknown-modifier clause is too greedy in ABNF

In section 4.6.1/2, unknown-modifier should be changed to:

  unknown-modifier = name "=" macro-string
                     ; where name is not any known modifier

Rationale:

The unknown-modifier clause is too greedy, causing any syntax errors in redirect or explanation to simply become unknown-modifier. For instance, "exp=-all" would match unknown-modifier. This was not the intent.

For a similar case see RFC 2822, where the field names of any optional-field MUST NOT be identical to any field name specified elsewhere in this standard.

Empty domain-spec on exp modifier

Problem statement:

Section 6.2/4 says:

If domain-spec is empty, or there are any DNS processing errors (any RCODE other than 0), or if no records are returned, or if more than one record is returned, or if there are syntax errors in the explanation string, then proceed as if no exp modifier was given.

However, 6.2/1 gives the grammar for exp as:

  explanation = "exp" "=" domain-spec
  domain-spec      = macro-string domain-end
  domain-end       = ( "." toplabel [ "." ] ) / macro-expand

Thus, domain-spec can never be empty. Syntax errors require a permerror result, which conflicts with the instruction to "proceed as if no exp modifier was given."

Suggested fix and rationale:

Section 6.2/4 should be changed to say:

If there are any DNS processing errors (any RCODE other than 0), or if no records are returned, or if more than one record is returned, or if there are syntax errors in the explanation string, then proceed as if no exp modifier was given.

The exp and redirect modifiers are special since they are included in the spec. They must be fully parsed, with any resulting Permerror, even when exp= is not otherwise supported. Clear syntax errors are supposed to be identified a.s.a.p. and reported as PermError, and supporting explanations in syntax isn't optional.

The prose obviously wants that an empty <target-name> and similar issues after the macro expansion of <domain-spec> are ignored. It's more important to reject the FAIL than to deal with obscure explanation issues.

PermError on invalid domains after macro expansion

Problem statement:

The Permerror definition ends with:

Be aware that if the domain owner uses macros (Section 8), it is possible that this result is due to the checked identities having an unexpected format.

A <target-name> after macro expansion of <domain-spec> can be invalid, i.e. a string not suited for DNS queries like foo..example (adjacent dots), a <target-name> with overlong labels, or similar issues not permitted in the DNS syntax.

Suggested fix (variant 1):

The last sentence in the Permerror definition is misleading. A syntactically malformed <target-name> can be also handled as no match. The specification should say:

Be aware that if the domain owner uses macros (Section 8), it is possible that this result is due to the checked identities having an unexpected format.

Please note that an unexpected <target-name> can be also handled as no match, ideally implementations document how they handle such issues. The outcome for an unexpected <domain-spec> without macros might differ from the outcome for an unexpected <target-name> after macro expansion.

Suggested fix (Variant 2):

The last sentence in the Permerror definition is misleading. A syntactically malformed <target-name> can be also handled as no match. The specification should say:

Be aware that it is also possible that this result is generated by certain SPF clients due to the input arguments having an unexpected format; see Section 4.8.

At the end of Section 4.8 add:

Note: Historically, this document has made no provisions for how to handle <domain-spec>s, or macro-expansions thereof, that are syntactically invalid per [RFC1035], such as names with empty labels (e.g., "foo..example.com") or overlong labels (more than 63 characters). Some implementations choose to treat as a no-match mechanisms, and ignore modifiers, with such names, whereas others throw a "PermError" exception. The outcome for an unexpected <domain-spec> without macros might even differ from that for an unexpected <target-name> after macro expansion.

Rationale:

Reporting a TempError in such cases is no option, the syntax problem won't go away for a given sender policy, HELO identity, envelope sender address, and sending IP combination with a try again later TempError approach. If anything else is as expected the sender policy might need to be fixed manually, supporting PermError.

If the DNS syntax problem is caused by random net abuse, or intentionally by an attacker, a no match approach, eventually reaching a FAIL for -all or whatever the sender policy offers, is better. In common practice this problem is handled as no match OR PermError, like similar problems explicitly addressed in the specification.

Miscellaneous typos

• Missing indentation for the second paragraph of the [US-ASCII] reference reported by Wayne.
• Missing line break on page 46 before mary.mobile-users reported by Wayne.
• Typo: "Danish" instead of "Danisch" in the references confirmed by Wayne and Frank.
• Missing words in the last sentence of the third paragraph of section 6.1: "The <ip> and <sender> arguments remain the same as in the current evaluation of check_host()." (reported by Julian)