Hi kre,
I've reordered the quotes...
- /var/spool/$LOGNAME is in UTF-8.
Says who? I think for me it is in whatever mixture of char encodings
that were used by the various senders of the messages that are there.
To be clear, we're talking about the use of UTF-8 in fields after
SMTPUTF8 has been seen in the SMTP EHLO reply, not any ‘charset’s in
Content-Type fields, or similar. So my thinking is the spool-file's
writer will either be something like Postfix which declares support for
SMTPUTF8, is handed UTF-8, and AFAICS stores it verbatim, or a program
with no support which will be writing ASCII, a UTF-8 subset.
Date: Thu, 10 Jun 2021 11:31:10 +0100
From: Ralph Corderoy <ralph(_at_)inputplus(_dot_)co(_dot_)uk>
Message-ID:
<20210610103110(_dot_)C017721911(_at_)orac(_dot_)inputplus(_dot_)co(_dot_)uk>
- mail/inbox/42 was written by us; it's our choice.
For me, it would be written by procmail (mostly) and it will be
unaltered from what was in the relevant message from /var/spool
If I'm right above then it will be UTF-8 if copied from /var/spool,
and as along as nmh also arranges it to be UTF-8, ignoring the user's
locale, then external and internal writers marry up.
- mail/draft is the process's locale.
Probably, but which process? How do we know what created it?
There's no requirement that it be sent any time soon after it was
composed - with just the draft file there's not a lot of leeway, but
we support drafts in a folder, and there there can be lots waiting to
be sent. My drafts/1 file is from 1997
1999 here.
One day I might send some of those messages...
If your locale today is incompatible with what it was then, and for many
ASCII→UTF-8 users it won't be, ISO 8859-1→UTF-8 is the problem, then
you'll have to iconv(1) or similar to convert the encoding before nmh
would stop griping. Unless you're unfortunate and it's ISO 8859-1 which
happens to be a valid UTF-8 rune.
--
Cheers, Ralph.