Re: The demon problem, ancestor matching, and match_subdomains=yes

> On Friday March 19, mengwong(_at_)dumbo(_dot_)pobox(_dot_)com wrote:
> > We've been thinking about this.  Some thinking is at:
> > http://spf.pobox.com/faq.html#demon
> >
> > But maybe we want to allow ancestor search for a record with a
> > match_subdomains=yes modifier.
--Neil Brown <neilb(_at_)cse(_dot_)unsw(_dot_)edu(_dot_)au> wrote:
> Would it make sense to take the following approach:
>
>  If there is no SPF record for the domain, but there are MX records,
>  choose an MX record with minimal priority and look for an SPF record
>  at that domain.
>
> I think this would do the right thing all the time, and makes it a lot
> easier to manage SPF records.

This might help to find an SPF record, but it may not be suitable for all 
the names that point mail at that server... the SPF record for a mail 
server is a lot more restrictive, usually.

I believe any domain that has an MX record ought to have SPF records as 
well.  Unfortunately there is the antiquated "Fallback to A" behavior still 
out there, where there is no MX, so SPF calls for putting in SPF records to 
match all your A records as well.  I don't like this, but I dislike the 
alternative even more (which is to "go up" a level until you find one, but 
the parent domain is not guaranteed to be owned by the same people at all.)
I am looking forward to the day when mail never gets addressed to an A 
record (like webmaster(_at_)www(_dot_)example(_dot_)com).  If there is no MX, shouldn't that 
be enough to tell you that they don't want mail?  But, lots more MX records 
would need to be added for this to happen.  For example, list mail comes to 
me from "portent.listbox.com" and if that server were to produce a bounce 
message it would probably be from MAILER-DAEMON(_at_)portent(_dot_)listbox(_dot_)com - but 
that name has no MX or TXT.  If there is ever a movement in the direction 
of "send mail to MX but never to A" then the mail servers themselves would 
need to add (portent MX 0 portent).  Sigh... I guess falling back to A is a 
necessity.
I am going to stick with the opinion that "create a lot of SPF records, as 
many as you have MX or A now" is still the best way.  If I HAD to come up 
with a solution to make one SPF record cover a whole domain, I would 
probably suggest something like:
 1. Try "sub.domain.co.xx" TXT - there isn't one
 2. Try "sub.domain.co.xx" SOA - this tells you the nearest start of 
authority above that subdomain.  (For example "dig www.demon.co.uk soa" 
gives "demon.co.uk."
 3. Look for SPF at that level.  (For example "dig demon.co.uk txt")
 3a. If SPF exists for the same label as the SOA, honor it if it says 
"match_subdomains=yes"
 3b. If SPF does not exist for the SOA domain name, stop.  You have found 
the owner of the zone and the owner has not published SPF.  Do not go up 
the chain any further.
It is *possible* for a domain owner to have lots of SOA records at various 
levels, and still be owned by the same people (such as yahoo.com and 
corp.yahoo.com)... but without knowing the internals of their operation, 
it's impossible for an outsider (or any automated system) to know for sure. 
I think stopping at the SOA and not going "up" any further is a good way to 
ensure that the "ownership" and "authority" comes from the same place. 
Some domain owners may want to optimize things further, but I think it's 
not really a significant burden to ask them to include an SPF wherever 
there is an SOA (it can even be a redirect or include)
I am not 100% sure about the extra qualifier "match_subdomains=yes" BUT it 
is is a heck of a lot safer.  If the SPF record at the SOA level is assumed 
to apply to all subdomains, then the rules I might publish for demon.co.uk 
would probably affect gconnor.demon.co.uk also -- you would have to put in 
SPF for all the exceptions and then we're back where we started almost.
--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>