SPF include backdoors?

[Marcus Bointon]

If you have an SPF record along the lines of "ip4:x.x.x.x. include:example.com -all", and the SPF it includes from example.com is like "ip4:x.x.x.x ?all", is it effectively back-dooring any host into being allowed to send from your domain because it will match the ?all in the include before it reaches the -all in your own?

Marcus

[Ian Eiloart]

Post by Marcus Bointon
If you have an SPF record along the lines of "ip4:x.x.x.x. include:example.com -all", and the SPF it includes from example.com is like "ip4:x.x.x.x ?all", is it effectively back-dooring any host into being allowed to send from your domain because it will match the ?all in the include before it reaches the -all in your own?

The specification says no. http://www.openspf.org/RFC_4408#mech-include

Of course, there’s no guarantee that any individual implementation will get it right. So, if you’re publishing, then it’s out of your hands. If you’re writing, or deploying, an implementation, then test it to be sure.

There is a vulnerability in include, though it’s not the one you’ve raised. If you publish a record including a third party record, then your record will fail if the third party record is invalid or non-existant.

From the spec:

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

[Marcus Bointon]

Post by Ian Eiloart
A recursive check_host()
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?

Marcus
--
Marcus Bointon
Technical Director, Synchromedia Limited

Creators of http://www.smartmessages.net/
UK 1CRM solutions http://www.syniah.com/
***@synchromedia.co.uk | http://www.synchromedia.co.uk/




-------------------------------------------
Sender Policy Framework: http://www.openspf.net [http://www.openspf.net]
Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]

Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/6959934-50ec8f89
Modify Your Subscription: https://www.listbox.com/member/?member_id=6959934&id_secret=6959934-b7c4528d
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=6959934&id_secret=6959934-edadf31a&post_id=20140306094627:15C7358E-A53E-11E3-9A46-867D96680265
Powered by Listbox: http://www.listbox.com

[Stuart Gathman]

Post by Ian Eiloart
A recursive check_host()
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".