Mailing List Archive

First result on Google:
http://cweiske.de/tagebuch/uribl_blocked.htm

Short version: URIBL will block you if you use any of the big DNS
providers, such as 8.8.8.8.


On 4/30/20 11:59 AM, Tom Williams wrote:
> Hi!  I'm new to this mailing list, but not new to SpamAssassin. I've
> used it on and off for a number years.  :)   Recently, (within the past
> 6 months or so) I enabled it for email in a shared web hosting
> environment (we host with InMotionHosting). Anyway, due to the volume of
> email traffic the server receives, I see a *lot* of 'URIBL_BLOCKED'
> entries in the SpamAssassin header injected in the headers of incoming
> mail.   If our server can't use URIBL to check mail, will that have an
> adverse or negative impact on SpamAssassin's ability to detect/identify
> spam?  Our host is running SpamAssassin 3.0 (shudders, I know it's
> ancient).
>
> Thanks in advance!
>
> Tom
>

I have too had a problem of this in my masscheck box. It is a cloud VM
in Google Cloud and they do like to provide a /etc/resolv.conf for their
own DNS which has been next to impossible to overcome. I do replace it
in the beginning of my masscheck process with my own but to no avail.

I now figured out I can add this to auto-mass-check.cf and going to see
how it works.

spam@gauntlet ~ $ grep dns gcloud/auto-mass-check.sh
    echo "dns_server 127.0.0.1" >> spamassassin/user_prefs

br. jarif

On 30.4.2020 22.28, Richard Doyle wrote:
> First result on Google:
> http://cweiske.de/tagebuch/uribl_blocked.htm
>
> Short version: URIBL will block you if you use any of the big DNS
> providers, such as 8.8.8.8.
>
>
> On 4/30/20 11:59 AM, Tom Williams wrote:
>> Hi!  I'm new to this mailing list, but not new to SpamAssassin. I've
>> used it on and off for a number years.  :)   Recently, (within the past
>> 6 months or so) I enabled it for email in a shared web hosting
>> environment (we host with InMotionHosting). Anyway, due to the volume of
>> email traffic the server receives, I see a *lot* of 'URIBL_BLOCKED'
>> entries in the SpamAssassin header injected in the headers of incoming
>> mail.   If our server can't use URIBL to check mail, will that have an
>> adverse or negative impact on SpamAssassin's ability to detect/identify
>> spam?  Our host is running SpamAssassin 3.0 (shudders, I know it's
>> ancient).
>>
>> Thanks in advance!
>>
>> Tom
>>

Still!

Syncing weekly_mass_check
check: dns_block_rule URIBL_BLOCKED hit, creating/home/jarif/.spamassassin/dnsblock_multi.uribl.com (This means dnsbl blocked you due to too many queries. Set all affected rules score to 0, or use "dns_query_restriction deny multi.uribl.com" to disable queries)
12:34:19 up 1:34, 0 users, load average: 32.21, 32.29, 32.17
rsync -Pcqz ham-net-jarif.log spam-net-jarif.log*munged*/
12:34:43 up 1:34, 0 users, load average: 21.57, 29.78, 31.34

Bummer.

br. jarif

On 2.5.2020 13.25, Jari Fredriksson wrote:
> I have too had a problem of this in my masscheck box. It is a cloud VM
> in Google Cloud and they do like to provide a /etc/resolv.conf for
> their own DNS which has been next to impossible to overcome. I do
> replace it in the beginning of my masscheck process with my own but to
> no avail.
>
> I now figured out I can add this to auto-mass-check.cf and going to
> see how it works.
>
> spam@gauntlet ~ $ grep dns gcloud/auto-mass-check.sh
>     echo "dns_server 127.0.0.1" >> spamassassin/user_prefs
>
> br. jarif
>
> On 30.4.2020 22.28, Richard Doyle wrote:
>> First result on Google:
>> http://cweiske.de/tagebuch/uribl_blocked.htm
>>
>> Short version: URIBL will block you if you use any of the big DNS
>> providers, such as 8.8.8.8.
>>
>>
>> On 4/30/20 11:59 AM, Tom Williams wrote:
>>> Hi!  I'm new to this mailing list, but not new to SpamAssassin. I've
>>> used it on and off for a number years.  :)   Recently, (within the past
>>> 6 months or so) I enabled it for email in a shared web hosting
>>> environment (we host with InMotionHosting). Anyway, due to the
>>> volume of
>>> email traffic the server receives, I see a *lot* of 'URIBL_BLOCKED'
>>> entries in the SpamAssassin header injected in the headers of incoming
>>> mail.   If our server can't use URIBL to check mail, will that have an
>>> adverse or negative impact on SpamAssassin's ability to detect/identify
>>> spam?  Our host is running SpamAssassin 3.0 (shudders, I know it's
>>> ancient).
>>>
>>> Thanks in advance!
>>>
>>> Tom
>>>
>

On 2.5.2020 13.30, Reindl Harald wrote:
> and why don't you just replace /etc/resolv.conf and fire up "chattr +i
> /etc/resolv.conf" like everyone else does for years to keep it untouched
> (that's even a ducomentaed way to prevent it overwritten by dhcp clients)
>
> there is no point using a shared dns from whatever provider and it's a
> shame that most people are still so bound to it that they often fuckup
> even tehir own named/unbound setup with forwarders

Thanks! I have used Linux since 1994 but was not aware of that. I'll try
it next.

br. jarif

On Sat, 2 May 2020 15:59:27 +0300
Jari Fredriksson wrote:

> On 2.5.2020 13.30, Reindl Harald wrote:
> > and why don't you just replace /etc/resolv.conf and fire up "chattr
> > +i /etc/resolv.conf" like everyone else does for years to keep it
> > untouched (that's even a ducomentaed way to prevent it overwritten
> > by dhcp clients)
> >
> > there is no point using a shared dns from whatever provider and
> > it's a shame that most people are still so bound to it that they
> > often fuckup even tehir own named/unbound setup with forwarders
>
> Thanks! I have used Linux since 1994 but was not aware of that. I'll
> try it next.

You shouldn't need to do that as you can configure the DNS cache in your
settings.

My understanding is that masschecks are supposed to reuse network
results from X-Spam-Status. Presumably the URIBL_BLOCKED warning is
about lookups that occurred during the original scan rather than during
the masscheck. Any network tests repeated during the masscheck would
tend to corrupt the results.

If you have dns_server set during scans and you are getting
URIBL_BLOCKED then you have either found a bug, your DNS is diverted,
or your IP address itself is blocked for some reason.

Man thanks to those who responded.  I was mainly wondering how the
inability to do blacklist checks would impact the overall ability of
SpamAssassin to detect spam.  Given the responses, I'll go in a
different direction.  I'll move the site to a VPS, where I can have more
control over SpamAssassin and DNS configuration.

Thanks!

Tom

On 5/2/20 3:25 AM, Jari Fredriksson wrote:
> I have too had a problem of this in my masscheck box. It is a cloud VM
> in Google Cloud and they do like to provide a /etc/resolv.conf for
> their own DNS which has been next to impossible to overcome. I do
> replace it in the beginning of my masscheck process with my own but to
> no avail.
>
> I now figured out I can add this to auto-mass-check.cf and going to
> see how it works.
>
> spam@gauntlet ~ $ grep dns gcloud/auto-mass-check.sh
>     echo "dns_server 127.0.0.1" >> spamassassin/user_prefs
>
> br. jarif
>
> On 30.4.2020 22.28, Richard Doyle wrote:
>> First result on Google:
>> http://cweiske.de/tagebuch/uribl_blocked.htm
>>
>> Short version: URIBL will block you if you use any of the big DNS
>> providers, such as 8.8.8.8.
>>
>>
>> On 4/30/20 11:59 AM, Tom Williams wrote:
>>> Hi!  I'm new to this mailing list, but not new to SpamAssassin. I've
>>> used it on and off for a number years.  :)   Recently, (within the past
>>> 6 months or so) I enabled it for email in a shared web hosting
>>> environment (we host with InMotionHosting). Anyway, due to the
>>> volume of
>>> email traffic the server receives, I see a *lot* of 'URIBL_BLOCKED'
>>> entries in the SpamAssassin header injected in the headers of incoming
>>> mail.   If our server can't use URIBL to check mail, will that have an
>>> adverse or negative impact on SpamAssassin's ability to detect/identify
>>> spam?  Our host is running SpamAssassin 3.0 (shudders, I know it's
>>> ancient).
>>>
>>> Thanks in advance!
>>>
>>> Tom
>>>

On 30 Apr 2020, at 14:59, Tom Williams wrote:

> Hi!  I'm new to this mailing list, but not new to SpamAssassin. I've
> used it on and off for a number years.  :)   Recently, (within the
> past 6 months or so) I enabled it for email in a shared web hosting
> environment (we host with InMotionHosting). Anyway, due to the volume
> of email traffic the server receives, I see a *lot* of 'URIBL_BLOCKED'
> entries in the SpamAssassin header injected in the headers of incoming
> mail.   If our server can't use URIBL to check mail, will that have
> an adverse or negative impact on SpamAssassin's ability to
> detect/identify spam? 

Yes. A quick look at one of the servers I manage shows that about 10% of
the spam identified by SA would not be over the threshold without the
contribution of URIBL rules.

> Our host is running SpamAssassin 3.0 (shudders, I know it's ancient).

Ancient, unsupported, incapable of using many current rules, and unsafe.

I know of no "in the wild" exploits of the known vulnerabilities that
have been fixed since 3.0, but that just means that any which exist have
been used carefully. I would not feel safe with anything older than
3.4.3. Given the fact that we've fixed a lot of issues that are based in
Perl versions since 5.10, I expect that there are issues in 3.0 that are
keeping you at some ancient version of Perl which itself has problems.

Update.

--
Bill Cole
bill@scconsult.com or billcole@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not For Hire (currently)

On 5/3/20 1:16 AM, Bill Cole wrote:
> On 30 Apr 2020, at 14:59, Tom Williams wrote:
>
>> Hi!  I'm new to this mailing list, but not new to SpamAssassin. I've
>> used it on and off for a number years.  :)   Recently, (within the
>> past 6 months or so) I enabled it for email in a shared web hosting
>> environment (we host with InMotionHosting). Anyway, due to the volume
>> of email traffic the server receives, I see a *lot* of
>> 'URIBL_BLOCKED' entries in the SpamAssassin header injected in the
>> headers of incoming mail.   If our server can't use URIBL to check
>> mail, will that have an adverse or negative impact on SpamAssassin's
>> ability to detect/identify spam? 
>
> Yes. A quick look at one of the servers I manage shows that about 10%
> of the spam identified by SA would not be over the threshold without
> the contribution of URIBL rules.
>
>
Thanks!  This is the kind of feedback I was most interested in.


Tom