On 02/06/2018 01:28 PM, Alex wrote:
Hi,
ifplugin Mail::SpamAssassin::Plugin::DNSEval
header __RCVD_IN_BRBL eval:check_rbl('brbl',
'bb.barracudacentral.org')
tflags __RCVD_IN_BRBL net
header __RCVD_IN_BRBL_2 eval:check_rbl_sub('brbl',
'127.0.0.2')
meta RCVD_IN_BRBL __RCVD_IN_BRBL_2 &&
!RCVD_IN_BRBL_LASTEXT
describe RCVD_IN_BRBL Received is listed in Barracuda RBL
bb.barracudacentral.org
score RCVD_IN_BRBL 1.2
tflags RCVD_IN_BRBL net
header RCVD_IN_BRBL_LASTEXT
eval:check_rbl('brbl-lastexternal',
'bb.barracudacentral.org')
describe RCVD_IN_BRBL_LASTEXT Last external is listed in
Barracuda
RBL bb.barracudacentral.org
score RCVD_IN_BRBL_LASTEXT 2.2
tflags RCVD_IN_BRBL_LASTEXT net
endif
You don't think these scores are a bit high for a normal installation?
The current default score for RCVD_IN_BRBL_LASTEXT is 1.4 and
RCVD_IN_BRBL doesn't otherwise exist.
Also, does someone have a recommended score for the lashback RBL? I've
had it in testing for quite some time and would like to put it into
production with reasonable values...
Ok, ok. Uncle. (Waving white flag.) I have been sufficiently flogged so
I
have learned my lesson. :) This works in my highly customized SA
platform
where I have to do outbound mail filtering so deep Received header
checking
is valuable to block spam from my customer's compromised accounts.
Leave out the RCVD_IN_BRBL rule above and change the RCVD_IN_BRBL_LASTEXT
score to 1.4 to keep things the same.
I didn't mean to imply I don't agree or otherwise support your
approach. It was just unclear that this was in conjunction with that
approach of using higher spam rule scores to offset lower ham rule
scores or if it was recommended for everyone.
If you think the RCVD_IN_BRBL rule is a good one, I'd like to use it,
and while I've implemented much of your approach, I can't implement
all of it. My users raise holy hell when they receive even one phish
from an otherwise trustworthy source that's been whitelisted. It hits
on a ton of email at both ends of the spectrum - most are either very
low scoring or are already spam.
First let me say that my method for many whitelist_auth entries does not
allow for any phishing emails so if I find any of those, they do not get a
whitelist_auth entry. With a properly tuned MTA in front of SA, the only
phishing or blatant spam should be coming from compromised accounts or
zero-hour spam which are going to be difficult to block anyway.
Yes, I should have mentioned that as well. We're not whitelisting any
end-user level accounts.
These phishes we've received were all from otherwise trusted sources
like salesforce, amazonses and sendgrid. These are examples that I
believe were previously whitelisted because of having received a phish
through these systems but have no been disabled.
whitelist_auth *@bounce.mail.salesforce.com
whitelist_auth *@sendgrid.net
whitelist_auth *@*.mcdlv.net
I have never received phishing emails from trusted senders like those.
If I did, then they would not be considered a trusted sender. We have
received unsolicited junk emails from customers of theirs after someone
sold our email addresses to some so-called "double opt-in" email lists
that we never opted into. I have been reporting this abuse and those
rogue customers are immediately locked/blocked/disabled/etc. which helps
all of us. I have never received a malicious/infected/spoofing email
from those, just harmless junk email.
My method should only be whitelist_auth'ing system-generated/bulk emails
from reputable senders that handle abuse reports quickly and shouldn't match
compromised accounts and "freemail" domains. It will also match commonly
spoofed domains like fedex.com, ups.com, and banks to help block those
phishing emails.
This also requires supporting rules that add significant points based
on their name most simply, or other more complicated rules to catch
more sophisticated phish attempts. Spammers hitting our systems are
far more sophisticated than just using "UPS" in the subject or
pretending to be from ups.com.
Sure. What I have found effective is to train your Bayes with all
spoofing emails so high BAYES rule hits will add points. The authentic
emails will score very low from the whitelist_auth entry. Add in some
custom regex rules in the subject and body for variations of
misspellings of the spoofed brand or new zero-hour findings and this is
the best protection I have been able to come up with for new
spoofing/spam campaigns.
Can I also ask again about reasonable RCVD_IN_LASHBACK and
RCVD_IN_LASHBACK_LASTEXT scores?
It really depends on how much customization you have done to SA and how much
your mail flow can handle bumping up scores. If you do some log analysis
and find that RCVD_IN_LASHBACK and RCVD_IN_LASHBACK_LASTEXT are pretty
accurate for your mail flow, then you can bump it up like I have to 2.2 and
4.2 respectively.
DISCLAIMER: I am not recommending this for everyone so no flaming. Set
these scores low and test for a few weeks or months to see how your mail
logs line up with real spam then increase the scores as you see fit. Again,
I do outbound mail filtering for my customers so the deep Received header
inspection is helpful to determine compromised accounts and keep my mail
servers off of RBLs.
Are there any numbers available from anyone's masschecks?
Thank you as always for your support.
The normal nightly masschecks for rule promotions are run against stock
SA and sandbox rules so they won't include local customized rules like
these.
Just grep your mail logs for hits on these rules and pull out the
scores. You can use perl or awk to get the average score. Another
option I have used is to find the emails that scored just below your
threshold by a point or two to see what would have been impacted/blocked
if you bumped up a particular score by a point or two.
--
David Jones
