Jo Rhett wrote:
> So this user's e-mail keeps getting tagged with rules that aren't
> right. There's no base64 here, at all (looked at the raw text) and
> there's certainly no stock spam. What's going on here?
>
> Is the charset triggering the base64 rules? They are false hits...
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
Note that your mail client will convert and render base64 encoded text.
Odds are this message really was base64 encoded, but it would be
impossible to tell for sure from your forward. My guess is if it wasn't
really base64, your mail client would have choked on it and displayed
garbage instead of text.
Forwarded messages are USELESS when trying to examine mime encodings,
because your mail client will completely re-encode the text in whatever
way it chooses.
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:")
Of course, also consider that you are spam threshold is 4.0, instead of
5. By doing so, you've asked SA to catch more spam at the expense of
having more false positives. This is one of them that would not have
been tagged at 5.0.
