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

[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         | Michael Slusarz <slusarz at mail.curecanti.org>
 Summary            | "forward" handles text/alternative wrongly
 Queue              | IMP
 Version            | 4.0.3
 State              | Assigned
 Priority           | 3. High
 Type               | Enhancement
 Owners             | Michael Slusarz
-----------------------------------------------------------------------


Michael Slusarz <slusarz at mail.curecanti.org> (2006-02-08 13:33) wrote:

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.