GNU bug report logs - #26918
25.2; rmail edit corrupts mail if content-type header not displayed

Previous Next

Package: emacs;

Reported by: Ken Olum <kdo <at> cosmos.phy.tufts.edu>

Date: Sun, 14 May 2017 01:40:01 UTC

Severity: normal

Found in version 25.2

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

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

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

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#26918; Package emacs. (Sun, 14 May 2017 01:40:01 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ken Olum <kdo <at> cosmos.phy.tufts.edu>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Sun, 14 May 2017 01:40:02 GMT) Full text and rfc822 format available.

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

From: Ken Olum <kdo <at> cosmos.phy.tufts.edu>
To: bug-gnu-emacs <at> gnu.org
Subject: 25.2; rmail edit corrupts mail if content-type header not displayed
Date: Sat, 13 May 2017 21:38:52 -0400
[Message part 1 (text/plain, inline)]
If you have a message in rmail which is in MIME format with base64
encoding and consists only of a single text/plain part, and if you do
not display the "Content-Type" header (e.g. by having it in
rmail-ignored-headers), the message will get corrupted.  The problem is
this: under the circumstances above, rmail-edit-current-message allows
you to edit your view of the message (which is good, since you don't
want to edit the base64).  But when it goes to reencode the message, it
looks in the headers it gave you to edit and doesn't see the
Content-Type.  Later it does see the Content-Type in the original
headers, and the result is massive confusion.  In some circumstances it
corrupts only that message, but in others it corrupts your mail file by
merging this message with the one before.

To reproduce:

1. emacs -Q

2. Visit attached rmail-test file

3. M-x rmail-mode

4. Set variable rmail-ignored-headers to ignore "Content-Type", e.g., by
editing it in customization system.

5. Push "t" twice so that previous change takes effect.  Verify that
Content-Type is not displayed.

6. Push "e" to edit message.  Insert a character at the end.  C-c C-c to
finish.

7. Observe corrupted message on screen

I'm not sure how to reproduce the situation where it corrupts your mail
file, but it has happened to me several times.

I can provide a fix for this bug if we agree on the right strategy.

                                        Ken

In GNU Emacs 25.2.1 (x86_64-unknown-linux-gnu, X toolkit, Xaw scroll bars)
 of 2017-05-13 built on neptune
Windowing system distributor 'The X.Org Foundation', version 11.0.11501000
System Description:	Ubuntu 14.04.5 LTS

Configured features:
XPM JPEG TIFF GIF PNG SOUND NOTIFY ZLIB TOOLKIT_SCROLL_BARS LUCID X11

Important settings:
  value of $LC_ALL: C
  value of $LANG: en_US.UTF-8
  locale-coding-system: nil

Major mode: Lisp Interaction

Minor modes in effect:
  shell-dirtrack-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t

Recent messages:
Loading /home/kdo/emacs-init.el (source)...done
For information about GNU Emacs and the GNU system, type C-h C-a.

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message dired format-spec rfc822 mml
mml-sec password-cache epg epg-config gnus-util mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail
rmail rfc2047 rfc2045 ietf-drums mm-util help-fns help-mode easymenu
mail-prsvr mail-utils shell pcomplete comint ansi-color ring cl-macs cl
gv cl-loaddefs pcase cl-lib warnings time-date mule-util tooltip eldoc
electric uniquify ediff-hook vc-hooks lisp-float-type mwheel x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list newcomment elisp-mode lisp-mode prog-mode register page
menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core frame cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese charscript case-table epa-hook jka-cmpr-hook help
simple abbrev minibuffer cl-preloaded nadvice loaddefs button faces
cus-face macroexp files text-properties overlay sha1 md5 base64 format
env code-pages mule custom widget hashtable-print-readable backquote
inotify dynamic-setting x-toolkit x multi-tty make-network-process
emacs)

Memory information:
((conses 16 95255 6032)
 (symbols 48 20728 0)
 (miscs 40 52 117)
 (strings 32 18042 4867)
 (string-bytes 1 512076)
 (vectors 16 13426)
 (vector-slots 8 443268 2725)
 (floats 8 169 6)
 (intervals 56 189 92)
 (buffers 976 18)
 (heap 1024 39178 767))

[rmail-test (application/octet-stream, attachment)]

Added indication that bug 26918 blocks24655 Request was from Glenn Morris <rgm <at> gnu.org> to control <at> debbugs.gnu.org. (Mon, 15 May 2017 00:27:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#26918; Package emacs. (Mon, 05 Jun 2017 21:18:02 GMT) Full text and rfc822 format available.

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

From: Glenn Morris <rgm <at> gnu.org>
To: Ken Olum <kdo <at> cosmos.phy.tufts.edu>
Cc: 26918 <at> debbugs.gnu.org
Subject: Re: bug#26918: 25.2;
 rmail edit corrupts mail if content-type header not displayed
Date: Mon, 05 Jun 2017 17:16:56 -0400
Ken Olum wrote:

> If you have a message in rmail which is in MIME format with base64
> encoding and consists only of a single text/plain part, and if you do
> not display the "Content-Type" header (e.g. by having it in
> rmail-ignored-headers), the message will get corrupted.  The problem is
> this: under the circumstances above, rmail-edit-current-message allows
> you to edit your view of the message (which is good, since you don't
> want to edit the base64).  But when it goes to reencode the message, it
> looks in the headers it gave you to edit and doesn't see the
> Content-Type.  Later it does see the Content-Type in the original
> headers, and the result is massive confusion.  In some circumstances it
> corrupts only that message, but in others it corrupts your mail file by
> merging this message with the one before.
>
> To reproduce:
>
> 1. emacs -Q
>
> 2. Visit attached rmail-test file
>
> 3. M-x rmail-mode
>
> 4. Set variable rmail-ignored-headers to ignore "Content-Type", e.g., by
> editing it in customization system.
>
> 5. Push "t" twice so that previous change takes effect.  Verify that
> Content-Type is not displayed.
>
> 6. Push "e" to edit message.  Insert a character at the end.  C-c C-c to
> finish.
>
> 7. Observe corrupted message on screen
>
> I'm not sure how to reproduce the situation where it corrupts your mail
> file, but it has happened to me several times.
>
> I can provide a fix for this bug if we agree on the right strategy.

It seems neither rmail user has an opinion. ;)
What do you suggest?
Two ideas that come to mind are:
1) force the relevant header(s) to be visible when editing a message
2) if the headers are not found in the message as edited, consult the
full unswapped message. (I wonder what happens if an edit adds a new,
duplicate Content-Type header that disagrees with the pre-existing one...)




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#26918; Package emacs. (Tue, 06 Jun 2017 15:07:02 GMT) Full text and rfc822 format available.

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

From: Ken Olum <kdo <at> cosmos.phy.tufts.edu>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 26918 <at> debbugs.gnu.org
Subject: Re: bug#26918: 25.2;
 rmail edit corrupts mail if content-type header not displayed
Date: Tue, 06 Jun 2017 11:06:41 -0400
   From: Glenn Morris <rgm <at> gnu.org>
   Date: Mon, 05 Jun 2017 17:16:56 -0400

   It seems neither rmail user has an opinion. ;)

That bad, is it?

   What do you suggest?

I'd be in favor of looking first at the edited message, and if there is
no Content-Type header there, looking at the full headers of the
original message.  If Content-Type is ignored, but the user adds one in
the edit buffer, I would replace the original one in the message with the
new one supplied by the user.  I think this is the general way that
added headers are handled.

                                        Ken




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#26918; Package emacs. (Thu, 08 Jun 2017 18:12:01 GMT) Full text and rfc822 format available.

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

From: Glenn Morris <rgm <at> gnu.org>
To: Ken Olum <kdo <at> cosmos.phy.tufts.edu>
Cc: 26918 <at> debbugs.gnu.org
Subject: Re: bug#26918: 25.2;
 rmail edit corrupts mail if content-type header not displayed
Date: Thu, 08 Jun 2017 14:10:44 -0400
Ken Olum wrote:

> I'd be in favor of looking first at the edited message, and if there is
> no Content-Type header there, looking at the full headers of the
> original message.  If Content-Type is ignored, but the user adds one in
> the edit buffer, I would replace the original one in the message with the
> new one supplied by the user.  I think this is the general way that
> added headers are handled.

That sounds like the correct approach to me.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#26918; Package emacs. (Mon, 19 Jun 2017 18:41:01 GMT) Full text and rfc822 format available.

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

From: Ken Olum <kdo <at> cosmos.phy.tufts.edu>
To: 26918 <at> debbugs.gnu.org, 27353 <at> debbugs.gnu.org
Subject: rmail-cease-edit patches for bugs 26918 and 27353
Date: Mon, 19 Jun 2017 14:40:24 -0400
[Message part 1 (text/plain, inline)]
Here is a patch to fix rmail editing problems associated with the
content-type header and reapplying the transfer-encoding to edited
messages.

                                        Ken

* lisp/mail/rmailedit.el (rmail-cease-edit): 
If no content-type in edited headers, look for one in original
headers and add it to edited headers (Bug #26918).
Marker to track start of new body, so that content-transfer-encoding
gets applied only to body (Bug #27353).
Ensure blank line at end of message after encoding, not before.

[rmailedit.patch (text/x-diff, attachment)]

Reply sent to Eli Zaretskii <eliz <at> gnu.org>:
You have taken responsibility. (Fri, 08 Sep 2017 09:12:02 GMT) Full text and rfc822 format available.

Notification sent to Ken Olum <kdo <at> cosmos.phy.tufts.edu>:
bug acknowledged by developer. (Fri, 08 Sep 2017 09:12:02 GMT) Full text and rfc822 format available.

Message #24 received at 26918-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ken Olum <kdo <at> cosmos.phy.tufts.edu>
Cc: 26918-done <at> debbugs.gnu.org, 27353-done <at> debbugs.gnu.org
Subject: Re: rmail-cease-edit patches for bugs 26918 and 27353
Date: Fri, 08 Sep 2017 12:11:22 +0300
> From: Ken Olum <kdo <at> cosmos.phy.tufts.edu>
> Date: Mon, 19 Jun 2017 14:40:24 -0400
> 
> Here is a patch to fix rmail editing problems associated with the
> content-type header and reapplying the transfer-encoding to edited
> messages.

Thanks, pushed to master.




bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Fri, 06 Oct 2017 11:24:03 GMT) Full text and rfc822 format available.

This bug report was last modified 6 years and 176 days ago.

Previous Next


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