On 07/07/2017 12:04 PM, Alex wrote:
Hi,
On Fri, Jul 7, 2017 at 12:14 PM, David Jones <djo...@ena.com> wrote:
On 07/07/2017 11:04 AM, Charles Amstutz wrote:
Thank you everyone for the suggestions, I will look into it. One thing
I've noticed is that sometimes it takes a day for any *BL's to pick up some
of the spam, and by that time, the run could be done. Greylisting isn't an
option. It sometimes feels like always reactive vs pro-active in filtering.
For example, I try to block the old runs of "Ford Warranties", write a few
rules, then never receive them again :)
This is a slight over exaggeration, but close.
No. I completely understand. A couple of years ago I was doing the same
thing always reacting to new spam campaigns. It took a lot of my time and I
never felt like I was winning those one-day battles.
Now I have tuned my MTA (Postfix with postscreen) to reject the majority of
junk before it ever reaches SA. See the archives for these Postscreen
weighted RBLs if you are running Postfix. With about 24 RBLs including
invaluement, I am able to be aggressive with many RBLs adding up to a block
threshold of 8 in postscreen.
I also have postfix, invaluement, of course Kevin's KAM rules, and
many (all?) of the other RBLs you use, including senderscore at the
postfix and spamassassin level.
I'm interested in how your system would have (or currently does)
handle this email I received some days ago:
https://pastebin.com/innRFvZt
Its IP (106.186.119.240) is still not listed with spamhaus, sorbs or
hostkarma, and has an 83 rating with senderscore.
It's just a short body with a URI which downloads malware. We got hit
by this pretty hard. This is where the real threats are. Receive one
of these to an Exchange distribution list and your reputation with the
customer suffers badly.
I'm also interested in other solutions - are those of you with
MIMEDefang or other systems blocking these?
I ran that message through one of my filters manually:
Content analysis details: (7.1 points, 5.0 required)
pts rule name description
---- ----------------------
--------------------------------------------------
-0.2 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no
trust
[106.186.119.240 listed in list.dnswl.org]
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 ENA_RELAY_JP Relayed through Japan
2.2 ENA_RELAY_NOT_US Relayed through country outside of the US
0.0 OS_UNKNOWN Relay runs on unknown OS
0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60%
[score: 0.5007]
1.7 MIME_BASE64_TEXT RAW: Message text disguised using base64
encoding
1.0 FROM_EXCESS_BASE64 From: base64 encoded unnecessarily
-0.2 RCVD_IN_SENDERSCORE_80_89 Senderscore.org score of 80 to 89
1.8 RCVD_DOUBLE_IP_SPAM Bulk email fingerprint (double IP) found
I guess I didn't mention that setting up the RelayCountry plugin and
then various rules based on country codes that are not normal for your
location:
header ENA_RELAY_NOT_US X-Relay-Countries =~
/\b[ABCDEFGHIJKLMNOPQRTVWYZ]{2}\b/
describe ENA_RELAY_NOT_US Relayed through country outside
of the US
score ENA_RELAY_NOT_US 2.2
header ENA_RELAY_CN X-Relay-Countries =~ /CN/
describe ENA_RELAY_CN Relayed through China
score ENA_RELAY_CN 2.2
header ENA_RELAY_KR X-Relay-Countries =~ /KR/
describe ENA_RELAY_KR Relayed through Korea
score ENA_RELAY_KR 6.2
header ENA_RELAY_CO X-Relay-Countries =~ /CO/
describe ENA_RELAY_CO Relayed through Columbia
score ENA_RELAY_CO 4.2
header ENA_RELAY_RU X-Relay-Countries =~ /RU/
describe ENA_RELAY_RU Relayed through Russia
score ENA_RELAY_RU 6.2
I guess I need to setup a wiki page or something similar with all of my
tweaks and tuning to document it all in one place.
--
Dave
