Subject: Re: [spfbis] spfbis Digest, Vol 10, Issue 21

From: Arthur Thisell <[email-masked]>
Date: Sat, 18 Aug 2012 18:59:33 -0700 (PDT)

> So let's say your SPF record has
>
>   exists:%{l}.users.example.com
>
> The bounce address is john.doe at example.com, so it looks up
> john.doe.users.example.com.  Is that first dot a delimiter between two
> components or part of the first component? 

John, you are the first person I've seen who as wondered if the first dot might be part of the first label.  It isn't.  People have been depending on it not since 2004 or so.   What is passed to the resolver is the string.  Please note that even RFC4408 said "The result of the macro expansion is not subject to any further escaping.  Hence, this facility cannot produce all characters that are legal in a DNS label (e.g., the control characters)."  A dot is another character SPF can't generate.

> What if the address is
> john..doe at example.com?  Does that create a valid or an invalid domain
> name?

yes, two dots in a row (null label) creates an invalid domain name.

> I have seen people stick a dot in there using \.
> which works in master files, but as far as I know not in resolver
> libraries.

I am not longer easily able to test this, but as I said in earlier posts, yes, I've tested it years ago.   It worked.

> Since approximately nobody has noticed this before, it just confirms
> that approximately nobody uses macros.
I glad to hear a whole bunch of people are nobodies.

The use of %{l} being used to inject potentially bad stuff was discussed several times in the years 2003-2005 (e.g., before RFC4408 was published).  There was a long discussion about a contrived example of mx:%{l} with "aol.com" used as a local part.   The conclusion was "it is stupid to publish such a SPF record".

I guess I don't have any objections adding something to the draft that points out that using SPF causes queries to other DNS servers.  Those DNS servers can send back answers such as referring to another name server which has malicious characters in the labels of that NS which can cause your name server to blow up.

Or, we could just remain silent until there is some evidence that this is a problem worth worrying about.