Re: Bug reported regarding Unicode handling in email address

[Ralph Corderoy]

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@inputplus.co.uk>
> > Message-ID:  <20210610103110.C017721911@orac.inputplus.co.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.