Troubleshooting dnsbl

Troubleshooting dnsbl

am 31.03.2008 05:55:51 von Wincent Colaiuta

I've just moved servers and the dnsbl config that previously worked no
longer does (sendmail 8.13.8-2.el5 as shipped with Red Hat EL 5.1);
these are the two lines from sendmail.mc:

FEATURE(`delay_checks', `friend')dnl
FEATURE(`dnsbl', `zen.spamhaus.org')dnl

I tried the debugging tips listed at:

http://www.sendmail.org/~ca/email/chk-dbg.html

ie. add this to sendmail.cf

SStart
R$* $$| $* $: $1 $| $2

Then:

sendmail -bt -d21.4
> .D{client_addr}17.254.13.7
> Start,checkrelay mail-in11.apple.com $| 17.254.13.7

(Note that I had to use checkrelay, check_relay is not defined in my
sendmail.cf when I use delay_checks)

This eventually boils down to this:

rewritten as: OK
rewrite: RHS $&{client_addr} => "127.0.0.1"
rewritten as: 127 . 0 . 0 . 1
rewritten as: < ? > 1 . 0 . 0 . 127 . zen . spamhaus . org . < TMP >
rewritten as: TMPOK
Basic_check_rela returns: TMPOK
rewritten as: TMPOK
checkrelay returns: TMPOK
== Ruleset checkrelay (190) status 75

If I drop the delay_checks and test again (this time using
"check_relay" rather than "checkrelay"), the test run ends with this
output:

rewritten as: < ? > < >
rewritten as: OK
rewrite: RHS $&{client_addr} => "17.254.13.7"
rewritten as: 17 . 254 . 13 . 7
rewritten as: < ? > 7 . 13 . 254 . 17 . zen . spamhaus . org . < TMP >
rewritten as: TMPOK
Basic_check_rela returns: TMPOK
rewritten as: TMPOK
check_relay returns: TMPOK
== Ruleset check_relay (190) status 75

I don't really know enough to interpret this output, but I see that
when delays_checks is active 127.0.0.1 is getting checked with the
dnsbl, which is not very helpful. When delay_checks is off at least
the right IP gets checked, or so it would seem.

Nevertheless, sending a test message to nelson-sbl-test@crynwr.com
(test address for the Spamhaus dnsbl) confirms my observations that
the dnsbl isn't working, regardless of whether I use delay_checks.

Any ideas on how I can explore this further?

Cheers,
Wincent

Re: Troubleshooting dnsbl

am 31.03.2008 06:32:32 von unknown

Post removed (X-No-Archive: yes)

Re: Troubleshooting dnsbl

am 31.03.2008 09:03:38 von Wincent Colaiuta

On 31 mar, 06:32, Res wrote:
> On Sun, 30 Mar 2008, Wincent Colaiuta wrote:
> > FEATURE(`delay_checks', `friend')dnl
>
> You don't really need 'friend' anymore but thats not your problem..

Really? I've got this in my /etc/mail/access because abuse and
postmaster need to be excluded for RFC compliance:

Spam:abuse@ FRIEND
Spam:postmaster@ FRIEND

Are you saying that if this will still work if I change my
delay_checks to?:

FEATURE(`delay_checks')dnl

> > FEATURE(`dnsbl', `zen.spamhaus.org')dnl
>
> Jump on your mail server and try a lookup, one that should get a hit that
> I just say from a tail on one of my maillogs is
>
> =A0 =A0 =A0 =A0 ~$ host 202.72.168.118.zen.spamhaus.org
>
> you should see
> =A0 =A0 =A0 =A0 202.72.168.118.zen.spamhaus.org has address 127.0.0.11
>
> If it does not respond, chances are you have bene filtered by spamhaus for=

> 'excessive querries', its their way of making you pay to do lookups, so if=

> that test fails use:

Yep, that looks to be the problem:

host 202.72.168.118.zen.spamhaus.org
;; connection timed out; no servers could be reached

Although in my case it can't possibly be excessive look-ups; I am
_way_ under the limits they list (well under 1% of their limits, I'd
say) and in any case only just moved to the new server and new IP on
Friday. Maybe a former owner of my IP is on their list of commercial
users...

Cheers,
Wincent

Re: Troubleshooting dnsbl

am 31.03.2008 09:44:20 von unknown

Post removed (X-No-Archive: yes)

Re: Troubleshooting dnsbl

am 31.03.2008 12:05:33 von Wincent Colaiuta

On 31 mar, 09:44, Res wrote:
>
> In most cases you can avoid their blacklist by using a different DNS
> server, if your box is a dedicated IP for mail/web etc, install BIND in
> cache config, and have your mailserver query 127.0.0.1, you'll find
> possibly you can again use spamhaus as it may not be your IP but your new
> DNS server that has been blocked, sadly though, there are enough people
> out there runnig open DNS servers so if you cant resolve it locally try
> use one of them :)
>

I queried my hosts (INetU) about this and my contact told me that it
does indeed look like Spamhaus has a block in place for their
nameservers. He said that they used to use the Spamhaus lists but no
longer do so. I've sent an email to Spamhaus asking them about the
block and if there is any chance of removing it, although I am not all
that hopeful about getting a reply.

Like you say, the only workaround may be to run a local caching DNS
just for sendmail and find some appropriate upsteam DNS servers. A bit
ugly, but it may be the only way.

Cheers,
Wincent

Re: Troubleshooting dnsbl

am 31.03.2008 12:39:42 von unknown

Post removed (X-No-Archive: yes)

Re: Troubleshooting dnsbl

am 31.03.2008 13:54:32 von Scott Grayban

Wincent Colaiuta wrote:
> On 31 mar, 09:44, Res wrote:
>> In most cases you can avoid their blacklist by using a different DNS
>> server, if your box is a dedicated IP for mail/web etc, install BIND in
>> cache config, and have your mailserver query 127.0.0.1, you'll find
>> possibly you can again use spamhaus as it may not be your IP but your new
>> DNS server that has been blocked, sadly though, there are enough people
>> out there runnig open DNS servers so if you cant resolve it locally try
>> use one of them :)
>>
>
> I queried my hosts (INetU) about this and my contact told me that it
> does indeed look like Spamhaus has a block in place for their
> nameservers. He said that they used to use the Spamhaus lists but no
> longer do so. I've sent an email to Spamhaus asking them about the
> block and if there is any chance of removing it, although I am not all
> that hopeful about getting a reply.
>
> Like you say, the only workaround may be to run a local caching DNS
> just for sendmail and find some appropriate upsteam DNS servers. A bit
> ugly, but it may be the only way.
>
> Cheers,
> Wincent
>

Spamhaus is *known* to change there policy at a whim and then not notify anyone.

Trying to get out of the blacklist from queries will fall on deaf ears, we
went through that and we ended up paying for access.

We eventually stopped using them altogether and now use SpamCop,
psbl.surriel.com, dnsbl.sorbs.net, blackholes.easynet.nl,
blackholes.mail-abuse.org, list.dsbl.org, &
combined-HIB.dnsiplists.completewhois.com which covers just about any and all
spam and spmmers.

Scott