php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #29646 mail() inserts change CRLF ("\r\n") to CRCRLF ("\r\r\n") for some extra headers
Submitted: 2004-08-13 10:31 UTC Modified: 2004-08-23 20:32 UTC
From: shelby at coolpage dot com Assigned:
Status: Not a bug Package: Mail related
PHP Version: 4.3.4 OS: FreeBSD
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: shelby at coolpage dot com
New email:
PHP Version: OS:

 

 [2004-08-13 10:31 UTC] shelby at coolpage dot com
Description:
------------
See the post for detailed description of problem, as well as fact that others are experiencing the problem:

http://www.zend.com/zend/comments/show_comment.php?article=sendmimeemailpart1&id=5733&pid=2921&days=10000&f_id=sendmimeemailpart1&mode=&kind=sl

I think the reason no one isolated this yet, is because it only manifests itself for certain extra headers and only causes a noticeable corruption in Outlook Express, even though the header corruption is occuring always.

I remembered seeing this before and remember it had something to do with extra "\r" character after a header line.

I then did a raw telnet session saved to a raw log and confirmed that the extra CR ("\r") is being inserted by mail().

I am guessing that the mail() code extracts known header lines and their "\r\n", then does str_replace( "\n", "\r\n" ) on remaining lines of extra headers?

I use pair.com as host:
php -v
PHP 4.3.4 (cli) (built: Nov  4 2003 16:10:03)
Copyright (c) 1997-2003 The PHP Group
Zend Engine v1.3.0, Copyright (c) 1998-2003 Zend Technologies

We do use Qmail.

See other relevant bug posts:

http://bugs.php.net/bug.php?id=15841&edit=2

http://bugs.php.net/bug.php?id=22262&edit=2

There seems to be no one answer of solution?





Reproduce code:
---------------
If the following headers input to mail():

"From: johndoe@domain.com\r\n" .
"Reply-To: johndoe@domain.com\r\n" .
"Date: Wed, 11 Aug 2004 08:15:15 -0400\r\n" .
"Mime-Version: 1.0\r\n" .
"Content-Type: text/plainn\r\n" .
"Content-Transfer-Encoding: 7BIT\r\n"


Expected result:
----------------
(1) In Outlook Express, you get:

From: johndoe@domain.com
Reply-To: johndoe@domain.com
Date: Wed, 11 Aug 2004 08:15:15 -0400

Mime-Version: 1.0

Content-Type: text/plain

Content-Transfer-Encoding: 7BIT


(2) In Eudora 4, you see:


From: johndoe@domain.com
Reply-To: johndoe@domain.com
Date: Wed, 11 Aug 2004 08:15:15 -0400
Mime-Version: 1.0
Content-Type: text/plainn
Content-Transfer-Encoding: 7BITT


(3) In raw text you see:

From: johndoe@domain.com\r\n
Reply-To: johndoe@domain.com\r\n
Date: Wed, 11 Aug 2004 08:15:15 -0400\r\r\n
Mime-Version: 1.0\r\r\n
Content-Type: text/plainn\r\r\n
Content-Transfer-Encoding: 7BIT\r\r\n



Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2004-08-13 11:12 UTC] shelby at coolpage dot com
Note I made two typos:

Content-Type: text/plainn\r\r\n

Should be:

Content-Type: text/plain\r\r\n

And:

There seems to be no one answer of solution?

Should be:

There seems to be no one answer or solution?

Also I would like to point out that either mail() or Qmail must be handling the CRLR after the From: dna Reply-To: headers correctly.  It is strange that only some headers are affected.  That could explain why others have not reproduced the bug reports of yore ("yore" is like 2002 apparently! :)

Now it seems I remember having this same problem (had to change my "\n" to "\r\n" between headers input to mail()) when I migrated from Pair.com to Rackspace.com (from Qmail to SendMail) and now revisiting this again when migrating back.

So what is correct work around?  Do I change all "\r\n" back to "\n" when using Qmail, or just the headers it seems to affect?

What is going to work in current and future CVS of PHP?

Please give some definitive guidance!

Having mail break for 1000 AccuSpam users (spam filter) is not pretty!

Thanks,
Shelby Moore
http://AccuSpam.com
http://CoolPage.com
 [2004-08-17 00:49 UTC] shelby at coolpage dot com
I verified that the work around this bug for my configuration (as previously mentioned) is to use "\r\n" only after the "From:", "Reply-To:", "Cc:", and "Bcc:" headers, if there is another header which follows, and to use only "\n" after other extra headers, if another header follows.

Note in my use, I only tried placing the "From:", "Reply-To:", "Cc:", and "Bcc:" headers first, and any extra headers (such as "Date:", "Mime-Versions:", etc) after.
 [2004-08-17 00:52 UTC] shelby at coolpage dot com
Thanks, but has the latest snapshot been specifically edited to fix this specific problem?

Because this problem as been around for years, and so only a specific fix is worth my time.

Also I have no way to test the latest snapshot until my host Pair.com upgrades.

I alerted Pair.com to this problem.
 [2004-08-17 00:58 UTC] shelby at coolpage dot com
Also telling us to try the latest snapshot is useless unless you tell us what is the correct use of the mail() function on Qmail.

Please see my original post and please answer the question as to what is the correct documented use.

In the meantime, I have provided a documented use in my comments on this bug which works and which I am suggesting that others link to, as a replacement for the document for PHP mail().  Hopefully that will generate enough pressure to finally fix this bug and also help people work around it in meantime!

Correction: in previous post for work around, I said "if another header follows".  I believe I insert the "\r\n" and "\n", even after the last header input to mail().
 [2004-08-17 08:11 UTC] derick@php.net
You're using a very old PHP version (4.3.4), I am very sure it was fixed since. So try that snapshot.
 [2004-08-18 19:44 UTC] shelby at coolpage dot com
No I will not do your work for you!

Your general assumption that it was fixed without specific knowledge it was fixed is not enough to make me go through the hassle.  In short I doubt your assertion it is fixed, because:

1. You have not provided specific knowledge that it was fixed.  It seems you are just hoping it was, and want me to go through hassle to prove it.  You prove it.  It is not my bug.  It is YOUR bug.

2. You closed this other similar bug report in Feb. 2003:

http://bugs.php.net/bug.php?id=22262

But I am using a version from Nov. 2003:

coolpage@qs662% php -v
PHP 4.3.4 (cli) (built: Nov  4 2003 16:10:03)
Copyright (c) 1997-2003 The PHP Group
Zend Engine v1.3.0, Copyright (c) 1998-2003 Zend Technologies

And this bug has been around since at least 2002 and has been ignored.  No related bug report has been marked as fixed.  They were both closed because the people who made the bug reports are not going to test it for you:

http://bugs.php.net/bug.php?id=22262

http://bugs.php.net/bug.php?id=15841

You method of closing bug reports because reporters are not willing to retest every time you decide to put a new version # on PHP is ridiculous.

Have it your way...fix it or do not fix it... closing this bug report does not mean it is fixed.
 [2004-08-18 23:11 UTC] iliaa@php.net
Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. 

Thank you for your interest in PHP.

Until can be verified with latest PHP version, considered 
bogus. 
 [2004-08-19 01:18 UTC] pollita@php.net
It's a qmail bug.  That MTA attempts to automagically guess newlines and does a bad job of it.
 [2004-08-23 20:32 UTC] shelby at coolpage dot com
Thanks for providing the additional information that you think it is a bug in QMail.  That would be logically consistent with my results in not having the problem with PHP on SendMail.

I have also alerted Pair.com about my work-around.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sat Nov 23 12:01:29 2024 UTC