Changes have been made in Git for this ticket:

Merge from HEAD (Request #4664).

http://git.horde.org/diff.php/imp/docs/CHANGES?rt=horde-git&r1=494134b0cb53996bc9815e438ac7bf14bd3fea50&r2=7de276204b5859d9ce8a62dfaee8a5cbe30f069c
http://git.horde.org/diff.php/imp/lib/Message.php?rt=horde-git&r1=717fab3db3df3b8d078ed97d9f12c08f63d089f1&r2=7de276204b5859d9ce8a62dfaee8a5cbe30f069c

The answer is much easier/more elegant than I thought - simply mark 
the stripped part as 'attachment', not 'inline'.  Makes more sense in 
the general scheme of things also. Fixed in IMP 4.3.1.

Changes have been made in CVS for this ticket:

http://cvs.horde.org/diff.php/imp/docs/CHANGES?r1=1.699.2.361&r2=1.699.2.362&ty=u
http://cvs.horde.org/diff.php/imp/lib/Message.php?r1=1.164.8.61&r2=1.164.8.62&ty=u

Changes have been made in CVS for this ticket:

http://cvs.horde.org/diff.php/imp/docs/CHANGES?r1=1.1197&r2=1.1198&ty=u
http://cvs.horde.org/diff.php/imp/lib/Message.php?r1=1.305&r2=1.306&ty=u

Now that you're working on the new MIME lib, Michael, can you either 
mark this as accepted or reject it permanently?

Stalling until IMP 5.

I could see this being incorporated into the new MIME library.  But 
adding specific code for a single MIME type in our attachment 
stripping code is not a good idea.  So this is something for IMP 5.0, 
at the earliest.

In the subject line and in my 1st poster, I was speaking of 
"attachments". I think, that term is misleading, I should rather have 
used the term "alternative parts". I beg your pardon for any confusion 
this may have caused.



To prevent possible misunderstandings:

This feature request is addressing the choice amongst alternative 
parts of a Content-Type:multipart/alternative structure, from wich 
some of the alternative parts have been removed.



I was mislead by the terminology Imp uses in its replacemet line: 
"Anhang entfernt" means "attachment removed".

How could this situation be detected?



Imp 4.1.2 marks a removed part  thusly:
This is tricky: The only safe criterion is the last line which depends 
on the user's option settings. Note that this message may well be 
forwarded to another user with different settings, or that the user 
may change hir settings, after removing that part.



Another mailer (example seen today, but cannot be attributed to a 
particular mailer) does it thusly:

Here, the key feature is the Content-Description line, in accordance 
with RFC 2045, section 8: this can be set independently of the user's 
settings, hence it can easily be detected.



So, my suggestion is:

- when removing an alternate part, set the Content-Description field, 
as in the second example, above;

- when deciding which alternate part to display, parts marked in this 
way should not be regarded as eligible,

- if possible, parts marked in the way of the 1st example, above, 
should also be not eligible for display.

Quoting RFC 2046, Section 5.1.4. Alternative Subtype:

«Systems should choose the "best" type based on the local environment 
and references, in some cases even through user interaction.»



So, what I am proposing, is that Imp should choose, in accordance with 
RFC 2046,  the remaining original alternative, as it is definitely 
"better" than the removed one. Or is there some other RFC dealing with 
multipart/alternative that contradicts this approach?



Of course, Imp can choose that alternative through user action; 
however, a sensible choice without user intervention would be 
superior, wouldn't it?

I don't think this is really possible without essentially ignoring the 
RFC on multipart/alternative messages. Michael?

When an attachent is removed from the message then it is replaced with 
a text/plain attachment comprising an informational message about the 
original attachment. This comes handy to remove unwanted alternative 
attachment formats.



Now, if the remaining alternative happens to come. in the message 
source, before the removed one, Imp will display that informational 
message, rather than the original message content.



To comply with the user's intent, Imp should recognize this situation 
and display the remaining, valid alternative (rather than the 
informational message that happens to follow it).