Uh-oh: Spam's getting more sophisticated

Computerworld - Just as security experts match wits with hackers, those trying to block unwanted e-mail face increasingly elaborate "attacks" from spammers trying to slip messages through antispam defenses.
"These guys' technical ability should be respected," John Graham-Cumming, author of open-source spam filtering software POPFile, told a conference at MIT today.
Graham-Cumming outlined several ways spam authors try to evade blocking software, ranging from the simple to the sophisticated. Some messages just alter words to foil basic efforts to spot red-flag words; for example, most recipients know what "Vi*gra," V1agra" or "V i a g r a" mean, but basic word-blocking software might not. Other efforts involving HTML-coded messages instead of plain text are far more clever.
"The most dastardly thing I've seen so far," Graham-Cumming said, involved words that were printed vertically within the raw HTML text,
l
i
k
e

s
o
. The HTML message then used tables to reassemble the words and display them horizontally again. The result: Antispam filters didn't understand that the words in vertical format were spam, and let the message through; but the HTML displayed normally to recipients. "This is ingenious," he said. The lesson for those writing antispam software: Filters need to understand how HTML is displayed to the end user, not merely look at the raw text.
Other filter-evading techniques include:

• Using a two-part Multipurpose Internet Mail Extensions (MIME) encoded message, with the plain-text portion looking like legitimate mail, which the filter reads and lets through, but the HTML portion shown to the recipient containing that message about making millions working at home or enlarging various parts of one's anatomy. Lesson: Filters should check whether text and HTML portions of two-part MIME messages are the same.


• Employing "invisible ink" within an HTML message -- white text on a white background, for example, containing words that look like a legitimate message but the user doesn't see; then there's just a short spam message actually visible to the user. Lesson: If the user can't see it, neither should a spam filter.


• Sending an HTML message with no words for a filter to check, just an image with the spam's message. Lesson: Filters need to look at more than text.


• Sending an HTML message with no spam contained initially; the spam is included in JavaScript code that changes the e-mail content after it's loaded. Lesson: Filters should either decode JavaScript or, as one audience member suggested, block it.