[Tickets #3381] "forward" handles text/alternative incorrectly

[bugs@bugs.horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/?id=3381
-----------------------------------------------------------------------
 Ticket             | 3381
 Updated By         | jmorzins at mit.edu
 Summary            | "forward" handles text/alternative incorrectly
 Queue              | IMP
 Version            | HEAD
 State              | Assigned
 Priority           | 3. High
 Type               | Enhancement
 Owners             | Michael Slusarz
-----------------------------------------------------------------------


jmorzins at mit.edu (2006-04-14 10:35) wrote:

Michael, I think the plan of having a choice between "forward as
message/rfc822" and "forward text and attachments" is a good solution.

I've been supporting mail programs for 12 years but don't know your own
experience, so please forgive me if the following comment is something you
already know: I hope you are aware that sub-parts of multipart/alternative
are not attachments.

This is crucially important, and bears repeating: sub-parts of
multipart/alternative are not attachments. They are alternate versions of a
single source. The "forward text and attachments" command should only
forward one of the sub-parts of the multipart/alternative bundle.


I'm sorry if I'm wasting your time by repeating things that you already
know, but I'd hate to see you spend a lot of time coding a feature that
doesn't addess the core of this bug report.

Multipart/alternative is the core of this report.  IMP's current behavior
has two bugs: (1) the "forward" command converts multipart/alternative into
multipart/mixed, and (2) the compose window allows a user to edit one of the
sub-parts without propagating those changes into the other sub-parts.

1) Converting multipart/alternative into multipart/mixed violates the intent
of multipart/alternative, because mail clients will automatically display
all subparts of multipart/mixed to the user.  See RFC 2046: "What is most
critical, however, is that the user not automatically be shown multiple
versions of the same data."

2) Editing one body part without editing the others also violates the intent
of multipart/alternative: see RFC 2046: "In particular, each of the body
parts is an "alternative" version of the same information."


Summing up: yes, I like your plan of offering a choice between "forward as
MIME attachment" and "forward text + attachments".