Description: ------------ This bug should not depend on a php version and most probably affects all of the sending options. The _sanitizeHeaders() method removes the 'boundary' section from the 'Content-Type' header which causes problems with some email systems (notably GMail) by not interpreting the attachments correctly. I have did a lot of debugging and the header is not altered until the _sanitizeHeaders() call. To test, run the test script. Then comment out the _sanitizeHeaders() call in the Mail_sendmail::send method and run the script again. Use a GMail account for the to address to see what happens for GMail users. Test script: --------------- $mail = Mail::factory( 'sendmail' ); $message = new Mail_mime(); $txt = 'A txt message'; $html = 'An html message'; $message->setTXTBody( $txt ); $message->setHTMLBody( $html ); $body = $message->get(); $recipient = 'Your Name <your-email@gmail.com>'; $headers = array( 'To' => $recipient, 'From' => 'test@example.com', 'Subject' => '_sanitizeHeaders() test' ); $headers = $message->headers( $headers ); $result = $mail->send( $recipient, $headers, $body ); if ( PEAR::isError( $result ) ) : echo $result->getMessage(); endif; Expected result: ---------------- It should work for GMail. Actual result: -------------- With _sanitizeHeaders() on, GMail will give a message with no body and a 'noname' attachment.

This bug hit us this morning as well. It looks like the "\\n" in the _sanitizeHeaders regex is removing the second half of the Content-type header, since it is two lines. This nukes "boundary" and makes the message unreadable by Gmail. As a temporary fix, I've changed the regex to read: preg_replace('=(<CR>|<LF>|0x0A/%0A|0x0D/%0D|\\n|\\r)[^[:blank:]]+=', null, $value); This should still protect against injection to some degree because the mail headers can't have whitespace before them. However, it allows "boundary" to pass through properly. Just a suggestion. :)

Unassigning this from me. I no longer maintain the Mail package.

so ? a solution about Gmail problem ?

I had the same in a bug report for Mail_Mime (Bug #8724). As it turns out after much debugging, this is not a problem with Mail_Mime/Mail, but with a local qmail mailer not liking headers seperated by \r\n. One should always use the EOL as used on the current OS (Available in the define PHP_EOL) as EOL. For more information please see the PHP Bug 15841

Submitter, does PHP Bug 15841 / Cipri's comment resolve your problem?