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

From: Arthur Thisell <[email-masked]>
Date: Thu, 30 Aug 2012 18:24:39 -0700 (PDT)

I did some more digging around in old SPF drafts.   My notes apparently say that there are many conflicts on this subject between the pre-marid drafts, marid drafts and the implementations.  I had forgotten how much of a mess it is.

No matter what we do, we will still have conflicts between drafts and conflicting implementations will be around for years.  *sigh*

Besides the three options you mentioned, the current text about in the RFC about chopping off labels until there are fewer than 253 octets could be expanded to chopping off labels until the domain is valid, but I don't much like that one.

I'm kind of leaning toward making invalid domains not match.

I guess no matter what we do, documenting this known brain damage is probably a good idea.

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 30 Aug 2012 22:10:00 -0400

Arthur Thisell <[email-masked]> wrote:

>I did some more digging around in old SPF drafts.   My notes apparently
>say that there are many conflicts on this subject between the pre-marid
>drafts, marid drafts and the implementations.  I had forgotten how much
>of a mess it is.
>
>No matter what we do, we will still have conflicts between drafts and
>conflicting implementations will be around for years.  *sigh*
>
>Besides the three options you mentioned, the current text about in the
>RFC about chopping off labels until there are fewer than 253 octets
>could be expanded to chopping off labels until the domain is valid, but
>I don't much like that one.
>

I think we need to document the brain damage so people know not to rely on either behavior and pick either no match or permerror as correct.  

I have a slight preference for permerror, but I care more about picking an unambiguous 'right' way for the future than which one we pick.

Scott K

---

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

> I think we need to document the brain damage so people know not to rely on either behavior and pick either no match or permerror as correct.

+1.

> I have a slight preference for permerror, but I care more about picking an unambiguous 'right' way for the future than which one we pick.

Since we're talking about data that are plainly malformed, I'm
inclined to agree with permerror.  But my preference is also slight.

-MSK

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 31 Aug 2012 10:17:46 +0200

On Fri 31/Aug/2012 05:32:06 +0200 Murray S. Kucherawy wrote:
>> I have a slight preference for permerror, but I care more about
>> picking an unambiguous 'right' way for the future than which one
>> we pick.
> 

Non-match makes sense in case the record is correct, but the parameter
is malicious, e.g.:

   exists:{%l}.{%o}._spf.lengthy-subdomain.example

That may match all allowed users, but can be made longer than 63 or
empty-label.  It is not an error in the record, and it would produce
noise to consider it as such if error reports are requested.

OTOH, exists:{%ir}.my..bad.example is a reportable error.

I agree the 'right' way is permerror.  However, leaving some leeway
spares us a change in the spec while also allowing the verifying
software to detect malicious macros and do better if it can.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 31 Aug 2012 07:18:32 -0700

> Non-match makes sense in case the record is correct, but the parameter

Is there a deterministic way to identify abuse?

"Do X if the input data is malicious" is not a recipe for normative guidance.

We need to pick the one that's more generally applicable, and move
forward with it.

-MSK