Tickets :: Comment on [#3381] "forward" handles multipart/alternative incorrectly

* Your Email Address
* Spam protection	Enter the letters below: . .. ..__ __ .__. \|\ \|\|_/ [__)/ `\| \| \| \\|\| \\| \__.\|__\
Comment	> 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
Attachment
Watch this ticket

Saved Queries