[2025-02-15 16:23] Ken Hornstein <[email protected]>
> >So I'm not sure if this is an NMH issue, or an issue with my
> >admittedly out-of-date system, or what.
> >
> >I received an email that has these lines in it:
> >
> >Subject: =?utf-8?Q?We=20are=20down=20to=20the=20wire.?=
> >From: Team PrezCon <[email protected]>
> >Reply-To: =?utf-8?Q?Team=20PrezCon?= <[email protected]>
> >
> >When I view the email, it looks fine:
> >
> >Date: Sun, 19 Jan 2025 12:23:34 -0500 (Sun, 19 Jan 2025 17:23:34 +0000)
> >To: <[email protected]>
> >From: Team PrezCon <[email protected]>
> >Subject: We are down to the wire.
> >
> >but when I reply to the email, I end up with this:
> >
> >To: =?utf-8?Q?Team=20PrezCon?= <[email protected]>
> >Subject: Re: =?utf-8?Q?We=20are=20down=20to=20the=20wire.?=
>
> Others have answered your question, but I have to ask ... what, exactly,
> is the problem? nmh is working exactly as designed here.
There are some problems with this:
Like hymie! already noticed, it looks prety ugly.
It's hard to read. So when you open an old draft you can't just reread
the subject and recipient to remined you of the topic and reason for
the draft.
> The default is to use RFC 2047 decoding (the =?...?= thing) for display,
> but copy the raw headers verbatim when replying.
Sadly there are some mail programms which use RFC 2047 for everything.
So they even encode the "Re:" in the subject. This leads then to
"Re: Re: ..." subject in the answer. When the transfare encoding now
is base64 it's quite hard to notice.
> The reason for this
> is that there is no guarantee that the character set in the encoded
> header will match the user's chosen character set, and there is a very
> real possibility that the subject will get mangled if the character
> sets involved don't have a valid conversion for some of the characters
> (this is further complicated by the insistance on a number of people to
> use us-ascii as their chosen character set for reasons that elude me).
> Using the raw header for replies ensures this doesn't happen.
When I remember the RFC 2047 implementation correctly, it should be
possible to check, if the string can complitly translated to the local
charset. With such a check we could decode it when posible without
lost of information and leave it RFC 2047 when not[0].
There are still some problems, like having special chars (i.e. ,) in
an encoded display name. But I would say it's possible to handle this
without writing RFC 2047 encoded text in a draft when it's not necesary.
Philipp
[0] maybe only let the RFC 2047 encoding for the parts which can't be
translated to the local encoding.
