On 7/8/2014 10:41 PM, David F. Skoll wrote:
On Tue, 08 Jul 2014 21:03:35 -0400
"Kevin A. McGrail" <kmcgr...@pccc.com> wrote:
So this sounds like you are searching the entire email for this
string which just sounds inefficient especially if they use some big
attachments.
It's not too bad because the regex is simple.
I just think it could hit on non-attachments quite easily without any
mime handling . I saw another email that tried to anchor it to base64
or something similar.
if (uc($header) eq "MZ") {
You don't want the uc(); that could lead to false-positives, but yes,
the idea is correct.
Good point.
The reason I did it with a SpamAssassin rule is that we have ways to
push out SpamAssassin rules easily to our customers, but not so much
code changes. :)
Make sense.
The rule hits on surprisingly few messages (only two out of a couple of
million so far), but it's not terribly accurate: One false-positive caused
by a stupid base-64 encoder that leaves extra newlines between lines,
and one sort-of-false-positive that was a DLL renamed to .DAT to sneak
past filename extension blocks, but wasn't otherwise malicious.
Having had some people I've helped hit by CryptoLocker, I think the FPs
may be outweighed by the gains.
Regards,
KAM
