From: "Geo" 

"Rich"  wrote in message news:435b1fe7{at}w3.nls.net...

>> What bothered him is that the encoded form is used when it wasn't
necessary and presumably some tool he is using doesn't understand this 12
year old standard.<<

Wrong. The spam filters I run do understand it or perhaps you didn't notice
the encoded [SPAM] tag they had added to that subject I posted. The problem
is that the netware email client that some customers use doesn't understand
this encoding. (it's a netware shortcoming)

In previous versions of my spam filters the subject line was decoded, the
spam tag was added and the uncoded text was then passed on as the subject
line. In the new version the tag is added in encoded form and the subject
line is left encoded. This netware client was seeing the lines correctly in
their unencoded form so end users could use the tag to do further
filtering, in the new version they get the raw encoded text which to them
is unreadable garbage.

I had to set my filters back to changing the subject line from tagged and
encoded to tagged and unencoded to make them happy.

What bothers me is that I didn't realize this sooner, and the fact that
this didn't affect OE users. It means OE rules are applied after the
decoding so it's not possible to create a rule to look for raw text in an
encoded subject line. I have both filtered and unfiltered email accounts
and I had a rule to move anything with an = in the subject line to a
special folder but it never caught anything except test emails I sent. Duh,
now I know why.

Geo. (learn something new every day)

--- BBBS/NT v4.01 Flag-5