Comment 3 for bug 373083

The motivation here is exactly the same - to preserve the original message format as much as possible.

Changing charset in the path between the sender and the recipient breaks automated processing as described above. Moreover, several MUAs make an asumption that it's best to reply in the same charset in which the original message arrived. When the listserver changes charset, this assumption becomes invalid.

Examples:

- sender generates email in UTF-8 to ensure uniform encoding in all cases. However, mailman configured for language with iso-8859-* charset sometimes "downgrades" that to iso-8859-*, sometimes keeps UTF-8 - depending on email content.

- sender generates email in iso-8859-1 since it can't display anything else properly. However MM configured for language with UTF-8 charset always changes that to UTF-8 and replies will use that.

The latter will become more visible after you change all languages to UTF-8. To be precise, I'm all in favour of changing all languages to UTF-8 as soon as possible for obvious reasons, but I believe you need to apply this patch beforehand otherwise some people with legacy environment will start complaining about getting all emails in UTF-8. With all languages in UTF-8, the new order will in fact mean: message charset first, then UTF-8 - which I think makes a lot of sense.

If Japanese need the reverse order for some reasons, an exception for euc_jp might be a decent solution, but I can't comment whether this is really needed.