CiviCRM Community Forums (archive)

I have been having problems with some attachments my users are sending out with Civimail.
Some long filenames were appearing to get the end of their filenames cut off, including the file extensions - which looked very bad to the recipients as they could not then open the files. The file content was fine and a rename to the appropriate extension proved the file was intact.

To reproduce this error:
- Create a new civimail mailing
- choose whatever settings you want up to the compose mail screen
- create a new file to attach in word (or equivalent) on windows and name it "Testing_the_attachments_this_is_a_very_long_filename_to_see_if_it_makes_a_difference_to_the_mailing_system.doc"
- You can also try putting spaces and non-latin characters in the filename as well.
- compose a test mail and add the attachment
- on the 'test mailing' screen, send yourself the mail
- View the attachment in your email program (I am using outlook 2003). The filename will be truncated and missing the extension


After a lot of debugging, tracing the route of the uploaded files through civicrm, I discovered that the filenames were fine in the database, were accessed correctly by the mailer job script, and even passed correctly into the compose method of the mailer object. In short, there is no problem with civicrm (hooray?).
The problem seems to be in the PEAR mailer function around lines 333 or 360 in CRM/Mailing/BAO/Job.php:

333: $body    =& $message->get();
360: $result = $mailer->send($recipient, $headers, $body, $this->id);

As far as I can tell the long filenames are passed correctly into these functions. After some googling, I discovered this (and a bunch of other attachment encoding problems) is a known issue with the PEAR library, and was patched in January 2010:

http://pear.php.net/bugs/bug.php?id=12411

Basically the mailer function has problems with a lot of modern style unicode filenames.

This is a big issue for our users, and the solution seems simple which is just to replace the civicrm PEAR mail library (in Packages/mail) with the latest version from here:
http://pear.php.net/bugs/roadmap.php?package=Mail_Mime&showold=1

My question is, if I use the new version of the package in my civicrm install, is there likely to be a compatibility problem, and my second (more important) question is;
Is there any chance we can include the latest version of this library (with the patches) in an upcoming civicrm release? (it doesn't appear to be in 3.1.5)

Hmm ok then, more complex than I hoped!

Not sure about MailMIME error that you coded around, but it looks like the version shipped with Civi is dated 2007 so if there was a bug logged with the Mail project I reckon its likely to have been fixed by now. I'm not sure what to search for otherwise I'd try and find out for you.

Perhaps I will wait for the upgrade and try to make sure the users use short filenames in the short term. It would be absolutely great if this can be incorporated into the next version of Civi...

I upgraded Mail, Mail_Mime, Mail_mimeDecode and Net_SMTP for CiviCRM 3.2 and – after testing that it seems to finally work without abominable workarounds – finally dropped CRM_Utils_Mail_FixedMailMIME.

We’ll see how well it works in 3.2.beta3 (to be released this week), but hopefully CiviCRM 3.2 will resolve these issues for you.