Bug #10232 :: Gmail creates double line break when \r\n is used

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	Your email:

Comments Add Comment Add patch

[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