* bug#64296: 30.0.50; problem with gnus-summary-resend-message
@ 2023-06-26 8:24 Peter Münster
2023-06-27 7:10 ` Andrew Cohen
0 siblings, 1 reply; 7+ messages in thread
From: Peter Münster @ 2023-06-26 8:24 UTC (permalink / raw)
To: 64296
[-- Attachment #1: Type: text/plain, Size: 992 bytes --]
Hi,
When using "gnus-summary-resend-message" (keypress "SDr") on a message
with such a header: "To: undisclosed-recipients:;" , the function stops
with an error:
--8<---------------cut here---------------start------------->8---
Debugger entered--Lisp error: (wrong-type-argument stringp nil)
string-match("@" nil 0)
split-string(nil "@")
textsec-email-address-suspicious-p(nil)
textsec-email-address-header-suspicious-p("undisclosed-recipients:;")
textsec-suspicious-p("undisclosed-recipients:;" email-address-header)
message-send-mail()
message-resend("email@address.com")
gnus-summary-resend-message("email@address.com" nil)
funcall-interactively(gnus-summary-resend-message "email@address.com" nil)
call-interactively(gnus-summary-resend-message nil nil)
command-execute(gnus-summary-resend-message)
--8<---------------cut here---------------end--------------->8---
How could this be fixed please?
TIA for any help,
--
Peter
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 211 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#64296: 30.0.50; problem with gnus-summary-resend-message
2023-06-26 8:24 bug#64296: 30.0.50; problem with gnus-summary-resend-message Peter Münster
@ 2023-06-27 7:10 ` Andrew Cohen
2023-06-27 8:04 ` Peter Münster
0 siblings, 1 reply; 7+ messages in thread
From: Andrew Cohen @ 2023-06-27 7:10 UTC (permalink / raw)
To: Peter Münster; +Cc: 64296
>>>>> "PM" == Peter Münster <pm@a16n.net> writes:
PM> Hi, When using "gnus-summary-resend-message" (keypress "SDr") on
PM> a message with such a header: "To: undisclosed-recipients:;" ,
PM> the function stops with an error:
PM> Debugger entered--Lisp error: (wrong-type-argument stringp nil)
PM> string-match("@" nil 0) split-string(nil "@")
PM> textsec-email-address-suspicious-p(nil)
PM> textsec-email-address-header-suspicious-p("undisclosed-recipients:;")
PM> textsec-suspicious-p("undisclosed-recipients:;"
PM> email-address-header) message-send-mail()
PM> message-resend("email@address.com")
PM> gnus-summary-resend-message("email@address.com" nil)
PM> funcall-interactively(gnus-summary-resend-message
PM> "email@address.com" nil)
PM> call-interactively(gnus-summary-resend-message nil nil)
PM> command-execute(gnus-summary-resend-message)
PM> How could this be fixed please?
The problem is in the parsing of email headers. According to RFC5322 the
"To", "Cc", and "Bcc" headers may contain a comma-separated list of
addresses, where an address is either a mailbox or a group. A group is
an identifier followed by a list of mailboxes (this list is sandwiched
between a colon and a semi-colon). For example in your case the
identifier is "undisclosed-recipients" and the list of mailboxes is
empty.
It appears that this group syntax for these headers is simply not
implemented. I have tried a quick hack to get this working. Can you
replace `ietf-drums-parse-addresses' with the function definition below
and see if that works? I have only done some very rudimentary testing
so it is possible that it fails to properly parse some existing headers.
#+begin_src emacs-lisp
(defun ietf-drums-parse-addresses (string &optional rawp)
"Parse STRING and return a list of MAILBOX / DISPLAY-NAME pairs.
If RAWP, don't actually parse the addresses, but instead return
a list of address strings."
(if (null string)
nil
(with-temp-buffer
(ietf-drums-init string)
(let ((beg (point))
pairs c address)
(while (not (eobp))
(setq c (char-after))
(cond
((eq c '?:)
(setq beg (1+ (point)))
(skip-chars-forward "^;")
(when-let ((address
(condition-case nil
(ietf-drums-parse-addresses
(buffer-substring beg (point)) rawp)
(error nil))))
(if (listp address)
(setq pairs (append address pairs))
(push address pairs)))
(forward-char 1)
(setq beg (point)))
((memq c '(?\" ?< ?\())
(condition-case nil
(forward-sexp 1)
(error
(skip-chars-forward "^,"))))
((eq c ?,)
(setq address
(if rawp
(buffer-substring beg (point))
(condition-case nil
(ietf-drums-parse-address
(buffer-substring beg (point)))
(error nil))))
(when (or (consp address) (and (stringp address) (< 0 (length address))))
(push address pairs))
(forward-char 1)
(setq beg (point)))
(t
(forward-char 1))))
(setq address
(if rawp
(buffer-substring beg (point))
(condition-case nil
(ietf-drums-parse-address
(buffer-substring beg (point)))
(error nil))))
(when (or (consp address) (and (stringp address) (< 0 (length address))))
(push address pairs))
(nreverse pairs)))))
#+end_src
--
Andrew Cohen
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#64296: 30.0.50; problem with gnus-summary-resend-message
2023-06-27 7:10 ` Andrew Cohen
@ 2023-06-27 8:04 ` Peter Münster
2023-06-27 8:31 ` Peter Münster
0 siblings, 1 reply; 7+ messages in thread
From: Peter Münster @ 2023-06-27 8:04 UTC (permalink / raw)
To: 64296
On Tue, Jun 27 2023, Andrew Cohen wrote:
> Can you replace `ietf-drums-parse-addresses' with the function
> definition below and see if that works?
Yes, it works. Thanks!
--
Peter
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#64296: 30.0.50; problem with gnus-summary-resend-message
2023-06-27 8:04 ` Peter Münster
@ 2023-06-27 8:31 ` Peter Münster
2023-06-27 9:18 ` Andrew Cohen
0 siblings, 1 reply; 7+ messages in thread
From: Peter Münster @ 2023-06-27 8:31 UTC (permalink / raw)
To: 64296
On Tue, Jun 27 2023, Peter Münster wrote:
> Yes, it works. Thanks!
Sorry, no, there is a new problem. When displaying a message with such a
header:
--8<---------------cut here---------------start------------->8---
In-Reply-To: <87o7p2b7w5.fsf@a16n.net> ("Peter Münster"'s
message of "Thu, 09
Mar 2023 10:18:02 +0100")
--8<---------------cut here---------------end--------------->8---
I get this error: "cond: End of buffer"
And the message is displayed in it's raw format...
--
Peter
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#64296: 30.0.50; problem with gnus-summary-resend-message
2023-06-27 8:31 ` Peter Münster
@ 2023-06-27 9:18 ` Andrew Cohen
2023-06-27 13:06 ` Andrew Cohen
0 siblings, 1 reply; 7+ messages in thread
From: Andrew Cohen @ 2023-06-27 9:18 UTC (permalink / raw)
To: Peter Münster; +Cc: 64296
>>>>> "PM" == Peter Münster <pm@a16n.net> writes:
PM> On Tue, Jun 27 2023, Peter Münster wrote:
>> Yes, it works. Thanks!
PM> Sorry, no, there is a new problem. When displaying a message
PM> with such a header:
PM> In-Reply-To: <87o7p2b7w5.fsf@a16n.net> ("Peter Münster"'s
PM> message of "Thu, 09 Mar 2023 10:18:02 +0100")
PM> I get this error: "cond: End of buffer"
PM> And the message is displayed in it's raw format...
Hmm, OK. First can you confirm that using the original
ietf-drums-parse-addresses doesn't encounter this problem (I assume
thats the case, but best to be sure).
In the meantime I'll see if I can reproduce the problem to figure out
what is happening (if you can provide a backtrace that might also help).
Best,
Andy
--
Andrew Cohen
Director, HKUST Jockey Club Institute for Advanced Study
Lam Woo Foundation Professor and Chair Professor of Physics
The Hong Kong University of Science and Technology
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#64296: 30.0.50; problem with gnus-summary-resend-message
2023-06-27 9:18 ` Andrew Cohen
@ 2023-06-27 13:06 ` Andrew Cohen
2023-07-03 8:44 ` Peter Münster
0 siblings, 1 reply; 7+ messages in thread
From: Andrew Cohen @ 2023-06-27 13:06 UTC (permalink / raw)
To: Peter Münster; +Cc: 64296
>>>>> "AC" == Andrew Cohen <acohen@ust.hk> writes:
>>>>> "PM" == Peter Münster <pm@a16n.net> writes:
PM> On Tue, Jun 27 2023, Peter Münster wrote:
>>> Yes, it works. Thanks!
PM> Sorry, no, there is a new problem. When displaying a message
PM> with such a header:
PM> In-Reply-To: <87o7p2b7w5.fsf@a16n.net> ("Peter Münster"'s
PM> message of "Thu, 09 Mar 2023 10:18:02 +0100")
PM> I get this error: "cond: End of buffer"
PM> And the message is displayed in it's raw format...
[...]
AC> In the meantime I'll see if I can reproduce the problem to
AC> figure out what is happening (if you can provide a backtrace
AC> that might also help).
The problem is the presence of the ":" in the parenthetical comment
following the mailbox. If I am reading the spec correctly this is not
allowed (the ":" and ";" are special characters). But it is relatively
common nonetheless.
I think the following version should take care of it. Try it for awhile
and see if any other problems arise. If not I'll push it to master.
#+begin_src emacs-lisp
(defun ietf-drums-parse-addresses (string &optional rawp)
"Parse STRING and return a list of MAILBOX / DISPLAY-NAME pairs.
If RAWP, don't actually parse the addresses, but instead return
a list of address strings."
(if (null string)
nil
(with-temp-buffer
(ietf-drums-init string)
(let ((beg (point))
pairs c address)
(while (not (eobp))
(setq c (char-after))
(cond
((eq c '?:)
(setq beg (1+ (point)))
(skip-chars-forward "^;")
(when-let ((address
(condition-case nil
(ietf-drums-parse-addresses
(buffer-substring beg (point)) rawp)
(error nil))))
(if (listp address)
(setq pairs (append address pairs))
(push address pairs)))
(condition-case nil
(forward-char 1)
(error nil))
(setq beg (point)))
((memq c '(?\" ?< ?\())
(condition-case nil
(forward-sexp 1)
(error
(skip-chars-forward "^,"))))
((eq c ?,)
(setq address
(if rawp
(buffer-substring beg (point))
(condition-case nil
(ietf-drums-parse-address
(buffer-substring beg (point)))
(error nil))))
(when (or (consp address)
(and (stringp address) (< 0 (length address))))
(push address pairs))
(forward-char 1)
(setq beg (point)))
((not (eobp))
(forward-char 1))))
(setq address
(if rawp
(buffer-substring beg (point))
(condition-case nil
(ietf-drums-parse-address
(buffer-substring beg (point)))
(error nil))))
(when (or (consp address)
(and (stringp address) (< 0 (length address))))
(push address pairs))
(nreverse pairs)))))
#+end_src
--
Andrew Cohen
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2023-07-03 8:44 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-06-26 8:24 bug#64296: 30.0.50; problem with gnus-summary-resend-message Peter Münster
2023-06-27 7:10 ` Andrew Cohen
2023-06-27 8:04 ` Peter Münster
2023-06-27 8:31 ` Peter Münster
2023-06-27 9:18 ` Andrew Cohen
2023-06-27 13:06 ` Andrew Cohen
2023-07-03 8:44 ` Peter Münster
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).