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

[Eli Zaretskii <eliz@gnu.org>]

> From: Florian Weimer <fweimer@redhat.com>
> Cc: larsi@gnus.org,  eric@ericabrahamsen.net,  emacs-devel@gnu.org,
>   ding@gnus.org
> Date: Mon, 19 Dec 2022 14:59:17 +0100
> 
> > I'm not sure this is related.  I was talking about the missing SPC
> > character before the parentheses.  But I know very little about this
> > stuff, so maybe I'm just misunderstanding you.
> 
> I was responding to “this From header is invalid”.  I'm not sure if the
> original message is actually malformed.

Ah, okay.  I'm not sure, either, although I don't think I've ever seen
such addresses.  But I'm no expert.  Maybe rfc2047.el needs to be more
tolerant and less dependent on whitespace; I'll leave that to experts.
But even if there's nothing wrong with this particular header, I think
you will agree that signaling and error and thus failing the entire
storage of the message is not TRT, especially since the change which
causes this was done for basically aesthetic reasons.  Falling back to
previous behavior in these cases is better, I think.

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

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

Again, I'm not an expert on this and don't use Gnus, so apologies for
possibly dumb questions.