On Thu, 3 May 2007 15:27:56 -0500, Winship <[log in to unmask]> wrote: > On Thu, 3 May 2007, Hal Keen wrote: >> But all three of your email samples were conveyed in quoted- >> printable. Some >> sample header information and demonstration text from each (with >> colons used >> as "vertical ellipses" to indicate where I have snipped): > > If you will look at the headers, the person often uses utf-8 for > her email > to this list (check the Contnet-Type: field). Thank you for helping me understand what's going on here. You seem to be saying that it's the way a particular email client renders content. If that's the case though why are do about 10% of people's messages have these = characters and not all or none of them? Curiously the characters don't appear with the = coding on the archive. 4′33″ gets rendered as 4′33″ in the archive. It seemed to make sense that it was the Content-Transfer-Encoding: field that was not converting the characters and adding =20 for line feeds, but then I saw the messages that appear this way on my apparently utf-8 Apple Mail.app also appeared with the = characters on my Palm Treo, so I suppose that's utf-8 as well. Apple Mail uses Automatic encoding <http://docs.info.apple.com/article.html?path=Dotmac/Mail/en/mac70.html> What seems to be happening is that when someone using an email application that does "automatic encoding" encounters a utf-8 character, it changes to that content-type. This can be done with cut and paste (as with my 4'33' example) or by replying to an email that is already encoded in utf-8. Accents will trigger the utf-8 encoding as well. I'll send a small email after this without any accents, extended characters or pastes that will show Content-Transfer-Encoding to be 7bit. It seems there should be a way for listserv to overlook 8 bit characters. Perhaps that is what "Translate = No" will do. KEF