Comment 11 for bug 373083

Petr Wrote:
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...

Tokio asked:
Have you set

DECORATE_CHARSETS = [DECORATE_MCSET, DECORATE_LCSET, 'utf-8']

in mm_cfg.py and execute bin/mailmanctl restart ?

Petr replied:
It doesn't solve the problem no matter what the settings are, since your patch only preserves CTE when charset is not changed.

Mark asks:
Why is charset changed in your example? With Tokio's patch, if DECORATE_MCSET is first, the outgoing mail should be in the charset and encoding of the original assuming the footer can be encoded in that charset which is true if it's UTF-8.

Petr also wrote:
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.

Mark replies:
This assumes all MTA's in the delivery path support 8BITMIME. Granted, If a receiving MTA doesn't support 8BITMIME, the sender MAY convert to another encoding (RFC1652), which will work as long as the MTA which doesn't support it is not the initial MTA that Mailman is sending to. In short, delivery of messages containing unencoded bytes >x7F is not guaranteed.

These are hard choices in general, but I am reluctant to make changes that would potentially break Mailman altogether, even if only in rare cases.