Of Spam & Men

To content | To menu | To search

Tag - spamassassin

Entries feed - Comments feed

Wednesday 1 August 2007

Dectecting doc/zip/xls/pdf spams with Spamassassin

When trying to build Spamassassin rules to detect a new kind of spam, it's always usefull to have several copies of the spam so you can check what parts never changes.
In the case of the pdf/zip/doc/xls/etc. spam, even if the spammer did a lot of work to try to make it indetectable, he forgot something: the boundary line of the content-type header is always built the same way and isn't common at all:

------------ then a random 24 characters alphanumeric string.

I've searched in my INBOX (more than 50 000 messages) and this boundary pattern only matches the spams.

From this, we can build our first SA rule:

full __UN_KNOWN_BOUND /boundary="------------\d{24}"/

Now, it's safer if we make sure it's really a spam by adding some attachment detection:

full __UN_PDF_ATTACH /application\/pdf/i
full __UN_OCTSTREAM_ATTACH /application\/octet-stream/i
full __UN_WORD_ATTACH /application\/vnd.ms-word/i
full __UN_EXCEL_ATTACH /application\/vnd.ms-excel/i


Then you can build a meta rule that will match our spams:

meta UN_ATTACH_SPAM __UN_KNOWN_BOUND && (__UN_PDF_ATTACH || __UN_OCTSTREAM_ATTACH || __UN_WORD_ATTACH || __UN_EXCEL_ATTACH)
score UN_ATTACH_SPAM 10

Sunday 26 November 2006

Catching fake replies with spamassassin

The most common (and useless?) trick used by spammers to fool users is the fake reply method. By adding "Re: <something>" in the subject, spammers assume that the victim will believe it's a reply to one of their mail. Unfortunately for them, the SMTP RFC (rfc 822) offers optional and commonly used headers for defining a reply and Spamassassin can be used to detect when those headers are missing.

Continue reading...