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 <[email protected]> > > Message-ID: <[email protected]> > > > > - 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.
