English is probably your native language and the one your emails are
written in.
This way non-ASCII text does not get handled specially (if no
attachment is present).
No MIMEification means that the characters are plainly in the mail
body. The original charset is not available in the mail which will
lead to broken or wrong charcters display on systems with a
non-compatible native charset.
Also the mail message is 8bit then.
Fixing this problem is part of my patch. @Jon: This actually can be
considered as some kind of usage bug of your system. If you include
non-ASCII text but no attachments then you need to run mime at whatnow
prompt manually, otherwise you must not.
My patch however does break compatibility if one likes to send
messages that contain non-ASCII chars without MIME.
Correct me if my memory is failing me here, I'm being lazy and not rereading
rfcs at the moment because I have other things to do.
I recall that in the absence of appropriate headers messages are defined as
ASCII. If that's the case, it strikes me that you're "fixing" something that
is convenient for you but technically not broken.
I think that I now understand what you want, which is to be able to do a simple
"comp" and have things work automatically with non-ASCII message bodies without
having to mess around with mhbuild and all.
I'm going to keep harping on the "don't break things" theme, because it seems
like the goal should be to make things more convenient for you without making
things less convenient for others.
Would you consider leaving the -attach stuff as it is and adding a
-assume_non_ascii_is_in_the_charset_defined_by_the_lang_environment_variable
option instead? Fine with me if you use a shorter name :)
Doing it this way doesn't break existing code, and makes the behavior optional
so that it won't surprise anybody who hasn't explicitly enabled it.
Jon
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
http://lists.nongnu.org/mailman/listinfo/nmh-workers