[Email-SIG] fixing the current email module

[Glenn Linderman]

On approximately 10/9/2009 3:08 PM, came the following characters from 
the keyboard of Tokio Kikuchi:
> What you said in message-id: <4ACE6F97.6010605 at g.nevcal.com> was:
>   
>> When it is not ASCII, it may still be
>> separated and recognizable.
>>     
> and our discussion might be concluded that this is true 'not really, but
> only theoretically.'  Your suggestions 1)-4) are not accesptable to
> Japanese users at all.
>   

There's something I don't understand here, and I'll hope you'll take a 
few moments to explain...

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 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, 
so if there is one I've missed, I'm extremely interested to learn (or be 
reminded) of it.


What I meant by "may still be separated and recognizable", is, in fact, 
somewhat theoretical.  Since I can't type Japanese, I'll just use a 
single accented non-ASCII character in my explanation, but here goes:

Message A arrives at Mailman for distribution.  No subject prefix or 
numbering.  Since it is Mailman doing it, Mailman could notice that the 
prefix is like  [abcdéfg 126] and must be encoded.  Mailman could encode 
the prefix as a separate encoded word than the rest of the subject 
value.  Let's assume that it does.

The rest cannot be guaranteed, because we have no control over the MUA 
of the person that replies.  But it might come back in the same 
manner... one encoded word with the prefix and then the rest of the 
subject line, possibly encoded, possibly not.  If it does, then if the 
first encoded word can be decoded, and the prefix and numbering 
recognized, then the modification to assign a new number can be done, 
whether or not the remaining part of the subject line can be decoded or not.

So that is what I meant, by the above.  It isn't a guarantee in any 
manner.  It could realistically happen, though, if an MUA simply adds 
"Re: " to the front of the stuff that it is passed (or an encoded word 
with an appropriate translation for "Re: ").

MUAs or mailing list handlers that decode, process, and reencode, will 
probably not produce headers with that pattern, but more likely like the 
one you showed in example 2.  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.

> I couldn't resist writing because the discussion was important in
> designing Mailman's subject prefixing and numbering.  I'll shut up my
> mouth again because I'm so busy.
>
> Sorry for disturbing

Thanks for your contribution; I hope for one more, at least.

-- 
Glenn -- http://nevcal.com/
===========================
A protocol is complete when there is nothing left to remove.
-- Stuart Cheshire, Apple Computer, regarding Zero Configuration Networking