bug#9521: PATCH for bug #9521, *not* bug #9766

[Mark Lillibridge <mdl@alum.mit.edu>]

[-- Attachment #1: Type: text/plain, Size: 3163 bytes --]


    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:

    

[-- Attachment #2: Type: text/html, Size: 947 bytes --]

[-- Attachment #3: Type: text/plain, Size: 637 bytes --]


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