You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Tom Robinson <to...@motec.com.au> on 2015/04/30 01:38:00 UTC
AWL defeating my SPAM classification
Hi,
Below is the source from an email that is clearly spam but the AWL is -1.3 defeating the spam classification. How can I best adjust the AWL to get this classified as SPAM.
Kind regards,
Tom
--
Tom Robinson
IT Manager/System Administrator
MoTeC Pty Ltd
121 Merrindale Drive
Croydon South
3136 Victoria
Australia
T: +61 3 9761 5050
F: +61 3 9761 5051
E: tom.robinson@motec.com.au
Return-Path: <og...@bonnieaugostino.com>
Delivered-To: tom@motec.com.au
Received: (qmail 2934 invoked by alias); 29 Apr 2015 23:02:24 -0000
Delivered-To: forum@motec.com.au
Received: (qmail 2923 invoked by uid 187); 29 Apr 2015 23:02:24 -0000
Received: from 78.188.129.11.dynamic.ttnet.com.tr by scion.motec.com.au (envelope-from <og...@bonnieaugostino.com>, uid 181) with qmail-scanner-2.08st
(clamdscan: 0.97.8/20394. spamassassin: 3.3.1. perlscan: 2.08st.
Clear:RC:0(78.188.129.11):SA:0(4.6/5.0):.
Processed in 14.230659 secs); 29 Apr 2015 23:02:24 -0000
X-Spam-Status: No, hits=4.6 required=5.0
X-Spam-Level: ++++
X-Spam-Report: SA TESTS
0.7 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL
[78.188.129.11 listed in zen.spamhaus.org]
2.9 HELO_DYNAMIC_SPLIT_IP Relay HELO'd using suspicious hostname (Split
IP)
0.2 CK_HELO_GENERIC Relay used name indicative of a Dynamic Pool or
Generic rPTR
0.0 TVD_RCVD_IP Message was received from an IP address
1.6 RCVD_IN_BRBL_LASTEXT RBL: RCVD_IN_BRBL_LASTEXT
[78.188.129.11 listed in bb.barracudacentral.org]
0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.
See
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
for more information.
[URIs: world-plants.ru]
0.4 RDNS_DYNAMIC Delivered to internal network by host with
dynamic-looking rDNS
-1.3 AWL AWL: Adjusted score from AWL reputation of From: address
Received: from 78.188.129.11.dynamic.ttnet.com.tr (78.188.129.11)
by scion.motec.com.au with SMTP; 29 Apr 2015 23:02:09 -0000
Message-ID: <FN...@bonnieaugostino.com>
Date: Thu, 30 Apr 2015 01:48:15 +0200
From: "American Express" <fr...@americanexpress.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: <em...@motec.com.au>
Subject: Irregular card activity
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Irregular check card activity
American Express
Dear Customer,
We detected irregular card activity on your American Express Check Card on 29 April, 2015.
As the Primary Contact, you must verify your credit card activity before you can continue using your card, and upon verification, we will remove any restrictions placed on your card.
To review your account as soon as possible please click on the link below.
http://world-plants.ru/foldername/index.html
Thank you for your Card Membership.
-------------
American Express Customer Care
Fraud Department:
Erica Bermudez
Level III Security Officer
Re: AWL defeating my SPAM classification
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
>On 30/04/15 09:56, Marieke Janssen wrote:
>> 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.
>> See
>> http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
>> for more information.
>> [URIs: world-plants.ru]
>>
>> You are blocked, This probably means you are using either public
>> nameservers or do too much queries. Running a dedicated nameserver on
>> localhost (dnsmasq,bind,unbound,whatever) can solve this (and besides
>> that, it speeds things up). If you fix this chances are you get scores
>> high enough to compensate/correct AWL.
On 30.04.15 12:10, Tom Robinson wrote:
>I have the mail server and a separate name server set up in a DMZ. The name
>server already runs as a caching nameserver but does forwarding to our ISP.
>I'm not sure how the non-caching works to eliminate this problem. Is it
>correct that currently, because I'm forwarding, the DNSBL query is denied
>because the DNSBL server thinks I'm the ISP making a query? Sorry, I'm not
>understanding the mechanism.
when you are forwarding, your nameserver asks forwarders for the data.
The DNSBL server apparently block your forwarders because they make too many
queries.
>If bind is going to forward lookups for DNSBL servers to a null list, will
>the cache have a record to look up at all?
>e.g.
>/* Disable forwarding for DNSBL queries */
>zone "multi.uribl.com" { type forward; forward first; forwarders {}; };
>zone "dnsbl.sorbs.net" { type forward; forward first; forwarders {}; };
>
>Does this rely on the caching namesever having already looked up and cached
> the DNSBL servers?
it will iterate the usual way without forwarders - from root servers etc.
>BTW, I do have rbldnsd set up on the caching nameserver in my DMZ. Is that
>useful in any way to resolve this issue?
you can set up forwarding to the rbldnsd server, if it contains proper
zones.
--
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.
They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety. -- Benjamin Franklin, 1759
Re: AWL defeating my SPAM classification
Posted by Reindl Harald <h....@thelounge.net>.
Am 30.04.2015 um 04:10 schrieb Tom Robinson:
> I have the mail server and a separate name server set up in a DMZ. The name server already runs as a
> caching nameserver but does forwarding to our ISP
don't do that when you are running mailservers or for whateverer reason
rely on trustable nameservers - that's it
Re: AWL defeating my SPAM classification
Posted by Dave Pooser <da...@pooserville.com>.
On 4/30/15, 5:55 AM, "Matus UHLAR - fantomas" <uh...@fantomas.sk> wrote:
>no, it's the "dig" command that does the trace, not the nameserver.
>This says nothing about your nameserver configuration, and it can't since
>nameserver does not provide that info.
I stand corrected-- I had tested on another machine that used a forwarding
server and had seen different results that did NOT include the root
servers (it queried the local router, then the Verizon forwarder, then
uribl directly) -- but that was probably either because Verizon does DNS
hijacking or a difference between the dig implementations on MacOS and
Ubuntu. Sorry for the noise!
<slinks off>
--
Dave Pooser
Cat-Herder-in-Chief, Pooserville.com
Re: AWL defeating my SPAM classification
Posted by Reindl Harald <h....@thelounge.net>.
Am 30.04.2015 um 12:55 schrieb Matus UHLAR - fantomas:
>> On 4/30/15, 12:16 AM, "Tom Robinson" <to...@motec.com.au> wrote:
>>> BTW, where can I see the results of my configuration changes? It
>>> would be
>>> nice to confirm that my
>>> changes have rectified the situation.
>
> On 30.04.15 01:38, Dave Pooser wrote:
>> On the server (via SSH or console) use the +trace argument to dig, and
>> then look for lines starting with ';;':
>>
>> postmstr@smtp:~$ dig +trace example.com.multi.uribl.com | grep ';;'
>> ;; global options: +cmd
>> ;; Received 913 bytes from 127.0.0.1#53(127.0.0.1) in 8 ms
>> ;; Received 760 bytes from 199.7.91.13#53(d.root-servers.net) in 48 ms
>> ;; Received 707 bytes from 192.54.112.30#53(h.gtld-servers.net) in 124 ms
>> ;; Received 553 bytes from 54.149.125.143#53(o.icudp.com) in 74 ms
>> ;; Received 206 bytes from 52.68.34.21#53(gg.uribl.com) in 147 ms
>>
>> So you can see that my mail server is querying its local DNS resolver,
>> which is querying the root servers and then working its way down to the
>> appropriate uribl.com server. In your case your actual IPs will be
>> different, but the pattern should still hold.
>
> no, it's the "dig" command that does the trace, not the nameserver.
> This says nothing about your nameserver configuration, and it can't since
> nameserver does not provide that info
correct because the nameserver of the machine below *for sure* does not
recursion but is a forwarder to a local cache which don't appear
[harry@srv-rhsoft:~]$ dig +trace example.com.multi.uribl.com | grep ';;'
;; global options: +cmd
;; Received 239 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms
;; Received 751 bytes from 202.12.27.33#53(m.root-servers.net) in 43 ms
;; Received 698 bytes from 192.41.162.30#53(l.gtld-servers.net) in 186 ms
;; Received 544 bytes from 94.228.131.217#53(p.icudp.net) in 32 ms
;; Received 90 bytes from 184.73.199.129#53(ee.uribl.com) in 173 ms
Re: AWL defeating my SPAM classification
Posted by Reindl Harald <h....@thelounge.net>.
Am 30.04.2015 um 17:06 schrieb Benny Pedersen:
> Matus UHLAR - fantomas skrev den 2015-04-30 12:55:
>
>> no, it's the "dig" command that does the trace, not the nameserver.
>> This says nothing about your nameserver configuration, and it can't since
>> nameserver does not provide that info.
>
> dig respects resolv.conf with nameserver 127.0.0.1
>
> try it :)
>
> dig @8.8.8.8 +trace example.org
that's bullshit - it just asks there for the root-ns
how does that help?
you should try to understand the context
where is my forwarder named is using in the trace output?
nowhere! and so *how* would that help to
answer the question if the nameserver does forwarding
or recursion? it don't - period
[harry@srv-rhsoft:~]$ dig +trace example.org | grep 10.0.0.6
[harry@srv-rhsoft:~]$
[harry@srv-rhsoft:~]$ dig +trace example.org
; <<>> DiG 9.9.6-P1-RedHat-9.9.6-8.P1.fc21 <<>> +trace example.org
;; global options: +cmd
. 2825 IN NS l.root-servers.net.
. 2825 IN NS m.root-servers.net.
. 2825 IN NS j.root-servers.net.
. 2825 IN NS b.root-servers.net.
. 2825 IN NS f.root-servers.net.
. 2825 IN NS h.root-servers.net.
. 2825 IN NS d.root-servers.net.
. 2825 IN NS i.root-servers.net.
. 2825 IN NS c.root-servers.net.
. 2825 IN NS k.root-servers.net.
. 2825 IN NS a.root-servers.net.
. 2825 IN NS e.root-servers.net.
. 2825 IN NS g.root-servers.net.
;; Received 239 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms
org. 172800 IN NS d0.org.afilias-nst.org.
org. 172800 IN NS a2.org.afilias-nst.info.
org. 172800 IN NS b2.org.afilias-nst.org.
org. 172800 IN NS b0.org.afilias-nst.org.
org. 172800 IN NS a0.org.afilias-nst.info.
org. 172800 IN NS c0.org.afilias-nst.info.
org. 86400 IN DS 21366 7 1
E6C1716CFB6BDC84E84CE1AB5510DAC69173B5B2
org. 86400 IN DS 21366 7 2
96EEB2FFD9B00CD4694E78278B5EFDAB0A80446567B69F634DA078F0 D90F01BA
org. 86400 IN RRSIG DS 8 1 86400
20150510050000 20150430040000 48613 .
CCXS9dvxUkQCVXzNYBnGgI4+9E0pRURKT5Bp7gBhTO28rQsoP64lbCxU
/0R13vcKBxS1ANPZnOreayAjlNCrL4ME2/09pKaBY/2OjaGc61+11W1g
+pggqcoxLOEdsp3Pg9oWVVDYNAmh3akVIMJIOjRGy3q3I7ntBhfjh0bf dZE=
;; Received 685 bytes from 192.228.79.201#53(b.root-servers.net) in 187 ms
example.org. 86400 IN NS a.iana-servers.net.
example.org. 86400 IN NS b.iana-servers.net.
example.org. 86400 IN DS 31589 8 1
7B8370002875DDA781390A8E586C31493847D9BC
example.org. 86400 IN DS 31589 8 2
3FDC4C11FA3AD3535EA8C1CE3EAF7BFA5CA9AE8A834D98FEE10085CF AEB625AA
example.org. 86400 IN RRSIG DS 7 2 86400
20150516154903 20150425144903 3213 org.
F4xyrnEiyAh73FDVDCksE2gwPci27NyrDBOvAheul5LnaMyCg4PrWWly
+vGTYbTv6A/OSS3Hc+1XdzvG39sN2fdGSBEXvGib1MVq0upC5dFA/RSu
sB3CauiWON2zxIptGrDnGOS0DenYSzPP8wDghMeykr+k5FT6RuuDVAFr Uvg=
;; Received 335 bytes from 199.249.120.1#53(b2.org.afilias-nst.org) in 38 ms
example.org. 86400 IN A 93.184.216.34
example.org. 86400 IN RRSIG A 8 2 86400
20150507130447 20150430112531 23014 example.org.
o95kdPQLidVQavRj2zcvtJPzra2mQ4VdWPlnnGUkd+/Wvv9/AT7TRArc
vjcdXhH7s9X0J6Jray7VA3SvqvEXixwqSbOUjS3WNXZ70pR0hz+9hAPl
/t2uIMDpIUFWSeZkBBU2Q+nPZ6z9zCi6f7FpRNFaV4CXN9gTrU/g9mXb ZiI=
example.org. 172800 IN NS a.iana-servers.net.
example.org. 172800 IN NS b.iana-servers.net.
example.org. 172800 IN RRSIG NS 8 2 172800
20150507230256 20150430112531 23014 example.org.
RPb4E38QRr2myhjs88BsIE3RhApL4TgJv+7rEgaMvxUYOs6g8nasKO2N
NbuJMRvJaTSEpQHlq6YpEMmhLgXKBk+szv964RAwj/zZOjgEh816ORyZ
GdA1cnvtHp7vFcRnQgGRsPTWFrYKpa22zimfi87fK/OBSPjONf4pGk/s TEc=
;; Received 534 bytes from 199.43.133.53#53(b.iana-servers.net) in 174 ms
Re: AWL defeating my SPAM classification
Posted by Benny Pedersen <me...@junc.eu>.
Matus UHLAR - fantomas skrev den 2015-04-30 12:55:
> no, it's the "dig" command that does the trace, not the nameserver.
> This says nothing about your nameserver configuration, and it can't
> since
> nameserver does not provide that info.
dig respects resolv.conf with nameserver 127.0.0.1
try it :)
dig @8.8.8.8 +trace example.org
Re: AWL defeating my SPAM classification
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
>On 4/30/15, 12:16 AM, "Tom Robinson" <to...@motec.com.au> wrote:
>>BTW, where can I see the results of my configuration changes? It would be
>>nice to confirm that my
>>changes have rectified the situation.
On 30.04.15 01:38, Dave Pooser wrote:
>On the server (via SSH or console) use the +trace argument to dig, and
>then look for lines starting with ';;':
>
>postmstr@smtp:~$ dig +trace example.com.multi.uribl.com | grep ';;'
>;; global options: +cmd
>;; Received 913 bytes from 127.0.0.1#53(127.0.0.1) in 8 ms
>;; Received 760 bytes from 199.7.91.13#53(d.root-servers.net) in 48 ms
>;; Received 707 bytes from 192.54.112.30#53(h.gtld-servers.net) in 124 ms
>;; Received 553 bytes from 54.149.125.143#53(o.icudp.com) in 74 ms
>;; Received 206 bytes from 52.68.34.21#53(gg.uribl.com) in 147 ms
>
>So you can see that my mail server is querying its local DNS resolver,
>which is querying the root servers and then working its way down to the
>appropriate uribl.com server. In your case your actual IPs will be
>different, but the pattern should still hold.
no, it's the "dig" command that does the trace, not the nameserver.
This says nothing about your nameserver configuration, and it can't since
nameserver does not provide that info.
--
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.
BSE = Mad Cow Desease ... BSA = Mad Software Producents Desease
Re: AWL defeating my SPAM classification
Posted by David Jones <dj...@ena.com>.
>On the server (via SSH or console) use the +trace argument to dig, and
>then look for lines starting with ';;':
>postmstr@smtp:~$ dig +trace example.com.multi.uribl.com | grep ';;'
>;; global options: +cmd
>;; Received 913 bytes from 127.0.0.1#53(127.0.0.1) in 8 ms
>;; Received 760 bytes from 199.7.91.13#53(d.root-servers.net) in 48 ms
>;; Received 707 bytes from 192.54.112.30#53(h.gtld-servers.net) in 124 ms
>;; Received 553 bytes from 54.149.125.143#53(o.icudp.com) in 74 ms
>;; Received 206 bytes from 52.68.34.21#53(gg.uribl.com) in 147 ms
>So you can see that my mail server is querying its local DNS resolver,
>which is querying the root servers and then working its way down to the
>appropriate uribl.com server. In your case your actual IPs will be
>different, but the pattern should still hold.
dig +trace always does a full root server lookup so it's not showing the same
path that the /etc/resolv.conf will take.
He will have to run a regular query and see if he gets back 127.0.0.1. If so,
then the current resolv.conf path is still being blocked.
>--
>Dave Pooser
>Cat-Herder-in-Chief, Pooserville.com
Re: AWL defeating my SPAM classification
Posted by Dave Pooser <da...@pooserville.com>.
On 4/30/15, 12:16 AM, "Tom Robinson" <to...@motec.com.au> wrote:
>BTW, where can I see the results of my configuration changes? It would be
>nice to confirm that my
>changes have rectified the situation.
On the server (via SSH or console) use the +trace argument to dig, and
then look for lines starting with ';;':
postmstr@smtp:~$ dig +trace example.com.multi.uribl.com | grep ';;'
;; global options: +cmd
;; Received 913 bytes from 127.0.0.1#53(127.0.0.1) in 8 ms
;; Received 760 bytes from 199.7.91.13#53(d.root-servers.net) in 48 ms
;; Received 707 bytes from 192.54.112.30#53(h.gtld-servers.net) in 124 ms
;; Received 553 bytes from 54.149.125.143#53(o.icudp.com) in 74 ms
;; Received 206 bytes from 52.68.34.21#53(gg.uribl.com) in 147 ms
So you can see that my mail server is querying its local DNS resolver,
which is querying the root servers and then working its way down to the
appropriate uribl.com server. In your case your actual IPs will be
different, but the pattern should still hold.
--
Dave Pooser
Cat-Herder-in-Chief, Pooserville.com
Re: AWL defeating my SPAM classification
Posted by Reindl Harald <h....@thelounge.net>.
Am 30.04.2015 um 07:16 schrieb Tom Robinson:
> On 30/04/15 15:09, Reindl Harald wrote:
>>
>>
>> Am 30.04.2015 um 04:10 schrieb Tom Robinson:
>>> Is it correct that currently, because I'm forwarding, the DNSBL query is
>>> denied because the DNSBL server thinks I'm the ISP making a query? Sorry, I'm not understanding the
>>> mechanism
>>
>> it is the ISP making the query for you and thousands of other of his customers - you are making
>> 50000 queries, your left and right meighbour too - oops 1500000 queries from your ISP's nameserver
>> which exceeds teh limit for a single IP
>>
>> there is no "mechanism" - when you don't make your queries at your own the forwarder does and the
>> rest is trivial math
>>
>
> Got it. Thanks Reindl.
>
> BTW, where can I see the results of my configuration changes? It would be nice to confirm that my
> changes have rectified the situation
when there is no "forward" in your config it does recursion - or in
other words: named before it get crippeled down to a forwarder does
recursion and caching out of the box
Re: AWL defeating my SPAM classification
Posted by Tom Robinson <to...@motec.com.au>.
On 30/04/15 15:09, Reindl Harald wrote:
>
>
> Am 30.04.2015 um 04:10 schrieb Tom Robinson:
>> Is it correct that currently, because I'm forwarding, the DNSBL query is
>> denied because the DNSBL server thinks I'm the ISP making a query? Sorry, I'm not understanding the
>> mechanism
>
> it is the ISP making the query for you and thousands of other of his customers - you are making
> 50000 queries, your left and right meighbour too - oops 1500000 queries from your ISP's nameserver
> which exceeds teh limit for a single IP
>
> there is no "mechanism" - when you don't make your queries at your own the forwarder does and the
> rest is trivial math
>
Got it. Thanks Reindl.
BTW, where can I see the results of my configuration changes? It would be nice to confirm that my
changes have rectified the situation.
Re: AWL defeating my SPAM classification
Posted by Reindl Harald <h....@thelounge.net>.
Am 30.04.2015 um 04:10 schrieb Tom Robinson:
> Is it correct that currently, because I'm forwarding, the DNSBL query is
> denied because the DNSBL server thinks I'm the ISP making a query? Sorry, I'm not understanding the
> mechanism
it is the ISP making the query for you and thousands of other of his
customers - you are making 50000 queries, your left and right meighbour
too - oops 1500000 queries from your ISP's nameserver which exceeds teh
limit for a single IP
there is no "mechanism" - when you don't make your queries at your own
the forwarder does and the rest is trivial math
Re: AWL defeating my SPAM classification
Posted by Benny Pedersen <me...@junc.eu>.
Tom Robinson skrev den 2015-04-30 04:35:
> Finally that makes sense. I will add the forwarding in as per the
> documentation.
remove forwarding is safe, only use forward dns on zones you self build
or have rsync access to
Re: AWL defeating my SPAM classification
Posted by Tom Robinson <to...@motec.com.au>.
On 30/04/15 12:15, Kevin A. McGrail wrote:
> On 4/29/2015 10:10 PM, Tom Robinson wrote:
>> I have the mail server and a separate name server set up in a DMZ. The name server already runs as a
>> caching nameserver but does forwarding to our ISP.
> Hi Tom,
>
> Your ISP is doing too many queries to the services exceeding free limits. You are being lumped in
> with your ISP.
>
> Run your own caching DNS server without forwarding but instead going to the root servers so you
> query on your own.
>
Finally that makes sense. I will add the forwarding in as per the documentation.
Re: AWL defeating my SPAM classification
Posted by "Kevin A. McGrail" <KM...@PCCC.com>.
On 4/29/2015 10:10 PM, Tom Robinson wrote:
> I have the mail server and a separate name server set up in a DMZ. The name server already runs as a
> caching nameserver but does forwarding to our ISP.
Hi Tom,
Your ISP is doing too many queries to the services exceeding free
limits. You are being lumped in with your ISP.
Run your own caching DNS server without forwarding but instead going to
the root servers so you query on your own.
Regards,
KAM
Re: AWL defeating my SPAM classification
Posted by Tom Robinson <to...@motec.com.au>.
On 30/04/15 09:56, Marieke Janssen wrote:
> Hi,
>
> Besides your awl problem, you have other problems.
>
> 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.
> See
> http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
> for more information.
> [URIs: world-plants.ru]
>
> You are blocked, This probably means you are using either public nameservers or do too much queries. Running a dedicated nameserver on localhost (dnsmasq,bind,unbound,whatever) can solve this (and besides that, it speeds things up).
> If you fix this chances are you get scores high enough to compensate/correct AWL.
>
> In SpamAssassin 3.4.1 there is a TxRep module, maybe you'll find it interesting. It decayes the learned scores over time (and other neat stuff). You can migrate existing AWL data to TxRep. (make sure to backup it first so you can go back).
>
>
Thanks Marieke,
I have the mail server and a separate name server set up in a DMZ. The name server already runs as a
caching nameserver but does forwarding to our ISP. I'm not sure how the non-caching works to
eliminate this problem. Is it correct that currently, because I'm forwarding, the DNSBL query is
denied because the DNSBL server thinks I'm the ISP making a query? Sorry, I'm not understanding the
mechanism.
If bind is going to forward lookups for DNSBL servers to a null list, will the cache have a record
to look up at all?
e.g.
/* Disable forwarding for DNSBL queries */
zone "multi.uribl.com" { type forward; forward first; forwarders {}; };
zone "dnsbl.sorbs.net" { type forward; forward first; forwarders {}; };
Does this rely on the caching namesever having already looked up and cached the DNSBL servers?
BTW, I do have rbldnsd set up on the caching nameserver in my DMZ. Is that useful in any way to
resolve this issue?
RE: AWL defeating my SPAM classification
Posted by Marieke Janssen <mj...@myguard.nl>.
Hi,
Besides your awl problem, you have other problems.
0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.
See
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
for more information.
[URIs: world-plants.ru]
You are blocked, This probably means you are using either public nameservers or do too much queries. Running a dedicated nameserver on localhost (dnsmasq,bind,unbound,whatever) can solve this (and besides that, it speeds things up).
If you fix this chances are you get scores high enough to compensate/correct AWL.
In SpamAssassin 3.4.1 there is a TxRep module, maybe you'll find it interesting. It decayes the learned scores over time (and other neat stuff). You can migrate existing AWL data to TxRep. (make sure to backup it first so you can go back).
/MJ
Re: AWL defeating my SPAM classification
Posted by Benny Pedersen <me...@junc.eu>.
Tom Robinson skrev den 2015-04-30 04:14:
> Actually, looking for this config I can't seem to find it. My
> spamassassin is linked in with qmail
> using qmail-scanner-queue.pl. That script looks in
> /home/qscand/.spamassassin/user_prefs but I also
> have configs in /etc/mail/spamassassin. What am I looking for exactly?
dig +trace apache.org
dig +trace google.com
did you see route on how dns treverse nameservers ?
when you use forwards in the chain it ignores this, and thus others use
your free limit on blacklists, and it will in some time begin to give no
results, leading to see diff problems in awl since its recorded before
with a diff spam score on the same ips
to solve it completely remove ALL forwards in your nameserver, and ONLY
use forward pr zone as needed, thus do not use forward in options
section in named.conf with is global fault :=)
i have seen domains that blocked my ips in there acl for being for them
a dynamic ip, all thay got back was that it was for them impossible to
send more mail until that was resolved
my ips was ripe listed in seperate, if admins had checked this it was
clearly not a dynamic ip, and problem had not arrised for them
in resolv.conf use nameserver 127.0.0.1, and configure your dns server
to only listen on 127.0.0.1 or if needed lan interfaces, no listning on
public ips
Re: AWL defeating my SPAM classification
Posted by Tom Robinson <to...@motec.com.au>.
Tom Robinson
IT Manager/System Administrator
MoTeC Pty Ltd
121 Merrindale Drive
Croydon South
3136 Victoria
Australia
T: +61 3 9761 5050
F: +61 3 9761 5051
E: tom.robinson@motec.com.au
On 30/04/15 10:10, Benny Pedersen wrote:
> Tom Robinson skrev den 2015-04-30 01:38:
>
>> 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL
>> was blocked.
>> See
>>
>> http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
>
> did you read the url here ?
>
> well if yes, show your AWL config for the AWL plugin
Actually, looking for this config I can't seem to find it. My spamassassin is linked in with qmail
using qmail-scanner-queue.pl. That script looks in /home/qscand/.spamassassin/user_prefs but I also
have configs in /etc/mail/spamassassin. What am I looking for exactly?
Re: AWL defeating my SPAM classification
Posted by Benny Pedersen <me...@junc.eu>.
Tom Robinson skrev den 2015-04-30 01:38:
> 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL
> was blocked.
> See
>
> http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
did you read the url here ?
well if yes, show your AWL config for the AWL plugin