Display existing alternative rather than removed attachment

When an attachent is removed from the message then it is rep

Wed, 15 Nov 2006 15:18:29 +0000

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

I don't think this is really possible without essentially ig

Wed, 15 Nov 2006 16:55:56 +0000

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

Quoting RFC 2046, Section 5.1.4. Alternative Subtype: «Sys

Wed, 15 Nov 2006 18:17:37 +0000

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?

How could this situation be detected? Imp 4.1.2 marks a r

Thu, 16 Nov 2006 14:49:38 +0000

How could this situation be detected? Imp 4.1.2 marks a removed part thusly: > ------=_NextPart_001_0001_319166C9.1979B12D > Content-Type: text/plain; > charset=UTF-8 > Content-Disposition: inline > Content-Transfer-Encoding: 7bit > > [Anhang entfernt: Ehemaliger Anhangstyp: text/html, Name: unbenannt] 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: > ------=_NextPart_000_001B_01C0CA81.7B015D10 > Content-ID: <121401Mfdab4$3f3dL780$75387018@57W81fa70Re> > MIME-Version: 1.0 > Content-Type: text/plain; name="message.pif"; charset="iso-8859-1" > Content-Description: Removed Attachment > Content-Disposition: attachment; filename="Removed Attachment.txt" > Content-Transfer-Encoding: quoted-printable > > This attachment contained a virus and was stripped. > Filename: message.pif > Content-Type: audio/x-wav > Virus(es): W32/Netsky-Q 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.

In the subject line and in my 1st poster, I was speaking of

Thu, 16 Nov 2006 15:02:37 +0000

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

I could see this being incorporated into the new MIME librar

Thu, 23 Nov 2006 21:14:47 +0000

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.

Stalling until IMP 5.

Mon, 05 Feb 2007 00:42:04 +0000

Stalling until IMP 5.

Now that you're working on the new MIME lib, Michael, can yo

Sun, 09 Nov 2008 02:02:43 +0000

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

Changes have been made in CVS for this ticket: http://cvs.h

Fri, 14 Nov 2008 20:49:12 +0000

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

Changes have been made in CVS for this ticket: http://cvs.h

Fri, 14 Nov 2008 20:51:48 +0000

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

The answer is much easier/more elegant than I thought - simp

Fri, 14 Nov 2008 20:52:46 +0000

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 Git for this ticket: Merge from H

Tue, 12 Jan 2010 23:54:49 +0000

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