I noticed that courier was rejecting mail from 192.168.5.5 (NOTE:
addresses/domains anonymized) with "517 SPF fail [email protected]:
Address does not pass the Sender Policy Framework" even though the SPF
for that domain passes all SPF check tools, such as the ones at
http://tools.bevhost.com/spf/ http://www.kitterman.com/spf/validate.html
and http://vamsoft.com/support/tools/spf-policy-tester
The domain in question uses the "include" mechanism in its SPF record,
and the included domain uses the "mx" mechanism. According to the RFC at
http://www.ietf.org/rfc/rfc4408.txt "include" should basically initiate
a new SPF lookup with <current-domain> changed to that of the included
domain. To the best of my understanding, the resolution chain should
basically go like this.
# dig -t txt example1.com +short
"v=spf1 include:example2.com -all"
# dig -t txt example2.com +short
"v=spf1 mx ~all"
# dig -t mx example2.com +short
10 mail.example2.com.
# dig -t A mail.example2.com +short
192.168.5.5
However, when looking up the mx record, Courier always pulls the domain
component from the mailfrom portion (which, unlike info.current_domain,
does NOT change when recursively calling lookup()), meaning it does a
lookup for mx entries for example1.com, instead of example2.com in the
third step, and the SPF check results in a "fail" instead of "pass" at
that point, since outbound mail is a different server than inbound mail
for example1.com. That is, it does this for the second and third steps:
# dig -t mx example1.com +short
10 smtp.example3.com
# dig -t A smtp.example3.com +short
192.168.200.200
As that obviously doesn't match 192.168.5.5 it falls to "-all" from the
initial record and fails, rejecting what should be a valid message.
I've attached a patch (spf-recursive.patch) which, I believe, properly
resolves the issue. However, as the current SPF tests provided with
courier (./testspf -test=1) do not work (the DNS records used are no
longer configured with SPF as far as I can tell) I don't have proper
unit tests. It's also possible that I (and several of the testing tools)
are misunderstanding the RFC, but I don't believe that is the case.
Please let me know if any further details are needed.
Thanks,
--Xepher
--- rfc1035/spf.c.orig 2014-08-16 18:19:19.583212703 -0700
+++ rfc1035/spf.c 2014-08-16 18:18:44.621289451 -0700
@@ -502,7 +502,7 @@
if (*start == 0 || *start == '/')
{
- *domain_ptr=strdup(strrchr(info->mailfrom, '@')+1);
+ *domain_ptr=strdup(info->current_domain);
if (*start == '/')
*pfix_ptr=get_dual_cidr_length(start);
@@ -523,8 +523,7 @@
if (*domain_ptr == 0)
{
free(*domain_ptr);
- *domain_ptr=strdup(strrchr(info->mailfrom,
- '@')+1);
+ *domain_ptr=strdup(info->current_domain);
}
}
------------------------------------------------------------------------------
Slashdot TV.
Video for Nerds. Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
courier-users mailing list
[email protected]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
