On Wed, 2007-02-07 at 23:31 -0500, Matt Kettler wrote: > No, the charset isn't triggering the base64 rules. The fact that the > Content-Transfer-Encoding declares the message is base-64 encoded is > causing it. > > >> Content-Transfer-Encoding: base64 > As for LW_STOCK_SPAM4, it's being triggered by the fact that the message > is base-64 encoded text AND has a Date: header that's missing a proper > timezone. Apparently a batch of stock spam went out at some point with > both of these abnormal features. I have to admit, it's a pretty rare > combination. > > > Date: February 6, 2007 9:52:29 AM PST > > That should, properly, should read something like this: > Date: Wed, 06 Feb 2007 09:52:29 -0800 > > Note that in the world of RFC 2822 "PST" isn't a valid timezone. -0800 is. > > RFC 822 allowed either format, but 2822 only allows the "offset from > UTC" style. 2822 superceded 822 in april of 2001, so it's been almost 5 > years now, and nearly every normal email system has caught up by now. > > (side note: neither format has ever allowed hours to be expressed as a > single digit. It's always been required to use "09:" not "9:")
Note that the original message was sent from a Blackberry, the base64 encoding and possibly the invalid date format are related to the blackberry server used. I'm guessing it was sent directly through Sprint's network via their integrated blackberry service. I've seen similar false triggers with other messages sent from Blackberry's.
signature.asc
Description: This is a digitally signed message part
