unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Mark Lillibridge <mdl@alum.mit.edu>
To: 9521@debbugs.gnu.org, 9766@debbugs.gnu.org
Subject: bug#9521: [RESEND] PATCH for bug #9521, *not* bug #9766
Date: Fri, 28 Dec 2012 12:55:25 -0800	[thread overview]
Message-ID: <87r4m999s2.fsf@foil.strangled.net> (raw)
In-Reply-To: <871uea9dzk.fsf@foil.strangled.net> (message from Mark Lillibridge on Fri, 28 Dec 2012 11:24:31 -0800)


    This bug (#9521) was easy to fix.  The problem was with the
rmail-insert-mime-forwarded-message function in rmailmm.el:1355:

  (defun rmail-insert-mime-forwarded-message (forward-buffer)
    "Insert the message in FORWARD-BUFFER as a forwarded message.
  This is the usual value of `rmail-insert-mime-forwarded-message-function'."
    (let ((message-buffer
  	 (with-current-buffer forward-buffer
  	   (if rmail-buffer-swapped
  	       forward-buffer
  	     rmail-view-buffer))))
      (save-restriction
        (narrow-to-region (point) (point))
        (message-forward-make-body-mime message-buffer))))


    This does exactly the wrong thing by inserting the decoded version
of the message.  Swapping the two buffers (forward-buffer,
rmail-view-buffer) in the if expression fixes this:

  (defun rmail-insert-mime-forwarded-message (forward-buffer)
    "Insert the message in FORWARD-BUFFER as a forwarded message.
  This is the usual value of `rmail-insert-mime-forwarded-message-function'."
    (let ((message-buffer
  	 (with-current-buffer forward-buffer
  	   (if rmail-buffer-swapped
> 	       rmail-view-buffer
> 	     forward-buffer))))
      (save-restriction
        (narrow-to-region (point) (point))
        (message-forward-make-body-mime message-buffer))))


    Note that this does not fix bug #9766, which was incorrectly merged
with bug #9521.  The problem there (#9766) is that many email clients
including in particular, the iPad email app, do not properly display
RFC822 attachments or do not show it inline.  Fixing that problem
requires substantial work, including on the design front.

    One idea would be to generate the RFC822 attachment as now, which
preserves the full details of the message for competent email clients,
and also generate an abbreviated version in the message body for human
viewers of incompetent email clients.  The simplest approach would be to
just insert the Rmail decoded version:

    ====== forwarded message as seen by sender (full message attached) ====
    From: Kenichi Handa <handa <at> m17n.org>
    To: handa <at> m17n.org
    Subject: test from shatin
    Date: Thu, 15 Sep 2011 14:14:58 +0900
    Message-ID: <87aaa6xu7h.fsf <at> m17n.org>
    Content-Type: multipart/mixed; boundary="=-=-="

    [1:text/plain Hide]
    
    test of attachment
    
    
    [2:application/pdf Show Save:temp.pdf (2kB)]

Here, the message headers have been filtered by the users usual header
filtering rules and the body is as seen when the forwarding was done.
e.g., whatever message part toggling the user did is still visible.

    Drawbacks: the PDF attachment here is not accessible to the
incompetent email clients, this approach fails miserably for HTML-only
messages (distressingly common these days), and there is no way to
forward the HTML part instead of the text part inline (perhaps the HTML
part has the real content).  The first of these could be fixed by
attaching all of the original non-inline attachments to the new message;
this is what email clients like Outlook do when you forword a message.

    For the second and third parts, I have been experimenting with the
following (had to add " " after <'s to make < #parts escaped):

    < #part type=text/html disposition=inline raw=t>
    <PRE>
    ===== Forwarded message (HTML part only) follows =====
    Date: Fri, 28 Dec 2012 19:44:57 -0000
    From: "Hilton Hotels & Resorts" <hiltonhotels@h1.hilton.com>
    To: lillibridge@gmail.com
    Subject: Pick your paradise: choose from three unforgettable resort experiences
    Reply-To: "Hilton Hotels & Resorts" <support-b7j7kpqa20rdfhauv5u0bqcx2vkpsh@h1.hilton.com>
    </PRE>
    
    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
    <title>Hilton Hotels &amp; Resorts</title><style type="text/css">
    body {
    	-webkit-text-size-adjust: none;
    }
    .ReadMsgBody {
    	width: 100%;
    }
    ...
    <img src="http://h1.hilton.com/a/hBQ3bP4AH$iOmB8v3UjNt2dv0P$/spacer.gif">
    </body></html>
    
    < #/part>

Note the need to use PRE or the equivalent to protect the headers.
Probably additional escaping of the headers are required and likely the
charset needs very careful handling.  Lots of corner cases here,
including what to do with multiple HTML parts.  


    At the moment, I have three versions of forward implemented, one
that sends the entire message as a RFC822 attachment, one that forwards
just the text part, and one that forwards just the HTML part.  The later
two work correctly when the entire message is one part.  I find each
useful in different circumstances so probably we don't want to support
only one of them.

- Mark






  parent reply	other threads:[~2012-12-28 20:55 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-16  7:51 bug#9521: 24.0.50; rmail-forward Kenichi Handa
2012-12-28 19:24 ` bug#9521: This bug is still present in version 24.2; it prevents forwarding correctly essentially any MINE message Mark Lillibridge
2012-12-28 20:46   ` bug#9521: PATCH for bug #9521, *not* bug #9766 Mark Lillibridge
2012-12-28 20:55   ` Mark Lillibridge [this message]
2012-12-28 21:22     ` bug#9766: workaround for 9766 Mark Lillibridge
2012-12-29  8:53     ` bug#9521: [RESEND] PATCH for bug #9521, *not* bug #9766 Eli Zaretskii
2013-01-01 22:10 ` bug#9521: this bug (#10080) also causes an extra blank line to be appended to forwarded messages Mark Lillibridge
  -- strict thread matches above, loose matches on Subject: below --
2011-10-16 11:19 bug#9766: 24.0.50; rmail-forward makes attachment that doesn't read right Richard Stallman
2011-10-16 12:54 ` Eli Zaretskii
2011-10-16 21:40   ` Richard Stallman
2011-10-17  5:05     ` Eli Zaretskii
2011-10-17 13:14       ` Richard Stallman
2011-10-17 14:07         ` Eli Zaretskii
2011-10-17 21:42           ` Richard Stallman
2011-10-18  1:00             ` Stefan Monnier
2011-10-18  3:54               ` Eli Zaretskii
2011-10-18 13:01                 ` Stefan Monnier
2011-10-18 13:26                   ` Eli Zaretskii
2011-10-18  3:47             ` Eli Zaretskii
2011-10-18 10:28               ` Lars Magne Ingebrigtsen
2011-10-18 10:56               ` Richard Stallman
2011-10-18  3:53             ` Eli Zaretskii
2011-10-16 18:43 ` Lars Magne Ingebrigtsen
2022-04-24 13:53 ` Lars Ingebrigtsen
2022-05-22 20:00   ` Lars Ingebrigtsen

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=87r4m999s2.fsf@foil.strangled.net \
    --to=mdl@alum.mit.edu \
    --cc=9521@debbugs.gnu.org \
    --cc=9766@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).