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
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not For Hire (currently)
