[Way OT] Re: [SGVLUG] REMOVE

[Emerson, Tom]

> -----Original Message-----
> Behalf Of serross at ix.netcom.com
> 
> Shure would be nice.............. IU'll vote twice to it.

Hmmm... I'm not sure what you're "voting twice for" -- including the oft-repeated footer of subscribe/unsubscribe info, of the inclusion of RFC-ordained headers?  In the former case, my point is that these are typically ignored (and has another problem I ran into about a year ago -- see below...), and in the latter "it already does that" ;)

Sometime around June of last year, on the "other" mailing list I frequented, somebody wrote a similar one-liner "unsubscribe" message to the LIST itself, and that list IS configured to dump the block of text:

    * To join/leave the list, search archives, change list settings, *
    * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

at the end of every message.  The usual (and touted as a beneficial) side-effect of this is that if someone does send such a message, he immediately receives instructions attached to his original message that are hard to miss.  In this particular case, however, the message did NOT (appear to) contain said block-of-text, but rather had some strange "random binary characters" at the end.  I (foolishly or otherwise) jumped to the conclusion that this could be the work of some "new virus" targeting e-mail list servers rather than end users (i.e., spread via lists)

AS IT TURNS out...  the truth behind what those "binary characters" were in first place is even funnier -- the sender was using an e-mail client that sent the message as "base-64 encoded" (ummm, it was "rich text" -- three guesses as to the culprit)  and my response (since, like this one, I sent "from work") was ALSO base-64 encoded(*) AND did not have the "footer" (or so it seemed).  In actuality, all of these messages had the footer, but as the "client" was in "decode this base 64 stuff" mode, it DIDN'T STOP DECODING when it got to the plain-text block shown above -- those "mystery characters" were in fact what you would get if you DECODED that block of text "as if" it was encoded data!

(to see the discussion, go to the above-linked archive for June 2004, around week 4, and look at the "unsubscribe" and "administrivia" threads)

Tom

(*) as I pointed out in one of those messages, Outlook tends to respond "in kind" to the source type of message -- if plain, it responds plain; if rich/html, it responds as html and gives a stern warning if you try to switch back... (and then doesn't provide the '> ' prefix on each line, forcing you to do this manually if you want it to look right...)