The old ISO-8859-x subject line encoding trick seems to be making a comeback, at least in a majority of the spam that's getting through our SpamFilter right now.  For example, today, I received a spam message with a subject line of:

Subject: =?iso-8859-1?B?c21hc2ggdGhhdCBwdTU1eQ==?=

When the mail client decodes this line, it reads:

Subject: smash that pu55y

A few months ago, Roberto mentioned that subject line decoding would be included in a future release (see http://www.logsat.com/spamfilter/forums/showmessage.asp?messageID=1945).  I'm not sure if that has been implemented or not, but even if it has, it will only go so far.  Decoding this text prior to passing it to the content filters would be beneficial in catching some spam... but unless we were keyword trapping on "pu55y" (and "puzzy" and "puszy" and 10,000 other possible character combinations that a spammer might use for this word) we most likely would not be stopping these messages anyway.

I'm a bit concerned about setting-up a RegEx to trap the "=?iso-8859-" etc. in the subject line.  While there is a 99.99%+ probability that any message with a subject line encoded in this manner IS spam (at least in our system), I'm not certain as to whether inline encoding of this type might be used in legitimate message content such as documents created with Microsoft Word or other applications.

In other words... if I could, I would be willing to enact the following rule on my system:

• If "=?iso-8859-" string is found within the SUBJECT of a message, it IS spam and should be quarantined.
• But if this string is found within the message content, it may NOT be spam, and should NOT be quarantined.

Has anyone done this, or have an idea on how this could be implemented?  And if it can't be done... Roberto, would it be possible to implement a "FilterEncodedSubject" INI setting or something like that, in a similar manner to the way that the "FilterBase64html" INI setting is currently implemented?

Thanks, Jim

Thanks, Roberto.  (Wow, that was a fast response!) 

This modification will be very beneficial, not just for the ISO-8859-x encoding issue, but also for other testing that might work great when limited to the subject line such as repetitive consonant traps, etc.

Jim