You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spamassassin.apache.org by bu...@bugzilla.spamassassin.org on 2017/02/13 19:20:48 UTC
[Bug 7392] New: SPF query randomly returning "result: none"
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7392
Bug ID: 7392
Summary: SPF query randomly returning "result: none"
Product: Spamassassin
Version: 3.4.1
Hardware: PC
OS: All
Status: NEW
Severity: blocker
Priority: P2
Component: spamassassin
Assignee: dev@spamassassin.apache.org
Reporter: arielgrin@hotmail.com
Target Milestone: Undefined
I'm using SpamAssassin 3.4.1 (checked both on Perl 5.10.1 on RHEL6 and Perl
5.24.1 on Win2003 Server SP1) and it seems that SPF queries are randomly
returning "result: none" while performing DNS based checks, even though the TXT
record exists and previous queries return expected result. I read about a bug
on Net::DNS 1.03 that might be related to this, but my Net::DNS version is
1.07, so not sure if it might be related or not.
As a consequence of this random inability to get the correct result, SPF_
related rules are not hit.
For example, running spamassasin first time, this is the result:
feb 13 15:40:29.985 [19480] dbg: spf: query for
comercial7@itser.com.ar/173.237.189.179/rock.webserverns.com: result: pass,
comment: , text: Mechanism 'ip4:173.237.189.179' matched
Running it again 2 minutes later, this is the result:
feb 13 15:42:08.686 [19590] dbg: spf: query for
comercial7@itser.com.ar/173.237.189.179/rock.webserverns.com: result: none,
comment: , text: No applicable sender
And this situation repeats itself
Running spamassasin one more time:
feb 13 16:16:13.249 [23894] dbg: spf: query for
comercial7@itser.com.ar/173.237.189.179/rock.webserverns.com: result: pass,
comment: , text: Mechanism 'ip4:173.237.189.179' matched
Running it again immediately after last run:
feb 13 16:16:25.696 [23909] dbg: spf: query for
comercial7@itser.com.ar/173.237.189.179/rock.webserverns.com: result: none,
comment: , text: No applicable sender policy available
Please let me know if you would need any additional information provided.
Regards, Ariel.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 7392] SPF query randomly returning "result: none"
Posted by bu...@bugzilla.spamassassin.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7392
--- Comment #9 from Ariel Grin <ar...@hotmail.com> ---
Created attachment 5438
--> https://bz.apache.org/SpamAssassin/attachment.cgi?id=5438&action=edit
2nd try, "result: none"
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 7392] SPF query randomly returning "result: none"
Posted by bu...@bugzilla.spamassassin.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7392
--- Comment #2 from Ariel Grin <ar...@hotmail.com> ---
Created attachment 5435
--> https://bz.apache.org/SpamAssassin/attachment.cgi?id=5435&action=edit
Debug log with SPF "result: pass"
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 7392] SPF query randomly returning "result: none"
Posted by bu...@bugzilla.spamassassin.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7392
Ariel Grin <ar...@hotmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|INVALID |---
Status|RESOLVED |REOPENED
--- Comment #7 from Ariel Grin <ar...@hotmail.com> ---
Sorry to reopen this, but I still think there is something going on with SPF
queries, as I tried it again and got random failures too.
I tried it again with other DNS and with other domain, brokers.com.ar, which I
know for a fact that has a valid SPF with no broken records.
Again, running spamassassin once, I get "result: pass" and SPF_PASS rule is
hit, and a second run immediately after the first one returns "result: none"
and no SPF rules are hit at all.
I'm attaching full logs and below is the line of the rules that are hit for the
two different consecutive runs
feb 15 08:04:36.838 [4313] dbg: check:
tests=DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,RP_MATCHES_RCVD,SPF_PASS
feb 15 08:04:46.284 [4323] dbg: check:
tests=DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,RP_MATCHES_RCVD
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 7392] SPF query randomly returning "result: none"
Posted by bu...@bugzilla.spamassassin.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7392
Ariel Grin <ar...@hotmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Component|spamassassin |Plugins
CC| |arielgrin@hotmail.com
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 7392] SPF query randomly returning "result: none"
Posted by bu...@bugzilla.spamassassin.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7392
Peter Ferri <pe...@bit.admin.ch> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |peter.ferri@bit.admin.ch
--- Comment #11 from Peter Ferri <pe...@bit.admin.ch> ---
(In reply to Ariel Grin from comment #10)
> Maybe it is not drectly an SPF issue, but an incompatible combination of
> versions of the different modules involved, like Mail::SPF and
> Net::DNS::Resolver::Programmable
Hi Ariel,
did you find a solution to your issue ? Since we are having the same
occurances, we are running SA 3.4.1 Perl 5.18.2 on SLES 12 Servers.
Rgds
Peter
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 7392] SPF query randomly returning "result: none"
Posted by bu...@bugzilla.spamassassin.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7392
Bill Cole <sa...@billmail.scconsult.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|REOPENED |RESOLVED
Resolution|--- |FIXED
--- Comment #15 from Bill Cole <sa...@billmail.scconsult.com> ---
Fixed in 3.4 branch (3.4.2-to-be) and trunk
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 7392] SPF query randomly returning "result: none"
Posted by bu...@bugzilla.spamassassin.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7392
--- Comment #10 from Ariel Grin <ar...@hotmail.com> ---
Maybe it is not drectly an SPF issue, but an incompatible combination of
versions of the different modules involved, like Mail::SPF and
Net::DNS::Resolver::Programmable
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 7392] SPF query randomly returning "result: none"
Posted by bu...@bugzilla.spamassassin.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7392
--- Comment #13 from Peter Ferri <pe...@bit.admin.ch> ---
Hi Kevin,
thanks for your reply, we did update to Net::DNS 1.10 already.
We are now investigating in the DNS Queries. we believe that the DNS Servers
answer with "SPF None" for some examples. Our example is hq.nato.int which
merely replies with "none" although there is a TXT (SPF) Record for that
domain.
rgds
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 7392] SPF query randomly returning "result: none"
Posted by bu...@bugzilla.spamassassin.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7392
RW <rw...@googlemail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rwmaillists@googlemail.com
--- Comment #1 from RW <rw...@googlemail.com> ---
You should be seeing both of those results per scan. The pass on ip4 is the
envelope sender result for itser.com.ar and the none result with "No applicable
sender policy" is the HELO result for rock.webserverns.com. What's probably
confusing you is that the two results are not logged in a consistent order, and
you have to look at the surrounding debug lines to tell which is which.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 7392] SPF query randomly returning "result: none"
Posted by bu...@bugzilla.spamassassin.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7392
--- Comment #8 from Ariel Grin <ar...@hotmail.com> ---
Created attachment 5437
--> https://bz.apache.org/SpamAssassin/attachment.cgi?id=5437&action=edit
2nd try, "result: pass"
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 7392] SPF query randomly returning "result: none"
Posted by bu...@bugzilla.spamassassin.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7392
Bill Cole <sa...@billmail.scconsult.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |INVALID
Status|NEW |RESOLVED
CC| |sa-bugz-20080315@billmail.s
| |cconsult.com
--- Comment #6 from Bill Cole <sa...@billmail.scconsult.com> ---
Your DNS server at 192.168.122.1 is not answering consistently. In the "pass"
example it is replying with 1 TXT (SPF) record for itser.com.ar but in the
"none" example it is replying that there are no TXT records for that domain.
Her are the relevant lines from your logs:
Pass:
feb 14 09:11:55.389 [2908] dbg: spf: checking EnvelopeFrom
(helo=rock.webserverns.com, ip=173.237.189.179,
envfrom=comercial7@itser.com.ar)
feb 14 09:11:55.391 [2908] dbg: dns: bgsend, DNS servers: [192.168.122.1]:53
feb 14 09:11:55.391 [2908] dbg: dns: attempt 1/1, trying connect/sendto to
[192.168.122.1]:53
feb 14 09:11:55.397 [2908] dbg: dns: providing a callback for id:
15727/IN/TXT/itser.com.ar
feb 14 09:11:55.566 [2908] dbg: dns: dns reply 15727 is OK, 1 answer records
None:
feb 14 09:14:31.361 [608] dbg: spf: checking EnvelopeFrom
(helo=rock.webserverns.com, ip=173.237.189.179,
envfrom=comercial7@itser.com.ar)
feb 14 09:14:31.362 [608] dbg: dns: bgsend, DNS servers: [192.168.122.1]:53
feb 14 09:14:31.363 [608] dbg: dns: attempt 1/1, trying connect/sendto to
[192.168.122.1]:53
feb 14 09:14:31.364 [608] dbg: dns: providing a callback for id:
5783/IN/TXT/itser.com.ar
feb 14 09:14:31.531 [608] dbg: dns: dns reply 5783 is OK, 0 answer records
Complicating matters, the SPF record for itser.com.ar is broken (it has
"include" elements that have no TXT records) but that's not likely to be the
root of your problem.
SpamAssassin is behaving as designed: when it can find an SPF record to use, it
uses it, but when DNS provides no SPF record it returns "none"
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 7392] SPF query randomly returning "result: none"
Posted by bu...@bugzilla.spamassassin.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7392
--- Comment #5 from RW <rw...@googlemail.com> ---
I can't reproduce this (FreeBSD 10.3, spamassassin 3.4.1, perl 5.24, Net:DNS
1.07).
Do the RHEL6 and Win2003 machines have a DNS cache in common that might be
causing it?
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 7392] SPF query randomly returning "result: none"
Posted by bu...@bugzilla.spamassassin.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7392
--- Comment #4 from Ariel Grin <ar...@hotmail.com> ---
(In reply to RW from comment #1)
> You should be seeing both of those results per scan. The pass on ip4 is the
> envelope sender result for itser.com.ar and the none result with "No
> applicable sender policy" is the HELO result for rock.webserverns.com.
> What's probably confusing you is that the two results are not logged in a
> consistent order, and you have to look at the surrounding debug lines to
> tell which is which.
Maybe I didn't explain myself correctly before. The issue is that in one run of
spamassasin, the result would be "result:none" and no SPF rules are hit, and on
another run of spamassassin over the same mail, the result would be "result:
pass" and the SPF_PASS would be hit.
The results I attached before are not part of the same run, but each one of
them is from a different run, and I checked at the surrounding lines, to make
sure that the behaviour was failing randomly.
I'm attaching the complete logs for both runs, one with "result: pass" and
SPF_PASS rule hit, and another with "result: none" and no SPF rules hit at all.
As you can see, in the first run the result is pass and SPF_PASS rule is hit,
but in the second run over the same email, the result is none and no SPF rules
are hit at all, so it is obvious that the SPF query is failing randomly, I just
don't know why.
As a preview, I'm showing you the test debug lines, where it can be seen that
one test has the SPF_PASS and the other one does not have it.
feb 14 09:11:59.006 [2908] dbg: check:
tests=DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HTML_IMAGE_RATIO_04,HTML_MESSAGE,SPF_PASS
feb 14 09:14:35.118 [608] dbg: check:
tests=DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HTML_IMAGE_RATIO_04,HTML_MESSAGE
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 7392] SPF query randomly returning "result: none"
Posted by bu...@bugzilla.spamassassin.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7392
Kevin A. McGrail <km...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |kmcgrail@apache.org
--- Comment #12 from Kevin A. McGrail <km...@apache.org> ---
Peter & Ariel, can you try the SVN version of SA? There is a change in
Net::DNS which might be causing some of the issue.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 7392] SPF query randomly returning "result: none"
Posted by bu...@bugzilla.spamassassin.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7392
--- Comment #3 from Ariel Grin <ar...@hotmail.com> ---
Created attachment 5436
--> https://bz.apache.org/SpamAssassin/attachment.cgi?id=5436&action=edit
Debug log with SPF "result: none"
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 7392] SPF query randomly returning "result: none"
Posted by bu...@bugzilla.spamassassin.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7392
--- Comment #14 from Bill Cole <sa...@billmail.scconsult.com> ---
(In reply to Peter Ferri from comment #13)
> Hi Kevin,
> thanks for your reply, we did update to Net::DNS 1.10 already.
This supports Kevin's recommendation of switching to the current trunk or 3.4.2
branch version of SpamAssassin from our Subversion server as a likely solution.
Thee was a change in Net::DNS between 0.83 and 1.01 which changed the format of
some DNS responses when checked using a method that returned DNS responses as a
RFC-1035 string (i.e. "zonefile" format,) determined by record length. This
broke SA's interpretation of DNS responses in the places where that method was
used. The problem has been fixed in the codebase, but there has not been a
release of a patched version.
--
You are receiving this mail because:
You are the assignee for the bug.