That actually brings up one point I have wondered about, and which might
help here - my recollection (it has been a long time since I tested this,
so things might have changed) is that nmh doesn't like receiving drafts
with MIME fields in the header (including particularly for right now) a
Content-Type field - is that still true? If so, does it need to be?
As I understand your question ... no, that is not true (with a few caveats).
We finally decided, I think around nmh 1.5 (or 1.6), to automatically run
"mhbuild" on all drafts because nmh users had the unpleasant habit of
doing things like sending out unencoded UTF-8 because that was very easy
to do unless you explicitly configured it otherwise.
Now PRIOR to that, if you had the AUTOMHNPROC environment variable set
(I think), send would also run mhbuild (back then, mhn). _If_ you did
that AND your draft contained a MIME header like Content-Type, you'd get
an error.
What we did was add a new flag to mhbuild, -auto, and send would run
mhbuild on the draft with the -auto flag. The two changes -auto does are
it disables mhbuild directives AND if mhbuild sees a MIME header, it silently
exits without error. The assumption there is if the outgoing draft already
has MIME headers then either the user knew what he/she was doing and we
shouldn't mess it it, or you already ran mhbuild once on the draft
explicitly. So if you provide send(1) with a draft with the proper
MIME headers then everything should work just fine.
That in a sense raises another question, what do we do when replying to
a message which is in some (perhaps exotic, like TIS-674) charset, and
quoting parts of that message, when my locale is "C" (or something
else different) ? Clearly converting everything to UTF8 would
allow it all to work, but whose responsibility is it to do that, and
when does it happen?
Sigh. We haven't QUITE covered all of the combinations yet. There is
some kind of add-on tooling that makes this easier but not perfect.
The short answer is the general trend is to call iconv() to convert
the source characters to the native character set (based on the locale),
and then your favorite editor will understand the characters in the
reply message. If iconv() fails on a character we insert a substitution
character. This obviously works best if your local character set is
UTF-8. I am aware that some people, for reasons I cannot comprehend,
want to run in the "C" locale but PRETEND that their character set
is UTF-8 and this approach does not work for them. To these people I
can only say ¯\_(ツ)_/¯.
--Ken