On 28 Mar 2016, at 13:29, Alex wrote:
Hi,
We're seeing an increasing number of quarantined mail resulting from
compromised desktops being listed in RCVD_IN_SBLXBL.
A rule with that name is not part of the currently maintained
SpamAssassin core ruleset and I'm fairly sure it has not been at any
time in the past 8 years, maybe even never. You may want to provide a
"describe" line for it and tell us what version of SA you're running.
There was a rule described on this list by that name in 2011 but that
definition looks like a very bad idea, prone to "punish the victim's
neighbor" FPs. There also are hints in Google that it may have been a
circa 2009 Debian "enhancement" (ugh) since some pages about Debian bugs
apparently mention it.
Bottom line: you can and should figure out where/why this rule lives on
your system and fix that either by removing the rule or making it not
cause you trouble. If your {internal,trusted,msa}_networks settings are
correct, you should be able to make sure you only look at suitable
Received headers for SBL-XBL clients by using the firsttrusted or
lastexternal limiter on the check.
This in turn
leads to an increase in the number of calls to the helpdesk with
"where's my mail".
This is typically the first Received header in the email, so not
something that is being rejected at the SMTP level.
Just to make sure I understand you: is this mail which people expect and
want to receive? i.e. NOT spam? And by "first Received header" you mean
earliest (deepest, i.e. first added) not the top (most recent, i.e. top
of the file) of multiple Received headers, correct?
Can you provide an example set of Received headers?
Is there some way to reject this mail at the SMTP level before it's
accepted, or something spamassassin/amavis can do after it's received
to notify the sender, without it becoming a backscatter issue to make
my job easier?
I'm confused. You want SpamAssassin to continue to treat this mail as
spam, but in a more severe way than you currently are treating it,
because it isn't actually spam and your users are having you pull too
much of it out of a quarantine that you have but which users can't
directly access???
That question IS NOT intended as sarcasm, although I can see where it
might seem to be. I'm honestly confused.
I'm already using postscreen with zen to block at the SMTP level.
And since Zen is a strict superset of SBL+XBL, so as long as you're
testing for the right values in Zen, you're not accepting directly from
listed machines, however in a complex setup you may need to look into
Received headers with SA to find the MX-guided hop in the chain and test
there.
I don't use Amavis myself so I could be wrong, but I believe it is most
common these days to use it as a "before-queue" smtpd proxy between
Postfix smtpd processes, so that if Amavis sends back a 5xx reply to the
end of the DATA command, Postfix passes that 5xx back to it's client
live. In short: make Amavis reject instead of quarantine, and you're
done. Blind common quarantines are a generally bad idea anyway, since
they either end up as black holes wasting disk space to store spam and
the occasional silent FP or you waste helpdesk staff time digging users'
borderline spam out of a shared dumpster. Reject or deliver (albeit
*maybe* to an individual's "likely spam" folder) should be the only
options for a message. I don't believe (but could be wrong) that Amavis
does not offer any way to determine the fate of a message based on which
particular SA rules were matched. Maybe an Amavis expert here can speak
to that...
A different alternative if you are committed to a quarantine sometimes,
rejection others, based on score total or matching a particular score or
what the 5th digit of the SHA512 of the message is or anything else you
feel like testing is to switch from Amavis to MIMEDefang, a milter with
support for SA and a range of common AV tools. MD has the advantage
relative to Amavis that its functional configuration consists of writing
(or cribbing from the examples) a set of Perl subroutines that can do
whatever you want them to do. On the same hand, MD has the
*DISADVANTAGE* relative to Amavis that its functional configuration
consists of writing (or cribbing from the examples) a set of Perl
subroutines that can do whatever you want them to do. It's very much a
matter of personal taste and talents.
