GNU bug report logs - #77866
30.0.50; message.el handling of non-ascii names in addresses

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 77866 in the body.
You can then email your comments to 77866 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Al Haji-Ali <abdo.haji.ali <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 30.0.50; message.el handling of non-ascii names in addresses
Date: Thu, 17 Apr 2025 13:54:21 +0100

This is a bit difficult for me to reproduce as a user in a clean instance of Emacs, since I am seeing it in notmuch, which uses message.el, and I don't know how to use message.el without my setup of notmuch.
However, I am sure that I've identified the reason for the bug(?) in message.el and I hope my description below is sufficient.

I have an email with a header field like this:
CC: "Blanco, Raúl" <blanco <at> test.com>

with a non-ASCII character in the name. When I call `message-send-mail`, on 29.1 I get an error
`split-string: Wrong type argument: stringp, nil`

and on 30.0.50, I get the error
`Email address can't be parsed`

The reason is that `message-send-mail` calls `mail-encode-encoded-word-buffer`, which encodes that part of the message as:

CC: "Blanco, =?utf-8?Q?Ra=C3=BAl=22?= <blanco <at> test.com>

So that the quotation marks are no longer paired, and `mail-header-parse-addresses` splits the address into two ill-formed ones.

The code below extracts the relevant function calls from `message-send-mail` for an easy check (even on 'emacs -Q'):

,----
| (require 'message)
| (let ((case-fold-search nil))
|   (with-temp-buffer
|     (insert "CC: \"Blanco, Raúl\" <blanco <at> test.com>")
|     (mail-encode-encoded-word-buffer)
|     (cl-loop
|      for addr in
|      (mail-header-parse-addresses
|       (message-fetch-field "CC")
|       t)
|      collect (cons addr (textsec-suspicious-p addr 'email-address-header)))))
`----

Message #8 received at 77866 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Al Haji-Ali <abdo.haji.ali <at> gmail.com>
Cc: 77866 <at> debbugs.gnu.org
Subject: Re: bug#77866: 30.0.50;
 message.el handling of non-ascii names in addresses
Date: Thu, 17 Apr 2025 16:19:21 +0300

> From: Al Haji-Ali <abdo.haji.ali <at> gmail.com>
> Date: Thu, 17 Apr 2025 13:54:21 +0100
> 
> 
> This is a bit difficult for me to reproduce as a user in a clean instance of Emacs, since I am seeing it in notmuch, which uses message.el, and I don't know how to use message.el without my setup of notmuch.
> However, I am sure that I've identified the reason for the bug(?) in message.el and I hope my description below is sufficient.
> 
> I have an email with a header field like this:
> CC: "Blanco, Raúl" <blanco <at> test.com>
> 
> with a non-ASCII character in the name. When I call `message-send-mail`, on 29.1 I get an error
> `split-string: Wrong type argument: stringp, nil`
> 
> and on 30.0.50, I get the error
> `Email address can't be parsed`
> 
> The reason is that `message-send-mail` calls `mail-encode-encoded-word-buffer`, which encodes that part of the message as:
> 
> CC: "Blanco, =?utf-8?Q?Ra=C3=BAl=22?= <blanco <at> test.com>
> 
> So that the quotation marks are no longer paired, and `mail-header-parse-addresses` splits the address into two ill-formed ones.

Isn't that because of the comma?  If you change the address to

  "Blanco Raúl" <blanco <at> test.com>

does the problem go away?

Message #11 received at 77866 <at> debbugs.gnu.org (full text, mbox):

From: Robert Pluim <rpluim <at> gmail.com>
To: Al Haji-Ali <abdo.haji.ali <at> gmail.com>
Cc: 77866 <at> debbugs.gnu.org
Subject: Re: bug#77866: 30.0.50; message.el handling of non-ascii names in
 addresses
Date: Thu, 17 Apr 2025 15:50:10 +0200

>>>>> On Thu, 17 Apr 2025 13:54:21 +0100, Al Haji-Ali <abdo.haji.ali <at> gmail.com> said:

    Abdo> This is a bit difficult for me to reproduce as a user in a
    Abdo> clean instance of Emacs, since I am seeing it in notmuch,
    Abdo> which uses message.el, and I don't know how to use
    Abdo> message.el without my setup of notmuch.  However, I am sure
    Abdo> that I've identified the reason for the bug(?) in message.el
    Abdo> and I hope my description below is sufficient.

    Abdo> I have an email with a header field like this:
    Abdo> CC: "Blanco, Raúl" <blanco <at> test.com>

    Abdo> with a non-ASCII character in the name. When I call
    Abdo> `message-send-mail`, on 29.1 I get an error `split-string:
    Abdo> Wrong type argument: stringp, nil`

    Abdo> and on 30.0.50, I get the error
    Abdo> `Email address can't be parsed`

    Abdo> The reason is that `message-send-mail` calls
    Abdo> `mail-encode-encoded-word-buffer`, which encodes that part
    Abdo> of the message as:

    Abdo> CC: "Blanco, =?utf-8?Q?Ra=C3=BAl=22?= <blanco <at> test.com>

    Abdo> So that the quotation marks are no longer paired, and
    Abdo> `mail-header-parse-addresses` splits the address into two
    Abdo> ill-formed ones.

Thanks for the test code, it made finding the issue easy.

The root cause of this is that `mail-encode-encoded-word-buffer' is
using the `mime' method to encode the value, instead of the
`address-mime' method. Thatʼs because youʼve written the "Cc" header
name as "CC", and the lookup for the method based on the header name
is being done case-sensitively. Patch below fixes it for me (it also
helps if you put a newline at the end of the string youʼre testing)

diff --git a/lisp/mail/rfc2047.el b/lisp/mail/rfc2047.el
index 66760a6595b..db6c0423a54 100644
--- a/lisp/mail/rfc2047.el
+++ b/lisp/mail/rfc2047.el
@@ -265,7 +265,8 @@ rfc2047-encode-message-header
 		 (if (= (length charsets) 1)
 		     (cons (mm-charset-to-coding-system (car charsets))
 			   mm-coding-system-priorities)
-		   mm-coding-system-priorities)))
+		   mm-coding-system-priorities))
+                (case-fold-search t))
 	    (while (setq elem (pop alist))
 	      (when (or (and (stringp (car elem))
 			     (looking-at (car elem)))

Robert
-- 

Message #14 received at 77866 <at> debbugs.gnu.org (full text, mbox):

From: Andreas Schwab <schwab <at> suse.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Al Haji-Ali <abdo.haji.ali <at> gmail.com>, 77866 <at> debbugs.gnu.org
Subject: Re: bug#77866: 30.0.50; message.el handling of non-ascii names in
 addresses
Date: Thu, 17 Apr 2025 15:57:27 +0200

On Apr 17 2025, Eli Zaretskii wrote:

> Isn't that because of the comma?

No, it's because of case-fold-search.

-- 
Andreas Schwab, SUSE Labs, schwab <at> suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Message #17 received at 77866 <at> debbugs.gnu.org (full text, mbox):

From: Al Haji-Ali <abdo.haji.ali <at> gmail.com>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: 77866 <at> debbugs.gnu.org
Subject: Re: bug#77866: 30.0.50; message.el handling of non-ascii names in
 addresses
Date: Thu, 17 Apr 2025 16:45:25 +0100

On 17/04/2025, Robert Pluim wrote:
> The root cause of this is that `mail-encode-encoded-word-buffer' is
> using the `mime' method to encode the value, instead of the
> `address-mime' method. Thatʼs because youʼve written the "Cc" header
> name as "CC", and the lookup for the method based on the header name
> is being done case-sensitively. Patch below fixes it for me (it also
> helps if you put a newline at the end of the string youʼre testing)

Yep, can confirm your patch fixes the issue. Thanks!

Message #20 received at 77866 <at> debbugs.gnu.org (full text, mbox):

From: Robert Pluim <rpluim <at> gmail.com>
To: Al Haji-Ali <abdo.haji.ali <at> gmail.com>
Cc: 77866 <at> debbugs.gnu.org
Subject: Re: bug#77866: 30.0.50; message.el handling of non-ascii names in
 addresses
Date: Fri, 18 Apr 2025 09:40:14 +0200

>>>>> On Thu, 17 Apr 2025 16:45:25 +0100, Al Haji-Ali <abdo.haji.ali <at> gmail.com> said:

    Abdo> On 17/04/2025, Robert Pluim wrote:
    >> The root cause of this is that `mail-encode-encoded-word-buffer' is
    >> using the `mime' method to encode the value, instead of the
    >> `address-mime' method. Thatʼs because youʼve written the "Cc" header
    >> name as "CC", and the lookup for the method based on the header name
    >> is being done case-sensitively. Patch below fixes it for me (it also
    >> helps if you put a newline at the end of the string youʼre testing)

    Abdo> Yep, can confirm your patch fixes the issue. Thanks!

Thanks for testing. Maintainers, since this bug has been around
basically forever, I guess the fix goes to master, not the release
branch?

Thanks

Robert
-- 

Message #23 received at 77866 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: abdo.haji.ali <at> gmail.com, 77866 <at> debbugs.gnu.org
Subject: Re: bug#77866: 30.0.50;
 message.el handling of non-ascii names in addresses
Date: Fri, 18 Apr 2025 14:31:56 +0300

> Cc: 77866 <at> debbugs.gnu.org
> From: Robert Pluim <rpluim <at> gmail.com>
> Date: Fri, 18 Apr 2025 09:40:14 +0200
> 
> >>>>> On Thu, 17 Apr 2025 16:45:25 +0100, Al Haji-Ali <abdo.haji.ali <at> gmail.com> said:
> 
>     Abdo> On 17/04/2025, Robert Pluim wrote:
>     >> The root cause of this is that `mail-encode-encoded-word-buffer' is
>     >> using the `mime' method to encode the value, instead of the
>     >> `address-mime' method. Thatʼs because youʼve written the "Cc" header
>     >> name as "CC", and the lookup for the method based on the header name
>     >> is being done case-sensitively. Patch below fixes it for me (it also
>     >> helps if you put a newline at the end of the string youʼre testing)
> 
>     Abdo> Yep, can confirm your patch fixes the issue. Thanks!
> 
> Thanks for testing. Maintainers, since this bug has been around
> basically forever, I guess the fix goes to master, not the release
> branch?

Yes, please.

Message #26 received at 77866 <at> debbugs.gnu.org (full text, mbox):

From: Robert Pluim <rpluim <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: abdo.haji.ali <at> gmail.com, 77866 <at> debbugs.gnu.org
Subject: Re: bug#77866: 30.0.50; message.el handling of non-ascii names in
 addresses
Date: Fri, 18 Apr 2025 17:15:23 +0200

tags 77866 fixed
close 77866 31.1
quit

>>>>> On Fri, 18 Apr 2025 14:31:56 +0300, Eli Zaretskii <eliz <at> gnu.org> said:

    >> Cc: 77866 <at> debbugs.gnu.org
    >> From: Robert Pluim <rpluim <at> gmail.com>
    >> Date: Fri, 18 Apr 2025 09:40:14 +0200
    >> 
    >> >>>>> On Thu, 17 Apr 2025 16:45:25 +0100, Al Haji-Ali <abdo.haji.ali <at> gmail.com> said:
    >> 
    Abdo> On 17/04/2025, Robert Pluim wrote:
    >> >> The root cause of this is that `mail-encode-encoded-word-buffer' is
    >> >> using the `mime' method to encode the value, instead of the
    >> >> `address-mime' method. Thatʼs because youʼve written the "Cc" header
    >> >> name as "CC", and the lookup for the method based on the header name
    >> >> is being done case-sensitively. Patch below fixes it for me (it also
    >> >> helps if you put a newline at the end of the string youʼre testing)
    >> 
    Abdo> Yep, can confirm your patch fixes the issue. Thanks!
    >> 
    >> Thanks for testing. Maintainers, since this bug has been around
    >> basically forever, I guess the fix goes to master, not the release
    >> branch?

    Eli> Yes, please.

Robert
-- 

Pushed to master.

7d886f214e1 2025-04-18T15:53:13+02:00 "Match mail headers case-insensitively when encoding"
https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=7d886f214e165d84d3fdbe14b3766d9e88056529

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.