>>>>> "Tokio" == Tokio Kikuchi <[EMAIL PROTECTED]> writes:
Dan> Well, so, one of them has no charset expressed at all that I Dan> can see. Ben> That means their charset is us-ascii. Tokio> Well, people around in Japan still use older MUAs and don't Tokio> add charset for Japanese messages. Tokio> So, the meaning of no charset should depend on the Tokio> mm_cfg.DEFAULT_SERVER_LANGUAGE, I suppose. This would violate RFC 1522: "5.2. Content-Type Defaults Default RFC 822 messages without a MIME Content-Type header are taken by this protocol to be plain text in the US-ASCII character set, which can be explicitly specified as: Content-type: text/plain; charset=us-ascii" Are we sure we really want to do that? Dan> Not really, if appropriate workaround is "ignore the incoming Dan> charset and add this footer unconditionally please". Ben> But this is the worst thing you can do. What happens when I Ben> post a message in UTF-8 and then a Japanese ISO-2022-JP Ben> footer gets tacked on? Not good. Tokio> That's why you need to 'normalize' the charsets of incoming Tokio> mail (into Unicode). That would work in the best of all possible worlds (i.e. NOT the real world :) but I think there is still information lost when converting some charsets into Unicode, like Big5 and EUC-TW. Also, who knows if we would corrupt PGP signatures by doing something like this? I would like to have Mailman move to this model eventually, when all mail readers support UTF-8 natively. Ben -- Brought to you by the letters N and R and the number 15. "Tahiti is not in Europe." Debian GNU/Linux maintainer of Gimp and Nethack -- http://www.debian.org/ _______________________________________________ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers