Description: ------------ An extra newline in the main "Content-type:" header right before the boundary= bit makes for invalid MIME according to this Mime Lint tool: http://www.apps.ietf.org/msglint.html Gmail fails to display the message and shoves all the content into an "noname" attachment. Gmail *hates* extra newlines and *hates* \r\n in the headers :-( A sample message output is provided in "Test script:" The actual PHP code is pretty much lifted verbatim from the example on php.net so I won't bore you with it. Test script: --------------- Delivered-To: richardlynchchicago@gmail.com Received: by 10.142.48.18 with SMTP id v18cs64351wfv; Thu, 6 Dec 2007 07:01:10 -0800 (PST) Received: by 10.100.214.15 with SMTP id m15mr6875501ang.1196953270369; Thu, 06 Dec 2007 07:01:10 -0800 (PST) Return-Path: Received: from mail.complaints.com ([74.201.1.7]) by mx.google.com with ESMTP id 36si556094nzk.2007.12.06.07.01.04; Thu, 06 Dec 2007 07:01:10 -0800 (PST) Received-SPF: fail (google.com: domain of sagacitydev@mail.complaints.com does not designate 74.201.1.7 as permitted sender) client-ip=74.201.1.7; Authentication-Results: mx.google.com; spf=hardfail (google.com: domain of sagacitydev@mail.complaints.com does not designate 74.201.1.7 as permitted sender) smtp.mail=sagacitydev@mail.complaints.com Date: Thu, 06 Dec 2007 07:01:08 -0800 (PST) Message-Id: <47580eb4.240b240a.3257.ffffb848SMTPIN_ADDED@mx.google.com> Received: by mail.complaints.com (Postfix, from userid 1001) id 76F084AC25C; Thu, 6 Dec 2007 09:01:05 -0600 (CST) To: "Richard Lynch" Subject: Re: Test Complaint MIME-Version: 1.0 From: "Complaints.com" Reply-to: "Complaints.com" Content-Type: multipart/alternative; boundary="=_9748ed5ba1974422fcf5f37c5b12b7d0" Message-Id: <20071206150105.76F084AC25C@mail.complaints.com> Date: Thu, 6 Dec 2007 09:01:05 -0600 (CST) --=_9748ed5ba1974422fcf5f37c5b12b7d0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="ISO-8859-1" Dear Richard Lynch; Thank you for emailing us your Complaint. You must visit this URL to finish: https://post-dev.complaints.com/manage.php/9613e6684e4fa50d3b3b183ba8e65111 By emailing your message to Complaints.com you agree to the Terms/Privacy of Complaints.com http://www-dev.complaints.com/terms_privacy.htm -- Complaints.com - consumers in control --=_9748ed5ba1974422fcf5f37c5b12b7d0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="ISO-8859-1"

Dear Richard Lynch;

Thank you for emailing us your Complaint.

You must visit this URL to finish:
https://post-dev.complaints.com/manage.php/9613e6684e4fa50d3b3= b183ba8e65111

By emailing your message to Complaints.com you agree to the Terms/Privac= y of Complaints.com
http://www-dev.= complaints.com/terms_privacy.htm

--=20 Complaints.com - consumers in control --=_9748ed5ba1974422fcf5f37c5b12b7d0-- Expected result: ---------------- I'd like to see that extra blank line before the boundary= in the headers gone so that the message is compliant, assuming the Lint tool is correct. When I take it out, the Lint tool is much happier. More importantly, I just want GMail users to be able to actually read the messages Mail_Mime generates. Right now, I can't really use Mail_Mime because the boss uses gmail, so he goes to test the system, and kablooey. :-( I had hoped this was all fixed in 1.4.0 as discussed in the last two notes of this bug report (which is two separate issues): http://pear.php.net/bugs/bug.php?id=30 But it would seem that either an extra \r\n has crept back in, or there's just one too many \n in there, and it's yet another separate newline issue that freaks out the very brittle Gmail. YOU ROCK!!! PS I've asked GMail support to lighten up and accept the not-quite-valid Mime, but I don't really expect that to yield results.

This comment just tries to add some info. Looking at the mime.php file, the function _encodeHeaders() uses \r\n as headers newline sequence. $imePrefs['line-break-chars'] = "\r\n"; //Specified in RFC2047 Although this follows the RFCs, some MTAs (e.g. qmail) seem to have problems with the php-\r\n pair. In fact, changing "\r\n" to "\n" makes the problem disappear in gmail. HTH, cesare

For package users to make GMail work properly: 1. make the change that [2008-02-01 17:22 UTC] cesare suggested AND 2. make sure to instantiate the package using new Mail_mime("\n") or call define('MAIL_MIME_CRLF', "\n") before new Mail_mime(). To the maintainers of this package: I can confirm that this issue still applies to the current CVS (mime.php,v 1.87). GMail renders (HTML?) e-mails incorrectly when using \r\n in the headers (it expects \n). I do understand that they might not follow the RFC but nobody can ignore gmail users as there are so many of them. Please at least replace all \r\n sequences in Mail_Mime to MAIL_MIME_CRLF so that line endings can be changed from the outside. I have attached a diff but it doesn't contain all occurences. Also, I have reviewed the code and I'd suggest the removal of the global MAIL_MIME_CRLF constant in the favor of the private $_eol variable which can be set through the class constructor. Thanks and Best Regards, Norbert

This bug has been fixed in SVN. 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.