[prev in list] [next in list] [prev in thread] [next in thread] 

List:       spamassassin-users
Subject:    Re: SBLXBL and compromised desktops
From:       "Bill Cole" <sausers-20150205 () billmail ! scconsult ! com>
Date:       2016-03-28 22:50:56
Message-ID: 1557E865-5469-4A5E-81D8-BD453F981F2E () billmail ! scconsult ! com
[Download RAW message or body]

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.
[prev in list] [next in list] [prev in thread] [next in thread]