On 9/2/2010 8:24 AM, Chris Datfung wrote:
On Thu, Sep 2, 2010 at 2:30 PM, Matt Kettler <mkettler...@verizon.net
<mailto:mkettler...@verizon.net>> wrote:
Can you try again using a message, such as the sample-spam.txt
that comes with the SA tarball.
spamassassin < sample-spam.txt 2>&1 -D
In particular, we want to look at the "dbg: dns: is DNS
available?" line and other DNS related ones nearby.
Hi Matt,
I included (hopefully only) the relevant data from the above command
below:
Sep 2 22:13:42.202 [11886] dbg: dns: checking RBL combined.njabl.org
<http://combined.njabl.org>., set njabl
<snip>
Sep 2 22:13:42.202 [11886] dbg: dns: checking RBL dnsbl.njabl.org
<http://dnsbl.njabl.org>., set njabl
<snip>
Well that sure looks like it is querying your dnsbl.njabl.org, and the
default rulset rule which uses combined.njabl.org.
What makes you think that it's not running the query?
Is your rule IN_NJABL_ORG never hitting? What about RCVD_IN_NJABL_*
rules (the rules that are part of the stock ruleset and query the same
DNSBL, but in a different way)? Are they hitting?
Is your mail already filtered at the MTA layer rejecting messages in
NJABL (which would make it much less likely, but not impossible, to see
hits)?
Are you on AT&T as an internet provider and using their DNS servers?
According to the NJABL FAQ, AT&T intentionally poisons dnsbl.njabl.org
(starting in 2004, they may or may not still do so), returing a NS
record pointing to 127.0.0.1.
Try this on the command line:
dig ns dnsbl.njabl.org
If you get no answer, or something like this:
;; AUTHORITY SECTION:
dnsbl.njabl.org. 82758 IN NS loopback.
;; ADDITIONAL SECTION:
loopback. 52978 IN A 127.0.0.1
Your provider is messing with you.
