Hello All, not sure where I'm going wrong.
in my custom.cf I have
#RBL's
header RCVD_IN_ZENSPAMHAUS eval:check_rbl('zenspamhaus-lastexternal',
'zen.spamhaus.org.')
describe RCVD_IN_ZENSPAMHAUS Relay is listed in zen.spamhaus.org
tflags RCVD_IN_ZENSPAMHAUS net
score RCVD_IN_ZENSPAMHAUS 5.0
if I query DNS, I get the expected answer from local caching:
dig +short TXT 2.0.0.127.zen.spamhaus.org
"https://www.spamhaus.org/sbl/query/SBL2";
"https://www.spamhaus.org/query/ip/127.0.0.2";
When I send a test message using Access the Portal – Blocklist Tester |
Spamhaus <https://blt.spamhaus.com/>
It goes through, and upon inspection of the email headers, the rule name
nor points shows anywhere.
I must be missing something.
Any suggestions?
Thanks
On Tue, Jun 28, 2022 at 5:28 PM Bill Cole <
sausers-20150...@billmail.scconsult.com> wrote:
> 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
>
--
Thanks!
Joey
