On 23 Jun 2015, at 8:34, Roman Gelfand wrote:
Periodically, I am running the following command on my spam box...
sa-learn --no-sync --spam
/mbx/adomain.com/auser/Maildir/.Junk/{cur,new}
It seems to work. However, I continue to get this message type. Why?
Here is SA message.
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on
mail.adomain.com
X-Spam-Level: ***
X-Spam-Status: No, score=3.6 required=5.0
tests=BAYES_99,BAYES_999,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,HTML_MESSAGE,SPF_PASS,URIBL_BLOCKED
autolearn=no
version=3.3.2
Your configuration appears to use the default scores for the rules that
are being hit there and for the "required" threshold. A 100% certain
Bayes judgment (technically anything >99.9%) only adds up to a score of
3.7 with the default scores, and the default threshold is 5.0, so you
need *something more* than a Bayes certainty to get SA to call anything
spam, using the default configuration. Without seeing the actual mail,
what "more" might be is a generic theoretical discussion.
However, in this case there's an obvious first thing to fix: stop using
a shared DNS resolver.
The URIBL_BLOCKED "rule" is a message from the operators of the
uribl.com service that the DNS resolver used for a query is explicitly
refused service. The most common reason for this is excess query volume
from a resolver. The only likely reasons for you to hit this are:
1. You are scanning so much mail with SA that you must be a large
commercial operation capable of helping to support the uribl.com service
as "free for most," so they require you to do so. This seems unlikely
for someone newly setting up SA...
2. You are using a DNS resolver that is shared by a large number of
other people and in aggregate you are all pounding the uribl.com
nameservers as if you are a commercial service provider or large
business.
The solution for (2) is a step that should be part of running *ANY* MTA
that accepts mail from the world at large: bring up a caching recursive
(NOT forwarding) resolver DNS daemon on the same host (or in multi-host
environments: same physical LAN) as the MTA and use it as the resolver
for the MTA. In addition to being able to use services like uribl.com
and Spamhaus that block large resolvers who don't support them, having
your own resolver makes DNS resolution substantially faster on average
for your MTA. With a modern MTA doing basic spam control, DNS resolution
time is a substantial contributor to session lifetime, which is a major
determinant of overall capacity. Another positive advantage is that many
shared resolvers (especially those run by ISPs) do non-standard things
in response to some queries designed to either assist and protect
web-surfing users or line their own pockets, depending on the particular
resolver and one's PoV. None of those tricks are helpful for an MTA, and
some can be positively harmful, so you shouldn't do resolution for an
MTA through such a server. A caching-only recursive nameserver isn't a
substantial load and isn't difficult to configure, and many OS
distributions include such a configuration in the base OS (e.g. FreeBSD)
or as the default config in packages of ISC BIND and/or other DNS
daemons.
