"forward" handles multipart/alternative incorrectly

Hi, We've noticed a problem with the way IMP forwards mes

Wed, 01 Feb 2006 18:16:54 +0000

Hi, We've noticed a problem with the way IMP forwards messages, and wanted to report it here so that you could look at the situation and consider changing IMP. The problem: - When forwarding a multipart/alternative message, IMP puts the text/plain part into the text editing field, and encourages the user to edit that text. However, IMP adds the text/html part as an attachment to the message! - This causes problems: we have users who will edit the text section (adding or deleting text), and send the message on. When the message is received, a recipient's mail program will often show the text/html part instead of the text/plain part -- showing the recipient text that the sender did not intend for the recipient to see. Users don't understand multipart/alternative and text/plain text/html distinctions. They only understand "I edited the text and I forwarded the message -- but my correspondant saw things he wasn't supposed to see! Stop this from happening!" We can train our users to check the Attachments section on the composition page, deleting text/html attachments before they send the forwarded message. But it would be easier for us if IMP were improved to be even more user-friendly. Possible solutions: I can think of two ways to adjust IMP to avoid this problem. You may be able to think of ways yourself. - Option 1: when forwarding a multipart/alternative message, IMP should choose the text/plain part and should DISCARD the text/html part. The user can edit the text/plain, and forward that, and they will send exactly what they thought they were sending. - Option 2: when forwarding a multipart/alternative message, IMP should not allow the user to edit the original text. IMP should attach the original text as a message/rfc822 attachment, and should allow the user to compose a preamble message. The main problem is the text/plain and text/html parts of a message should never be out of sync. Either of these options will avoid that problem; you may be able to think of your own solutions. Thank you, Jacob Morzinski MIT IS&T: Customer Support Services jmorzins@mit.edu

Damn - I just wrote a page for this ticket and my session ti

Fri, 03 Feb 2006 01:54:21 +0000

Damn - I just wrote a page for this ticket and my session timed out :( Quick synopsis then: I have been wrestling with this issue for way too long now and finally have decided to at least try forwarding always as a message/rfc822 part instead of trying to be fancy in figuring out what parts should be forwarded. I have implemented (sort of) #2 with the addition that we still put the text of the first viewable text part into the message body window. This is because I (at the least) find it very useful when forwarding messages to others in order to point out details of the forwarded message for example. But since the original text part is in the rfc822 part, the concerns raised below about differing text is alleviated. This will just be in HEAD for awhile but if the reaction is good there, this should probably be backported before we release 4.1.0.

> I have implemented > (sort of) #2 with the addition that

Fri, 03 Feb 2006 21:02:18 +0000

> I have implemented > (sort of) #2 with the addition that we still put the text of the > first viewable text part into the message body window. Hi, Thanks for looking at this! I have one fear about your proposed solution: is the text that you put in the message body window editable? Please make that text not editable! If the text is editable, then two version of the text will still be sent -- the edited text (in the message body), plus the original text (in the attachment). My goal is to make sure that only one version of text is sent. If you'd like to compare to another mail program, I can say how the Pine mail reader does it: 1. By default, forward only the text/plain part. During the sending process, insert the text/plain into the editing buffer, so that the user can edit it. 2. If the user choose an optional forwarding command, pine will attach the forwarded message as a message/rfc822 attachment, and will not let the user edit the text of the attachment. (The user can still type a preamble, that will be put in to the first part of the message, before the attachment.) This algorithm simplifies down to something like: 1. If the user edits the text of the forwarded message, make sure that ONLY that text is sent, and that no other text from the original message is sent. Send only the edited text. 2. If the user user does not edit the text of the forwarded message, then it is safe to forward anything that was in the original message. Thank you, -Jacob Morzinski

> Quick synopsis then: I have been wrestling with this issue

Sun, 05 Feb 2006 17:53:59 +0000

> Quick synopsis then: I have been wrestling with this issue for way > too long now and finally have decided to at least try forwarding > always as a message/rfc822 part instead of trying to be fancy in > figuring out what parts should be forwarded. I have implemented > (sort of) #2 with the addition that we still put the text of the > first viewable text part into the message body window. This is > because I (at the least) find it very useful when forwarding messages > to others in order to point out details of the forwarded message for > example. But since the original text part is in the rfc822 part, the > concerns raised below about differing text is alleviated. I'm not really in favor of this. For one thing, wasn't whether or not to forward as attachment a preference before? I also like having the ability to pick and choose which attachments get forwarded when I forward a message. Seems to me like we should be able to, if forwarding a multipart/alternative message inline, just not add as attachments any other alternatives to that part. Is it not that simple?

Having used the "new" way for a few days, I agree with Chuck

Wed, 08 Feb 2006 21:33:24 +0000

Having used the "new" way for a few days, I agree with Chuck that this is not an ideal solution. Pros/cons: Pros: This is the only way to reliably forward the message leaving the old message (and its attachments) unaltered. Easy. Clean. Cons: Can't delete individual parts from forwarded message. Pros/cons of an approach where we simply attach all MIME_Parts from the original message into the new message: Pros: Allows us to pick/choose parts we actually want to forward. Cons: We end up with complicated MIME structure information that the enduser should really not be dealing with (i.e. part 2 may be of type multipart/mixed and part 3 may be of type multipart/related, which probably mean about zero to the enduser). Additionally, we end up forwarding information (i.e. PGP signature information) that has absolutely no use to the receiving user - since it does not pertain to the forwarded message at all. Another alternative: only attach parts that have a "filename" defined in the MIME headers. Pros: We are assured these parts can be "downloaded". Cons: We lose the ability to forward all kinds of good stuff (e.g. multipart/related) that are possible via MIME. People can't think of a MIME Part as a single file (i.e. MIME Part = 1file on local filesystem). MIME Parts allow much richer presentation than this. This option is completely not feasible. So you can see my dilemna.

Brainstorming some more: maybe this should become a preferen

Thu, 09 Feb 2006 03:39:33 +0000

Brainstorming some more: maybe this should become a preference. Thereby allowing those that want to attach via rfc822 part and those that want individual parts to both be happy.

I really thought this _did_ used to be a preference?

Thu, 09 Feb 2006 16:14:13 +0000

I really thought this _did_ used to be a preference?

> I really thought this _did_ used to be a preference? No

Fri, 10 Feb 2006 07:08:24 +0000

> I really thought this _did_ used to be a preference? Not for forwards AFAIK. Especially considering, up until a week or so ago, it was not possible to forward all parts as a single attachment from the message screen before since there was no code setup to do this.

How do other mail client handle this?

Wed, 15 Feb 2006 01:25:55 +0000

How do other mail client handle this?

> How do other mail client handle this? All over the boar

Wed, 15 Feb 2006 01:33:14 +0000

> How do other mail client handle this? All over the board. But it is important to note that we really should not be looking at how *desktop* clients handle forwarding (i.e. thunderbird/outlook). They have the advantage of showing the content of the forwards in the text body themselves - and the user doesn't have a concept that they are even attachments. Obviously, we are more limited by what we can do in how we display attachment information since we are dealing with both browser and platform limitations.

Another idea - what about having the 'Forward' button be a j

Wed, 15 Feb 2006 01:35:30 +0000

Another idea - what about having the 'Forward' button be a javascript popup menu that would allow the user to choose from 'Forward entire message' and 'Forward attachments only'? This would also be useful for the Reply button - i.e. having a single reply button that may contain the options 'Reply', 'Reply to All', and (if necessary) 'Reply to List'. We could default to having all these options simply displaying on the action bar if javascript is not available.

That sounds like a smart solution, though I personally would

Wed, 15 Feb 2006 08:38:07 +0000

That sounds like a smart solution, though I personally would hate to loose the direct keyboard shortcuts for the several reply types.

Since we really need this for forwardings only, how about

Wed, 15 Feb 2006 08:41:44 +0000

Since we really *need* this for forwardings only, how about the much simpler, though not as beautiful, solution, to show a confirm dialog instead. The most often used selection should be attached to the OK button. Something along "Click OK to forward message's attachments separately, otherwise the complete message will be attached."

> Since we really need this for forwardings only, how abou

Wed, 15 Feb 2006 16:07:11 +0000

> Since we really *need* this for forwardings only, how about the much > simpler, though not as beautiful, solution, to show a confirm dialog > instead. The most often used selection should be attached to the OK > button. Something along "Click OK to forward message's attachments > separately, otherwise the complete message will be attached." If I understand you correctly, the alternative would be bound to the "Cancel" button, right? I think that's very unintuitive. I'd rather have two links, or put the options into a dropdown (we can still bind shortcut keys with JavaScript then, and at least it can be made to work without js. And it can be enhanced with dhtml, etc, if it's a