Allan Odgaard wrote:
On 18 Jun 2008, at 16:09, Mark Sapiro wrote:
[...] The process of adding the list header and/or footer to the message attempts to add these to a text/plain body by coercing the body and the header/footer to unicode, concatenating them and then coercing back to the original body charset. If the last step doesn't work, it will try to coerce to the charset of the list's preferred language.
My list header/footer is pure ASCII. So there should never be a
problem going back to the original body encoding.
Actually, I misspoke above. The preferred encoding is that of the list's preferred language. The incoming message encoding is the fallback.
So should I consider it a bug that setting list encoding to utf-8 will
(in my experience) _always_ produce (base 64 encoded) utf-8 letters,
when both header/footer and letter itself sent to list is ASCII?
You may consider it a bug if you wish. It is intentional (but still perhaps wrong) that the message is coerced to the character set of the list's preferred language when msg_header and/or msg_footer are added.
The base64 encoding for a utf-8 message is a separate issue and is done by the Python email library.
Here is what I did to test: Set list encoding to utf-8 (in mm_cfg.py).
Created a new list (called Test) and subscribed to it. Even the
welcome letter contained:Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Subject: =?utf-8?q?Welcome_to_the_=22Test=22_mailing_list?=
This is a 'virgin' message from Mailman which will always be in the charset of the list's or user's preferred language, so no surprise here.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan