Description: ------------ When creating a multi part email message with HTML and Text alternative, with an attachment. The mimePart.php file is creating the same boundary for the multi part/alternative and the attachment boundary. This causes most web mail clients to not display, or allow the attachment to be downloaded. I could not find any direct references to this bug, so I apologize if this is a duplicate. Test script: --------------- $mime = new Mail_mime("\r\n"); $mime->setHTMLBody($htmlMsg); $mime->setTXTBody($txtMsg); $mime->addAttachment($fileName.".pdf", "application/pdf", "CompletionCertificate.pdf", true, 'base64', 'inline'); $msg = $mime->get(); $hdr = $mime->headers(....); $mailer = MAIL::factory("mail"); $mailer->send($to, $hdr, $msg); Expected result: ---------------- The message should display in HMTL or Text depending on the users mail client and preference, and should allow the user to download the attachment. What happens in most web mail clients (stand alones such as Thunderbird, seem to work fine) is both the text and html are displayed and the attachment cannot be downloaded. Actual result: -------------- Not sure if this is the right box to put this , but. I actually edited the mimePart.php file and got the boundaries to create as expected. On line 243 there is this line: srand((double)microtime()*1000000); This was causing the random boundary to be the same. As of PHP 4.2, srand is no longer needed. I would suggest adding version check line and only calling srand if < 4.2. In my case, I just commented the line out, and my emails started to work as expected.

This bug still exists, and is very real. Essentially, Mail_Mime is busted for any multipart/alternative included within any other multipart wrapper. The fix suggested by Derek Carlson works beautifully.

Further to this, it is now worth noting that GMail and Apple Mail both reject these bogus boundary values and render the email as *empty*. i.e Mail generated by Mail_Mime is useless.

I just have noticed the same problem. I think the problem lies in the quite less than ideal implementation of boundary generation: MimePart::encode() ... srand((double)microtime()*1000000); $boundary = '=_' . md5(rand() . microtime()); ... On a platform with low microtime() resolution (either hardware or os related) this is basically is the same as '$boundary = 1'. The srand() call guarantees that the rand() in the next line is just a fancy scrambled version of microtime(). Thus the boundary will be the same on every encode() call. Solution: Remove the srand() line.

This bug has been fixed in CVS. If this was a documentation problem, the fix will appear on pear.php.net by the end of next Sunday (CET). If this was a problem with the pear.php.net website, the change should be live shortly. Otherwise, the fix will appear in the package's next release. Thank you for the report and for helping us make PEAR better.