Comment 8 for bug 373083

Tokio, I tried your patch, but unfortunately it does not solve our problem. Try setting language to e.g. German and feed mailman with UTF-8/8bit email containing german text. What comes out is ISO-8859-1/QP, i.e. both charset and encoding are different...

You seem to have introduced 'LCSET first' rule because of Japanese lists. Please note however, that situation in Japan is very specific - instead of using 8bit/Base64/QP with standard charset you're converting all email into special iso-2022-jp charset which is 7bit already and doesn't need any form of content-transfer-encoding by principle. In this situation I understand your preference to convert anything into iso-2022-jp at first place, but that's clearly not apropriate as general solution.

Therefore I propose to try LCSET first only if the LCSET is euc-jp. That way you will keep your specific requirements and others won't be negatively affected by the side-effects.

Now to Mark's concern: my patch uses None in the situation you described. This will call encode_7or8bit fuction from email/encoders.py which will do the right thing - i.e. it will set content-transfer-encoding to 7bit if body is ascii or iso-2022-* based, but will set it to 8bit if some accentuated character is present in the footer. This is perfectly valid according to RFC2045 and is heavily used in the field - for example popular MUAs like Thunderbird or Mutt are doing this by default, also e.g. bugzilla or subversion send all emails this way. Mailman passes such messages just fine if no footer is configured.

Thus I don't think mailman should base64-encode (=make unreadable) us-ascii emails just because it adds a footer. If you're concerned about generating 8bit CTE, then the second best solution is to add footer as MIME multipart (wrap=True).

I'm glad to hear that you're considering changing to UTF-8 for Mailman 2.2 ! BTW, you can also change Russian (koi8-r) as they are using UTF-8 in e.g. Squirrelmail for quite a long time already.