You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Michael Brunnbauer <br...@netestate.de> on 2018/04/01 14:25:52 UTC
This sucks
hi
I think I lost quite a few customers in the last months because DNS-lookups
are fucked up with Spamassassin so all DNSBL tests won't trigger while not
reporting errors. A problem with newer versions of Net::DNS that has been
known for months without any consequences - like a new release. This sucks.
So I downgraded to Net-DNS-0.83 today and got spamassassin working but not
spamd.
spamassassin -D looks like:
Apr 1 15:30:18.733 [22195] dbg: dns: hit <dns:210.8.207.185.zen.spamhaus.org> 127.0.0.3
spamd -D looks like:
Apr 1 15:10:51 merlot spamd[6505]: dns: hit <dns:210.8.207.185.zen.spamhaus.org> \# 4 7f000003
One time the result is an IP as integer and one time it's a normal IP. The
integer result is not recognized and the DNSBL tests do not trigger.
What can I do?
P.S.: This is the third time I try to send mail to the list - I hope it works
this time. I'll try without PGP sig.
Regards,
Michael Brunnbauer
--
++ Michael Brunnbauer
++ netEstate GmbH
++ Geisenhausener Straße 11a
++ 81379 München
++ Tel +49 89 32 19 77 80
++ Fax +49 89 32 19 77 89
++ E-Mail brunni@netestate.de
++ http://www.netestate.de/
++
++ Sitz: München, HRB Nr.142452 (Handelsregister B München)
++ USt-IdNr. DE221033342
++ Geschäftsführer: Michael Brunnbauer, Franz Brunnbauer
++ Prokurist: Dipl. Kfm. (Univ.) Markus Hendel
Re: This sucks
Posted by Benny Pedersen <me...@junc.eu>.
Michael Brunnbauer skrev den 2018-04-01 16:25:
> hi
>
> I think I lost quite a few customers in the last months because
> DNS-lookups
> are fucked up with Spamassassin so all DNSBL tests won't trigger while
> not
> reporting errors. A problem with newer versions of Net::DNS that has
> been
> known for months without any consequences - like a new release. This
> sucks.
since spamassassin does NOT reject dont blame it
> So I downgraded to Net-DNS-0.83 today and got spamassassin working but
> not
> spamd.
>
> spamassassin -D looks like:
>
> Apr 1 15:30:18.733 [22195] dbg: dns: hit
> <dns:210.8.207.185.zen.spamhaus.org> 127.0.0.3
>
> spamd -D looks like:
>
> Apr 1 15:10:51 merlot spamd[6505]: dns: hit
> <dns:210.8.207.185.zen.spamhaus.org> \# 4 7f000003
>
> One time the result is an IP as integer and one time it's a normal IP.
> The
> integer result is not recognized and the DNSBL tests do not trigger.
>
> What can I do?
say it sucks again :)
add trusted ips that should not reject to trusted_networks
or stop REJECT based on spamassassin ips blacklists
> P.S.: This is the third time I try to send mail to the list - I hope it
> works
> this time. I'll try without PGP sig.
poor manns dkim :=)
i uaw poardix clamav spampd opendkim opendmarc pypolicyd-spf i never
rejected a maillist or wanted mail
Re: This sucks
Posted by David Jones <dj...@ena.com>.
On 04/01/2018 09:25 AM, Michael Brunnbauer wrote:
>
> hi
>
> I think I lost quite a few customers in the last months because DNS-lookups
> are fucked up with Spamassassin so all DNSBL tests won't trigger while not
> reporting errors. A problem with newer versions of Net::DNS that has been
> known for months without any consequences - like a new release. This sucks.
>
> So I downgraded to Net-DNS-0.83 today and got spamassassin working but not
> spamd.
>
> spamassassin -D looks like:
>
> Apr 1 15:30:18.733 [22195] dbg: dns: hit <dns:210.8.207.185.zen.spamhaus.org> 127.0.0.3
>
> spamd -D looks like:
>
> Apr 1 15:10:51 merlot spamd[6505]: dns: hit <dns:210.8.207.185.zen.spamhaus.org> \# 4 7f000003
>
> One time the result is an IP as integer and one time it's a normal IP. The
> integer result is not recognized and the DNSBL tests do not trigger.
>
> What can I do?
>
What is your MTA? You should do as much as possible in the MTA like RBL
checks and other basic DNS checks. If you are using Postfix, enable
postscreen to help a lot with defaults. Then enable weighted RBL checks
in postscreen like we have mentioned often on this mailling list in the
past year or so. Make sure you add postwhite from github.com along with
with the postscreen weighted RBLs.
Enable greylisting, rate limiting, connection limits, pipelining limits,
etc. in the MTA too. Setup a high MX that simply tempfails everything
to attract botnets that won't retry.
Setup OpenDMARC, OpenDKIM, and policyd-spf to improve SA's ability to
allow through trusted senders. Add dkimwl.org rules along with other
custom rules that have been discussed the past year or so on this
mailing list like:
DecodeShortURLs.cf & pm
iXhash2.cf & pm
dwl.dnswl.org
dkimwl.org
KAM.cf
b.barracudacentral.org
ubl.unsubscore.com (Lashback)
score.senderscore.com
UNOFFICIAL ClamAV sigs from sanesecurity.com
Invaluement (subscription required but it's not expensive and worth
every bit)
--
David Jones
Re: This sucks
Posted by Michael Brunnbauer <br...@netestate.de>.
hi
On Sun, Apr 01, 2018 at 12:55:33PM -0500, David Jones wrote:
> Can you provide an example message lightly redacted via pastebin.com?
I use this message for testing: https://pastebin.com/9h9d62UW
The relay IP 185.207.8.210 is in several blacklists but spamd won't notice.
spamassassin does.
> Please
> tell us more details about your environment like OS version, Perl version,
> etc. We know you are using spamd as the SA glue but what version of SA?
Linux Kernel 3.16.56
Glibc 2.27
Perl 5.24.1
SpamAssassin 3.4.1
Net::DNS 0.83
> How is your DNS setup? Do you have a local recursive resolver that is not
> forwarding?
The first Nameserver in /etc/resolv.conf is on the local network and is
a non-forwarding recursive resolver. I tried this in local.cf but it does not
change anything:
dns_available yes
dns_server <dns ip>
> What type and version of a local recursor are you running? See
> this article for more details:
It's bind 9.10.4-P8
Regards,
Michael Brunnbauer
--
++ Michael Brunnbauer
++ netEstate GmbH
++ Geisenhausener Straße 11a
++ 81379 München
++ Tel +49 89 32 19 77 80
++ Fax +49 89 32 19 77 89
++ E-Mail brunni@netestate.de
++ http://www.netestate.de/
++
++ Sitz: München, HRB Nr.142452 (Handelsregister B München)
++ USt-IdNr. DE221033342
++ Geschäftsführer: Michael Brunnbauer, Franz Brunnbauer
++ Prokurist: Dipl. Kfm. (Univ.) Markus Hendel
Re: This sucks
Posted by David Jones <dj...@ena.com>.
On 04/01/2018 11:26 AM, Michael Brunnbauer wrote:
>
> hi all,
>
> Reindl Harald wrote:
>> but your distribution sucks too when you need to "So I downgraded to
>> Net-DNS-0.83 today and got spamassassin working but not spamd"
>
> I don't use a distribution and build everything myself (since I bootstrapped
> my system in the 1990ies). I seldom have problems to get things running.
>
> I deleted the .so and .pm files and directories belonging to the newer
> Net::DNS in /usr/lib/perl5 before downgrading to the older one.
>
> David Jones wrote:
>> What is your MTA?
>
> qmail.
>
>> Enable greylisting
>
> I have.
>
> [lot's of other useful tips]
>
> I'd like to start to improve things by getting DNS blacklist in Spamassassin
> to work again. I think it would improve things drastically. So let's look at
> my problem again: running my example spam through spamassassin gets it
> marked as spam while using spamc+spamd does not.
>
> Benny Pedersen wrote:
>
>> add trusted ips that should not reject to trusted_networks
>> or stop REJECT based on spamassassin ips blacklists
>
> I have my trusted ips in trusted_networks. I also have checked with
>
> add_header all RelaysUntrusted _RELAYSUNTRUSTED_
>
> that the relevant untrusted relays get checked. This is also clear from the
> output I sent. Here is is again:
>
> spamassassin -D looks like:
>
> Apr 1 15:30:18.733 [22195] dbg: dns: hit <dns:210.8.207.185.zen.spamhaus.org> 127.0.0.3
>
> spamd -D looks like:
>
> Apr 1 15:10:51 merlot spamd[6505]: dns: hit <dns:210.8.207.185.zen.spamhaus.org> \# 4 7f000003
>
> spamassassin reports RCVD_IN_SBL_CSS while spamd -D does not. The output
> from spamassassin contains a normal IP while that from spamd prints the IP
> as integer. This is extremely suspicious. I'd like to focus on that.
>
> And sorry for being negative. It's easter sunday and I'm working because a
> customer is drowning in spam - spam that would be filtered out with working
> DNS blacklisting.
>
> Regards,
>
> Michael Brunnbauer
>
Can you provide an example message lightly redacted via pastebin.com?
Please tell us more details about your environment like OS version, Perl
version, etc. We know you are using spamd as the SA glue but what
version of SA?
How is your DNS setup? Do you have a local recursive resolver that is
not forwarding? What type and version of a local recursor are you
running? See this article for more details:
https://wiki.apache.org/spamassassin/CachingNameserver
If someone can reproduce the problem with spamd then we need to open a
bug at https://bz.apache.org/SpamAssassin/ with all the proper details
to reproduce the problem to get a developer to take a look at this.
In the mean time, there might be other ways for you to call SA from
qmail to get around this spamd problem. I am not familiar with qmail
enough to help but maybe there are others on this list that can.
--
David Jones
Re: This sucks
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
On 01.04.18 18:26, Michael Brunnbauer wrote:
>I'd like to start to improve things by getting DNS blacklist in Spamassassin
>to work again. I think it would improve things drastically. So let's look at
>my problem again: running my example spam through spamassassin gets it
>marked as spam while using spamc+spamd does not.
how do you run spamd?
apparently when checking through spamd, different user preferences are used.
--
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Micro$oft random number generator: 0, 0, 0, 4.33e+67, 0, 0, 0...
Re: This sucks
Posted by Michael Brunnbauer <br...@netestate.de>.
Hello Bill,
On Mon, Apr 02, 2018 at 02:33:08AM -0400, Bill Cole wrote:
> So I guess I was right?
I don't think so.
> Is there a tree of Perl modules under /root?
No. I actually just reproduced the problem with a completely empty /root:
cd /
mkdir root1
chmod go= root1
mv root root.old ; mv root1 root
cd
spamd
(Should have done this before, sorry).
> A normal startup of spamd (by sysvinit, Upstart, systemd, etc.) is what you
> need to diagnose, not a manual startup from a login shell. None of those
> normally should put the daemon in /root as a working directory.
People restart services at runtime by calling init scripts. Those may or may
not change the working directory. Mine did not (now they do).
I don't think spamd should behave differently depending on the working
directory (maybe depending on what's in it - but not depending on the
working directory itself).
> No, it's not a timing issue. The root cause is that Net::DNS::RR->rdatastr()
> should never have been relied upon by SA to have any particular format
> because it was always poorly documented and quietly vanished from the
> documentation (but not the code) for Net::DNS::RR.pm in 0.69. What it
> actually contains is a function of the specific DNS record and what server
> generated the response, making an explanation for any specific oddity
> something of a guessing game.
Well this oddity seems to be *very* odd.
> More recently, there have been multiple other changes in various components
> of the Net-DNS distribution that have caused other problems in SA, and they
> may interact with the rdatastr issue. These issues have all been addressed
> in the current SA code, both in the 'trunk' and in the 3.4 branch which will
> (hopefully soon) become the 3.4.2 release. Many (most? all?) packagers of SA
> maintaining it for major platforms have incorporated some or all of the
> necessary DNS-related fixes. I've attached a patch that aggregates all of
> the fixes to this message. You could also install SA from the current 3.4
> branch or the last 3.4.2 release candidate package, or if you're
> adventurous, from the SVN 'trunk' that will eventually yield v4.0.
Yes I tried the 3.4 and the trunk checkout with the current Net::DNS before
writing to the list. They both had problems with make test while 3.4.1 did
not so I decided that downgrading Net::DNS would be safer.
Regards,
Michael Brunnbauer
--
++ Michael Brunnbauer
++ netEstate GmbH
++ Geisenhausener Straße 11a
++ 81379 München
++ Tel +49 89 32 19 77 80
++ Fax +49 89 32 19 77 89
++ E-Mail brunni@netestate.de
++ http://www.netestate.de/
++
++ Sitz: München, HRB Nr.142452 (Handelsregister B München)
++ USt-IdNr. DE221033342
++ Geschäftsführer: Michael Brunnbauer, Franz Brunnbauer
++ Prokurist: Dipl. Kfm. (Univ.) Markus Hendel
Re: This sucks
Posted by Bill Cole <sa...@billmail.scconsult.com>.
On 1 Apr 2018, at 21:09 (-0400), Michael Brunnbauer wrote:
[...]
>> Figuring out what spamd is using is less simple (and system-specific)
>> but
>> since you've been maintaining a system by hand for a long time I
>> expect
>> you'll be able to figure out how to do so safely.
>
>
> This does not sound very helpful of you
Well, it's rather difficult to guess what mechanism you are using to
start spamd and when I wrote that I had not seen your message narrowing
down the range of possibilities to those one might use on Linux.
> so I did some debugging on my own and
> have more information:
So I guess I was right?
> The problem only occurs only when spamd is started in the homedir of
> root. If
> I start it in any other directory (including subdirs of /root),
> Net:DNS
> behaves like it should: $answer->rdatastr in dnsbl_uri in Dns.pm
> contains IP
> addresses in dotted quad notation, like 127.0.0.3. If I start spamd in
> /root,
> $answer->rdatastr contains strings like "\# 4 7f000003" instead. This
> occurs
> regardless of any -x or -u flags to spamd.
OK, so that is quite odd.
Is there a tree of Perl modules under /root? Perl before 5.26 includes
'.' in the @INC array that defines where modules might live, which could
cause this if you have a private install tree (as is the default in some
distros.) Also, if you run spamd as root it drops to 'nobody' but if
you're in /root and /root/.spamassassin is world-readable, it will still
get used as the user prefs directory.
A normal startup of spamd (by sysvinit, Upstart, systemd, etc.) is what
you need to diagnose, not a manual startup from a login shell. None of
those normally should put the daemon in /root as a working directory.
Run as a proper system daemon by the normal startup subsystem, spamd
gets a substantially different environment than if you run it by hand
from an interactive shell.
> So being in /root when started changes the behavior of spamd. Is it
> possible
> that this is a timing issue? Could "\# 4 7f000003" be some unprocessed
> response that would be converted to 127.0.0.3 a moment later? Or is
> there
> some other explanation for this?
No, it's not a timing issue. The root cause is that
Net::DNS::RR->rdatastr() should never have been relied upon by SA to
have any particular format because it was always poorly documented and
quietly vanished from the documentation (but not the code) for
Net::DNS::RR.pm in 0.69. What it actually contains is a function of the
specific DNS record and what server generated the response, making an
explanation for any specific oddity something of a guessing game.
More recently, there have been multiple other changes in various
components of the Net-DNS distribution that have caused other problems
in SA, and they may interact with the rdatastr issue. These issues have
all been addressed in the current SA code, both in the 'trunk' and in
the 3.4 branch which will (hopefully soon) become the 3.4.2 release.
Many (most? all?) packagers of SA maintaining it for major platforms
have incorporated some or all of the necessary DNS-related fixes. I've
attached a patch that aggregates all of the fixes to this message. You
could also install SA from the current 3.4 branch or the last 3.4.2
release candidate package, or if you're adventurous, from the SVN
'trunk' that will eventually yield v4.0.
--
Bill Cole
bill@scconsult.com or billcole@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Currently Seeking Steady Work: https://linkedin.com/in/billcole
Re: This sucks
Posted by RW <rw...@googlemail.com>.
On Tue, 3 Apr 2018 14:58:39 +0200
Michael Brunnbauer wrote:
> Hello Giovanni,
>
> On Tue, Apr 03, 2018 at 11:04:46AM +0200, Giovanni Bechis wrote:
> > if you start spamd from /root and you use a perl module that is
> > using "use lib 'lib';" or similar piece of code the relevant code
> > will not load because the user spamd is running on (spamd or
> > whichever you have configured) will not have access to $PWD.
>
> Thank you very much - this makes sense. NetAddr uses such a construct
I'm curious what it's using, "use lib ..." is a way to make perl
look for libraries first in additional non-standard locations. I
don't see why NetAddr would have that unless someone had edited it
locally.
Also I don't see what the location of a library has to do with the
spamd user's access to $PWD, unless the library is in $PWD. And you've
already said you have no libraries under /root.
Re: This sucks
Posted by Michael Brunnbauer <br...@netestate.de>.
Hello Giovanni,
On Tue, Apr 03, 2018 at 11:04:46AM +0200, Giovanni Bechis wrote:
> if you start spamd from /root and you use a perl module that is using "use lib 'lib';" or similar piece of code the relevant code will not load because the user spamd is running on (spamd or whichever you have configured) will not have access to $PWD.
Thank you very much - this makes sense. NetAddr uses such a construct and I
can confirm that triggering a DNS query before setuid is called will make the
problem go away.
Despite what has already been said about starting spamd from /root I think
this should be addressed because people might stumble over it while doing
debugging.
Regards,
Michael Brunnbauer
--
++ Michael Brunnbauer
++ netEstate GmbH
++ Geisenhausener Straße 11a
++ 81379 München
++ Tel +49 89 32 19 77 80
++ Fax +49 89 32 19 77 89
++ E-Mail brunni@netestate.de
++ http://www.netestate.de/
++
++ Sitz: München, HRB Nr.142452 (Handelsregister B München)
++ USt-IdNr. DE221033342
++ Geschäftsführer: Michael Brunnbauer, Franz Brunnbauer
++ Prokurist: Dipl. Kfm. (Univ.) Markus Hendel
Re: This sucks
Posted by Giovanni Bechis <gi...@paclan.it>.
On Mon, Apr 02, 2018 at 03:09:34AM +0200, Michael Brunnbauer wrote:
[...]
> So being in /root when started changes the behavior of spamd. Is it possible
> that this is a timing issue? Could "\# 4 7f000003" be some unprocessed
> response that would be converted to 127.0.0.3 a moment later? Or is there
> some other explanation for this?
>
if you start spamd from /root and you use a perl module that is using "use lib 'lib';" or similar piece of code the relevant code will not load because the user spamd is running on (spamd or whichever you have configured) will not have access to $PWD.
Giovanni
Re: This sucks
Posted by Michael Brunnbauer <br...@netestate.de>.
Hello Bill,
On Sun, Apr 01, 2018 at 03:55:48PM -0400, Bill Cole wrote:
> This is a critical fact. It indicates that your spamd and the spamassassin
> script you are running are definitely using different SpamAssassin
> configurations, possibly different versions of the SpamAssassin
> distribution, and or possibly even different versions of Perl.
I am very sure that there are no other versions of SpamAssassin, Perl and
Net::DNS lying around.
> Determining what config the spamassassin script is using is fairly easy:
> 'spamassassin -D generic,config,diag --lint' will give you all the details.
> Figuring out what spamd is using is less simple (and system-specific) but
> since you've been maintaining a system by hand for a long time I expect
> you'll be able to figure out how to do so safely.
This does not sound very helpful of you so I did some debugging on my own and
have more information:
The problem only occurs only when spamd is started in the homedir of root. If
I start it in any other directory (including subdirs of /root), Net:DNS
behaves like it should: $answer->rdatastr in dnsbl_uri in Dns.pm contains IP
addresses in dotted quad notation, like 127.0.0.3. If I start spamd in /root,
$answer->rdatastr contains strings like "\# 4 7f000003" instead. This occurs
regardless of any -x or -u flags to spamd.
So being in /root when started changes the behavior of spamd. Is it possible
that this is a timing issue? Could "\# 4 7f000003" be some unprocessed
response that would be converted to 127.0.0.3 a moment later? Or is there
some other explanation for this?
Regards,
Michael Brunnbauer
--
++ Michael Brunnbauer
++ netEstate GmbH
++ Geisenhausener Straße 11a
++ 81379 München
++ Tel +49 89 32 19 77 80
++ Fax +49 89 32 19 77 89
++ E-Mail brunni@netestate.de
++ http://www.netestate.de/
++
++ Sitz: München, HRB Nr.142452 (Handelsregister B München)
++ USt-IdNr. DE221033342
++ Geschäftsführer: Michael Brunnbauer, Franz Brunnbauer
++ Prokurist: Dipl. Kfm. (Univ.) Markus Hendel
Re: This sucks
Posted by Bill Cole <sa...@billmail.scconsult.com>.
On 1 Apr 2018, at 12:26 (-0400), Michael Brunnbauer wrote:
> So let's look at
> my problem again: running my example spam through spamassassin gets it
> marked as spam while using spamc+spamd does not.
This is a critical fact. It indicates that your spamd and the
spamassassin script you are running are definitely using different
SpamAssassin configurations, possibly different versions of the
SpamAssassin distribution, and or possibly even different versions of
Perl.
Determining what config the spamassassin script is using is fairly easy:
'spamassassin -D generic,config,diag --lint' will give you all the
details. Figuring out what spamd is using is less simple (and
system-specific) but since you've been maintaining a system by hand for
a long time I expect you'll be able to figure out how to do so safely.
--
Bill Cole
bill@scconsult.com or billcole@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Currently Seeking Steady Work: https://linkedin.com/in/billcole
Re: This sucks
Posted by Michael Brunnbauer <br...@netestate.de>.
Hello Amir,
On Sun, Apr 01, 2018 at 01:17:03PM -0600, Amir Caspi wrote:
> On Apr 1, 2018, at 10:26 AM, Michael Brunnbauer <br...@netestate.de> wrote:
> >
> > running my example spam through spamassassin gets it marked as spam while using spamc+spamd does not.
>
> I know this is the equivalent of ???did you plug it in??? but... did you restart spamd after rebuilding Net::DNS?
Yes. Actually I'm not testing on the production system any more. I use a
different system where I have to start spamd manually to test. So spamassassin
and spamd use the same setup.
Regards,
Michael Brunnbauer
--
++ Michael Brunnbauer
++ netEstate GmbH
++ Geisenhausener Straße 11a
++ 81379 München
++ Tel +49 89 32 19 77 80
++ Fax +49 89 32 19 77 89
++ E-Mail brunni@netestate.de
++ http://www.netestate.de/
++
++ Sitz: München, HRB Nr.142452 (Handelsregister B München)
++ USt-IdNr. DE221033342
++ Geschäftsführer: Michael Brunnbauer, Franz Brunnbauer
++ Prokurist: Dipl. Kfm. (Univ.) Markus Hendel
Re: This sucks
Posted by Amir Caspi <ce...@3phase.com>.
On Apr 1, 2018, at 10:26 AM, Michael Brunnbauer <br...@netestate.de> wrote:
>
> running my example spam through spamassassin gets it marked as spam while using spamc+spamd does not.
I know this is the equivalent of “did you plug it in” but... did you restart spamd after rebuilding Net::DNS?
Just making sure. Sometimes it’s the obvious that still gets all of us.
--- Amir
thumbed via iPhone
Re: This sucks
Posted by Michael Brunnbauer <br...@netestate.de>.
hi all,
Reindl Harald wrote:
> but your distribution sucks too when you need to "So I downgraded to
> Net-DNS-0.83 today and got spamassassin working but not spamd"
I don't use a distribution and build everything myself (since I bootstrapped
my system in the 1990ies). I seldom have problems to get things running.
I deleted the .so and .pm files and directories belonging to the newer
Net::DNS in /usr/lib/perl5 before downgrading to the older one.
David Jones wrote:
> What is your MTA?
qmail.
> Enable greylisting
I have.
[lot's of other useful tips]
I'd like to start to improve things by getting DNS blacklist in Spamassassin
to work again. I think it would improve things drastically. So let's look at
my problem again: running my example spam through spamassassin gets it
marked as spam while using spamc+spamd does not.
Benny Pedersen wrote:
> add trusted ips that should not reject to trusted_networks
> or stop REJECT based on spamassassin ips blacklists
I have my trusted ips in trusted_networks. I also have checked with
add_header all RelaysUntrusted _RELAYSUNTRUSTED_
that the relevant untrusted relays get checked. This is also clear from the
output I sent. Here is is again:
spamassassin -D looks like:
Apr 1 15:30:18.733 [22195] dbg: dns: hit <dns:210.8.207.185.zen.spamhaus.org> 127.0.0.3
spamd -D looks like:
Apr 1 15:10:51 merlot spamd[6505]: dns: hit <dns:210.8.207.185.zen.spamhaus.org> \# 4 7f000003
spamassassin reports RCVD_IN_SBL_CSS while spamd -D does not. The output
from spamassassin contains a normal IP while that from spamd prints the IP
as integer. This is extremely suspicious. I'd like to focus on that.
And sorry for being negative. It's easter sunday and I'm working because a
customer is drowning in spam - spam that would be filtered out with working
DNS blacklisting.
Regards,
Michael Brunnbauer
--
++ Michael Brunnbauer
++ netEstate GmbH
++ Geisenhausener Straße 11a
++ 81379 München
++ Tel +49 89 32 19 77 80
++ Fax +49 89 32 19 77 89
++ E-Mail brunni@netestate.de
++ http://www.netestate.de/
++
++ Sitz: München, HRB Nr.142452 (Handelsregister B München)
++ USt-IdNr. DE221033342
++ Geschäftsführer: Michael Brunnbauer, Franz Brunnbauer
++ Prokurist: Dipl. Kfm. (Univ.) Markus Hendel