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

[Florian Weimer]

* Eli Zaretskii:

>> As I expected, I could reproduce the issue with new mail.  I'm happy to
>> report that replacing nnml--encode-headers with your new version fixes
>> the issue.
>
> Thanks, so I've now installed this on the emacs-29 branch, for the
> upcoming Emacs 29.1.

It's a denial-of-service issue, so it should be backported to 28 if
possible, too.

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

I don't know.

>> I assume that there is some protection in place that tabs are not
>> possible here?
>
> Tabs where, and what kind of protection are we talking about?

The .overview file is in tab-separated-values format, and I think the
code is supposed to replace tabs with spaces before the lines are
written.  But mail-encode-encoded-word-string/rfc2047-encode-string
generally does not replace tabs, so your change shouldn't make things
worse at least.

Thanks,
Florian