Re: AWL defeating my SPAM classification
On 4/30/15, 12:16 AM, Tom Robinson tom.robin...@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
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, uh...@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
On 4/30/15, 12:16 AM, Tom Robinson tom.robin...@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, uh...@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
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
Am 30.04.2015 um 12:55 schrieb Matus UHLAR - fantomas: On 4/30/15, 12:16 AM, Tom Robinson tom.robin...@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 signature.asc Description: OpenPGP digital signature
Re: AWL defeating my SPAM classification
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
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
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 . 2825IN NS l.root-servers.net. . 2825IN NS m.root-servers.net. . 2825IN NS j.root-servers.net. . 2825IN NS b.root-servers.net. . 2825IN NS f.root-servers.net. . 2825IN NS h.root-servers.net. . 2825IN NS d.root-servers.net. . 2825IN NS i.root-servers.net. . 2825IN NS c.root-servers.net. . 2825IN NS k.root-servers.net. . 2825IN NS a.root-servers.net. . 2825IN NS e.root-servers.net. . 2825IN 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 2015051005 2015043004 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 signature.asc Description: OpenPGP digital signature
Re: AWL defeating my SPAM classification
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
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
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.robin...@motec.com.au Return-Path: og...@bonnieaugostino.com Delivered-To: t...@motec.com.au Received: (qmail 2934 invoked by alias); 29 Apr 2015 23:02:24 - Delivered-To: fo...@motec.com.au Received: (qmail 2923 invoked by uid 187); 29 Apr 2015 23:02:24 - 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 - X-Spam-Status: No, hits=4.6 required=5.0 X-Spam-Level: X-Spam-Report: SA TESTS 0.7 RCVD_IN_XBLRBL: 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_GENERICRelay used name indicative of a Dynamic Pool or Generic rPTR 0.0 TVD_RCVD_IPMessage 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 AWLAWL: 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 - Message-ID: fn4sakwr.2943...@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: emailpete.swin...@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 signature.asc Description: OpenPGP digital signature
Re: AWL defeating my SPAM classification
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
RE: AWL defeating my SPAM classification
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
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?
signature.asc
Description: OpenPGP digital signature
Re: AWL defeating my SPAM classification
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. signature.asc Description: OpenPGP digital signature
Re: AWL defeating my SPAM classification
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.robin...@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? signature.asc Description: OpenPGP digital signature
Re: AWL defeating my SPAM classification
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
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 5 queries, your left and right meighbour too - oops 150 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 signature.asc Description: OpenPGP digital signature
Re: AWL defeating my SPAM classification
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 signature.asc Description: OpenPGP digital signature
Re: AWL defeating my SPAM classification
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 5 queries, your left and right meighbour too - oops 150 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 signature.asc Description: OpenPGP digital signature
Re: AWL defeating my SPAM classification
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 5 queries, your left and right meighbour too - oops 150 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. signature.asc Description: OpenPGP digital signature
