Hector Santos wrote:
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?
Say I publish a policy for DomainA, but some of the users of DomainA
send also mail via an ISP on DomainB. DomainB is perfectly entitled to
publish a policy ending in -all as they know all of their mail servers,
and I have to include their SPF record as mail from DomainA can also be
sent via the same servers.
Or am I completely misreading you?
--
Rene Barbier