From: "Rainer Gemulla" <rgemulla@gmx.de>
To: 39884@debbugs.gnu.org
Subject: bug#39884: 27.0.50; Emacs may destroy outgoing email messages during sending
Date: Tue, 03 Mar 2020 15:36:37 +0000 [thread overview]
Message-ID: <em9d82ef94-40d3-4ba9-b274-1129039029d0@gemma> (raw)
[-- Attachment #1.1: Type: text/plain, Size: 4120 bytes --]
I am composing emails using Emacs message mode. Shortly after switching
to Emacs 27, some people complained to me that they could not read some
of emails I sent them. I checked in my local email archive: even my
archived emails were not readable with Emacs any more. This is a major
bug, and for this reason I switched back to Emacs 26. It is my current
understanding that the bug occurs when (1) forwarding messages and (2)
signing the forwarded messages using GPG. So not everyone seems to be
affected. Nevertheless, I experienced this bug on multiple machines (in
fact, on all machines that I tried).
The rest of this email explains where the bug arises and how to
reproduce it.
Before sending an email, Emacs converts the email text to MIME. This
conversion process is performed by a function called mml-to-mime. I
found that this function (or it's interaction with signing) is
responsible for Emacs 27 destroying emails: the produced MIME can be
invalid. This happens mostly when there are multiple mml parts in the
original email, which is the case when forwarding an email.
After some playing around, I found a way to reproduce the bug. It's
somewhat painful, but the error consistently arises. I first list the
steps, then the original email, then its correct MIME encoding, and the
incorrect MIME encoding that Emacs may produce. Note that step 3+4
encode the message for the first time (all fine), steps 5-7 add signing,
steps 8-9 encode the orginal message again (without signing, now
broken).
1. Run: emacs -Q
2. M-x message-mode
3. Clear scratch buffer, paste original message
4. M-: (mml-to-mime) --> gives CORRECT result
5. Clear scratch buffer, paste original message
6. Insert a new line "<#secure method=pgpmime mode=sign>" at start of
message (after line "--text follows this line--"). This makes Emacs try
to sign the mail.
7. M-: (mml-to-mime) --> throws (expected) signer name error
8. Clear scratch buffer, paste original message
9. M-: (mml-to-mime)
--> broken result (first Content-Type after "text follows..." is
wrong)
I tried to track down the bug further and found this piece of code in
mml-parse-1, line 284:
(setq tag (list 'part '(type . "text/plain"))
no-markup-p t
warn t)
During step 9, this statement is executed, but afterwards, the tag
variable is not set to the list mentioned in the statement (seriously!).
In my case, it had value 'Content-Type: multipart/alternative;
boundary="====-=-="' right afterwards (as in the incorrect result
below). At this point I gave up, looks like a deeper problem.
ORIGINAL MESSAGE
From: a@b.ce
To: c@d.de
Subject: Test
--text follows this line--
Test
<#mml type=message/rfc822 disposition=inline>
<#multipart type=alternative>
<#part type=text/plain charset="UTF-8" disposition=inline nofile=yes>
Some text.
<#part type=text/html charset="UTF-8" nofile=yes>
Some more text.
<#/multipart>
<#/mml>
CORRECT RESULT
From: a <at> b.ce
To: c <at> d.de
Subject: Test
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
--text follows this line--
--=-=-=
Content-Type: text/plain
Test
--=-=-=
Content-Type: message/rfc822
Content-Disposition: inline
--====-=-=
Content-Disposition: inline
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="====-=-="
Some text.
--====-=-=
Content-Type: text/html; charset=utf-8
Some more text.
--====-=-=--
--=-=-=--
INCORRECT RESULT AFTER STEP 9
From: a <at> b.ce
To: c <at> d.de
Subject: Test
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
--text follows this line--
--=-=-=
Content-Type: multipart/alternative; boundary="====-=-="
Content-Transfer-Encoding: base64
VGV4dAoK
--=-=-=
Content-Type: message/rfc822
Content-Disposition: inline
--====-=-=
Content-Disposition: inline
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="====-=-="
Some text.
--====-=-=
Content-Type: text/html; charset=utf-8
Some more text.
--====-=-=--
--=-=-=--
[-- Attachment #1.2: Type: text/html, Size: 9420 bytes --]
[-- Attachment #2: Type: application/pgp-signature, Size: 876 bytes --]
next reply other threads:[~2020-03-03 15:36 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-03 15:36 Rainer Gemulla [this message]
2020-04-15 7:51 ` bug#39884: Simple fix Rainer Gemulla
2020-04-15 12:24 ` bug#39884: 27.0.50; Emacs may destroy outgoing email messages during sending Noam Postavsky
2020-04-15 12:57 ` Rainer Gemulla
2020-04-15 13:11 ` Noam Postavsky
2020-04-17 0:30 ` Noam Postavsky
2020-04-17 7:48 ` Rainer Gemulla
2020-04-17 7:49 ` Rainer Gemulla
2020-04-17 9:54 ` Eli Zaretskii
2020-04-25 13:59 ` Noam Postavsky
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=em9d82ef94-40d3-4ba9-b274-1129039029d0@gemma \
--to=rgemulla@gmx.de \
--cc=39884@debbugs.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).