In Section "5.2 Include"
It talks about handling the include statement.
I was updating my SPF implementation and I was running some test against my
test suite that test many scenarios of includes, in particular malicious
recursions. I came across one such as:
IP: 216.243.68.59
HELO: millipede.postdirect.com
MFROM: illuminations(_at_)illuminations(_dot_)p0(_dot_)com
The SPF records are:
illuminations.p0.com
"v=spf1 a ptr include:postdirect.com include:clickaction.net
include:easymailers.org -all"
postdirect.com
"v=spf1 a ptr -all"
clickaction.net
"v=spf1 a ptr include:postdirect.com include:easymailers.org -all"
easymailers.org
"v=spf1 a ptr include:postdirect.com include:clickaction.net -all"
As you can see, this is a malicious recursive SPF publication.
I was thinking about better ways to handle this.
1) Any domain that publishes a recursive domain of count 1 should be deemed
a PERMERROR.
I don't see any reason for a valid system to be repeating a recursion of the
same domain. This may require a SPF implementation to keep a stack of
domains checked and watch for a repeat. Nonetheless, my assertion is that
it should not be a tolerated and therefore I consider this a POOR setup or
MALICIOUS setup.
Do you see a reason where a RECURSION of the same domain is valid? I don't.
This will drastically improve DNS lookups. A test for this specific domain
takes a rather long time.
2) Using INCLUDES must be SOFTFAILS otherwise a FAIL is assumed.
The table in section 5.2 shows:
A recursive check_host() result of: Fail
---> Causes the "include" mechanism to: not match
This implies you should continue with the test.
It would seem to me that anyone what is going to use a INCLUDE should do
with a SOFTFAIL for the included domain. In this case, this triggers the
first level check to go to the next directive.
Example:
DomainA
v=spf1 a ptr include:DomainB include:DomainC -all
DomainB
v=spf1 a ptr ~all
DomainC
v=spf1 a ptr ~all
The reason I say this is because if a system tried to go direct to domainB
or domainC, and they had a hard fail -ALL, then it would a rejected
situation.
So the question is, why is a NOT a rejection when it is used as a INCLUDE?
My point is, if a legit system is going to cross domains, the crossed
domains should not fail in situations if they were directed checked. The
system which attempts to create such policies, in my view, so prepare it
correctly so that it doesn't become a burden on the SPF network.
Comments?
What don't I see here?
Thanks
Sincerely,
Hector Santos, CTO
Santronics Software, Inc.
http://www.santronics.com
305-431-2846 Cell
305-248-3204 Office