-----Original Message----- From: Rob McEwen [mailto:webmaster@powerviewsystems.com] Sent: Wednesday, August 11, 2004 9:02 AM To: 'SURBL Discussion list' Subject: [SURBL-Discuss] RE: Pesky Pron Spam Importance: High
I keep getting this "pesky" pron spam which gets past my all my filters (my regex-based linguestic filter, my spamhaus.org RBL filter, and my SURBL filter).
I think that these are getting blocked the next day, but this particular spammer is very aggressive and keeps sending new stuff so I keep getting the new stuff before it gets a chance to get blocked.
I have noticed some patterns in the e-mails. For example, they all have three images stacked vertically. Therefore, I think that I should be able to catch these with the right formulation of rules within my linguistic filter.
You can find the raw contents of my most recent two of these as follows:
Does anyone have any suggestions? Note that I am not using SpamAssassin. I am using another program. However, if SpamAssassin already handles this, could someone point me to the rules that SpamAssassin uses so that I can use these as a guide? Any other suggestions?
Thanks!
Rob McEwen
Look at these things they have in common. Need to look at rawbody code.
alt=3d =2e(org|gif|htm) #split into 3 name=3dgenerator ==.HTM bgColor=3d face=3d src=3d border=3d title=3d face=3d <STYLE></STYLE>
Needs to be one big meta rule
HTH --Chris
Thanks Chris,
I was hoping to find all this work already done in a SpamAssassin rule. (O.K., I'm lazy!). But what you've provided is the next best thing.
Thanks again!
Rob McEwen
on Wed, Aug 11, 2004 at 09:49:39AM -0400, Chris Santerre wrote:
Look at these things they have in common. Need to look at rawbody code.
alt=3d =2e(org|gif|htm) #split into 3 name=3dgenerator ==.HTM bgColor=3d face=3d src=3d border=3d title=3d face=3d
<STYLE></STYLE>
Needs to be one big meta rule
...that will also catch pretty much every last MSHTML email ever sent. That's just base64-encoded HTML, Chris. The empty STYLE element may be unique, but I doubt it.
I first successfully quarantined these by searching on
<BIG><STRONG> and <STRONG><BIG>
in the body. That should be sufficient without FPs. But these others are common enough that I wouldn't want to risk it, even in a big compound rule.
On Wed, 11 Aug 2004, Steven Champeon wrote:
on Wed, Aug 11, 2004 at 09:49:39AM -0400, Chris Santerre wrote:
Look at these things they have in common. Need to look at rawbody code.
alt=3d =2e(org|gif|htm) #split into 3 name=3dgenerator ==.HTM bgColor=3d face=3d src=3d border=3d title=3d face=3d
<STYLE></STYLE>
Needs to be one big meta rule
...that will also catch pretty much every last MSHTML email ever sent. That's just base64-encoded HTML, Chris. The empty STYLE element may be unique, but I doubt it.
Beg to differ with you Steve, that is NOT base64-encoded HTML, that is BASTARD-64-encoded HTML. If you read the MIME RFCs, they state very clearly (with 'MUST' wording) that the Hex Digits MUST BE IN CAPS. EG: "bgColor=3D" is valid, "bgColor=3d" is NOT.
I've written several SA rules that look for that kind of violation of the standards, and they take out that particular spam varient quite consistently, even before SURBL hits the URIs.
on Wed, Aug 11, 2004 at 01:10:48PM -0500, David B Funk wrote:
On Wed, 11 Aug 2004, Steven Champeon wrote:
on Wed, Aug 11, 2004 at 09:49:39AM -0400, Chris Santerre wrote:
Look at these things they have in common. Need to look at rawbody code.
alt=3d =2e(org|gif|htm) #split into 3 name=3dgenerator ==.HTM bgColor=3d face=3d src=3d border=3d title=3d face=3d
<STYLE></STYLE>
Needs to be one big meta rule
...that will also catch pretty much every last MSHTML email ever sent. That's just base64-encoded HTML, Chris. The empty STYLE element may be unique, but I doubt it.
Beg to differ with you Steve, that is NOT base64-encoded HTML, that is BASTARD-64-encoded HTML. If you read the MIME RFCs, they state very clearly (with 'MUST' wording) that the Hex Digits MUST BE IN CAPS. EG: "bgColor=3D" is valid, "bgColor=3d" is NOT.
Aha - very cool. I must admit I don't give many HTML email clients high marks in following any kind of standards, so I didn't distinguish. But that's good to know.
Looks like =2e in any URL would be a pretty good indicator, too.