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: unalloca...@exim.org Reporter: bugs-...@moonlit-rail.com CC: exim-dev@exim.org 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:<t...@example.com> [ ... ] 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 t...@example.com -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=t...@example.com; 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. -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##