Forwarding attachments has been reimplemented in HEAD.  Help would be 
great in tweaking the attachment recognition algorithim.

An excellent example!  Thank you for including it.
I suggest that you could choose to "Forward entire message as MIME 
attachment".  The message will be forwarded as a message/rfc822 
attachment, successfully passing the entire multipart/alternative tree 
onward to the next recipient.  (You can do this from the folder index 
-- put a checkmark on the line with the message, and click the 
"forward" command from above the list of messages.  And yes, it would 
be nice if there were a way to invoke the "forward as MIME" command 
directly while viewing a message.)



Most people won't be as sophisticated as you, and will be content with 
a simpler scheme, where IMP picks just one part of the 
multipart/alternative bundle, and forwards that one part.

Not trying to be difficult here :) but here's the big issue w/ 
multipart/alternative parts.  Say you receive this message (which I 
do, on a fairly consistent basis, from a known contact):



+ multipart/alternative

   + text/plain

   + text/html

   + application/pdf



What I *really* want out of these three is the application/pdf.  Those 
other 2 are useful for displaying inline (since inline PDF display 
isn't happening - at least very easily w/web based clients).  But when 
I forward this kind of message (which I often do), what I really want 
is that application/pdf part to make it to the next user.  the 
text/plain and text/html parts are worthless when it comes to 
formatting of that PDF part.  So simply "picking" one part of the 
multipart is not that easy...

I haven't looked into the source code about this yet, but I imagine 
just pulling out the text/plain or text/html depending on if the user 
selects plain or html editor should be simple enough, and not forward 
the other alternative parts.

I understand where you're coming from here, but I think the previous 
behavior was more intuitive for most users. The only real issue was 
with multipart/alternative parts, thus the original issue in this 
ticket.

I think those 2 are what is needed, and a preference matches what I 
remember clients like Thunderbird providing.



With multipart/alternative + forwarding inline, I'd also be fine with 
just taking the text part from the alternative part and dropping the 
rest. If at some point we can be smarter and take the HTML part if we 
support HTML composition, that's a bonus.

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".

sounds great (in the meantime I also learned to like the reply drop-down)

Please see the comment dated 2/8/2006.  The issue is it is very 
difficult (if not impossible) to code an algorithim that 100% 
correctly identifies what "should" be forwarded and what shouldn't.   
IMP's previous algorithim was not 100% reliable - that is why I have 
been playing around with other methods.



My goal is to create a forward drop-down (like the current reply 
drop-down) that has (at least) 2 options: Forward as RFC822 part and 
Forward attachments only.  Also, to add a preference for default 
forwarding behavior - this behavior will be used when the 'Forward' 
navbar action is clicked (rather than any of the options in the drop 
down).  I just haven't had a whole heck of a lot of time lately, which 
is why this ticket has stalled lately.  But this is at the top of my 
list of things to do (this obviously needs to be resolved before IMP 
4.2 so I am bumping the milestone).

I am an ordinary user too - I loved the possibilty to remove single 
attachments

I would like to comment on this issue from the perspective of a simple user.



A user gets a message, which contains a body and may  be one or more 
attachments. When I forwar this message, I expect to see the body in 
the editor, so that I can comment it or just add my own text. Iexpect 
eventual attachments from the original message to be attached again 
with the possibility to remove them one by one. That's it.



I can see that there may be reasons to do more sophisticated things 
with message parts, but please let that not be the default behavior.



As it is now compared to how it used to be in older versions:

- Processing mail gets more complicated, I have to go through a menu 
instead of just click the action I want(or use a short cut key).

- After two times forwarding a message(common practice here) the end 
recipient gets a message with two extra attachments containing message 
sources and two 'unnamed' links which if followed show a piece of the 
message already on screen. This is the 'without body text' option. In 
the standard behavior things are even worse, it ends up with three 
copies of the original body text as an extra.



Please keep it simple for ordinary users.

I'm not clear what the purpose of this is - it's trivial to delete the 
text if you don't want it. The original reporter was complaining about 
the original text still being in the _attachment_.

Added option in CVS to forward without adding the body text to the 
compose message's body.

Sounds good to me. Also, the javascript is there in this 
implementation specifically so it does work in IE - emulates the 
:hover stuff.

This specific one doesn't work with IE, but something like this would 
be nice. Hm, maybe we should take the opportunity and turn the whole 
action bar into an unordered list?

What about using drop down menus using CSS code such as:

http://www.htmldog.com/articles/suckerfish/dropdowns/

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 
<select> dropdown.

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."

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

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.

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.

How do other mail client handle this?

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.

I really thought this _did_ used to be a preference?

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.

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.

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?

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

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.

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