FAQ
Edit report at http://pear.php.net/bugs/bug.php?id=12628&edit=1

ID: 12628
Updated by: alec@alec.pl
Reported By: ceo at l-i-e dot com
Summary: Extra newline causes invalid Mime, breaks GMail
Status: Open
Type: Bug
Package: Mail_Mime
Operating System: Gentoo
Package Version: 1.5.2
PHP Version: 4.4.7
-Assigned To:
+Assigned To: alec
-Roadmap Versions:
+Roadmap Versions: 1.5.3
New Comment:

-Assigned To:
+Assigned To: alec
-Roadmap Versions:
+Roadmap Versions: 1.5.3



Previous Comments:
------------------------------------------------------------------------

[2008-05-01 10:46:46] norbert

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

------------------------------------------------------------------------

[2008-02-01 12:22:02] cesare

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

------------------------------------------------------------------------

[2007-12-06 11:09:19] richardlynch

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: <sagacitydev@mail.complaints.com>
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" <richardlynchchicago@gmail.com>
Subject: Re: Test Complaint
MIME-Version: 1.0
From: "Complaints.com" <webmaster@complaints.com>
Reply-to: "Complaints.com" <webmaster@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"




<div style=3D"color: red;">

<p>Dear Richard Lynch;</p>

<p>Thank you for emailing us your Complaint.</p>

<p>You must visit this URL to finish:<br />

<a
href=3D"https://post-dev.complaints.com/manage.php/9613e6684e4fa50d3b3b1=

83ba8e65111">https://post-dev.complaints.com/manage.php/9613e6684e4fa50d3b3=

b183ba8e65111</a>

</p>

<p>By emailing your message to Complaints.com you agree to the
Terms/Privac=

y of Complaints.com<br />

<a
href=3D"http://www-dev.complaints.com/terms_privacy.htm">http://www-dev.=

complaints.com/terms_privacy.htm</a><br />

</div>



--=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.

------------------------------------------------------------------------


--
Edit this bug report at http://pear.php.net/bugs/bug.php?id=12628&edit=1

Search Discussions

  • Alec at Dec 21, 2009 at 9:53 am
    Edit report at http://pear.php.net/bugs/bug.php?id=12628&edit=1

    ID: 12628
    Updated by: alec@alec.pl
    Reported By: ceo at l-i-e dot com
    Summary: Extra newline causes invalid Mime, breaks GMail
    -Status: Assigned
    +Status: Closed
    Type: Bug
    Package: Mail_Mime
    Operating System: Gentoo
    Package Version: 1.5.2
    PHP Version: 4.4.7
    Assigned To: alec
    Roadmap Versions:
    New Comment:

    -Status: Assigned
    +Status: Closed
    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.




    Previous Comments:
    ------------------------------------------------------------------------

    [2009-12-21 07:43:40] alec

    -Assigned To:
    +Assigned To: alec
    -Roadmap Versions:
    +Roadmap Versions: 1.5.3


    ------------------------------------------------------------------------

    [2008-05-01 10:46:46] norbert

    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

    ------------------------------------------------------------------------

    [2008-02-01 12:22:02] cesare

    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

    ------------------------------------------------------------------------

    [2007-12-06 11:09:19] richardlynch

    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: <sagacitydev@mail.complaints.com>
    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" <richardlynchchicago@gmail.com>
    Subject: Re: Test Complaint
    MIME-Version: 1.0
    From: "Complaints.com" <webmaster@complaints.com>
    Reply-to: "Complaints.com" <webmaster@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"




    <div style=3D"color: red;">

    <p>Dear Richard Lynch;</p>

    <p>Thank you for emailing us your Complaint.</p>

    <p>You must visit this URL to finish:<br />

    <a
    href=3D"https://post-dev.complaints.com/manage.php/9613e6684e4fa50d3b3b1=

    83ba8e65111">https://post-dev.complaints.com/manage.php/9613e6684e4fa50d3b3=

    b183ba8e65111</a>

    </p>

    <p>By emailing your message to Complaints.com you agree to the
    Terms/Privac=

    y of Complaints.com<br />

    <a
    href=3D"http://www-dev.complaints.com/terms_privacy.htm">http://www-dev.=

    complaints.com/terms_privacy.htm</a><br />

    </div>



    --=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.

    ------------------------------------------------------------------------


    --
    Edit this bug report at http://pear.php.net/bugs/bug.php?id=12628&edit=1

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppear-bugs @
categoriesphp
postedDec 21, '09 at 7:43a
activeDec 21, '09 at 9:53a
posts2
users1
websitepear.php.net

1 user in discussion

Alec: 2 posts

People

Translate

site design / logo © 2022 Grokbase