Re: SPF include backdoors?

On 03/06/2014 09:46 AM, Marcus Bointon wrote:
> On 6 Mar 2014, at 15:03, Ian Eiloart <[email protected]> wrote:
>
>> A recursive check_host()
>> result of:	Causes the "include" mechanism to:
>> Pass		match
>> Fail		not match
>> SoftFail	not match
>> Neutral		not match
>> TempError	throw TempError
>> PermError	throw PermError
>> None		throw PermError
> >From that I gather that it would back-door your record if an included record was so foolish as to end in +all?
Think of include as "match if this other guy over there would give a 
pass".   Let's suppose you contract with an SMTP provider, 
mailout.example.com to send out your emails with their honking array of 
servers.  The IP addresses of their servers changes quite often as they 
upgrade their network.  So you include:spf.mailout.example.com, which 
they provide for use in your SPF record.  (mailout.example.com would 
likely be for *their* emails as opposed to their customers).

On the other hand, suppose you have a ?all policy because you have too 
many clients that couldn't correctly implement SPF checking to save 
their life (and insist on checking *after* the emails have already gone 
through a front end MX, for example, but without using the Received: 
header to compensate).  You notice, however, that most of the forgeries 
that caused you problems come from comcast.net, so you add 
-include:comcast.net to your policy.  "fail if comcast.net would give a 
pass".