[LINK] getting rid of image spam

[Craig Sanders]

On Thu, Nov 02, 2006 at 08:14:25AM +1100, Neale Banks wrote:
> Hi Craig,
> 
> [...]
> > for anyone using postfix, here's a PCRE header_checks rule which blocks them:
> > 
> > /^Content-Type:.*multipart\/related.*boundary="(?:------------|--+=?_NextPart)/ REJECT
> > 
> > i came up with the boundary=... qualifier by examining all the
> > multipart/related image spams in my amavisd spamtrap quarrantine.
> > there's no guarantee that it wont reject other non-image-spam messages,
> > but this pattern is common to all of the ones in my spamtrap.
> 
> Interesting observation... but either I'm mis-reading your PCRE or
> getting different spams than you, like this one:
> 	Content-Type: multipart/related; ??boundary="D1404ZGM1C0I4LWS1WJU"
> That appears to be from a NAB phishing attempt, given the sender's domain.

the rule was designed to block image spam, not phishing.

i have a pretty PCRE good header_checks rule to block most phishing
spams - very few of them get through these days. as you can probably
guess, it evolved over a few months, as each new variation arrived. it's
still evolving.

it mostly gets paypal and ebay phishes - bank phishes vary a lot more in
their subject header.

/^Subject:.*((?:bank|acc?ount|Westpac).*(?:compromised|limited|flagged|suspen|On.?hold|confirm|violate|verif|updat|frozen|screen|block|authen)|Security Center|Limited acc?ount|Card Blocked|new.*anti.*fraud.*system|identified.*unusual.*activit|Fraud Prevention|Notif.*(?:acc?ount|profile|update)|Acc?ount.*(?:Review|Security)|Routing Code|PayPal.*Security.*Measure|(?:update|restore|upgrade).*(?:Acc?ount|Information|records|address|identity|detail)|power.*seller.*(?:promotion|registration|membership)|PayPal.*Check.*acc?ount|(?:unlock|protect).*acc?ount|IMPORTANT: Password Change Required|INV NOTICE:.*Acc?ount.*Suspen|User.*Linked.*Suspen|Security.*be.*advi[cs]|Important\s*News\s*!|invite.*power.*seller|Get\s*Verified\s*!|PayPal Email ID|Activate Your PayPal Acc?ount!|PayPal.*Activity.*Verification|Please.*update.*record|(?:Confirm|Verify|Update|Upgrade|Activ).*(?:Acc?ount|log.?in|profile).*(?:Details|Records|Info)|New.*address.*added.*PayPal|Urgent.*Security.*Alert|Your.*PayPal.*(?:Acc?ount|Info)|Critical.*info.*acc?ount|Comprom.*Acc?ount|(?:Verify|Confirm|Update|Activ).*(?:PayPal|ebay|bank|your).*(?:Acc?ount|identity|info|records|address|profile)|Bank.*Acc?ount.*Information|(?:PayPal|ebay).*(?:Security|Notice)|Apply.*PayPal.*Card|Credit.*Card.*Cloned|(?:security|prevention).*(?:measure|feature)|Important.*Notice.*Acc?ount|Acc?ounts Info|(?:Warning|Important)Notif|(?:PayPal|ebay|bank).*Fraud.*Alert|acc?ount.*(?:!\s*)+|Receipt of paye?ment to|fraud.*alert|limited.*access.*acc?ount|confirm.*(?:credit|debit).*card|Secuirty.*(?:Update|Request)|Urgent.*Security.*Precaution|eBay.*Expiration.*Reminder|New Security Warning|Update Your Profile|Preserve.*Account.*Stability|Resolution Center Notice|URGENT.*Reward.*Survey|PayPal.*Suspicious.*Activity|LWPELECTRONICS|Power.?(?:Seller|Buyer))/   REJECT


> But... the nice thing about that one is it's wrong as it omits the
> required parameter "Type".  I.e. in regexp terms:
> 
> 	if /^Content-Type:[[:space:]]*multipart\/related/
> 	!/type=/ REJECT RFC2387 says multipart/related requires a Type
> 	endif

that's useful. thanks.

unfortunately, it probably wont be long before spammers fix their
spamware.


> FWIW, I've received at least two "genuine" multipart/related emails this
> week so have reservations about summary blocking of all multipart/related.

yeah, that was my concern with my multipart/related rule - i was pretty
sure that it would end up blocking legit mail too.

fortunately, with my mail patterns, it hasn't actually blocked any legit
mail yet.

and with a small home system, i can afford to say "i don't care about
receiving mail from outlook users". none of my friends use outlook
(they're either geeks, or i've ranted about the evils of microsoft and
especially outlook so much that they would be too embarrassed to use
it). that's obviously not a viable approach for an ISP - but that was
always the case, even when i was working at an ISP...my home system had
far stricter anti-spam rules than my work mail systems. partly because i
could afford to be more ruthless about spam at home, and partly because
my home system was used to test anti-spam rules before i implemented
them at work.


i'd prefer a solution that didn't have a high risk of false positives,
but what i have will do until it actually causes a problem for me.

your rule may actually do that for me.  i'll try it for a while.  if
it blocks 90+% of the image spam, that's good enough.


> So the question remains: how to distinguish them?

that's the difficult one. i haven't yet seen anything unique to image
spam in either headers or body, and haven't found anything better than
my rule (or your one) with a google search.

craig

-- 
craig sanders <cas at taz.net.au>           (part time cyborg)