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

[Mark Lillibridge]

Richard Stallman <address@hidden> writes:

>       You want to insert the undecoded but unmbox-escaped message.
>  
>  I am not sure what that means.  What is "unmbox-escaped"?  How
>  does that relate to decoding?

    Messages stored in mbox format have lines starting with >*From\
escaped by adding an extra > at the front.  This escaping needs to be
reversed to get the original message back.  See bug #13329 for more
details.


>  And why do you think this behavior is the right behavior, rather than
>  forwarding the message as displayed?
>  
>        The visible message is very
>      likely not a valid RFC message because it is missing headers and
>      boundary parts.  It also likely is missing some of the attachments.
>  
>  Yes, but why do you think that is wrong?  If f forwards whatever
>  is displayed, the user has the choice to type v and forward
>  the undecoded message, or not type v, and forward the message as
>  decoded with selected parts visible.

    Ignoring defaults for the moment, it seems like ideally we should be
able to do any of three things:

    (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.  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.  E.g., deal with
    its in-line multipart alternative parts appropriately, etc.  If you
    attach an invalid message (e.g., bad MIME headers), I would expect the
    recipient to see garbage or an error message for the message attachment.
    
        The text here can be placed directly in the message body, possibly
    prefixed with "> "'s.  Pretty much any email client should be able to
    see the included text but there's no way to include attachments or
    render HTML as HTML in the destination client.  E.g., this method cannot
    be used with HTML-only messages.  It also often loses formatting (e.g.,
    colors) that is present only in HTML parts.
    
    (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 (this means handling both the text
    and HTML in-line parts correctly if formatting is not to be lost)
    and attaches all the original non-in-line attachments as well.  This
    would be fairly tricky to do right; see my email about this in the
    bug discussion for bug #9766.  Something like this is what Outlook
    does, for example.


    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.

- Mark