You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ruleqa@spamassassin.apache.org by Jari Fredriksson <ja...@iki.fi> on 2018/08/26 06:53:19 UTC
net-darxus: URIBL_BLOCKED
Something in darxus infra is wrong.
This saturdays mass check shows lots of URIBL_BLOCKED for it.
br. jarif
Re: net-darxus: URIBL_BLOCKED
Posted by Dave Warren <dw...@thedave.ca>.
On Sun, Aug 26, 2018, at 14:23, Benny Pedersen wrote:
> Kevin A. McGrail skrev den 2018-08-26 21:56:
> > I see no reason to disable it. They meet the free for some parameters
> > and the URIBL blocked rule exists to let admins know they are being
> > blocked.
>
> who will hack spamassassin to use memcache for uribl and rbl ?
>
> it cant be right masscheckers need to pay for there work
It could simply be a misconfiguration by a masschecker -- Perhaps someone switched to 1.1.1.1 or similar without considering the consequences?
When I was running a reasonably large masscheck environment I set up a dedicated unbound as a DNS resolve+cache and set a high minimum TTL of several hours so that no one query would need to be repeated for the duration of a masscheck run. While this configuration would definitely not make sense on a production mail server, in the context of a masscheck we're working with messages that are days to months old and only re-checking once a week so there is no negative impact.
I didn't keep any of the statistics but I recall getting 50%-80% cache hit ratios (but this includes NS and other records that wouldn't count against DNSBL metrics), so this kept me well below any DNSBL's free tier limitations.
Even if masschecking does take you over the limit, I would suggest having the masschecker reach out to the DNSBL in question and request free access. If a DNSBL does not want to work with SpamAssassin's masscheckers then (personally) I would strongly consider dropping them from SpamAssassin completely only at that time.
Re: net-darxus: URIBL_BLOCKED
Posted by Benny Pedersen <me...@junc.eu>.
Kevin A. McGrail skrev den 2018-08-26 21:56:
> I see no reason to disable it. They meet the free for some parameters
> and the URIBL blocked rule exists to let admins know they are being
> blocked.
who will hack spamassassin to use memcache for uribl and rbl ?
it cant be right masscheckers need to pay for there work
> This is just a situation where a mass checker has someone got a
> problem.
underlaying problem is marketing, knowing more is dns miss use
Re: net-darxus: URIBL_BLOCKED
Posted by "Kevin A. McGrail" <km...@apache.org>.
I see no reason to disable it. They meet the free for some parameters and
the URIBL blocked rule exists to let admins know they are being blocked.
This is just a situation where a mass checker has someone got a problem.
--
Kevin A. McGrail
VP Fundraising, Apache Software Foundation
Chair Emeritus Apache SpamAssassin Project
https://www.linkedin.com/in/kmcgrail - 703.798.0171
On Sun, Aug 26, 2018 at 9:46 AM, Benny Pedersen <me...@junc.eu> wrote:
> Jari Fredriksson skrev den 2018-08-26 08:53:
>
>> Something in darxus infra is wrong.
>>
>> This saturdays mass check shows lots of URIBL_BLOCKED for it.
>>
>
> time to disable it ?
>
> #
> # dns_query_restriction (allow|deny) domain1 domain2 ...
> # Option allows disabling of rules which would result in a DNS
> query to
> # one of the listed domains. The first argument must be a literal
> # "allow" or "deny", remaining arguments are domains names.
> #
> # Most DNS queries (with some exceptions) are subject to
> # dns_query_restriction. A domain to be queried is successively
> # stripped-off of its leading labels (thus yielding a series of its
> # parent domains), and on each iteration a check is made against an
> # associative array generated by dns_query_restriction options.
> Search
> # stops at the first match (i.e. the tightest match), and the
> matching
> # entry with its "allow" or "deny" value then controls whether a
> DNS
> # query is allowed to be launched.
> #
> # If no match is found an implicit default is to allow a query. The
> # purpose of an explicit "allow" entry is to be able to override a
> # previously configured "deny" on the same domain or to override an
> # entry (possibly yet to be configured in subsequent config
> directives)
> # on one of its parent domains. Thus an 'allow zen.spamhaus.org'
> with a
> # 'deny spamhaus.org' would permit DNS queries on a specific DNS
> BL zone
> # but deny queries to other zones under the same parent domain.
> #
> # Domains are matched case-insensitively, no wildcards are
> recognized,
> # there should be no leading or trailing dot.
> #
> # Specifying a block on querying a domain name has a similar
> effect as
> # setting a score of corresponding DNSBL and URIBL rules to zero,
> and
> # can be a handy alternative to hunting for such rules when a site
> # policy does not allow certain DNS block lists to be queried.
> #
> # Example:
> # dns_query_restriction deny dnswl.org surbl.org
> # dns_query_restriction allow zen.spamhaus.org
> # dns_query_restriction deny spamhaus.org mailspike.net
> spamcop.net
>
> dns_query_restriction deny uribl.com
>
> very old thread with it
>
> http://spamassassin.1065346.n5.nabble.com/Obvious-Disabling-
> some-RBL-URIBL-checks-td57047.html
>
> just dont use old method on disable
>
> disable deep ip lookups
>
> take care of doubble queries
>
Re: net-darxus: URIBL_BLOCKED
Posted by Benny Pedersen <me...@junc.eu>.
Jari Fredriksson skrev den 2018-08-26 08:53:
> Something in darxus infra is wrong.
>
> This saturdays mass check shows lots of URIBL_BLOCKED for it.
time to disable it ?
#
# dns_query_restriction (allow|deny) domain1 domain2 ...
# Option allows disabling of rules which would result in a DNS
query to
# one of the listed domains. The first argument must be a
literal
# "allow" or "deny", remaining arguments are domains names.
#
# Most DNS queries (with some exceptions) are subject to
# dns_query_restriction. A domain to be queried is successively
# stripped-off of its leading labels (thus yielding a series of
its
# parent domains), and on each iteration a check is made against
an
# associative array generated by dns_query_restriction options.
Search
# stops at the first match (i.e. the tightest match), and the
matching
# entry with its "allow" or "deny" value then controls whether a
DNS
# query is allowed to be launched.
#
# If no match is found an implicit default is to allow a query.
The
# purpose of an explicit "allow" entry is to be able to override
a
# previously configured "deny" on the same domain or to override
an
# entry (possibly yet to be configured in subsequent config
directives)
# on one of its parent domains. Thus an 'allow zen.spamhaus.org'
with a
# 'deny spamhaus.org' would permit DNS queries on a specific DNS
BL zone
# but deny queries to other zones under the same parent domain.
#
# Domains are matched case-insensitively, no wildcards are
recognized,
# there should be no leading or trailing dot.
#
# Specifying a block on querying a domain name has a similar
effect as
# setting a score of corresponding DNSBL and URIBL rules to
zero, and
# can be a handy alternative to hunting for such rules when a
site
# policy does not allow certain DNS block lists to be queried.
#
# Example:
# dns_query_restriction deny dnswl.org surbl.org
# dns_query_restriction allow zen.spamhaus.org
# dns_query_restriction deny spamhaus.org mailspike.net
spamcop.net
dns_query_restriction deny uribl.com
very old thread with it
http://spamassassin.1065346.n5.nabble.com/Obvious-Disabling-some-RBL-URIBL-checks-td57047.html
just dont use old method on disable
disable deep ip lookups
take care of doubble queries