[Email-SIG] fixing the current email module

[Stephen J. Turnbull]

Glenn Linderman writes:
 > On approximately 10/9/2009 3:08 PM, came the following characters from 
 > the keyboard of Tokio Kikuchi:

 > > Your suggestions 1)-4) are not accesptable to Japanese users at
 > > all.

 > If a message with an encoded header arrives (like your number 2 sample) 
 > but it cannot be decoded, what action _is_ acceptable to Japanese 
 > users?  And what action is implemented in Mailman (if different)?

I know a fair bit about Japanese (both the language and the users),
and I'm having difficulty understanding what Tokio means, given your
list of hypotheses.  I suspect he's basically rejecting the hypothesis
that it can't be decoded -- if it can't be decoded, then learn how to
do so!

 > I can think of a 5th technique... don't modify the header, and send
 > it through unchanged.  Now I think I've covered the gamut of
 > possibilities,

I agree.  However, I think we're way out of bounds here.  We already
know how to decode anything that RFC 2047 can throw at us in charsets
that Python can handle.  Anything that can't be decoded then is
seriously malformed from the point of view of the mailing list users.
So why are we discussing this?  We don't even know what our mainline
APIs are going to look like, why are we discussing forcibly operating
on broken input?

[[ Aside:

 > with an appropriate translation for "Re: ").

"Re" is a Latin abbreviation; there is no appropriate translation. ;-)
]]

 > MUAs or mailing list handlers that attempt to retain what was sent
 > (idempotency or invertibility), would be more likely to do what I
 > describe, and are more robust when faced with new character sets
 > that they don't understand how to decode.

Maybe they are, but the email module doesn't know or care about what
they do.  Let's stick within what the email module is supposed to
handle.