From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: "Rainer Gemulla" Newsgroups: gmane.emacs.bugs Subject: bug#39884: 27.0.50; Emacs may destroy outgoing email messages during sending Date: Tue, 03 Mar 2020 15:36:37 +0000 Message-ID: Reply-To: Rainer Gemulla Mime-Version: 1.0 Content-Type: multipart/signed; boundary="------=_MB0BE8C248-8358-4AA5-8CC8-B74AA9D2AEC7"; protocol="application/pgp-signature"; micalg=SHA-256 Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="28512"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: eM_Client/7.2.35595.0 To: 39884@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Mar 03 16:37:41 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1j99c4-0007KX-O5 for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 03 Mar 2020 16:37:40 +0100 Original-Received: from localhost ([::1]:49126 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j99c3-0007Sy-GJ for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 03 Mar 2020 10:37:39 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47321) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j99bX-0007Mb-59 for bug-gnu-emacs@gnu.org; Tue, 03 Mar 2020 10:37:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j99bS-0002pc-Lk for bug-gnu-emacs@gnu.org; Tue, 03 Mar 2020 10:37:07 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:33889) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1j99bS-0002pY-GQ for bug-gnu-emacs@gnu.org; Tue, 03 Mar 2020 10:37:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1j99bS-000899-DP for bug-gnu-emacs@gnu.org; Tue, 03 Mar 2020 10:37:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: "Rainer Gemulla" Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 03 Mar 2020 15:37:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 39884 X-GNU-PR-Package: emacs X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Original-Received: via spool by submit@debbugs.gnu.org id=B.158324981431299 (code B ref -1); Tue, 03 Mar 2020 15:37:02 +0000 Original-Received: (at submit) by debbugs.gnu.org; 3 Mar 2020 15:36:54 +0000 Original-Received: from localhost ([127.0.0.1]:39862 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1j99bJ-00088l-FP for submit@debbugs.gnu.org; Tue, 03 Mar 2020 10:36:53 -0500 Original-Received: from lists.gnu.org ([209.51.188.17]:44607) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1j99bI-00088d-2E for submit@debbugs.gnu.org; Tue, 03 Mar 2020 10:36:52 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47302) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j99bG-0006zS-6r for bug-gnu-emacs@gnu.org; Tue, 03 Mar 2020 10:36:51 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j99bE-0002nO-7y for bug-gnu-emacs@gnu.org; Tue, 03 Mar 2020 10:36:50 -0500 Original-Received: from mout.gmx.net ([212.227.15.18]:36875) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1j99bD-0002mO-OW for bug-gnu-emacs@gnu.org; Tue, 03 Mar 2020 10:36:48 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1583249805; bh=kS1OLcBr35nfMe2SqqNONrYEwBcjg3/186QzgygRV50=; h=X-UI-Sender-Class:From:To:Subject:Date:Reply-To; b=GWhB4wcy/KquWuv9Hz5c91gUgt4IbUJ2phhzVgbWpFB/CMohmUxT+kWLBk9Apkfoa QzbBybHekc/UeKUOmTkepv2xICjQljxnZ6KMgUNLOa7KbfY5P3ZiVQAgPqD/tkVDbY vvfvosNx0RjUFMxV3YVuAl+8i++U7xPo67wegdcY= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from [134.155.85.75] ([134.155.85.75]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MKsjH-1ioSLg1sQn-00LIEB for ; Tue, 03 Mar 2020 16:36:45 +0100 X-Provags-ID: V03:K1:Uk2N3u8v/XFH7Zoz2UU0PMxeIIXa7DD/La5m71O5FgGCVLFiEIu 3xBV8Jz0NojPSYy6lizkDTK+fobaqdbLf+Va70j95WPbZdQ2WaDj0yeOQqS6F4/2pVQwcAX 9kg+9gxEXMAFjKeNMGr3/En6BD7vue/NqGlF2pIVh+8u/gJ2uak3H841iipLsi4c9iT41tE CpcvTPDhyhRpeT3m870WA== X-UI-Out-Filterresults: notjunk:1;V03:K0:/dPPBTpDXm4=:RH/z6qdZt2X6xC2dIMGM5F FGFu9lsLOfAY5yAXT0/XGeosSptDRyQVmKlIxiS5vtgnOomDpzrro0/H0gqBpj2Hrut1dZa3u 6fhAaZW4+HtIYkPzhV+ulIBnTOozQctNtI45XPHW+OpdTwhpveXP/ROnicfj3Sn1FDWpdS1RX 0alRA+7DqMOawDypnjbG/AUgVOwjqT4lVLagi1Pyr/Gt3yvJkpCz72TUkXQ21HUnwl2V62Xj7 jL4BwumZNu2UoX45gcFlljjVm57rLec+KBFO3FMExV9yDuNTR51kB7RKbMJc/9lw9N+R6JIGe WLORDgCIahfMTU+in4k1nI/h4sdigkeU8WVnlR6OSy8EqAXrK0ji+OYbGI51UCzC/9is6kIGD ta0hdyxFKj5a9UN/YwlLV2J+qXZYCCCb/PF8vXVtKzJoIgvb51semmQiirCdVnhv+DEvp28L8 BTmhzaWp3azU3t8RXe/TabAnGz8Mjds1/nNbMv3jFmd6Kgx6MIC3mGyRGvjjk4jOs6wOgT/x0 v2CmvW52JXK3bToXZQnA4ynIJf/yQznIgpJdoFmZwiWvK+zaB1TObDq5x5i7aPiTzvNR47Lxg mCyjfnmFG6Yj2+gTH26pGAjThvzV69/rxqjp83Q1lKAIlQSR1objdvqBxJhFmexk34QoZjc/j csoQnl6VHwNBN6wReDNM3PY/ZmCw0HiPuuxmgmYrU17sm36IXsYc/+Jrc0Wir0KmU++KQz9BU AGUgUa7sw5/Y0eOYOJZIiai/hA5DmdwaBYwis7EucB5aOWlhLzQNlwOM/rVAOTtJhqD0GqEo X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:176798 Archived-At: --------=_MB0BE8C248-8358-4AA5-8CC8-B74AA9D2AEC7 Content-Type: multipart/alternative; boundary="------=_MBC8DD49D3-5B1B-4C29-8C99-FAAFE030DDF1" --------=_MBC8DD49D3-5B1B-4C29-8C99-FAAFE030DDF1 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable I am composing emails using Emacs message mode. Shortly after switching=20 to Emacs 27, some people complained to me that they could not read some=20 of emails I sent them. I checked in my local email archive: even my=20 archived emails were not readable with Emacs any more. This is a major=20 bug, and for this reason I switched back to Emacs 26. It is my current=20 understanding that the bug occurs when (1) forwarding messages and (2)=20 signing the forwarded messages using GPG. So not everyone seems to be=20 affected. Nevertheless, I experienced this bug on multiple machines (in=20 fact, on all machines that I tried). The rest of this email explains where the bug arises and how to=20 reproduce it. Before sending an email, Emacs converts the email text to MIME. This=20 conversion process is performed by a function called mml-to-mime. I=20 found that this function (or it's interaction with signing) is=20 responsible for Emacs 27 destroying emails: the produced MIME can be=20 invalid. This happens mostly when there are multiple mml parts in the=20 original email, which is the case when forwarding an email. After some playing around, I found a way to reproduce the bug. It's=20 somewhat painful, but the error consistently arises. I first list the=20 steps, then the original email, then its correct MIME encoding, and the=20 incorrect MIME encoding that Emacs may produce. Note that step 3+4=20 encode the message for the first time (all fine), steps 5-7 add signing,=20 steps 8-9 encode the orginal message again (without signing, now=20 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=3Dpgpmime mode=3Dsign>" at start of= =20 message (after line "--text follows this line--"). This makes Emacs try=20 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=20 wrong) I tried to track down the bug further and found this piece of code in=20 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=20 variable is not set to the list mentioned in the statement (seriously!).=20 In my case, it had value 'Content-Type: multipart/alternative;=20 boundary=3D"=3D=3D=3D=3D-=3D-=3D"' right afterwards (as in the incorrect re= sult=20 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=3Dmessage/rfc822 disposition=3Dinline> <#multipart type=3Dalternative> <#part type=3Dtext/plain charset=3D"UTF-8" disposition=3Dinline nofile=3Dye= s> Some text. <#part type=3Dtext/html charset=3D"UTF-8" nofile=3Dyes> Some more text. <#/multipart> <#/mml> CORRECT RESULT From: a b.ce To: c d.de Subject: Test MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=3D"=3D-=3D-=3D" --text follows this line-- --=3D-=3D-=3D Content-Type: text/plain Test --=3D-=3D-=3D Content-Type: message/rfc822 Content-Disposition: inline --=3D=3D=3D=3D-=3D-=3D Content-Disposition: inline MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=3D"=3D=3D=3D=3D-=3D-=3D" Some text. --=3D=3D=3D=3D-=3D-=3D Content-Type: text/html; charset=3Dutf-8 Some more text. --=3D=3D=3D=3D-=3D-=3D-- --=3D-=3D-=3D-- INCORRECT RESULT AFTER STEP 9 From: a b.ce To: c d.de Subject: Test MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=3D"=3D-=3D-=3D" --text follows this line-- --=3D-=3D-=3D Content-Type: multipart/alternative; boundary=3D"=3D=3D=3D=3D-=3D-=3D" Content-Transfer-Encoding: base64 VGV4dAoK --=3D-=3D-=3D Content-Type: message/rfc822 Content-Disposition: inline --=3D=3D=3D=3D-=3D-=3D Content-Disposition: inline MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=3D"=3D=3D=3D=3D-=3D-=3D" Some text. --=3D=3D=3D=3D-=3D-=3D Content-Type: text/html; charset=3Dutf-8 Some more text. --=3D=3D=3D=3D-=3D-=3D-- --=3D-=3D-=3D-- --------=_MBC8DD49D3-5B1B-4C29-8C99-FAAFE030DDF1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I am composin= g emails using Emacs message mode. Shortly after switching to Emacs 27, som= e people complained to me that they could not read some of emails I sent th= em. I checked in my local email archive: even my archived emails were not r= eadable with Emacs any more. This is a major bug, and for this reason I swi= tched back to Emacs 26.=C2=A0It is my current understanding that the bug oc= curs when (1) forwarding messages and (2) signing the forwarded messages us= ing 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 ema= il explains where the bug arises and how to reproduce it.

<= /div>
Before sending an email, Emacs conv= erts the email text to MIME. This conversion process is performed by a func= tion called mml-to-mime. I found that this function (or it's interaction wi= th signing) is responsible for Emacs 27 destroying emails: the produced MIM= E can be invalid. This happens mostly when there are multiple mml parts in= the original email, which is the case when forwarding an email.
<= /div>

After some playing around, I found a way to reproduce the bug. It's some= what painful, but the error consistently arises. I first list the steps, th= en the original email, then its correct MIME encoding, and the incorrect MI= ME encoding that Emacs may produce. Note that step 3+4 encode the message f= or the first time (all fine), steps 5-7 add signing, steps 8-9 encode the o= rginal message again (without signing, now broken).

1. Run: emac= s -Q

2. M-x message-mode
3. Clear scratch buffer= , paste original message=C2=A0
4. M-: (mml-to-mime)=C2=A0--> gives= CORRECT result

5. Clear scratch buffer, paste or= iginal message=C2=A0
6. Insert a new line "<#secure method=3Dp= gpmime mode=3Dsign>" at start of message (after line "--text follows thi= s line--"). This makes Emacs try to sign the mail.
7. M-: (mml-to-mime= )=C2=A0--> throws (expected) signer name error

=
8. Clear scratch buffer, paste original message=C2=A0
9. M-: (mml-to-mime)=C2=A0
=C2=A0 = --> broken result (first Content-Type after "text follows..." is wrong)=

I tried to track down the bug further and found this piece of cod= e in mml-parse-1, line 284:

(setq tag (list 'part '(type . "text= /plain"))
=C2=A0 =C2=A0=C2=A0 =C2=A0no-markup-p t
=C2=A0 =C2=A0= =C2=A0 =C2=A0warn t)

During step 9, this statement is executed,= but afterwards, the tag variable is not set to the list mentioned in the st= atement (seriously!). In my case, it had value 'Content-Type: multipart/alt= ernative; boundary=3D"=3D=3D=3D=3D-=3D-=3D"' right afterwards (as in the in= correct result below). At this point I gave up, looks like a deeper problem= .


ORIGINAL MESSA= GE
From: <= a href=3D"mailto:a@b.ce">a@b.ce
To: c@d.= de
Subject: Test
--text follows this line--
Test
<#mml type=3Dmessage/rfc822 disposition=3Dinline>
<#multi= part type=3Dalternative>
<#part type=3Dtext/plain charset=3D"UTF= -8" disposition=3Dinline nofile=3Dyes>
Some text.
<#part ty= pe=3Dtext/html charset=3D"UTF-8" nofile=3Dyes>
Some more text.
<#/multipart>
<#/mml>


<= div>
CORRECT RESULT
From: a <at> b.ce
To: c <at> d.de
Subject= : Test
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary= =3D"=3D-=3D-=3D"
--text follows this line--
--=3D-=3D-=3D
Content-Type: text/plain

Test

<= /font>
--=3D-=3D-=3D
Content-Type: message/rfc822
Content-Di= sposition: inline

--=3D=3D=3D=3D-=3D-=3D
Content-Dispositio= n: inline
MIME-Version: 1.0
Content-Type: multipart/alternative;= boundary=3D"=3D=3D=3D=3D-=3D-=3D"

Some text.

--=3D=3D= =3D=3D-=3D-=3D
Content-Type: text/html; charset=3Dutf-8

Som= e more text.

--=3D=3D=3D=3D-=3D-=3D--

--=3D-=3D-=3D--= 


INCORRECT RESULT AFTER ST=
EP 9
From: a <at> b.ce
To: c <at> d.de
Subject: Test
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=3D"=3D-=3D-=3D"
--text follows this line--
--=3D-=3D-=3D
Content-Type: multipart/alternative; boundary=3D"=3D=3D=3D=3D-=3D-=3D"
Content-Transfer-Encoding: base64

VGV4dAoK
--=3D-=3D-=3D
Content-Type: message/rfc822
Content-Disposition: inline

--=3D=3D=3D=3D-=3D-=3D
Content-Disposition: inline
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary=3D"=3D=3D=3D=3D-=3D-=3D"

Some text.

--=3D=3D=3D=3D-=3D-=3D
Content-Type: text/html; charset=3Dutf-8

Some more text.

--=3D=3D=3D=3D-=3D-=3D--

--=3D-=3D-=3D--
--------=_MBC8DD49D3-5B1B-4C29-8C99-FAAFE030DDF1-- --------=_MB0BE8C248-8358-4AA5-8CC8-B74AA9D2AEC7 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: BCPG C# v1.8.1.0 iQI+BAABCAAoBQJeXnmKIRxSYWluZXIgR2VtdWxsYSA8cmdlbXVsbGFAZ214LmRl PgAKCRB0pw6+EqKRW8KaEACeLdMW3wF6W77D2dki4IeSP+en6Ykfyv7cQ0mLuVHU 4eEdsFx+Pa8edewh8ADWHS9XZ+QvYxQpVlpD3rNyLPeRgsCYbC0n+hqEnbxOEwzC eXCWlYHDLDE14lKXzNgPRsCpJFD2R7B21sxbG2QWUvX9ZLAB25qQanG2rLbohv7k 7xRI9PB2BuPD4UEu1aipQ0EBSxV1j52kYTx2rwIeC/F2iVaOR/nSs4N3jI3gRdv4 +KBl3OnFdy6nIHUl5iiW2OoLCvjW1KrEGbw1g3TFvZ+VgpW7IrJKnrVoVnsg2QUi n9LOIsbrQD7bnpp1tG8Ln3qa7MbSENxH34TaynNd4RrJcG3Q2f0JFKWhaxT9PD+w A0OarDNINqsqpN/sfwwwlg/0gorvvjBHRGdKIWxKGZyeUvTXoR5S373fes3sXbZT vTg5bdAXVVDVfBuU3OB7AfZcQ8j2wCnbeJMHMzutSyU/BDkJ/1z99x/OmH6JVOdo 3c0xBU1k09YAq29HdVs2pWpDoLo0rpPqZyEa9HM6DfymPrr3jAbO2QJYUpHAAJvY uRShsKER6aRBPqfAKpp/GOhAoD68fomOyM5D5Y70++YXBFTaJuSaCIqLDmTmDw1p 1MRE3Vw5tZBoM/x/M29nez/UqVemrHdVgBLpzYC7h5cUObO4QG8J/NPWngXRqixI HQ== =ufqc -----END PGP SIGNATURE----- --------=_MB0BE8C248-8358-4AA5-8CC8-B74AA9D2AEC7--