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

[Eli Zaretskii <eliz@gnu.org>]

> From: Florian Weimer <fweimer@redhat.com>
> Cc: Lars Ingebrigtsen <larsi@gnus.org>,  Eric Abrahamsen
>  <eric@ericabrahamsen.net>,  emacs-devel@gnu.org,  ding@gnus.org
> Date: Sat, 17 Dec 2022 15:57:18 +0100
> 
> >> Mail source (maildir :path …) failed: (error Invalid data for rfc2047 encoding: 罗勇刚(Yonggang Luo) via Elfutils-devel <elfutils-devel@sourceware.org>)
> >> 
> >> On an older Emacs without this change, it seems that the original header
> >> is written to the .overview file, which sidestep the problem that not
> >> all strings are encodable by the rfc2047 functions.
> >
> > Thanks.  I guess this From header is invalid because there's no space
> > between the "罗勇刚" and the "(Yonggang Luo)" parts?
> 
> Yes, that seems to be what's tripping the encoder.  But I'm not sure if
> proper encoding of ( or ) (as =28 or =29 using the Q encoding, or using
> the B encoding as in the raw text) is actually invalid.  RFC 2047 only
> talks about unencoded ( or ).  In contrast, encoded ( and ) are valid
> syntax at the RFC 822 layer because encoding hides them.

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.

> > Does the naïve patch below solve the problem?
> >
> > diff --git a/lisp/gnus/nnml.el b/lisp/gnus/nnml.el
> > index 40e4b9e..7aa445e 100644
> > --- a/lisp/gnus/nnml.el
> > +++ b/lisp/gnus/nnml.el
> > @@ -776,17 +776,22 @@ nnml-parse-head
> >  	(nnml--encode-headers headers)
> >  	headers))))
> >  
> > +;; RFC2047-encode Subject and From, but leave invalid headers unencoded.
> >  (defun nnml--encode-headers (headers)
> >    (let ((subject (mail-header-subject headers))
> >  	(rfc2047-encoding-type 'mime))
> >      (unless (string-match "\\`[[:ascii:]]*\\'" subject)
> > -      (setf (mail-header-subject headers)
> > -	    (mail-encode-encoded-word-string subject t))))
> > +      (let ((encoded-subject
> > +             (ignore-errors (mail-encode-encoded-word-string subject t))))
> > +        (if encoded-subject
> > +            (setf (mail-header-subject headers) encoded-subject)))))
> >    (let ((from (mail-header-from headers))
> >  	(rfc2047-encoding-type 'address-mime))
> >      (unless (string-match "\\`[[:ascii:]]*\\'" from)
> > -      (setf (mail-header-from headers)
> > -	    (rfc2047-encode-string from t)))))
> > +      (let ((encoded-from
> > +             (ignore-errors (rfc2047-encode-string from t))))
> > +        (if encoded-from
> > +            (setf (mail-header-from headers) encoded-from))))))
> >  
> >  (defun nnml-get-nov-buffer (group &optional incrementalp)
> >    (let ((buffer (gnus-get-buffer-create
> 
> Thanks!
> 
> I somehow can't reproduce the original issue.  I expect more problematic
> messages to arrive next week, though, and will report then how it goes.

Thanks.  Please do get back, even if you don't succeed in reproducing.
I tested the code by invoking the body of nnml--encode-headers
directly on the header you provided, so I'm quite sure the fix will
prevent the error and will restore Gnus to how it worked before this
change, when such problematic headers are used.  So I'd like to
install this fix on the release branch for the upcoming Emacs 29.1,
and need your feedback.

TIA