https://bugs.exim.org/show_bug.cgi?id=2499
Bug ID: 2499
Summary: SPF false fail, empty MX lookups overwrite previous
good ones
Product: Exim
Version: N/A
Hardware: x86
OS: Linux
Status: NEW
Severity: bug
Priority: medium
Component: Lookups
Assignee: unallocated@???
Reporter: bugs-a17@???
CC: exim-dev@???
When a TXT SPF record contains two MX references, and the second reference
returns no DNS RRs, Exim erases the results retrieved from the first lookup,
treating it as also null. This causes the SPF ACL to return "fail" even though
the first MX clause should short-circuit the result as "pass".
I encountered this bug when, after I added "deny spf = fail" to my exim.conf, I
stopped receiving all mail from a mailing list I'm subscribed to. Gmail and
such had no problem with mail from the same list, nor did the "spfquery"
utility that accompanies libspf2. I reproduced it trivially using a local DNS
server.
To reproduce, create a DNS zone for "example.com" with the following:
$ORIGIN example.com.
@ MX 10 mta-1.example.com
TXT "v=spf1 mx mx:mta-1.example.com -all"
mta-1 A 1.2.3.4
And likewise the reverse:
$ORIGIN 3.2.1.in-addr.arpa
4 PTR mta-1.example.com.
Then, from the command line, run:
# exim -bh 1.2.3.4
220 localhost ESMTP Exim 4.93 ...
HELO mta-1.example.com
250 localhost Hello mta-1.example.com [1.2.3.4]
MAIL FROM:<test@???>
[ ... ]
processing "deny" (/etc/exim/exim.conf 123)
550 Your host 1.2.3.4 is not allowed to send mail from example.com
First, please note that "mx:mta-1.example.com" should be "a:mta-1.example.com".
As mta-1.example.com has no MX record in the DNS, the lookup returns null.
This is irrelevant, or rather it should be irrelevant, as SPF uses the first
matching clause ("short circuit") to determine outcome; as first clause "mx"
succeeds, the result should be "pass".
# spfquery -ip 1.2.3.4 -sender test@??? -helo mta-1.example.com
spfquery: domain of example.com designates 1.2.3.4 as permitted sender
Received-SPF: pass (spfquery: domain of example.com designates 1.2.3.4 as
permitted sender) client-ip=1.2.3.4; envelope-from=test@???;
helo=mta-1.example.com;
Taking a look at the Exim code, it seems that Exim is replacing the DNS lookup
code in libspf2 with its own (cached) version. Somewhere in the code path, the
result returned for the second lookup ("mx:mta-1.example.com") is overwriting
the DNS results returned for the first clause ("mx"), causing the first to also
fail. I didn't dig down into the innards to find out why. Hoping the author
here will recognize it and think of an easy patch/fix.
--
You are receiving this mail because:
You are on the CC list for the bug.
