Any luck tracking this down?  This really sounds like a MIME filtering 
issue outside of the scope of IMP/Horde.  Maybe attaching the message 
source of a message that has been stripped would be useful.

Nope.  It's on.  Besides, wouldn't the actual received message still 
have the attachment?



Still trying to track down the cause over here...

Sounds like the preference to NOT save attachments in sent-mail is turned on.

Probably true.  Works fine in my mail client anyhow so I don't care.
The attachment is completely omitted in the IMAP-stored message.  It's 
exactly as if it was never attached to begin with.
Fair enough.  Let's find and fix the bug, then.

That doesn't tell us anything because Gmail may very well be broken 
re: this.  I don't think Gmail supports multipart/encrypted anyway.
How about looking at the sent-mail folder?  IMP will save the exact 
copy of the message text it sends to the outbound mail server, so 
looking at the copy in the sent-mail folder will show what is being 
sent out unadulterated by any other process down the chain.  The 
message source of the message might be useful to look at.
As mentioned previously, it's a waste of space (60-80 bytes per e-mail 
adds up on a server with millions of users).  It's also *not* what 
Content-Description was created for.  From RFC 2045[8]:



    The ability to associate some descriptive information with a given

    body is often desirable.  For example, it may be useful to mark an

    "image" body as "a picture of the Space Shuttle Endeavor."  Such text

    may be placed in the Content-Description header field.  This header

    field is always optional.



Here, we don't care about descriptive information for attachments 
(while there is a Description field in IMP 4, this field has been 
removed in IMP 5 for exactly this reason).  Description != filename.



Additionally, adding the Content-Description field is simply masking 
the real problem.  This is no different than turning up your car radio 
when your engine starts making funny sounds.  It may fix the issue 
temporarily, but doesn't give you any insight into the reason why it 
is broken in the first place.

You're right, I do see that, when I look at the message in my sent 
mail folder in claws-mail with the PGP plugin.  But when I look 
through the Gmail web interface, I see "noname".  Go figure?
Apology accepted.



I have tried sending attachments both with and without PGP.  I have an 
exceedingly complicated setup, so it's very hard to track down what's 
causing the problem, but I have verified that attachments work 100% of 
the time when a Content-Description is included.



Here is how mail flows for me:



1.  Message composed using Horde web interface

2.  Message delivered to local "sendmail" (SSMTP) on web server and 
stored on mail server via IMAP

3.  Sendmail connects via TLS to SMTP port 2525 on mail server

4.  Mail server accepts message via Postfix

5.  Postfix on mail server feeds message to DKIM-signer

6.  DKIM-signer reinjects message into mail server local Postfix

7.  Mail goes out



I don't think the DKIM signer is the problem, honestly.  It just adds 
two header fields to the message.  So that just leaves the IMAP 
server, ssmtp, postfix, and imp.



Looking at this from another direction, adding the Content-Description 
field does no harm save for making messages one line longer per 
attachment.  So why NOT put it in by default?  Users could still clear 
it by blanking the attachment description fields...

You are correct in the MUA's will display Content-Description for a 
part.  But in the absence of a Content-Description part, a MUA will 
fall back to the filename of the part (if it exists) in either the 
Content-Disposition or Content-Type MIME header.  This is why, for 
attachments, Content-Description is superfluous.  For other, 
non-attachment parts (such as a PGP multipart container part), it is 
useful to have a Content-Description header because there is no 
filename.



However, for PGP signature, we already set the Content-Description 
header (see, e.g., horde/framework/Crypt/Crypt/pgp.php, line 1487):



$pgp_sign->setDescription(String::convertCharset(_("PGP Digital 
Signature"), NLS::getCharset(), $charset));



So if that is not appearing in your message, I don't know what is happening.

I did not mean to sound condescending and I apologize.  I simply was 
trying to indicate that this more than likely is something specific to 
your system rather than with Horde/IMP in general.  And explaining why 
I was not going to apply your patch - simply because in theory, it 
shouldn't fix anything.



Are you only sending attachments with PGP?  Have you tried sending 
attachments with no encryption?

I'm using Apache 2.2.10, PHP 5.2.8-r1, and a Zimbra 5.0.12 IMAP 
server.  All this runs atop Linux 2.6.18-xen-r4 on a VM allocated 2 
Xeon E5310s and 3/4 of a GB of memory.

Isn't the Content-Description what is displayed by MUAs for the 
attachment?  When I PGP-sign something, the signature shows up as 
"noname".  Why would you not want it to be something like "Signature" 
instead?  Why would you choose to have a file be "noname" over 
"foo.txt"?
OK, look, I'm not making this up.  This is an actual bug at my end.   
Please work with me to find out what combination of options triggers 
it instead of asserting that it works for millions of people.



I will attach all relevant configuration files and information.

#1 - There is no need to add description information.  It is useless, 
superfluous information in this situation.

#2 - More important, attaching files works perfectly fine for me.  And 
considering how this is how the millions of people that use IMP attach 
files every day, it is doubtful there is anything wrong with our code. 
  You need to find the exact reason/location in IMP code why we 
wouldn't be attaching the file if there is no description.

Seems okay unless I'm missing something.

Imp loses attachments which have no name.

Steps to reproduce:

1.  Enter the compose window, put in a destination address and subject

2.  At the bottom, click the browse button to attach a file from the 
local filesystem (not VFS).

3.  Click "update" on the bottom-right

- At this point you should have a message stating that the attachment 
was successful -

4.  Send the message

5.  Check if the message was sent with an attachment - it was not.



An easy fix/workaround (patch attached) is to name attachments after 
their filename by default.  Now unless the user manually clears out 
the description box at the bottom, the file will get attached.  I have 
verified that PGP-signed messages with attachments go out on my setup 
using this patch.