Re: master ef14acf: Make nnml handle invalid non-ASCII headers more consistently

[Eli Zaretskii <eliz@gnu.org>]

> From: Eric Abrahamsen <eric@ericabrahamsen.net>
> Cc: Florian Weimer <fweimer@redhat.com>,  larsi@gnus.org,
>   emacs-devel@gnu.org,  ding@gnus.org
> Date: Mon, 19 Dec 2022 09:48:15 -0800
> 
> On 12/19/22 19:07 PM, Eli Zaretskii wrote:
> >> Going back to older mail, I see that previously the From: header was
> >> written in encoded form to .overview (slightly wrapped to avoid SMTP
> >> issues):
> >> 
> >> 8523 Re: [PATCH 1/7] Rename 'hello2.spec.' -> 'hello2.spec'
> >> 'hello3.spec.' -> 'hello3.spec'
> >> =?utf-8?b?572X5YuH5YiaKFlvbmdnYW5nIEx1bykgdmlhIEVsZnV0aWxzLWRldmVs?=
> >> <elfutils-devel@sourceware.org> Thu, 24 Nov 2022 16:27:56 +0800
> >> <CAE2XoE_RBNdsPZMLiSQKJroyx4ycvqf7y+VDbuY=-XbhOwsL8g@mail.gmail.com>
> >>   <20220920084307.1696-1-luoyonggang@gmail.com>
> >> <20220920084307.1696-2-luoyonggang@gmail.com>
> >> <Y0nH98k6YumMRSz0@wildebeest.org>
> >> <CAE2XoE-xfFQNMN1JYSi8Kp+-DUUookRkzwUV+OvKGfnZKDXKEA@mail.gmail.com>
> >> <20221019194930.GC24703@redhat.com>
> >> <3bf19d05c8976411432709fae1cc2bcc2d21d700.camel@klomp.org>
> >>   <586fbfd512763e539f0d06e8ffa308da34be5368.camel@wildebeest.org>
> >> 705 32 Xref: oldenburg.str.redhat.com
> >> lists.sourceware.elfutils-devel:8523 Cc: "Frank Ch. Eigler"
> >> <fche@redhat.com>, elfutils-devel@sourceware.org To: Mark Wielaard
> >> <aegon@wildebeest.org>
> >> 
> >> Now it uses unencoded form:
> >> 
> >> 8762 Re: [PATCH v2 13/16] lib: isatty is not available on windows 罗
> >> 勇刚(Yonggang Luo) via Elfutils-devel
> >> <elfutils-devel@sourceware.org> Mon, 19 Dec 2022 20:32:48 +0800
> >> <CAE2XoE-Xv6+4Npj38ih_nPMZ8e6ph7oS8wxvKFx1uE-sRfH_kw@mail.gmail.com>
> >> <20221217165213.152-1-luoyonggang@gmail.com>
> >>   <20221217165213.152-14-luoyonggang@gmail.com> 1074 43 Xref:
> >> oldenburg.str.redhat.com lists.sourceware.elfutils-devel:8762 To:
> >> elfutils-devel@sourceware.org
> >
> > Is that a problem?  I think this was part of the reason for that
> > change in nnml.el.
> 
> It would definitely be a problem to change the on-disk representation of
> data in the .overview files! Lots of code depends on a very specific
> format for those files; I've broken things badly in the past by removing
> header encoding there.

But this change is there since Emacs 28, so if it's a problem, someone
would have hollered already, no?

Or are you saying that the changes I installed are causing the
difference?  If so, I don't see how that could happen, since the
change just ignores any errors signaled by rfc2047, and if rfc2047
does signal an error, what is stored in the file is the same string as
what we did before the new function nnml--encode-headers was added and
we started using it.

So unless I'm missing something, the changes I installed cannot cause
any new problems we didn't have since quite long ago.