Subject: Re: [spfbis] #22: RFC 4408: Section 2.5.7 PermError on invalid domains after macro expansion

From: S Moonesamy <[email-masked]>
Date: Thu, 23 Aug 2012 09:06:18 -0700

At 08:21 21-02-2012, spfbis issue tracker wrote:
>#22: RFC 4408: Section 2.5.7 PermError on invalid domains after 
>macro expansion
>
>  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.
>
>  http://www.ietf.org/mail-archive/web/spfbis/current/msg00476.html

Can WG participants please review draft-ietf-spfbis-4408bis-06 and 
comment on Issue #22?

Regards,
S. Moonesamy

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 30 Aug 2012 13:18:10 +0200

On Thu 23/Aug/2012 18:06:18 +0200 S Moonesamy wrote:
>>  syntactically malformed <target-name> can be also handled as no
>>  match. The specification should say:
>>
>> 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.
>>
>>  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.
>>
>> 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.
>>

It is not clear whether the above provides for derivative strategies,
such as throwing an error depending on the qualifier of the "all"
mechanism.  I'd opt to allow implementation-dependent behavior as long
as an evaluation that went through errors cannot result in a "pass".

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 30 Aug 2012 06:39:34 -0700

>>  differ from that for an unexpected <target-name> after macro expansion.

I prefer this solution, with some corrections to the final paragraph
(get rid of "throw" as has been done elsewhere, correct "to treat as
a", and give an example of what the last sentence is talking about).

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 30 Aug 2012 10:16:10 -0500

"Murray S. Kucherawy" <[email-masked]> wrote:

>match.
>>> The
>by

If I understand this correctly, you're favoring documenting the current ambiguity, but not resolving it?

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 30 Aug 2012 12:25:34 -0700

> If I understand this correctly, you're favoring documenting the current ambiguity, but not resolving it?

If that's the signal you're getting from my reply then maybe I'm not
understanding the problem.  However, Suggested Variant 1 (upthread a
bit) also doesn't seem to do much other than document the ambiguity.

Is there a proposal for something more firm that I missed?

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 30 Aug 2012 16:12:54 -0400

> Is there a proposal for something more firm that I missed?

Leaving specific wording aside for a moment, I think there are three options:

Invalid domains after macro expansion (empty label/label too long) produce 
domains that can never be matched, but there is no error returned.

Invalid domains after macro expansion (empty label/label too long)  are rrors 
and a permerror is returned.

The current spec is ambiguous on which of these is correct and there are 
implementations that do both (thus the erratum).  We could leave this 
ambiguity and specify it as OK and warn against relying on either behavior.

Obviously documenting the discrepancy and moving on is the most backward 
compatible solution, but it does leave ambiguity.  Personally, I'm inclined to 
make them errors, but I'm not sure that's right.

Scott K