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

[Eric Abrahamsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> 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.

Sorry, I misunderstood -- I thought this change was introducing a
difference in the saved files. My mistake for not following along
closely enough.

Maybe all this warrants some regression tests in ./test/lisp/mail?