Re: Change in rmail-insert-mime-forwarded-message

[Mark Lillibridge]

Richard Stallman <address@hidden> writes:

>       (1) forward the exact original message with all formatting and
>       attachments included.  That pretty much has to be done via an
>       RFC822(sp?) attachment of the original message as received.  As noted by
>       bug #9766, some email clients are unable to display such attachments.
>  
>       (2) include the text seen by the Rmail user at the time forward is
>       called.
>  
>  Both of these were possible before your change.
>  The first was done with v f
>  and the second with plain f.

    My wording for (2) wasn't very good and you didn't quote the
relevant bits, but it was intend to require that the text be put in the
message body not a message attachment, which cannot be read by users of
lame message clients.  Your 'f' does not actually correctly implement
(2) as I meant it.  I agree that your 'vf' (assuming suitable bug fixes
have been applied) implements (1).


>          I do not think we should use RFC822(?) message attachments for
>       this: I haven't read all the relevant RFC's, but I assume the
>       destination email client will attempt to display an RFC822(sp?) message
>       attachment as if it was a separately received message. 
>  
>  f always puts the forwarded message into mime attachment, and there is
>  no problem in this case.  The message _as displayed in rmail_ does not
>  contain mime part headers.  It has things like this
>  
>      [1:text/plain Hide]
>  
>  instead.

    Depends on how the user is viewing the message.  Hitting "t" will
definitely get you the MIME headers but not the correct corresponding
body.  (A rare case, I grant you.)  Also note that the charset encoding
header is likely also gone, probably causing characters to be displayed
incorrectly.



>       (3) A smarter version of (2) that both makes the original message
>       body visible to the destination client even for clients that don't
>       handle RFC message attachments
>  
>  I can't make concrete sense of that, sorry.

    Let me try a concrete example.  Suppose you have a message with a
text part message body "this is in red", message body HTML part with the
same except actually in red, and an attached (non-in-line) PDF.

With (3), the forwarded message would have:

  * a text message body part with something like "===== forwarded message
    =====", the Rmail filtered headers, then "this is in red"

  * the equivalent as an HTML message body part (including the headers
    protected via <PRE> or the like), with the "this is in red" part
    actually in red.

  * the attached PDF as an individual attachment (same suggested file name)

Optionally, you could also attach the original message as an RFC822(?)
message attachment part.

    For even more fun, there should be an easy way for the user to add
text before the "===== forwarded message =====" that shows up in both
parts.  See what I mean about being nontrivial?


>       At the moment, in the absence of availability of (3), I use (1) for
>      forward and use resend message to deal with people with limited mailers.
>      I don't think (2) is a reasonable default because it drops attachments,
>      formatting, and doesn't work for HTML-only messages.
>  
>  With your change, only (1) is possible.  I think (2) is the right
>  default, but in any case, it is better to have both options.
>  
>  So I think I will revert your change.

    I agree that we should have more than one option, which is what I
recommended in the relevant bug report.  Correct code for (2) or ideally
(3) needs to be written and linked to a different invocation path.   If
only one is supported, then (1) is the better choice in my opinion.  I
think users can set rmail-enable-mime-composing to nil if they want (2) for
'f' but currently this is a startup choice rather than on a forward by
forward basis.

    Hmmm.  Richard, does the behavior of "f" when
rmail-enable-mime-composing is set to nil do what you want?  If so, we
just need to figure out a good way to make that behavior and my patch
behavior for "f" available at the same time.

    I'm not really keen on using the "vf" trick; it has the side effect
of changing the display of the original message being forwarded.  It
also seems not unlikely that users might want to send the raw message
with (1) to users of lame email clients but your use of "vf" for (2)
preempts that possibility.  I can also imagine trying to forward the
same message twice and having muscle memory type "vf" twice, screwing up
the second forward.

- Mark