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