Re: URIBL_BLOCKED

[@lbutlr]

On 2018-02-15 (02:10 MST), Tobi  wrote:
> 
> and does your bind server use other forward servers?

Nope. It is its own thing. Nor forwarders. Dunno what the issue was, but it was 
transient AFAICT.

-- 
Forever was over. All the sands had fallen. The great race between
entropy and energy had been run, and the favourite had been the winner
after all. Perhaps he ought to sharpen the blade again?  No. Not much
point, really.

Re: URIBL_BLOCKED

[Dianne Skoll]

On Thu, 15 Feb 2018 16:06:40 +0100
Matus UHLAR - fantomas  wrote:

> >Or if you like using your ISP's servers, most DNS server software
> >lets you forward by default but make exceptions for specific
> >domains.  

> although possible, this does not make sense IMHO.

It makes a lot of sense, IMO.  I'm not H like the rest of you.

> you would need to keep track of DNSBLs you need to access directly,
> while they can change with SA rules without your knowledge.

IMO, it makes no sense to run a mail server without having complete
knowledge of which DNSBLs you use.

Regards,

Dianne.

Re: URIBL_BLOCKED

[Matus UHLAR - fantomas]

On Wed, 14 Feb 2018 14:05:54 -0800 (PST)
John Hardin  wrote:


This detail always gets glossed over: set up a local NON-FORWARDING
resolver.



If you set up a local resolver and it just forwards requests to your
ISP's DNS servers, you have not materially changed the problem.


On 15.02.18 09:57, Dianne Skoll wrote:

Or if you like using your ISP's servers, most DNS server software lets
you forward by default but make exceptions for specific domains.


although possible, this does not make sense IMHO.

you would need to keep track of DNSBLs you need to access directly,
while they can change with SA rules without your knowledge.

--
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.
(R)etry, (A)bort, (C)ancer

Re: URIBL_BLOCKED

[Dianne Skoll]

On Wed, 14 Feb 2018 14:05:54 -0800 (PST)
John Hardin  wrote:

> This detail always gets glossed over: set up a local NON-FORWARDING 
> resolver.

> If you set up a local resolver and it just forwards requests to your
> ISP's DNS servers, you have not materially changed the problem.

Or if you like using your ISP's servers, most DNS server software lets
you forward by default but make exceptions for specific domains.

Regards,

Dianne.

Re: URIBL_BLOCKED

[Matus UHLAR - fantomas]

On 15 Feb 2018, at 4:10 (-0500), Tobi wrote:


Am 15.02.2018 um 02:35 schrieb @lbutlr:

On 2018-02-14 (09:55 MST), Tobi  wrote:


Am 14.02.2018 um 17:16 schrieb @lbutlr:

I can't imagine why i'd be over limit, my mail server is tiny.


its not the mailserver that got blocked by limits, but the dns 
resolver

your mailserver uses!


I use my own DNS on Bind 9.12, however the block error is not

appearing today, so...




and does your bind server use other forward servers? Or does it 
directly

resolve the queries from the authorative nameservers? All depends
whether you resolver is in forward mode or not. If it's in forward
mode then it sounds that the ips of those forwarders might got limited


On 15.02.18 09:49, Bill Cole wrote:
Another possibility is DNS hijacking. Connection providers pitch it 
as a security measure, and I guess it can be for residential 
customers and small businesses that essentially use their connections 
in the same ways as home users, but it's lethal for mail systems. My 
provider (WOW Business) does it by default.


DNSSEC should avoid that too, however you must get root key via other way
and I have no information about dnsbls signing their 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.
Christian Science Programming: "Let God Debug It!".

Re: URIBL_BLOCKED

[Bill Cole]

On 15 Feb 2018, at 4:10 (-0500), Tobi wrote:


Am 15.02.2018 um 02:35 schrieb @lbutlr:

On 2018-02-14 (09:55 MST), Tobi  wrote:


Am 14.02.2018 um 17:16 schrieb @lbutlr:

I can't imagine why i'd be over limit, my mail server is tiny.


its not the mailserver that got blocked by limits, but the dns 
resolver

your mailserver uses!


I use my own DNS on Bind 9.12, however the block error is not

appearing today, so...




and does your bind server use other forward servers? Or does it 
directly

resolve the queries from the authorative nameservers? All depends
whether you resolver is in forward mode or not. If it's in forward
mode then it sounds that the ips of those forwarders might got limited


Another possibility is DNS hijacking. Connection providers pitch it as a 
security measure, and I guess it can be for residential customers and 
small businesses that essentially use their connections in the same ways 
as home users, but it's lethal for mail systems. My provider (WOW 
Business) does it by default.


--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Currently Seeking Steady Work: https://linkedin.com/in/billcole

Re: URIBL_BLOCKED

[Tobi]

Am 15.02.2018 um 02:35 schrieb @lbutlr:
> On 2018-02-14 (09:55 MST), Tobi  wrote:
>>
>> Am 14.02.2018 um 17:16 schrieb @lbutlr:
>>> I can't imagine why i'd be over limit, my mail server is tiny.
>>
>> its not the mailserver that got blocked by limits, but the dns resolver
>> your mailserver uses!
>
> I use my own DNS on Bind 9.12, however the block error is not
appearing today, so...
>
>
>
and does your bind server use other forward servers? Or does it directly
resolve the queries from the authorative nameservers? All depends
whether you resolver is in forward mode or not. If it's in forward
mode then it sounds that the ips of those forwarders might got limited

Re: URIBL_BLOCKED

[@lbutlr]

On 2018-02-14 (09:55 MST), Tobi  wrote:
> 
> Am 14.02.2018 um 17:16 schrieb @lbutlr:
>> I can't imagine why i'd be over limit, my mail server is tiny.
> 
> its not the mailserver that got blocked by limits, but the dns resolver
> your mailserver uses!

I use my own DNS on Bind 9.12, however the block error is not appearing today, 
so...



-- 
"...and that's not incense"

Re: URIBL_BLOCKED

[John Hardin]

On Wed, 14 Feb 2018, Tobi wrote:




Am 14.02.2018 um 17:16 schrieb @lbutlr:

I can't imagine why i'd be over limit, my mail server is tiny.


its not the mailserver that got blocked by limits, but the dns resolver
your mailserver uses!
If you're using a 3rd party resolver (ex the ones from your provider or
8.8.8.8) you can hit the limits quite fast depending on how many other
users use the same resolver for their uribl queries.
I recommend to setup a local resolver (unbound or something similar) and
use that resolver for your mailserver(s).


This detail always gets glossed over: set up a local NON-FORWARDING 
resolver.


If you set up a local resolver and it just forwards requests to your ISP's 
DNS servers, you have not materially changed the problem.


--
 John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
 jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
 key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
---
  A sword is never a killer, it is but a tool in the killer's hands.
  -- Lucius Annaeus Seneca (Martial) 4BC-65AD
---
 8 days until George Washington's 286th Birthday

Re: URIBL_BLOCKED

[Tobi]

Am 14.02.2018 um 17:16 schrieb @lbutlr:
> I can't imagine why i'd be over limit, my mail server is tiny.

its not the mailserver that got blocked by limits, but the dns resolver
your mailserver uses!
If you're using a 3rd party resolver (ex the ones from your provider or
8.8.8.8) you can hit the limits quite fast depending on how many other
users use the same resolver for their uribl queries.
I recommend to setup a local resolver (unbound or something similar) and
use that resolver for your mailserver(s).

Cheers

tobi

Re: URIBL_BLOCKED

[Kevin A. McGrail]

On 2/14/2018 11:16 AM, @lbutlr wrote:

Ah, I didn't know URIBL was a blacklist, I thought it was being used as a 
generic abbreviation variant of RBL.

I can't imagine why i'd be over limit, my mail server is tiny.


It's confusing, I agree.  See 
https://issues.apache.org/jira/browse/COMDEV-267?jql=text%20~%20%22GSOC%202018%22 
for one of the ideas I wrote for improving it.

Re: URIBL_BLOCKED

[@lbutlr]

On 2018-02-13 (14:45 MST), Reindl Harald  wrote:
> 
> Am 13.02.2018 um 21:21 schrieb @lbutlr:
>> 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: cz-salda.ru]
>> So, I’ve never heard of cz-salda.ru, is that the RBL that is blocking me? If 
>> so, where is it listed in SA’s configuration (FreeBSD 11.1-RELEASE)? (tried 
>> a `grep salda.ru /usr/local/etc/mail/spamassassin/*` for no results)
> 
> jesus christ click on the link you even quote

I did click on the link.

> "cz-salda.ru" was the domain which would have been checked against URIBL and 
> URIBL said "you are over limit, go away"

Ah, I didn't know URIBL was a blacklist, I thought it was being used as a 
generic abbreviation variant of RBL.

I can't imagine why i'd be over limit, my mail server is tiny.

-- 
Women like silent men, they think they're listening.

Re: URIBL_BLOCKED

[David B Funk]

If you read that informational spamassassin wiki page referenced in that message
you'd know that it has nothing to do with querying a Russian RBL.

That Russian URI is what the query to URIBL was asking.
So your use of URIBL (via spamassassin) hit a threshold and was blocked.

Read that spamassassin wiki page for more information.


On Tue, 13 Feb 2018, @lbutlr 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: cz-salda.ru]

So, I’ve never heard of cz-salda.ru, is that the RBL that is blocking me? If 
so, where is it listed in SA’s configuration (FreeBSD 11.1-RELEASE)? (tried a 
`grep salda.ru /usr/local/etc/mail/spamassassin/*` for no results)

Also, why would anything be checking a Russian RBL?

Supposedly I can disable this with a line like

Score RCVD_IN_ORBS 0

But “ORBS” wouldn’t be right and there’s nothing in the text above to indicate 
what it might be.





--
Dave Funk  University of Iowa
College of Engineering
319/335-5751   FAX: 319/384-0549   1256 Seamans Center
Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527
#include 
Better is not better, 'standard' is better. B{

Re: URIBL_BLOCKED - which one?

[Tom Hendrikx]

Hi,

Note that on at least Ubuntu from some time ago, unbound was
automatically configured to take the dns servers that were received from
an upstream server during DHCP, and configure those as forwarders.

Can you show us output of: unbound-control list_forwards

Kind regards,
Tom

On 13-10-17 18:59, John Hardin wrote:
> 
> I just want to call this out as the critical detail in all the
> back-and-forth:
> 
>> The main thing with setting up a DNS server for DNSBL lookups is not
>> "caching", it is "non-forwarding".  Take a look at your unbound
>> settings and make sure it is doing all of the lookups itself and not
>> forwarding to another server.
> 




signature.asc
Description: OpenPGP digital signature

Re: URIBL_BLOCKED - which one?

[John Hardin]

I just want to call this out as the critical detail in all the 
back-and-forth:


The main thing with setting up a DNS server for DNSBL lookups is not 
"caching", it is "non-forwarding".  Take a look at your unbound settings 
and make sure it is doing all of the lookups itself and not forwarding 
to another server.


--
 John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
 jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
 key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
---
  The tree of freedom must be freshened from time to time
  with the blood of tyrants and tyrannosaurs.
 -- DW, commenting on the GM6 Lynx .50BMG bullpup
---
 197 days since the first commercial re-flight of an orbital booster (SpaceX)

Re: URIBL_BLOCKED - which one?

[David Jones]

On 10/13/2017 08:45 AM, AJ Weber wrote:

On 10/13/2017 9:23 AM, Reindl Harald wrote:
next time make a notice in your first post that you don#t have a 
serious mailserver but "maybe because I have a DHCP address from a 
major ISP and that's a problem"


OK, I can do that, but there isn't anything in the troubleshooting for 
DNSBL regarding how your IP address is assigned.  It just recommends 
that you use your own, caching DNS server.  If that is important, maybe 
it should be mentioned in the docs?



Am 13.10.2017 um 15:20 schrieb AJ Weber:

I put the following in my local.cf.  This does not work?

dns_available yes
# - REDIRECT DNS LOOKUPS TO LOCAL "unbound" service to avoid RBL bans
dns_server 127.0.0.1

then your machine is *not* using 127.0.0.1 as the only DNS server
So does this "dns_server" directive in my local.cf file work as 
expected?  If so, my SA *is* using 127.0.0.1 as the only DNS server.


It should.  Do a test dig @127.0.0.1 to make sure unbound is resolving 
properly.  I am trying to do a test query from my mail servers to 
multi.uribl.com and not getting any response right now.  I have tried 
from multiple locations on the Internet so I could show you exactly how 
to tell you when you are blocked.


According to the SA rules, if you get back a response with xxx.xxx.xxx.1 
then your query volume is too high and you hit URIBL_BLOCKED.  The way 
to resolve this is to run your own local DNS that does it's own full 
recursive lookup and does not forward to any other DNS server.


Forwarding to other DNS servers combines your queries with potentially 
other queries to the RBL and you don't want that.  You want your DNS 
queries to be independent from any other so they are as few as possible 
to stay under free usage limits.


If you are sure your DNS queries are isolated (not forwarding) and you 
still hit URIBL_BLOCKED, then your only option is to disable those RBLs 
by scoring them as 0.


--
David Jones

Re: URIBL_BLOCKED - which one?

[Bowie Bailey]

On 10/13/2017 9:45 AM, AJ Weber wrote:

On 10/13/2017 9:23 AM, Reindl Harald wrote:
next time make a notice in your first post that you don#t have a 
serious mailserver but "maybe because I have a DHCP address from a 
major ISP and that's a problem"


OK, I can do that, but there isn't anything in the troubleshooting for 
DNSBL regarding how your IP address is assigned.  It just recommends 
that you use your own, caching DNS server.  If that is important, 
maybe it should be mentioned in the docs?


This may be an issue with getting your outgoing mail accepted on other 
mail servers, but it shouldn't make a difference with DNSBL lookups.





Am 13.10.2017 um 15:20 schrieb AJ Weber:

I put the following in my local.cf. This does not work?

dns_available yes
# - REDIRECT DNS LOOKUPS TO LOCAL "unbound" service to avoid RBL bans
dns_server 127.0.0.1

then your machine is *not* using 127.0.0.1 as the only DNS server
So does this "dns_server" directive in my local.cf file work as 
expected?  If so, my SA *is* using 127.0.0.1 as the only DNS server.


As far as I know, it should work.  I just have it set in my 
/etc/resolv.conf so it is used for everything on the machine.  This is 
the simplest setup unless you have some reason to need a different type 
of DNS for other things.


The main thing with setting up a DNS server for DNSBL lookups is not 
"caching", it is "non-forwarding".  Take a look at your unbound settings 
and make sure it is doing all of the lookups itself and not forwarding 
to another server.


--
Bowie

Re: URIBL_BLOCKED - which one?

[AJ Weber]

On 10/13/2017 9:23 AM, Reindl Harald wrote:
next time make a notice in your first post that you don#t have a 
serious mailserver but "maybe because I have a DHCP address from a 
major ISP and that's a problem"


OK, I can do that, but there isn't anything in the troubleshooting for 
DNSBL regarding how your IP address is assigned.  It just recommends 
that you use your own, caching DNS server.  If that is important, maybe 
it should be mentioned in the docs?



Am 13.10.2017 um 15:20 schrieb AJ Weber:

I put the following in my local.cf.  This does not work?

dns_available yes
# - REDIRECT DNS LOOKUPS TO LOCAL "unbound" service to avoid RBL bans
dns_server 127.0.0.1

then your machine is *not* using 127.0.0.1 as the only DNS server
So does this "dns_server" directive in my local.cf file work as 
expected?  If so, my SA *is* using 127.0.0.1 as the only DNS server.

Re: URIBL_BLOCKED - which one?

[AJ Weber]

I put the following in my local.cf.  This does not work?

dns_available yes
# - REDIRECT DNS LOOKUPS TO LOCAL "unbound" service to avoid RBL bans
dns_server 127.0.0.1



On 10/13/2017 8:48 AM, Reindl Harald wrote:



Am 13.10.2017 um 14:40 schrieb AJ Weber:
I guess this qualifies as a newbie question...I've been running SA 
for a while, but haven't really dug into some of the workings...


I occasionally see the URIBL_BLOCKED notice in some of my spam 
results. I read the related web page, and started using unbound as a 
local DNS, but I'm still seeing this


then your machine is *not* using 127.0.0.1 as the only DNS server

Re: URIBL_BLOCKED - which one?

[AJ Weber]

On 10/13/2017 8:57 AM, David Jones wrote:

On 10/13/2017 07:47 AM, Markus Clardy wrote:
URIBL_BLOCKED is in reference to multi.uribl.com 
.

--
  - Markus


To disable queries to multi.uribl.com, put this in your local.cf or 
equivalent in /etc/mail/spamassassin:


score URIBL_BLACK 0
score URIBL_GREY 0
score URIBL_RED 0

Based on my mail flow and other RBLs, I didn't miss this RBL when I 
disabled it years ago.  It may be valuable to some but Spamhaus and 
IVM do most of the heavy lifting on my mail filters.


@Markus, @David: Thank you both.  I started digging into the .cf files 
and did find that reference to multi.uribl.com.


Strange that they are denying my queries.  Maybe because I have a DHCP 
address from a major ISP and that's a problem?  I don't really 
understand how they determine who is querying their RBLs.  I thought 
running unbound locally would help mitigate that problem, but I guess not.


Thanks again.

Re: URIBL_BLOCKED - which one?

[David Jones]

On 10/13/2017 08:01 AM, Reindl Harald wrote:



Am 13.10.2017 um 14:57 schrieb David Jones:
To disable queries to multi.uribl.com, put this in your local.cf or 
equivalent in /etc/mail/spamassassin:


score URIBL_BLACK 0
score URIBL_GREY 0
score URIBL_RED 0

Based on my mail flow and other RBLs, I didn't miss this RBL when I 
disabled it years ago.  It may be valuable to some but Spamhaus and 
IVM do most of the heavy lifting on my mail filters


terrible bad idea and not a solution at all when likely his server is 
not using 127.0.0.1 as the only DNS and so other RBL's also won#t work 
as expected - when you see URIBL_BLACK you have a problem which needs to 
be solved and not burried




His server's /etc/resolv.conf could be pointed to 127.0.0.1 and still 
have too high of volume to hit URLBL_BLOCKED like mine was years ago.


But yes, make sure you have unbound setup and working properly and 
/etc/resolv.conf is pointing to 127.0.0.1.  Then do a manual query to 
127.0.0.1 to confirm it's working:


# dig @127.0.0.1 test.dbl.spamhaus.org

;; ANSWER SECTION:
test.dbl.spamhaus.org.  60  IN  A   127.0.1.2

be sure i scored it not to 6.5 just for fun based on a 8.0 milter-reject 
score


BLOCKED: 1512
URIBL_BLACK: 512

[root@mail-gw:~]$ sa-score.sh URIBL_BLACK
/usr/share/spamassassin
score URIBL_BLACK 0 1.7 0 1.7 # n=0 n=2

/var/lib/spamassassin/3.004001/updates_spamassassin_org
score URIBL_BLACK 0 1.7 0 1.7 # n=0 n=2

/etc/mail/spamassassin/local-*.cf
score URIBL_BLACK 6.5


Like I said, disabling URIBL didn't impact my mail filtering because of 
other RBLs and my specific mail flow.  Different mail flow from 
different locations around the world/Internet will cause SA to be a 
little different for everyone.  There's no one-size-fits-all with mail 
filtering and SA but we have common issues like URIBL_BLOCKED that are 
generally solved the same way.  If your volume is low enough, you can 
keep it and setup your local DNS server to do full recursive lookups. 
If you volume is too high for their free usage limit, then disable it an 
use other RBLs that could be better for your locale.


--
David Jones

Re: URIBL_BLOCKED - which one?

[David Jones]

On 10/13/2017 07:47 AM, Markus Clardy wrote:

URIBL_BLOCKED is in reference to multi.uribl.com .

On Fri, Oct 13, 2017 at 1:40 PM, AJ Weber > wrote:


I guess this qualifies as a newbie question...I've been running SA
for a while, but haven't really dug into some of the workings...

I occasionally see the URIBL_BLOCKED notice in some of my spam
results.  I read the related web page, and started using unbound as
a local DNS, but I'm still seeing this.

Since I have a number of RBL's setup, is there a way to determine
which of the RBLs blocked my query?  Maybe I have one configured
that I need to "license" or subscribe-to in some way?

Thanks for the troubleshooting assistance.

-AJ




--
  - Markus


To disable queries to multi.uribl.com, put this in your local.cf or 
equivalent in /etc/mail/spamassassin:


score URIBL_BLACK 0
score URIBL_GREY 0
score URIBL_RED 0

Based on my mail flow and other RBLs, I didn't miss this RBL when I 
disabled it years ago.  It may be valuable to some but Spamhaus and IVM 
do most of the heavy lifting on my mail filters.


--
David Jones

Re: URIBL_BLOCKED - which one?

[Markus Clardy]

URIBL_BLOCKED is in reference to multi.uribl.com.

On Fri, Oct 13, 2017 at 1:40 PM, AJ Weber  wrote:

> I guess this qualifies as a newbie question...I've been running SA for a
> while, but haven't really dug into some of the workings...
>
> I occasionally see the URIBL_BLOCKED notice in some of my spam results.  I
> read the related web page, and started using unbound as a local DNS, but
> I'm still seeing this.
>
> Since I have a number of RBL's setup, is there a way to determine which of
> the RBLs blocked my query?  Maybe I have one configured that I need to
> "license" or subscribe-to in some way?
>
> Thanks for the troubleshooting assistance.
>
> -AJ
>
>


-- 
 - Markus

Re: URIBL_BLOCKED on 2 Fedora 25 servers with working dnsmasq, w/ NetworkManager service

[Kevin A. McGrail]

On 5/19/2017 1:59 PM, David Jones wrote:

Would it be beneficial to add a local.cf config option to allow SA to
specify a different DNS server rather than what the OS is using in
/etc/resolv.conf?


I believe there is also an idea in bugzilla to specify this on a per RBL 
basis.  I can't find it but I know his issue crops up from time to time.


Regards,
KAM

Re: URIBL_BLOCKED on 2 Fedora 25 servers with working dnsmasq, w/ NetworkManager service

[David Jones]

>Would it be beneficial to add a local.cf config option to allow SA to
>specify a different DNS server rather than what the OS is using in
>/etc/resolv.conf?

Nevermind.  David Funk just posted about "dns_server" that I wasn't
able to find earlier.  Seems like setting that would be the best option
for those where the /etc/resolv.conf is being managed.

I will update the wiki page with this config option.

Dave
  

Re: URIBL_BLOCKED on 2 Fedora 25 servers with working dnsmasq, w/ NetworkManager service

[Kris Deugau]

David Jones wrote:

Would it be beneficial to add a local.cf config option to allow SA to
specify a different DNS server rather than what the OS is using in
/etc/resolv.conf?


IIRC it does, and a quick scan of the Mail::SpamAssassin::Conf man page 
turned up:


   dns_server ip-addr-port  (default: entries provided by Net::DNS)
   Specifies an IP address of a DNS server, and optionally its
   port number.  The dns_server directive may be specified
   multiple times, each entry adding to a list of available
   resolving name servers. The ip-addr-port argument can either
   be an IPv4 or IPv6 address, optionally enclosed in brackets,
   and optionally followed by a colon and a port number. In
   absence of a port number a standard port number 53 is
   assumed. When an IPv6 address is specified along with a port
   number, the address must be enclosed in brackets to avoid
   parsing ambiguity regarding a colon separator. A scoped
   link-local IP address is allowed (assuming underlying
   modules allow it).

   Examples :
dns_server 127.0.0.1
dns_server 127.0.0.1:53
dns_server [127.0.0.1]:53
dns_server [::1]:53
dns_server fe80::1%lo0
dns_server [fe80::1%lo0]:53

   In absence of dns_server directives, the list of name
   servers is provided by Net::DNS module, which typically
   obtains the list from /etc/resolv.conf, but this may be
   platform dependent. Please consult the Net::DNS::Resolver
   documentation for details.

-kgd

Re: URIBL_BLOCKED on 2 Fedora 25 servers with working dnsmasq, w/ NetworkManager service

[David Jones]

>From: Robert Kudyba 

>> Wiki page updated and simplified.

>> https://wiki.apache.org/spamassassin/CachingNameserver 

>For Fedora, since NetworkMangler (as many are fond to call it) is enabled
>by default it might be worthwhile to mention this comment at, but note that
>/etc/resolv.conf will be managed by dnssec-trigger daemon:
>https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver
>#How_to_get_Unbound_and_dnssec-trigger_running

>"If you use NetworkManager, configure it to use unbound. Add the
>following line into /etc/NetworkManager/NetworkManager.conf
>dns=unbound"

The wiki says to search for details in other online articles like that link.
I would prefer not to try to keep up with every little detail like this on
this wiki page since it seems to only get updated every 3 years.  In fact,
I was already thinking about removing any detail and just mention the
DNS servers so there are no details to become invalid in a year or two
like the reference to njabl.org.

Would it be beneficial to add a local.cf config option to allow SA to
specify a different DNS server rather than what the OS is using in
/etc/resolv.conf?

Dave
  

Re: URIBL_BLOCKED on 2 Fedora 25 servers with working dnsmasq, w/ NetworkManager service

[David B Funk]

On Fri, 19 May 2017, John Hardin wrote:


On Thu, 18 May 2017, Rob McEwen wrote:

In many cases, they explain to me that their settings got auto-overwritten 
by their hoster - who just HAD to switch their resolv.conf file back to 
8.8.8.8


cron. job.


Wouldn't the SA config parameter "dns_server" over-ride what's in the 
resolv.conf, or doesn't that work for RBL queries?


EG, set:
  dns_server 127.0.0.1

in your local.cf file and don't worry about what's in the resolv.conf


--
Dave Funk  University of Iowa
College of Engineering
319/335-5751   FAX: 319/384-0549   1256 Seamans Center
Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527
#include 
Better is not better, 'standard' is better. B{

Re: URIBL_BLOCKED on 2 Fedora 25 servers with working dnsmasq, w/ NetworkManager service

[John Hardin]

On Thu, 18 May 2017, Rob McEwen wrote:

In many cases, they explain to me that their settings got auto-overwritten by 
their hoster - who just HAD to switch their resolv.conf file back to 8.8.8.8


cron. job.

--
 John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
 jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
 key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
---
  News flash: Lowest Common Denominator down 50 points
---
 50 days since the first commercial re-flight of an orbital booster (SpaceX)

Re: URIBL_BLOCKED on 2 Fedora 25 servers with working dnsmasq, w/ NetworkManager service

[Robert Kudyba]

>
> Wiki page updated and simplified.
>
> https://wiki.apache.org/spamassassin/CachingNameserver


For Fedora, since NetworkMangler (as many are fond to call it) is enabled
by default it might be worthwhile to mention this comment at, but note that
/etc/resolv.conf will be managed by dnssec-trigger daemon:
https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver#How_to_get_Unbound_and_dnssec-trigger_running
"If you use NetworkManager, configure it to use unbound. Add the following
line into /etc/NetworkManager/NetworkManager.conf
dns=unbound"

Re: URIBL_BLOCKED on 2 Fedora 25 servers with working dnsmasq, w/ NetworkManager service

[David Jones]

From: Matus UHLAR - fantomas 
    
>On 18.05.17 17:05, Robert Kudyba wrote:
>> The link to http://njabl.org/rsync.html is broken at the moment.

>njabl.org is dead four (4) years

>On 18.05.17 14:39, John Hardin wrote:
>>I think this part of the wiki page may not be stressed stongly enough:
>[...]
>>/* Disable forwarding for DNSBL queries */
>[...]
>>zone "combined.njabl.org" { type forward; forward first; forwarders {}; };

>see above

>>zone "fulldom.rfc-ignorant.org" { type forward; forward first; forwarders {}; 
>>};

>rfc-ignorant.org is dead for years.

Wiki page updated and simplified.  

https://wiki.apache.org/spamassassin/CachingNameserver

Re: URIBL_BLOCKED on 2 Fedora 25 servers with working dnsmasq, w/ NetworkManager service

[Matus UHLAR - fantomas]

On 18.05.17 17:05, Robert Kudyba wrote:

The link to http://njabl.org/rsync.html is broken at the moment.


njabl.org is dead four (4) years

On 18.05.17 14:39, John Hardin wrote:

I think this part of the wiki page may not be stressed stongly enough:

[...]

/* Disable forwarding for DNSBL queries */

[...]

zone "combined.njabl.org" { type forward; forward first; forwarders {}; };


see above


zone "fulldom.rfc-ignorant.org" { type forward; forward first; forwarders {}; };


rfc-ignorant.org is dead for years.

--
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.
"One World. One Web. One Program." - Microsoft promotional advertisement
"Ein Volk, ein Reich, ein Fuhrer!" - Adolf Hitler

Re: URIBL_BLOCKED on 2 Fedora 25 servers with working dnsmasq, w/ NetworkManager service

[Rob McEwen]

On 5/18/2017 5:46 PM, David Jones wrote:

it should be pretty clear now to not use a forwarding DNS server locally and
do not point the server to another DNS server in /etc/resolv.conf.


Thanks David!

Some may be interested to know at least 15% of my entire labor 
"overhead" for running invaluement - involves playing "whack a mole" (so 
to speak) with both testers and existing subscribers - whose DNS 
settings CONSTANTLY revert back to sending direct queries to invaluement 
via Google and/or OpenDNS - which are then blocked - even as the 
instructions were extremely clear about how/why not to do it that way.


In many cases, they explain to me that their settings got 
auto-overwritten by their hoster - who just HAD to switch their 
resolv.conf file back to 8.8.8.8


In some rare worst case scenarios - I have to "fire the customer", due 
to many repeated incidents where the labor involved in constantly 
babysitting their settings - was no longer worth their subscription payment.


And unfortunately there is just basically a very sizable portion of IT 
professionals in the entire world... probably hundreds of thousands of 
IT people - who have been convinced that pointing all DNS to 8.8.8.8 is 
standard operating procedure that they think is always the best way.


For me, it feels like annoying busy work. Imagine that for at least one 
hour out of your day - you have to stop what you're doing and dig a hole 
in your back yard - and then fill it back in.


So I'm grateful every time I see thread like this that pushes back 
against that, and encourages others to run industry standard 
non-forwarding caching DNS servers.


THANKS!

--
Rob McEwen
http://www.invaluement.com

Re: URIBL_BLOCKED on 2 Fedora 25 servers with working dnsmasq, w/ NetworkManager service

[Martin Gregorie]

On Thu, 2017-05-18 at 21:46 +, David Jones wrote:
> > From: John Hardin 
> > I think this part of the wiki page may not be stressed stongly
> > enough:
> > Non-forwarding
> > If you have a large ISP or are using large public DNS provider(s)
> > it is 
> > recommended you not forward mail-related DNS traffic through their
> > DNS 
> > servers (though non-mail DNS traffic from your site shouldn't have 
> > problems.) With bind, this means not having any "forwarders"
> > listed. Or, 
> > at a minimum, you could create exemptions by defining empty
> > forwarders for 
> > DNSBL zones, like this:
> 
> https://wiki.apache.org/spamassassin/CachingNameserver
> 
> I just simplified that page quite a bit.  It needs a little more work
> on it but it
> should be pretty clear now to not use a forwarding DNS server locally
> and do
> not point the server to another DNS server in /etc/resolv.conf.
> 
Minor correction: The Bind for RedHat section of the page needs changes
to bring it into like with the unbound instructions.

For Fedora you'd use: 

dnf install bind
systemctl enable bind
systemctl start bind

Can't comment about RHEL/CentOS


Martin

Re: URIBL_BLOCKED on 2 Fedora 25 servers with working dnsmasq, w/ NetworkManager service

[Bill Cole]

On 18 May 2017, at 17:05, Robert Kudyba wrote:


On May 18, 2017, at 4:41 PM, David Jones  wrote:


From: Robert Kudyba 



Am 18.05.2017 um 22:30 schrieb Reindl Harald:
"with working dnsmasq" says all - DNSMASQ DON'T DO RECURSION - IT 
CAN#T
you are forwarding to some other nameserver and you are not the 
only one



But the nameserver I’m forwarding to is in our university.


Your server needs to do it's on full recursive DNS lookups.


So dnsmasq is no longer an option?


It never was a reasonable option for anything more than a toy mail 
server on a network with real recursers that aren't shared by mail 
servers doing significant volume.


If you want a mail server to perform decently while using all the modern 
tools for fraud & spam detection (DNSBLs, SPF, DKIM, DMARC, DANE, 
requiring FCrDNS with a non-generic name, etc.) you need a fully 
recursive (never-forwarding) DNS resolver with a sizable cache on the 
same machine or at worst the same physical LAN. A substantial fraction 
of the time it takes to accept or reject a piece of mail is spent 
waiting for DNS replies, especially if you are relying on a cache that 
in on the other side of a router.



/etc/resolv.dnsmasq
search subdomain.ourschool.edu ourschool.edu
nameserver 150.108.x.yy
nameserver 150.108.y.xx


Tangent: You do know that your email address a complete Received trail 
is in your mail, right? Not much point in obfuscation...


Isn’t the point of enabling dnsmasq to cache DNS calls? I’m just 
following the
instructions at  
https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.apache.org_spamassassin_CachingNameserver-23=DwIFEA=aqMfXOEvEJQh2iQMCb7Wy8l0sPnURkcqADc2guUW8IM=X0jL9y0sL4r4iU_qVtR3lLNo4tOL1ry_m7-psV3GejY=Xfhs5TxObQNstiygWZx6rtuJIMJ_Q65ueMPfIdG6MPw=YjlCBF15mxOWWMeVSUh_L9Jz1s8o454zFPqUC_5chAU=

Installing_dnsmasq_as_a_Caching_Nameserver which BTW has a broken
link to instructions.


Evidence that the wiki does not see a lot of maintenance. There's a LOT 
of staleness there.




I see there’s rbldnsd.


ONLY if you have a way to get full copies of the zones you want, because 
rbldnsd is ONLY authoritative. It is useful if you're paying for a 
subscription to a DNSBL provider like Spamhaus, but it's NOT a 
general-purpose resolver.


On Fedora and one of our 2 servers, we run NIS & ypbind. One runs 
NetworkManager and the other just the network service. I guess I’m 
looking for the best recommendation and easy configuration without 
conflicts.


IMHO NetworkMangler doesn't belong on ANY server, but that's a rant for 
elsewhere...


Unbound is by far my favorite for pure simple caching fully-recursive 
resolvers. I use BIND as well, but only where I need complex rigs that I 
have not yet tried to implement with Unbound.


The link to http://njabl.org/rsync.html  
is broken at the moment.


It shall remain so until such time as it is removed, as NJABL is long 
dead.

Re: URIBL_BLOCKED on 2 Fedora 25 servers with working dnsmasq, w/ NetworkManager service

[David Jones]

>From: John Hardin 

>I think this part of the wiki page may not be stressed stongly enough:

>Non-forwarding

>If you have a large ISP or are using large public DNS provider(s) it is 
>recommended you not forward mail-related DNS traffic through their DNS 
>servers (though non-mail DNS traffic from your site shouldn't have 
>problems.) With bind, this means not having any "forwarders" listed. Or, 
>at a minimum, you could create exemptions by defining empty forwarders for 
>DNSBL zones, like this:

https://wiki.apache.org/spamassassin/CachingNameserver

I just simplified that page quite a bit.  It needs a little more work on it but 
it
should be pretty clear now to not use a forwarding DNS server locally and do
not point the server to another DNS server in /etc/resolv.conf.

Dave

Re: URIBL_BLOCKED on 2 Fedora 25 servers with working dnsmasq, w/ NetworkManager service

[John Hardin]

On Thu, 18 May 2017, Robert Kudyba wrote:




Am 18.05.2017 um 22:30 schrieb Reindl Harald:

"with working dnsmasq" says all - DNSMASQ DON'T DO RECURSION - IT CAN#T
you are forwarding to some other nameserver and you are not the only one


But the nameserver I’m forwarding to is in our university.


/etc/resolv.dnsmasq
search subdomain.ourschool.edu ourschool.edu
nameserver 150.108.x.yy
nameserver 150.108.y.xx

seriously - what do you think happens?
you and everybody else on planet earth using 150.xx.xx.xx are coming with the 
same IP to the DNSBL/URIBL hosts


Isn’t the point of enabling dnsmasq to cache DNS calls? I’m just 
following the instructions at 
https://wiki.apache.org/spamassassin/CachingNameserver#Installing_dnsmasq_as_a_Caching_Nameserver 
which BTW has a broken link to instructions.


I think this part of the wiki page may not be stressed stongly enough:



Non-forwarding

If you have a large ISP or are using large public DNS provider(s) it is 
recommended you not forward mail-related DNS traffic through their DNS 
servers (though non-mail DNS traffic from your site shouldn't have 
problems.) With bind, this means not having any "forwarders" listed. Or, 
at a minimum, you could create exemptions by defining empty forwarders for 
DNSBL zones, like this:


/* Disable forwarding for DNSBL queries */
zone "multi.uribl.com" { type forward; forward first; forwarders {}; };
zone "dnsbl.sorbs.net" { type forward; forward first; forwarders {}; };
zone "combined.njabl.org" { type forward; forward first; forwarders {}; };
zone "activationcode.r.mail-abuse.com" { type forward; forward first; 
forwarders {}; };
zone "nonconfirm.mail-abuse.com" { type forward; forward first; forwarders {}; 
};
zone "iadb.isipp.com" { type forward; forward first; forwarders {}; };
zone "bl.spamcop.net" { type forward; forward first; forwarders {}; };
zone "fulldom.rfc-ignorant.org" { type forward; forward first; forwarders {}; };
zone "list.dnswl.org" { type forward; forward first; forwarders {}; };
zone "blackholes.mail-abuse.org" { type forward; forward first; forwarders {}; 
};
zone "bl.score.senderscore.com" { type forward; forward first; forwarders {}; };
zone "zen.spamhaus.org" { type forward; forward first; forwarders {}; };


--
 John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
 jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
 key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
---
  If you are "fighting for social justice," then you are defining
  yourself as someone who considers regular old everyday
  *equal* justice to be something you don't want.   -- GOF at TSM
---
 49 days since the first commercial re-flight of an orbital booster (SpaceX)

Re: URIBL_BLOCKED on 2 Fedora 25 servers with working dnsmasq, w/ NetworkManager service

[Robert Kudyba]

On May 18, 2017 5:11 PM, "Reindl Harald"  wrote:



Am 18.05.2017 um 23:05 schrieb Robert Kudyba:

>
> On May 18, 2017, at 4:41 PM, David Jones  djo...@ena.com>> wrote:
>>
>> From: Robert Kudyba >
>>>
>>
>> Am 18.05.2017 um 22:30 schrieb Reindl Harald:

> "with working dnsmasq" says all - DNSMASQ DON'T DO RECURSION - IT CAN#T
> you are forwarding to some other nameserver and you are not the only
> one
>

>> But the nameserver I’m forwarding to is in our university.
>>>
>>
>> Your server needs to do it's on full recursive DNS lookups.
>>
>
> So dnsmasq is no longer an option?
>

it was never - no dns software which needs another nameserver for it's job
is suiteable on a inbound spamfilter

I will fix this wiki page now…
>>
>
> I see there’s rbldnsd. On Fedora and one of our 2 servers, we run NIS &
> ypbind. One runs NetworkManager and the other just the network service. I
> guess I’m looking for the best recommendation and easy configuration
> without conflicts. The link to https://urldefense.proofpoint.
> com/v2/url?u=http-3A__njabl.org_rsync.html=DwID-g=aqMfXO
> EvEJQh2iQMCb7Wy8l0sPnURkcqADc2guUW8IM=X0jL9y0sL4r4iU_qVtR3
> lLNo4tOL1ry_m7-psV3GejY=_GpsD3DHYXO7rQ_TtNdtAq_0iO39u8Q
> BVn0morPE0hs=-BaByTtCkQ37-fWpZVVp9ZMa7nLIUpa8OWscKkMi3T8=  is broken
> at the moment
>

rbldnsd is a completly different thing and supposed to host your *own*
dnsbl zones

what you you need is a *basic* namesever just donig recursion and tell your
mailserver just use it

* get rid of other crap
* dnf install unbound
* systemctl enable unbound
* systemctl start unound
* just use your unbound on 127.0.0.1


It looks like I'll have to

   - Add the following line into /etc/NetworkManager/NetworkManager.conf

dns=unbound

or ask the idiot maintaining "I'm forwarding to is in our university" why
he is forwarding queries outside your university to google instead doing
recursion


Probably because the university uses gmail. Our department does not.

Re: URIBL_BLOCKED on 2 Fedora 25 servers with working dnsmasq, w/ NetworkManager service

[Robert Kudyba]

> On May 18, 2017, at 4:41 PM, David Jones  wrote:
> 
>> From: Robert Kudyba 
> 
>>> Am 18.05.2017 um 22:30 schrieb Reindl Harald:
 "with working dnsmasq" says all - DNSMASQ DON'T DO RECURSION - IT CAN#T
 you are forwarding to some other nameserver and you are not the only one
> 
>> But the nameserver I’m forwarding to is in our university.
> 
> Your server needs to do it's on full recursive DNS lookups.

So dnsmasq is no longer an option?

> 
>>> /etc/resolv.dnsmasq
>>> search subdomain.ourschool.edu ourschool.edu
>>> nameserver 150.108.x.yy
>>> nameserver 150.108.y.xx
>>> 
>>> seriously - what do you think happens?
>>> you and everybody else on planet earth using 150.xx.xx.xx are coming with
>> the same IP to the DNSBL/URIBL hosts
> 
> He's being rude but he's right.  You can't guarantee that all of the other DNS
> queries being made through your university DNS servers isn't going over the
> free limit on the URIBL DNS servers.
> 
>> Isn’t the point of enabling dnsmasq to cache DNS calls? I’m just following 
>> the
>> instructions at  
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.apache.org_spamassassin_CachingNameserver-23=DwIFEA=aqMfXOEvEJQh2iQMCb7Wy8l0sPnURkcqADc2guUW8IM=X0jL9y0sL4r4iU_qVtR3lLNo4tOL1ry_m7-psV3GejY=Xfhs5TxObQNstiygWZx6rtuJIMJ_Q65ueMPfIdG6MPw=YjlCBF15mxOWWMeVSUh_L9Jz1s8o454zFPqUC_5chAU=
>>  
>> Installing_dnsmasq_as_a_Caching_Nameserver which BTW has a broken
>> link to instructions.
> 
> I will fix this wiki page now…

I see there’s rbldnsd. On Fedora and one of our 2 servers, we run NIS & ypbind. 
One runs NetworkManager and the other just the network service. I guess I’m 
looking for the best recommendation and easy configuration without conflicts. 
The link to http://njabl.org/rsync.html  is broken 
at the moment. 

Re: URIBL_BLOCKED on 2 Fedora 25 servers with working dnsmasq, w/ NetworkManager service

[David Jones]

>From: Robert Kudyba 

>> Am 18.05.2017 um 22:30 schrieb Reindl Harald:
>>> "with working dnsmasq" says all - DNSMASQ DON'T DO RECURSION - IT CAN#T
>>> you are forwarding to some other nameserver and you are not the only one

>But the nameserver I’m forwarding to is in our university.

Your server needs to do it's on full recursive DNS lookups.

>> /etc/resolv.dnsmasq
>> search subdomain.ourschool.edu ourschool.edu
>> nameserver 150.108.x.yy
>> nameserver 150.108.y.xx
>> 
>> seriously - what do you think happens?
>> you and everybody else on planet earth using 150.xx.xx.xx are coming with
>the same IP to the DNSBL/URIBL hosts

He's being rude but he's right.  You can't guarantee that all of the other DNS
queries being made through your university DNS servers isn't going over the
free limit on the URIBL DNS servers.

>Isn’t the point of enabling dnsmasq to cache DNS calls? I’m just following the
>instructions at  https://wiki.apache.org/spamassassin/CachingNameserver#
> Installing_dnsmasq_as_a_Caching_Nameserver which BTW has a broken
>link to instructions.

I will fix this wiki page now...

Dave

Re: URIBL_BLOCKED on 2 Fedora 25 servers with working dnsmasq, w/ NetworkManager service

[David Jones]

>From: Robert Kudyba 

>host -tTXT test.uribl.com.multi.uribl.com
>test.uribl.com.multi.uribl.com descriptive text "127.0.0.1 -> Query Refused. 
>See
> http://uribl.com/refused.shtml for more information [Your DNS IP: 
> 74.125.19.15]"

>Some logs to show dnsmasq in use:
>May 17 14:23:32 ourserver dnsmasq[2336]: reading /etc/resolv.conf
>May 17 14:23:32 ourserver dnsmasq[2336]: using nameserver 150.108.x.yy#53
>May 17 14:23:32 ourserver dnsmasq[2336]: using nameserver 150.108.x.zz#53
>May 17 14:23:32 ourserver dnsmasq[2336]: reading /etc/resolv.conf
>May 17 14:23:32 ourserver dnsmasq[2336]: using nameserver 127.0.0.1#53

You can't use dnsmasq since it only forwards to other DNS servers.  You need to
use unbound, BIND, or my favorite PowerDNS recursor so that your server does
it's own full recursive DNS lookups and doesn't rely on any other servers.  When
you rely on other DNS servers, then your DNS queries will be combined with all
of the other queries pushing you over the URIBL free usages limit.

Dave

Re: URIBL_BLOCKED on 2 Fedora 25 servers with working dnsmasq, w/ NetworkManager service

[Robert Kudyba]

> Am 18.05.2017 um 22:30 schrieb Reindl Harald:
>> "with working dnsmasq" says all - DNSMASQ DON'T DO RECURSION - IT CAN#T
>> you are forwarding to some other nameserver and you are not the only one

But the nameserver I’m forwarding to is in our university.

> /etc/resolv.dnsmasq
> search subdomain.ourschool.edu ourschool.edu
> nameserver 150.108.x.yy
> nameserver 150.108.y.xx
> 
> seriously - what do you think happens?
> you and everybody else on planet earth using 150.xx.xx.xx are coming with the 
> same IP to the DNSBL/URIBL hosts

Isn’t the point of enabling dnsmasq to cache DNS calls? I’m just following the 
instructions at 
https://wiki.apache.org/spamassassin/CachingNameserver#Installing_dnsmasq_as_a_Caching_Nameserver
 which BTW has a broken link to instructions.

Re: URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.

[Benny Pedersen]

Emin Akbulut skrev den 2017-02-14 16:03:

It's Gmail. When I hit the reply button, it only sends the last
poster, -in this reply, it's you and I manually added users@-


gmail ignores List-* headers, leading to much more problems then users 
using gmail


if you need more support on there broken gmail ask them

Re: URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.

[Emin Akbulut]

It's Gmail. When I hit the reply button, it only sends the last poster,
-in this reply, it's you and I manually added users@-

On Tue, Feb 14, 2017 at 5:57 PM, Reindl Harald <h.rei...@thelounge.net>
wrote:

> what is wrong with your mailprogram that it appearently is lacking a
> "reply" button and so you seem to need forward messages which breaks
> threading in any sane mail-client and list-archive?
>
> Am 14.02.2017 um 15:43 schrieb Emin Akbulut:
>
>>
>> -- Forwarded message --
>> From: *David Jones* <djo...@ena.com <mailto:djo...@ena.com>>
>>     Date: Tue, Feb 14, 2017 at 5:33 PM
>> Subject: Re: URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL
>> was blocked.
>> To: "users@spamassassin.apache.org
>> <mailto:users@spamassassin.apache.org>"
>> <users@spamassassin.apache.org <mailto:users@spamassassin.apache.org
>> >>
>>
>>
>> Note that if your mail volume is high enough, you may
>> still hit their free usage limit even after doing this.
>> Dave
>>
>>
>>
>> I've got plenty of inboxes. I've read SpamAssassin's info page about the
>> block and it says:
>>
>> Resolving the block might be as simple as using your
>> own non-forwarding
>> <https://wiki.apache.org/spamassassin/CachingNameserver#Non-
>> forwarding> caching
>> nameserver
>> <https://wiki.apache.org/spamassassin/CachingNameserver> to avoid
>> being lumped together with other users queries; setting up your own
>> mirror of the DNS-blocklist; or paying to use the blocklist. The
>> choice is up to the DNS-Blocklist administrator.
>>
>>
>>
>> Then I found myself at configuring DNS cond. forwarder because of an
>> incorrect advise
>>
>

Re: URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.

[Benny Pedersen]

Emin Akbulut skrev den 2017-02-14 14:21:


How can I set the DNS conditional forwarders properly?


setup spamasassin to use 127.0.0.1 as dns server, not any remote ips

i dont know anything on how windows works :=)

Re: URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.

[David Jones]

>From: RW <rwmailli...@googlemail.com>
>Sent: Tuesday, February 14, 2017 7:51 AM
>To: users@spamassassin.apache.org
>Subject: Re: URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was 
>blocked.
    
>On Tue, 14 Feb 2017 16:21:04 +0300
>Emin Akbulut wrote:

>> Hi
>> 
>> URIBL checks are blocked. I think bec. of so many queries. I'm
>> advised to set up conditional forwarder on Windows DNS Server.>

>If you mean that you should *stop* forwarding this traffic than that
>is correct. You need to be doing your own look-ups to the
>whitelist/blacklist servers from your own IP address, forwarding to a
>shared server is what causes the problem.

This is a common problem and has been discussed on this list
many times before.  I wish SpamAssassin had a better way to
handle this rule hit and explaining to the server admin but I
don't think this is possible.

Basically you need to point to a DNS server that you manage
or know for sure that it's not forwarding to another DNS server.
It's not required to have a local DNS server on your SA box but
it's the best way to know for sure that it's doing full recursive
lookups, not forwarding to other DNS servers that will
consolidate your queries with others pushing you over the
free usage limits and thus hitting this rule.

Note that if your mail volume is high enough, you may
still hit their free usage limit even after doing this.

Dave

Re: URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.

[RW]

On Tue, 14 Feb 2017 16:21:04 +0300
Emin Akbulut wrote:

> Hi
> 
> URIBL checks are blocked. I think bec. of so many queries. I'm
> advised to set up conditional forwarder on Windows DNS Server.

If you mean that you should *stop* forwarding this traffic than that
is correct. You need to be doing your own look-ups to the
whitelist/blacklist servers from your own IP address, forwarding to a
shared server is what causes the problem.



> How can I set the DNS conditional forwarders properly?

This is a question about Windows.

Re: URIBL_BLOCKED while using local BIND

[Matus UHLAR - fantomas]

On 16.09.15 09:50, Bowie Bailey wrote:
The SA config is probably a better solution than the bind exemptions.  


I would say just the opposite. For example, MTA at SMTP level can look up
RBLs, and SA would benefit from having records in local cache.

--
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.
The only substitute for good manners is fast reflexes. 

Re: URIBL_BLOCKED while using local BIND

[Bowie Bailey]

On 9/18/2015 4:25 PM, Matus UHLAR - fantomas wrote:

On 16.09.15 09:50, Bowie Bailey wrote:
The SA config is probably a better solution than the bind exemptions. 


I would say just the opposite. For example, MTA at SMTP level can look up
RBLs, and SA would benefit from having records in local cache


True.  I was thinking more in terms of the amount of work needed in 
setup and maintenance.  Whenever SA changes it's RBL list (which is, 
admittedly, not that often), you need to update the exemption list in 
bind.  And if you make a typo in the domain name, it is not immediately 
obvious since you are still getting results from the query.


On the other hand, if you point SA to it's own non-forwarding DNS 
server, it just works and you don't have to touch it again.


--
Bowie

Re: URIBL_BLOCKED while using local BIND

[Marc Richter]

Hi Adam,

that's a great workarround and perfectly fits my needs! Thank you for 
that! :)


I'll use this if I cannot find out why my exemptions do not work in a 
reasonable amount of time.


Best regards,
Marc

Am 15.09.2015 um 20:14 schrieb Adam Major:

Hi.

If you don't want change DNS resolver for all DNS queries from your
server you can add in SA config line:

dns_server x.y.z.k:53

where z.y.z.k is IP DNS server using to resolve only by SA.


Then in resolv.conf you can use different (ex. ISP) DNS server.


More info:

http://spamassassin.apache.org/full/3.4.x/doc/Mail_SpamAssassin_Conf.html#port



Best Regards.

Re: URIBL_BLOCKED while using local BIND

[Marc Richter]

Hi Dave,

you are right: That is a measurement of "how fast is my ISP's cache?". 
But literally, that's all I want:
I do not want "better" DNS results than I got from my ISPs DNS servers 
so far. I'd like to keep up the benefit of using a large DNS cache, 
without blocking these resources on my host. My ISPs DNS servers are 
dedicated to resolve and cache the results. Why shouldn't I make use of 
these cached data, but build up an own pool of cached data for a second 
time, blocking resources on my machine, which can make good use of these 
resources for another workload?
Also, this caches are preserved when my machines are restarted. And WHY 
these results are faster provided is technically an unfair comparison, 
yes, but summed up to what's important for my case it isn't.


All I want is to make queries to the DNSBL services on my own and not 
using my ISPs servers, since these have drained their free contingent 
all the time.


That's why I have tried to configure bind as suggested at 
http://wiki.apache.org/spamassassin/CachingNameserver#Non-forwarding , 
but this seems not to work.


Best regards,
Marc

Am 15.09.2015 um 16:41 schrieb Dave Funk:

However you did not empty your ISP's dns server cache.
That 2 msec response time is from his cache, the 543 msec for your
server is when it's not in your server's cache.
So you're not making a fair comparison.

A response from a cache is always going to be faster, that's why people
use caching servers.
However with everybody & his cat using your ISP's server it gets query
blocked and thus is caching the bad (blocked) response.

So either you get bad data fast or good data slowly.

Once you get a second spam with similar contents, queries for that copy
will be in your cache and be fast.

Given that a modern SA parallelizes DNS queries a somewhat slow DNS
response (hundreds of Msecs) won't have too much overall affect on the
spam processing time.

On Tue, 15 Sep 2015, Marc Richter wrote:


Yes

Am 15.09.2015 um 13:30 schrieb Axb:

On 09/15/2015 01:23 PM, Marc Richter wrote:

Also, you shouldn't make assumptions without measuring something:

1. without forwarding:

;; Query time: 543 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)

2. with forwarding to my ISP's servers:

;; Query time: 2 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)

That's 271 times faster than root-servers's lookup.


did you EMPTY cache after each query?

Re: URIBL_BLOCKED while using local BIND

[Reindl Harald]

Am 16.09.2015 um 11:36 schrieb Marc Richter:

I am - it's the very same setup you describe like I'm using. The only
difference is that I do not rely on a dedicated DNS resolver I setup
myself, but the centralized nameserver of my ISP, which works exactly
like any nameserver I'd setup myself.


no it does not

ISP nameservers have proven all sort of troubles over the years like 
ignoring TTL, spit out random expired responses, from one day to the 
next decide to answer wildcard instead NXDOMAIN which kills any 
mailservice from one moment to the next and so on



Although, the intended setup with exemptions by defining empty
forwarders for DNSBL zones was not my idea - this scenario is described
on the SA wiki as a working solution:
http://wiki.apache.org/spamassassin/CachingNameserver#Non-forwarding

This seems to not be working, so I'm heading for this ML to find out why.


well, that would be a question for the bind-ML


you should read and
understand their posts in full before doing so at least, to not look
like a jackass additional to an impolite person.


obviously it don't work


That's right - so let's work out the reasons for it and not fight
against each other. This setup is described in the official SA wiki and
not working. So let's improve this public resource together.


until now it is not sure that your setup is correct (only using 
127.0.0.1 as nameserver)



What I wrote is:

 >> ... but created the exemptions as listed at the very bottom of that
 >> site, to make sure my bind don't forward requests on these services
 >> to my ISP's DNS ...


but it does forward otherwise the problem would be solved


You are right. I double-checked in the meantime (and awaited some spams
to arrive) by disabling forwarding completely. It does work then.
I do and did not doubt this - but the issue remains: I'd still like to
forward all of my requests to take the advantage of my ISPs DNS caches.
But those queries to the DNSBL zones should be resolved exceptionally by
my local recursion nameserver.

Why is the example in the SA wiki not working?


maybe you did not tell SA directly or the OS in /etc/resolv.conf *only* 
use 127.0.0.1 as DNS server



I do - and you are right with what you described. But all you mentioned
is not important for my setup and specific application. Fast resolution
and a huge DNS cache is. I know, that those aren't the times achieved
when my ISPs DNS servers initiate a recursive query on the data, but
deliver what they already have cached, only. But that is OK for me. I
only need these cached data


well, you only benefit from the ISP cache when another customer within 
the TTL did the same request, in any other case the response would be 
slower because one hop more


you are still missing the whole picture!


When I would do the recursive resolvings on my own, not only my initiate
queries would take quite a long time compared to those my ISPs does, but
I would "waste" a lot of resources needed to provide these caches on my
own servers. My setup simply isn't big enough to reasonably dedicate a
box on it's own or use that resources of my apps host, only to provide
nearly the same my ISP already serves.


you just need 64-128 MB RAM for a reasonable cache and when it comes to 
ressources i would use unbound instead named as caching-only resolver


*all* blacklist services have a very low TTL, with unbound you even 
cache *much* better than any ISP resolver because you can sepcifiy that 
responses are cached for at least 10 minutes instead ask every 5 seconds 
again and again - they are doing that to enforce hit their limits by 
intention


 msg-cache-size: 64m
 neg-cache-size: 64m
 rrset-cache-size: 128m
 cache-min-ttl: 600
 cache-max-ttl: 10800



signature.asc
Description: OpenPGP digital signature

Re: URIBL_BLOCKED while using local BIND

[Marc Richter]

Hi Axb,

yes, I did c the config block from the wiki 1:1 into my BIND setup.
I have added that zone - exemption you suggested into my config.

I'll wait for a few spams to arrive to see the results.

Thank you for sharing your thoughts.

Best regards,
Marc

Am 16.09.2015 um 11:41 schrieb Axb:

On 09/16/2015 11:36 AM, Marc Richter wrote:

Although, the intended setup with exemptions by defining empty
forwarders for DNSBL zones was not my idea - this scenario is described
on the SA wiki as a working solution:
http://wiki.apache.org/spamassassin/CachingNameserver#Non-forwarding

This seems to not be working, so I'm heading for this ML to find out why.


are you doing this:

zone "multi.uribl.com" { type forward; forward first; forwarders {}; };

if yes try adding:

zone "uribl.com" { type forward; forward first; forwarders {}; };

Re: URIBL_BLOCKED while using local BIND

[Marc Richter]

if you are trying to insult people at all costs


really?

you would recognize it when i intend to do so


Please read your previous reply again. You will find that you used a 
very harsh tone against someone who comes here asking questions in a 
reasonable and moderate tone. Yes - maybe I *am* doing something wrong - 
that's even likely, since otherwise I'd be not the first to find such an 
issue in such a widely used software. But I expect the same reasonable 
tone in the answers to my question like I'm writing my questions in.



*any* expierienced mailadmin out there has a local recursion nameserver
on his MTA or at least somewhere in his LAN to use a central local cache
but only you can't do it?


I am - it's the very same setup you describe like I'm using. The only 
difference is that I do not rely on a dedicated DNS resolver I setup 
myself, but the centralized nameserver of my ISP, which works exactly 
like any nameserver I'd setup myself.


Although, the intended setup with exemptions by defining empty 
forwarders for DNSBL zones was not my idea - this scenario is described 
on the SA wiki as a working solution: 
http://wiki.apache.org/spamassassin/CachingNameserver#Non-forwarding


This seems to not be working, so I'm heading for this ML to find out why.


you should read and
understand their posts in full before doing so at least, to not look
like a jackass additional to an impolite person.


obviously it don't work


That's right - so let's work out the reasons for it and not fight 
against each other. This setup is described in the official SA wiki and 
not working. So let's improve this public resource together.



What I wrote is:

 >> ... but created the exemptions as listed at the very bottom of that
 >> site, to make sure my bind don't forward requests on these services
 >> to my ISP's DNS ...


but it does forward otherwise the problem would be solved


You are right. I double-checked in the meantime (and awaited some spams 
to arrive) by disabling forwarding completely. It does work then.
I do and did not doubt this - but the issue remains: I'd still like to 
forward all of my requests to take the advantage of my ISPs DNS caches. 
But those queries to the DNSBL zones should be resolved exceptionally by 
my local recursion nameserver.


Why is the example in the SA wiki not working?


 > and *no* the ISP nameserver is *not* a lot faster in most cases

Also, you shouldn't make assumptions without measuring something:

1. without forwarding:

;; Query time: 543 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)

2. with forwarding to my ISP's servers:

;; Query time: 2 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)

That's 271 times faster than root-servers's lookup.


*lol* yes, the second hit already in your local cache when you don't
clear it before, you never ever have 2 ms with a forwarding reslover on
the internet asked - never ever!

for *that* one specific request if you have the luck it's in his cache
it *can* be faster, otherwise the ISP would need to do the whole
recursion itself and then answer to your cache with one additional hop

what you also ignore is the fact that you get the lowered TTL depending
on how old the cache entry on the forwarder is while you own cache entry
with recursion would be valid the whole TTL of the SOA

in other words: you don't look at the whole picture


I do - and you are right with what you described. But all you mentioned 
is not important for my setup and specific application. Fast resolution 
and a huge DNS cache is. I know, that those aren't the times achieved 
when my ISPs DNS servers initiate a recursive query on the data, but 
deliver what they already have cached, only. But that is OK for me. I 
only need these cached data.
When I would do the recursive resolvings on my own, not only my initiate 
queries would take quite a long time compared to those my ISPs does, but 
I would "waste" a lot of resources needed to provide these caches on my 
own servers. My setup simply isn't big enough to reasonably dedicate a 
box on it's own or use that resources of my apps host, only to provide 
nearly the same my ISP already serves.



anyways 543 msec is high

;; Query time: 121 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Di Sep 15 13:27:59 CEST 2015
;; MSG SIZE  rcvd: 57



That's correct and one of the reasons I'd like to rely on my ISPs data, 
since changing this is out of my hands.


Best regards,
Marc

Re: URIBL_BLOCKED while using local BIND

[Marc Richter]

Hi Bowie,

thanks for your reply.


I would suggest temporarily removing the forward completely as a test
and see if this fixes the problem.  If so, then your exemptions are not
working correctly.  If not, then double-check that you are actually
using the local server and not still querying the ISP's server.


I did exactly this the last hours and let spam reach my box during that 
time. When forwarding is disabled completely, the DNSBL services work. 
So, as you said, something's not OK with the exemptions.


This makes me wonder a bit, since these are described on the SA wiki 
site 
http://wiki.apache.org/spamassassin/CachingNameserver#Non-forwarding and 
they were copied 1:1 into my setup.


I'll try to find out what's wrong in the Bind-community, too.

Best regards,
Marc

Re: URIBL_BLOCKED while using local BIND

[Marc Richter]

Hi Axb,

Am 16.09.2015 um 11:41 schrieb Axb:

Although, the intended setup with exemptions by defining empty
forwarders for DNSBL zones was not my idea - this scenario is described
on the SA wiki as a working solution:
http://wiki.apache.org/spamassassin/CachingNameserver#Non-forwarding

This seems to not be working, so I'm heading for this ML to find out why.


are you doing this:

zone "multi.uribl.com" { type forward; forward first; forwarders {}; };

if yes try adding:

zone "uribl.com" { type forward; forward first; forwarders {}; };


looks like this is it! I changed this as suggested and send myself some 
spams. The DNSBL Checks are working now, Thank you :)



Best regards,
Marc

Re: URIBL_BLOCKED while using local BIND

[Reindl Harald]

Am 16.09.2015 um 13:38 schrieb Marc Richter:

Am 16.09.2015 um 11:41 schrieb Axb:

Although, the intended setup with exemptions by defining empty
forwarders for DNSBL zones was not my idea - this scenario is described
on the SA wiki as a working solution:
http://wiki.apache.org/spamassassin/CachingNameserver#Non-forwarding

This seems to not be working, so I'm heading for this ML to find out
why.


are you doing this:

zone "multi.uribl.com" { type forward; forward first; forwarders {}; };

if yes try adding:

zone "uribl.com" { type forward; forward first; forwarders {}; };


looks like this is it! I changed this as suggested and send myself some
spams. The DNSBL Checks are working now, Thank you :)


you need to maintain this everytime domains / subdomains are changing 
and probably new lists are added - you need to take care about all of 
this when rule-updates arrive


* what about barracuda RBL
* what about mailspike

both used in SA and not mentioned there

a local unbound cache with 64-128 MB RAM and a minimal TTL of 10 minutes 
would save you a lot of headache and result in even better caching




signature.asc
Description: OpenPGP digital signature

Re: URIBL_BLOCKED while using local BIND

[Benny Pedersen]

Reindl Harald skrev den 2015-09-16 15:35:


"cache-min-ttl" is AFAIK a unbound-only feature because it violates
RFC's but in case of a mailserver it's your decision and if you don#t
set it for days normally not a problem


so configure unbound to listing only on 127.0.0.2 and in named.conf use 
forward only to that ip, make sure bind does not bind to 127.0.0.2


then one can have ttl ignored for spamassassin dns but rfc ok for others

or just set dns_servers in local.cf for 127.0.0.2

even it for did all that right both bind and unbound will work together

wehn dns servers enforce small ttl and not tell there orher servers with 
a soa notify thay make there own problems

Re: URIBL_BLOCKED while using local BIND

[Bowie Bailey]

The SA config is probably a better solution than the bind exemptions.  
As was pointed out elsewhere in this thread, URIBL is not the only 
DNS-based blacklist that enforces usage limits and it may not be as easy 
to tell that you are being blocked with some of the others.


If you add in the 'dns_server' entry to the config, then SA will use the 
local nameserver for everything and you don't have to worry about 
keeping track of which blacklist queries you need to exempt from forwarding.


Set your resolv.conf back to your ISP, remove forwarding from your local 
name server, and add 'dns_server 127.0.0.1' to your local.cf.


Bowie

On 9/16/2015 5:44 AM, Marc Richter wrote:

Hi Adam,

that's a great workarround and perfectly fits my needs! Thank you for 
that! :)


I'll use this if I cannot find out why my exemptions do not work in a 
reasonable amount of time.


Best regards,
Marc

Am 15.09.2015 um 20:14 schrieb Adam Major:

Hi.

If you don't want change DNS resolver for all DNS queries from your
server you can add in SA config line:

dns_server x.y.z.k:53

where z.y.z.k is IP DNS server using to resolve only by SA.


Then in resolv.conf you can use different (ex. ISP) DNS server.


More info:

http://spamassassin.apache.org/full/3.4.x/doc/Mail_SpamAssassin_Conf.html#port 





Best Regards.

Re: URIBL_BLOCKED while using local BIND

[Reindl Harald]

Am 16.09.2015 um 15:22 schrieb Marc Richter:

All this is true.

As you already pointed out in a previous post, resolving is quite slow
on that host. I have no influence on the networking arround that box. So
I did not want other things starting to go slow by this.


well, and there unbound with "cache-min-ttl: 3600" on 127.0.0.1 will 
save you a ton of DNS requests outside your network for repeatly 
hammering clients / urls, the ones which ar enot very active are most 
likely in no cache anyways


"cache-min-ttl" is AFAIK a unbound-only feature because it violates 
RFC's but in case of a mailserver it's your decision and if you don#t 
set it for days normally not a problem


you just need to outweight caching/timing and how much junk slips 
because you cache a NXDOMAIN for a DNSBL/URIBL while 10 minutes later it 
may be listed


you need also to look very careful if it always is that slow or just for 
some domains - the slowdown can also be caused by the DNS server 
responsible for a domain/PTR-zone and you would only benefit from the 
ISP cache if another user already asked the same question there, if not 
you have to wait the same time because the ISP cache can't make the SOA 
server faster



Am 16.09.2015 um 13:43 schrieb Reindl Harald:


Am 16.09.2015 um 13:38 schrieb Marc Richter:

Am 16.09.2015 um 11:41 schrieb Axb:

Although, the intended setup with exemptions by defining empty
forwarders for DNSBL zones was not my idea - this scenario is
described
on the SA wiki as a working solution:
http://wiki.apache.org/spamassassin/CachingNameserver#Non-forwarding

This seems to not be working, so I'm heading for this ML to find out
why.


are you doing this:

zone "multi.uribl.com" { type forward; forward first; forwarders {}; };

if yes try adding:

zone "uribl.com" { type forward; forward first; forwarders {}; };


looks like this is it! I changed this as suggested and send myself some
spams. The DNSBL Checks are working now, Thank you :)


you need to maintain this everytime domains / subdomains are changing
and probably new lists are added - you need to take care about all of
this when rule-updates arrive

* what about barracuda RBL
* what about mailspike

both used in SA and not mentioned there

a local unbound cache with 64-128 MB RAM and a minimal TTL of 10 minutes
would save you a lot of headache and result in even better caching



--

Reindl Harald
the lounge interactive design GmbH
A-1060 Vienna, Hofmühlgasse 17
CTO / CISO / Software-Development
m: +43 (676) 40 221 40, p: +43 (1) 595 3999 33
icq: 154546673, http://www.thelounge.net/

http://www.thelounge.net/signature.asc.what.htm



signature.asc
Description: OpenPGP digital signature

Re: URIBL_BLOCKED while using local BIND

[Marc Richter]

All this is true.

As you already pointed out in a previous post, resolving is quite slow 
on that host. I have no influence on the networking arround that box. So 
I did not want other things starting to go slow by this.


But you convinced me - I now also thing that the other way bears too 
much stumbling blocks.


Marc

Am 16.09.2015 um 13:43 schrieb Reindl Harald:



Am 16.09.2015 um 13:38 schrieb Marc Richter:

Am 16.09.2015 um 11:41 schrieb Axb:

Although, the intended setup with exemptions by defining empty
forwarders for DNSBL zones was not my idea - this scenario is described
on the SA wiki as a working solution:
http://wiki.apache.org/spamassassin/CachingNameserver#Non-forwarding

This seems to not be working, so I'm heading for this ML to find out
why.


are you doing this:

zone "multi.uribl.com" { type forward; forward first; forwarders {}; };

if yes try adding:

zone "uribl.com" { type forward; forward first; forwarders {}; };


looks like this is it! I changed this as suggested and send myself some
spams. The DNSBL Checks are working now, Thank you :)


you need to maintain this everytime domains / subdomains are changing
and probably new lists are added - you need to take care about all of
this when rule-updates arrive

* what about barracuda RBL
* what about mailspike

both used in SA and not mentioned there

a local unbound cache with 64-128 MB RAM and a minimal TTL of 10 minutes
would save you a lot of headache and result in even better caching

Re: URIBL_BLOCKED while using local BIND

[Adam Major]

Hi.

If you don't want change DNS resolver for all DNS queries from your
server you can add in SA config line:

dns_server x.y.z.k:53

where z.y.z.k is IP DNS server using to resolve only by SA.


Then in resolv.conf you can use different (ex. ISP) DNS server.


More info:

http://spamassassin.apache.org/full/3.4.x/doc/Mail_SpamAssassin_Conf.html#port



Best Regards.

Re: URIBL_BLOCKED while using local BIND

[Bowie Bailey]

On 9/15/2015 6:51 AM, Marc Richter wrote:

Hi everyone,

I recently read the following in all my filtered Mail:

0.0 URIBL_BLOCKED   ADMINISTRATOR NOTICE: The query to URIBL was blocked.
See  http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
for more information.

So I read what's written there and setup a local DNS server, as 
described at http://wiki.apache.org/spamassassin/CachingNameserver .
I did choose to forward the requests to my ISP's DNS servers, since it 
is a lot faster, but created the exemptions as listed at the very 
bottom of that site, to make sure my bind don't forward requests on 
these services to my ISP's DNS, but resolve them using DNS Root servers.


But even the IP of my server was sending just 2 requests for incomming 
spam since I have integrated BIND, these messages contain this 
ADMINISTRATOR NOTICE also. How can I hit the free usage limit by just 
2 requests?


I would suggest temporarily removing the forward completely as a test 
and see if this fixes the problem.  If so, then your exemptions are not 
working correctly.  If not, then double-check that you are actually 
using the local server and not still querying the ISP's server.


--
Bowie

Re: URIBL_BLOCKED while using local BIND

[Axb]

On 09/15/2015 12:51 PM, Marc Richter wrote:

Hi everyone,

I recently read the following in all my filtered Mail:

0.0 URIBL_BLOCKED   ADMINISTRATOR NOTICE: The query to URIBL was blocked.
See  http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
for more information.

So I read what's written there and setup a local DNS server, as
described at http://wiki.apache.org/spamassassin/CachingNameserver .
I did choose to forward the requests to my ISP's DNS servers, since it
is a lot faster, but created the exemptions as listed at the very bottom
of that site, to make sure my bind don't forward requests on these
services to my ISP's DNS, but resolve them using DNS Root servers.

But even the IP of my server was sending just 2 requests for incomming
spam since I have integrated BIND, these messages contain this
ADMINISTRATOR NOTICE also. How can I hit the free usage limit by just 2
requests?


remove the forwarding to your iSP .
unless a wider range is being blocked, your problem should be solved


btw: adding a hop to every query isn't faster.

Re: URIBL_BLOCKED while using local BIND

[Marc Richter]

Yes

Am 15.09.2015 um 13:30 schrieb Axb:

On 09/15/2015 01:23 PM, Marc Richter wrote:

Also, you shouldn't make assumptions without measuring something:

1. without forwarding:

;; Query time: 543 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)

2. with forwarding to my ISP's servers:

;; Query time: 2 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)

That's 271 times faster than root-servers's lookup.


did you EMPTY cache after each query?

Re: URIBL_BLOCKED while using local BIND

[Benny Pedersen]

Marc Richter skrev den 2015-09-15 13:23:


That's 271 times faster than root-servers's lookup.


hmm

maybe your server is heavy loaded of spam ?, and your isp is not ?

lets check this so:

dig +trace uribl.com

show me how it is for you

note +trace do not care of forwards at all

what version of bind and bind-tools are you using ?

did you ask of help on bind maillist ?

is threads enabled or disabled in compile time for your bind ?, eg does 
it use all cores when running ?, if not its forking with slows things 
down a little, this does not help if you are still on a single core cpu

Re: URIBL_BLOCKED while using local BIND

[Benny Pedersen]

Marc Richter skrev den 2015-09-15 12:51:


But even the IP of my server was sending just 2 requests for incomming
spam since I have integrated BIND, these messages contain this
ADMINISTRATOR NOTICE also. How can I hit the free usage limit by just
2 requests?


https://www.google.dk/search?q=dnswalk

dig +trace uribl.com

do NOT add forwards in named.conf in the options section

its ok pr zone if needed, but not global

and make sure resolv.conf ONLY have nameserver 127.0.0.1

Re: URIBL_BLOCKED while using local BIND

[Marc Richter]

Hey Reindl,

if you are trying to insult people at all costs, you should read and 
understand their posts in full before doing so at least, to not look 
like a jackass additional to an impolite person.


What I wrote is:

>> ... but created the exemptions as listed at the very bottom of that
>> site, to make sure my bind don't forward requests on these services
>> to my ISP's DNS ...

> and *no* the ISP nameserver is *not* a lot faster in most cases

Also, you shouldn't make assumptions without measuring something:

1. without forwarding:

;; Query time: 543 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)

2. with forwarding to my ISP's servers:

;; Query time: 2 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)

That's 271 times faster than root-servers's lookup.

Marc

Am 15.09.2015 um 12:55 schrieb Reindl Harald:


Am 15.09.2015 um 12:51 schrieb Marc Richter:

I recently read the following in all my filtered Mail:

0.0 URIBL_BLOCKED   ADMINISTRATOR NOTICE: The query to URIBL was blocked.
See  http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
for more information.

So I read what's written there and setup a local DNS server, as
described at http://wiki.apache.org/spamassassin/CachingNameserver .
I did choose to forward the requests to my ISP's DNS servers, since it
is a lot faster


WTF - and all your requests are coming from the ISP resolver and not
from your IP which is the reason that you should setup your own *caching
and recursing* nameserver

and *no* the ISP nameserver is *not* a lot faster in most cases

PEBCAK - problem exists between chair and keyboard

Re: URIBL_BLOCKED while using local BIND

[Reindl Harald]

Am 15.09.2015 um 12:51 schrieb Marc Richter:

I recently read the following in all my filtered Mail:

0.0 URIBL_BLOCKED   ADMINISTRATOR NOTICE: The query to URIBL was blocked.
See  http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
for more information.

So I read what's written there and setup a local DNS server, as
described at http://wiki.apache.org/spamassassin/CachingNameserver .
I did choose to forward the requests to my ISP's DNS servers, since it
is a lot faster


WTF - and all your requests are coming from the ISP resolver and not 
from your IP which is the reason that you should setup your own *caching 
and recursing* nameserver


and *no* the ISP nameserver is *not* a lot faster in most cases

PEBCAK - problem exists between chair and keyboard



signature.asc
Description: OpenPGP digital signature

Re: URIBL_BLOCKED while using local BIND

[Axb]

On 09/15/2015 01:23 PM, Marc Richter wrote:

Also, you shouldn't make assumptions without measuring something:

1. without forwarding:

;; Query time: 543 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)

2. with forwarding to my ISP's servers:

;; Query time: 2 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)

That's 271 times faster than root-servers's lookup.


did you EMPTY cache after each query?

Re: URIBL_BLOCKED while using local BIND

[Reindl Harald]

Am 15.09.2015 um 13:23 schrieb Marc Richter:

if you are trying to insult people at all costs


really?

you would recognize it when i intend to do so

*any* expierienced mailadmin out there has a local recursion nameserver 
on his MTA or at least somewhere in his LAN to use a central local cache 
but only you can't do it?



you should read and
understand their posts in full before doing so at least, to not look
like a jackass additional to an impolite person.


obviously it don't work


What I wrote is:

 >> ... but created the exemptions as listed at the very bottom of that
 >> site, to make sure my bind don't forward requests on these services
 >> to my ISP's DNS ...


but it does forward otherwise the problem would be solved


 > and *no* the ISP nameserver is *not* a lot faster in most cases

Also, you shouldn't make assumptions without measuring something:

1. without forwarding:

;; Query time: 543 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)

2. with forwarding to my ISP's servers:

;; Query time: 2 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)

That's 271 times faster than root-servers's lookup.


*lol* yes, the second hit already in your local cache when you don't 
clear it before, you never ever have 2 ms with a forwarding reslover on 
the internet asked - never ever!


for *that* one specific request if you have the luck it's in his cache 
it *can* be faster, otherwise the ISP would need to do the whole 
recursion itself and then answer to your cache with one additional hop


what you also ignore is the fact that you get the lowered TTL depending 
on how old the cache entry on the forwarder is while you own cache entry 
with recursion would be valid the whole TTL of the SOA


in other words: you don't look at the whole picture

anyways 543 msec is high

;; Query time: 121 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Di Sep 15 13:27:59 CEST 2015
;; MSG SIZE  rcvd: 57



Am 15.09.2015 um 12:55 schrieb Reindl Harald:


Am 15.09.2015 um 12:51 schrieb Marc Richter:

I recently read the following in all my filtered Mail:

0.0 URIBL_BLOCKED   ADMINISTRATOR NOTICE: The query to URIBL was
blocked.
See  http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
for more information.

So I read what's written there and setup a local DNS server, as
described at http://wiki.apache.org/spamassassin/CachingNameserver .
I did choose to forward the requests to my ISP's DNS servers, since it
is a lot faster


WTF - and all your requests are coming from the ISP resolver and not
from your IP which is the reason that you should setup your own *caching
and recursing* nameserver

and *no* the ISP nameserver is *not* a lot faster in most cases

PEBCAK - problem exists between chair and keyboard




signature.asc
Description: OpenPGP digital signature

Re: URIBL_BLOCKED while using local BIND

[Dave Funk]

However you did not empty your ISP's dns server cache.
That 2 msec response time is from his cache, the 543 msec for 
your server is when it's not in your server's cache.

So you're not making a fair comparison.

A response from a cache is always going to be faster, that's why people 
use caching servers.
However with everybody & his cat using your ISP's server it gets query 
blocked and thus is caching the bad (blocked) response.


So either you get bad data fast or good data slowly.

Once you get a second spam with similar contents, queries for that copy 
will be in your cache and be fast.


Given that a modern SA parallelizes DNS queries a somewhat slow DNS 
response (hundreds of Msecs) won't have too much overall affect on the 
spam processing time.


On Tue, 15 Sep 2015, Marc Richter wrote:


Yes

Am 15.09.2015 um 13:30 schrieb Axb:

On 09/15/2015 01:23 PM, Marc Richter wrote:

Also, you shouldn't make assumptions without measuring something:

1. without forwarding:

;; Query time: 543 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)

2. with forwarding to my ISP's servers:

;; Query time: 2 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)

That's 271 times faster than root-servers's lookup.


did you EMPTY cache after each query?








--
Dave Funk  University of Iowa
College of Engineering
319/335-5751   FAX: 319/384-0549   1256 Seamans Center
Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527
#include 
Better is not better, 'standard' is better. B{

Re: URIBL_BLOCKED

[Kevin A. McGrail]

On 10/24/2012 6:37 AM, Jared Hall wrote:

Anybody else getting this this morning?
Need more information but off the cuff it sounds like you are blocked 
because you aren't using a locally cached copy of an RBL or you've 
exceed an RBL's free limits.