[exim-dev] [Bug 2499] New: SPF false fail, empty MX lookups…

Pàgina inicial
Delete this message
Reply to this message
Autor: admin
Data:  
A: exim-dev
Assumpte: [exim-dev] [Bug 2499] New: SPF false fail, empty MX lookups overwrite previous good ones
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.