Package home | Report new bug | New search | Development Roadmap Status: Open | Feedback | All | Closed Since Version 1.10.12

Bug #10232 Gmail creates double line break when \r\n is used
Submitted: 2007-03-01 15:51 UTC
From: stephen dot bigelis at gmail dot com Assigned: cipri
Status: Closed Package: Mail_Mime (version 1.3.1)
PHP Version: 4.4.1 OS: 4.11-STABLE FreeBSD
Roadmaps: 1.4.0, 1.4.0RC1    
Subscription  


 [2007-03-01 15:51 UTC] stephen dot bigelis at gmail dot com (Stephen Bigelis)
Description: ------------ Emails come in as attachments. Because the added line break prevents gmail from parsing the boundary description. I don't believe it is necessary for any email clients to put a line break in before the boundary definition, so I just removed it. (I checked a ton of mime newsletters in my own mail box and the majority just used a tab.) Then gmail would recognize the email, but the html-code was being displayed because of added line breaks in the section headers. So I manually changed them to "\n", then any lines of html longer then 76 char were displaying wrong because of the added line break in the html, so I changed the end of line marker in _quotedPrintableEncode(); Please note that you can't just define MAIL_MIMEPART_CRLF as "\n" that will cause a ton of other problems. The temporary fix I am currently using takes place entirely in mimePart.php. First in the encode function: function encode() { $encoded =& $this->_encoded; if (!empty($this->_subparts)) { srand((double)microtime()*1000000); $boundary = '=_' . md5(rand() . microtime()); $this->_headers['Content-Type'] .= ';' . "\t" . 'boundary="' . $boundary . '"'; // Add body parts to $subparts for ($i = 0; $i < count($this->_subparts); $i++) { $headers = array(); $tmp = $this->_subparts[$i]->encode(); foreach ($tmp['headers'] as $key => $value) { $headers[] = $key . ': ' . $value; } $subparts[] = implode("\n", $headers) . MAIL_MIMEPART_CRLF . MAIL_MIMEPART_CRLF . $tmp['body']; } $encoded['body'] = '--' . $boundary . "\n" . implode('--' . $boundary . "\n", $subparts) . '--' . $boundary.'--' . "\n"; } else { $encoded['body'] = $this->_getEncodedData($this->_body, $this->_encoding) . MAIL_MIMEPART_CRLF; } // Add headers to $encoded $encoded['headers'] =& $this->_headers; return $encoded; } and then to make your html properly display you must change: $eol = "\n"; in _quotedPrintableEncode(); So far I have tested this in gmail, hotmail, yahoo, aol, lotus notes, & thunderbird. I haven't had a problem yet, but I suspect there has got to be client out there that won't like it. Test script: --------------- '; // Add a valid email here $headers= array('From' => $from, 'Subject' => $subject); $textMessage='This is a text message thank you'; $htmlMessage='Invite
This is an HTML message
thank you
'; $mime = new Mail_Mime(); $mime->setTxtBody($textMessage); $mime->setHtmlBody($htmlMessage); $body = $mime->get(); $hdrs = $mime->headers($headers); $mail = &Mail::factory('mail'); $mail->send($to, $hdrs, $body); if($mail){ echo "Note: Your Message has been sent"; } else { die('FATAL ERROR: '); } //else ?> Expected result: ---------------- Gmail header should look like this: Message-ID: <20070301151528.45850.qmail@df25.myhost.com> To: myemail@gmail.com Subject: test Mime-Version: 1.0 From: Stephen Bigelis Content-Type: multipart/alternative; boundary="=_ce8703e586c1d5b49955824c21e1da92" --=_ce8703e586c1d5b49955824c21e1da92 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit This is a text message thank you --=_ce8703e586c1d5b49955824c21e1da92 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Invite
This is an HTML message
thank you
--=_ce8703e586c1d5b49955824c21e1da92-- Actual result: -------------- Gamil header comes in looking like this: Message-ID: <20070301152312.48208.qmail@myhost.com> To: myemail@gmail.com Subject: test2 Mime-Version: 1.0 From: Stephen Bigelis Content-Type: multipart/alternative; boundary="=_76d9d1e8ab8f2f3a4a8cd53c1616536b" --=_76d9d1e8ab8f2f3a4a8cd53c1616536b Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit This is a text message thank you --=_76d9d1e8ab8f2f3a4a8cd53c1616536b Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Invite
This is an HTML message
thank you
</body><html> --=_76d9d1e8ab8f2f3a4a8cd53c1616536b--

Comments

 [2007-03-08 17:21 UTC] cipri (Cipriano Groenendal)
Thank you for taking the time to report a problem with the package. Unfortunately you are not using a current version of the package -- the problem might already be fixed. Please download a new version from http://pear.php.net/packages.php If you are able to reproduce the bug with one of the latest versions, please change the package version on this bug report to the version you tested and change the status back to "Open". Again, thank you for your continued support of PEAR. Please try the new Mail_Mime 1.4.0a1 package as it contains a lot of fixes.
 [2007-04-05 08:38 UTC] cipri (Cipriano Groenendal)
No feedback, Bug moved to release 1.4.0a3
 [2007-04-07 16:38 UTC] cipri (Cipriano Groenendal)
We are unable to reproduce the bug as reported. Please provide a simple script (10 lines or less) or a link to an external script that can be used to reproduce the bug. If you can provide the script, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PEAR. I've tried this myself with the current 1.4.0a3 release, but I can't reproduce it. Your test script arrives in my gmail box without any problems and is 100% readable.
 [2007-04-12 10:27 UTC] cipri (Cipriano Groenendal)
As it turns out after much debugging, this is not a problem with Mail_Mime, 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 following PHP Bug 15841 Also, as it turns out, this is a duplicate of the PEAR::Mail Bug #8724
 [2007-05-05 15:06 UTC] cipri (Cipriano Groenendal)
Thank you for your bug report. This issue has been fixed in the latest released version of the package, which you can download at http://pear.php.net/get/Mail_Mime Fixed in 1.4.0