[#4221] Off-by-one error: Selecting NO for 'Save Attachments with message in sent-mail folder' and attaching PHP public key removes all but one of the attachments
Summary Off-by-one error: Selecting NO for 'Save Attachments with message in sent-mail folder' and attaching PHP public key removes all but one of the attachments
Queue IMP
Queue Version HEAD
Type Bug
State Resolved
Priority 1. Low
Owners Michael Slusarz <slusarz (at) horde (dot) org>
Requester breu (at) cfu (dot) net
Created 07/31/2006 (1069 days ago)
Due
Updated 12/08/2008 (208 days ago)
Assigned 11/08/2008 (238 days ago)
Resolved 12/08/2008 (208 days ago)
Attachments
Milestone 5.0
Patch No

History
12/08/2008 Michael Slusarz Comment #7
State ⇒ Resolved
Reply to this comment
Fixed in IMP 5.
11/08/2008 Chuck Hagenbuch Comment #6
State ⇒ Assigned
Version ⇒ HEAD
Reply to this comment
Un-stalling
10/31/2007 Michael Slusarz Comment #5
State ⇒ Stalled
Reply to this comment
So we end up not stripping one attachment that we should? I'm not 
sure I follow why the above means that, but if that's the case at 
least this isn't destructive. If you confirm, please stall this for 
5.0.
What I mean is that if we create a multipart/mixed message ourself, 
and then populate with subparts, these parts have no MIME IDs - i.e. 
these IDs can not be dynamically assigned/determined by MIME_Part.   
Unless you specifically set the MIME IDs at creation time - which we 
do when rebuilding from IMAP message data for example - it is 
impossible to access the individual MIME parts.

IIRC, this off-by-one issue deals with this limitation, and there is 
no solution except to make BC-breaking changes to MIME_Part.  So 
stalling for Horde 5.
10/25/2007 Chuck Hagenbuch Comment #4 Reply to this comment
After further investigation - this is going to be extremely 
difficult to fix without either breaking BC or having to rewrite 
MIME_Part in IMP.  Essentially the issue is that, when creating 
complex MIME_Parts ourselves (i.e. not from pre-existing mail data), 
the MIME ID's are not dynamically updated.  Therefore, it is 
impossible to access any MIME parts except for the outer-most 
container parts (i.e. parts 1, 2, 3).
So we end up not stripping one attachment that we should? I'm not sure 
I follow why the above means that, but if that's the case at least 
this isn't destructive. If you confirm, please stall this for 5.0.
11/24/2006 Michael Slusarz Priority ⇒ 1. Low
 
08/20/2006 Michael Slusarz Comment #3 Reply to this comment
After further investigation - this is going to be extremely difficult 
to fix without either breaking BC or having to rewrite MIME_Part in 
IMP.  Essentially the issue is that, when creating complex MIME_Parts 
ourselves (i.e. not from pre-existing mail data), the MIME ID's are 
not dynamically updated.  Therefore, it is impossible to access any 
MIME parts except for the outer-most container parts (i.e. parts 1, 2, 
3).
08/09/2006 Michael Slusarz Comment #2
Priority ⇒ 2. Medium
Reply to this comment
Occurs in HEAD also.
08/01/2006 Jan Schneider Assigned to Michael Slusarz
State ⇒ Assigned
 
07/31/2006 breu (at) cfu (dot) net Comment #1
Summary ⇒ Off-by-one error: Selecting NO for 'Save Attachments with message in sent-mail folder' and attaching PHP public key removes all but one of the attachments
Type ⇒ Bug
State ⇒ Unconfirmed
Priority ⇒ 1. Low
Queue ⇒ IMP
Reply to this comment
Steps to recreate:

Compose new message
Select 'Attach a copy of your PGP public key to your message?'
Attach a file
Select 'NO' for 'Save Attachments with message in sent-mail folder?'
Send message

The message that is stored in the sent folder will contain the 
original attachment and the PGP attachment will be stripped.