As I've mentioned previously, I'm working on updating the SPF RFC, RFC
4408, and hoping to get it out of Experimental and onto standards track.
I've gone through the RFC 4408 errata and they all seem quite
straightforward, except for one (copied here, since the web site is down
again):
> 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.
My preference here would be to treat these as PermError since an empty
domain-spec is not useful to the protocol and should be an error. I
think it's enough of a corner case that I don't think we need to warn
about the difference from RFC 4408. My solution (note: different than
RFC4408 already due to other, non-controversial erratum):
> A "PermError" result means that the domain's published records
> could not be correctly interpreted. This signals an error
> condition that requires manual intervention to be resolved, as
> opposed to the TempError result. 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. Be aware that if the domain owner uses macros
> (<xref target="macros"/>), it is possible that this result is due
> to the checked identities having an unexpected format. The domain
> and domain-spec MUST be fully macro expanded before being tested
> for errors.
I don't think anything other than macro expansion before evaluation
makes sense. Please discuss.
Scott K
-------------------------------------------
Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/1311532-17d8a1ba
Modify Your Subscription: https://www.listbox.com/member/?member_id=1311532&id_secret=1311532-f2ea6ed9
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=1311532&id_secret=1311532-bdbb122a&post_id=20111024163756:0CD3E470-FE80-11E0-89F0-A0E3D75F85EF
Powered by Listbox: http://www.listbox.com
4408, and hoping to get it out of Experimental and onto standards track.
I've gone through the RFC 4408 errata and they all seem quite
straightforward, except for one (copied here, since the web site is down
again):
> 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.
My preference here would be to treat these as PermError since an empty
domain-spec is not useful to the protocol and should be an error. I
think it's enough of a corner case that I don't think we need to warn
about the difference from RFC 4408. My solution (note: different than
RFC4408 already due to other, non-controversial erratum):
> A "PermError" result means that the domain's published records
> could not be correctly interpreted. This signals an error
> condition that requires manual intervention to be resolved, as
> opposed to the TempError result. 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. Be aware that if the domain owner uses macros
> (<xref target="macros"/>), it is possible that this result is due
> to the checked identities having an unexpected format. The domain
> and domain-spec MUST be fully macro expanded before being tested
> for errors.
I don't think anything other than macro expansion before evaluation
makes sense. Please discuss.
Scott K
-------------------------------------------
Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/1311532-17d8a1ba
Modify Your Subscription: https://www.listbox.com/member/?member_id=1311532&id_secret=1311532-f2ea6ed9
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=1311532&id_secret=1311532-bdbb122a&post_id=20111024163756:0CD3E470-FE80-11E0-89F0-A0E3D75F85EF
Powered by Listbox: http://www.listbox.com