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

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

Saved Queries