On 2022-06-28 at 14:38:16 UTC-0400 (Tue, 28 Jun 2022 14:38:16 -0400)
Joey J <jacklistm...@gmail.com>
is rumored to have said:
Hello All,
In trying to setup RBL's with SA, I wanted to make sure the proper way
to
do it.
I have seen some samples like this
header RCVD_IN_BARRACUDACEN eval:check_rbl('bbarracuda-lastexternal',
'b.barracudacentral.org.')
describe RCVD_IN_BARRACUDACEN Relay is listed in
b.barracudacentral.org
tflags RCVD_IN_BARRACUDACEN net
score RCVD_IN_BARRACUDACEN 4.0
That looks right. Definitive documentation can be had with 'perldoc
Mail::SpamAssassin::Plugin::DNSEval' and 'perldoc
Mail::SpamAssassin::Conf'
Is this actually going out and doing a DNS query or reading from the
header
of the message?
It does both...
SA analyzes the Received headers in a message to find relevant SMTP
handoffs, with relevant settings in trusted_networks, internal_networks,
and msa_networks. For DNSBLs, typically the "last external" Recceived
heasder is the key: the latest one written by a trusted machine,
documenting a handoff from a machine which is not in any of those
special sets. It tests the IP address of that last external machine to
handle the message. DNSEval looks up that IP address in the DNSBL.
I think I want to actually do the DNS query and I will cache locally
to
avoid issues and increase performance.
The proper way to do this is to run a local caching recursive resolver
(e.g. Unbound or BIND, NOT dnsmasq) on the same machine as the MTA and
use that for all DNS lookups. Using more distant DNS servers can result
in latency delays and using forwarding of any sort will cause blocking
by DNSBL services. Any DNS server that filters or modifies responses to
'protect' user personal computers is unfit for use with email.
Also if someone has a list of these rules, that they use and could
share
that would be great.
There are many in the standard ruleset. I think we do a reasonably good
job of curating them, and they should all be safe to use as designed.
Note that some DNSBLs are explicitly NOT intended for use on a mail
server that accepts initial submission from end users.
The last part of my question is, here we score and then based on
scoring
the next part can either quarantine the message or deliver it, but is
there
a way from SA to simply say reject it right there?
(I think the answer is no, it simply scores it, but wanted to be sure)
SpamAssassin itself has no capacity to handle the disposition of email.
It only scores messages and reports those scores to whatever tool is
using it.
Hence, if you are accepting or quarantining mail based on a SA score,
there's Something Else making that disposition decision. It might be a
milter (MIMEDefang, MailMunge, spamass-milter, or amavisd-milter,) or a
Postfix content_filter script or a SMTP proxy (many amavisd systems) or
an Exim config stanza (not sure if that's an 'acl' or a 'router' in Exim
jargon.) It is that 'glue' between the MTA and SA which implements the
handling decision for scored messages.
Generally it is a good idea to reject messages that you are not going to
deliver. As a backstop for false positives rejection alerts the sender
to the problem, in contrast to the silent death of quarantining.
Quarantining (or worse, discarding) borderline messages may seem good in
that it doesn't give any feedback to spammers, but in practice there's
no evidence that they use the sort of feedback they get from rejections
in any way. The simplest way they might do so in theory, washing bad
addresses out of their lists, would actually be GOOD if they all did it.
--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
