This is causing mail generated by PHP to be BLOCKED as being potentially a virus by some anti-virus SMTP servers.

The presence of "\r\n" in headers is typically a sign of a virus trying to reach Outlook. Some antivirus products now totally block MIME mail containing "\r\n".

This means all mail generated by PHP programs...

on windows we *do* talk STMP ...

The Right Thing(TM), then, is to determine which method (direct or SMTP injection) is being done. If SMTP, use \r\n. If direct, determine what the OS' line terminator is (\r\n for Windows, \n for Unix, \r for Mac (?!)) and use that instead.

i still do not see the point, even for unix/sendmail

even /usr/lib/sendmail will transfer the message
using SMTP, and during this step you will have
\r\n line endings anyway, or am i missing something?

The point is that it is incorrect to send DOS line endings to a Unix command line program.

Sending a message through qmail (for example) with \r\n line endings results in extraneous \r's in the delivered email. qmail assumes the user knows what they're doing and converts only the '\r' characters to '\r\n'. So if you use '\r\n' it injects '\r\r\n' into the SMTP conversation.

e.g. 
Headers:
"X-1: test1\nX-2: test2\r\nX-3: test3\r\nX-4: test4:

Message:
Subject: test message
X-1: test1
X-2: test2^M
X-3: test3^M
X-4: test4

I notice that some mail readers sanitize the incoming message and strip the extra \r's (e.g. Eudora) but Mozilla doesn't and only the first extra header is displayed as a header while the others appear in the body of the message.

ok

1) blame qmail, it should know better ...
2) lets have SMTP as a default implementation
   for Unix mail(), too, instead of relying
   on external programs

the "it isn't broken, so don't fix it" argument
got even weaker right now ...

reclassified

I would be VERY nice if PHP would at least have the option of sending mail using SMTP when running under Unix.  It seems silly to support the option only when running under Windows, especially when the code is already written.

I looked for CRLF in source, but I cannot find CRLF with quick glance of current CVS source.
It seems mail.c is not converting LF to CRLF.

Are you using qmail-inject or qmail sendmail wrapper?
I don't have any problem with qmail-inject nor qmail's sendmail wrapper.

My phpinfo() says:
sendmail_path    /usr/bin/sendmail -t -i 

I'm running a vanilla qmail installation.

The mail() function works fine... it passes to the MTA whatever data the user supplies for headers, with whatever line breaks the user supplied.

The problem is that the line breaks should be unix-style on a Unix system. But they need to be DOS-style on Windows. This creates a portability issue for PHP scripts.

See my comment of 6 Mar 2:58pm for an example of the problem when using DOS-style line breaks on a Unix system.

mail() is NOT the all-in-one solution, nor is it really platform compatible. In fact, win32/mail() is a completely different kind of story (using native socket interface to talk to sendmail daemon on port 25) then on unix (calling another executeable and exchanging data)

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".

Documentation of mail() states:

"Note:  You must use \r\n to separate headers, although some Unix mail transfer agents may work with just a single newline (\n)."

This is WRONG. On Unix systems, any line ending (also between header fields) has to be \n. On Windows Systems, it has to be \r\n.

Here is part of the sounce code in mail.c (in case of a Unix system):
	sendmail = popen(sendmail_cmd, "w");
	fprintf(sendmail, "To: %s\n", to);
	fprintf(sendmail, "Subject: %s\n", subject);
	if (headers != NULL) {
		fprintf(sendmail, "%s\n", headers);
	}
	fprintf(sendmail, "\n%s\n", message);
	ret = pclose(sendmail);

On Windows Systems, the SMTP session is handled within SendText() in sendmail.c, which sends headers and message as is, so the line endings have to be \r\n.

Please correct the above cited note and any samples.

There is a further bug in example 4:
| $headers .= "Bcc: birthdaycheck@example.com\r\n";
     remove the ending line break

The header must not end with a line break. As you can see in above code snipet, the mail implementation adds a \n at the end of the header.

BTW, this is a documentation problem.

Hi,

I would really want official PHP Team confirmation for 
comments [18 Apr 2:46pm CEST] and [6 Mar 2002 11:04am 
CET].
I'm facing the same problem on FreeBSD 5.x, mod_php4
-4.3.6_1,1
If you follow the documentation (using \r\n) mail() will 
output badly formated headers. Many SMTPds or Filters 
will rewrite headers (sendmail does, Amavisd-new does, 
..., but postfix alone doesn't, for example)

I've set up a shell script to pipe mail()'s output into 
a file rather than into a SMTP : 

  $ more /usr/local/sbin/sendmail.cat 
  #!/bin/sh
  cat > /tmp/mailout

then I've set sendmail path to /usr/local/sbin/
sendmail.cat in httpd.conf : 

  php_admin_value sendmail_path "/usr/local/sbin/
sendmail.cat"

using \r\n as a header separator results in a mix of \n 
and \r\n :

  $ cat -v /tmp/mailout
  To: patpro@example.com
  Subject: un dernier test
  From: patpro@example.com^M
  Reply-To: patpro@example.com^M
  Content-Type: text/html; charset=iso-8859-1^M
  MIME-Version: 1.0^M
  Content-Transfer-Encoding: 8bit^M

this mix is not RFC compliant and breaks rendering in 
many mail clients.

It would be nice to change the php documentation 
accordingly, and even nicer to provide mail() with the 
ability to reformat headers.

I suddenly had header problems. Perhaps my host changed mail configs or updated PHP (they never reply to my email, so I don't ask many question). In any case, all my beautiful HTML emails were being sent out with broken headers that yturned them into ugly unreadable text and code.

I am on a Unix server, so I changed all my /r/n newlines to /n. This fixed the issue immediately. If you find this happens to you, just use the appropriate newline characters for your host OS.

THANKS for pointing out this bug!

I agree with @patpro, mail() should reformate the headers.

This is my quick-and-dirty workaround (from a Q&D specialist) , in /etc/php.ini :

sendmail_path = "unix2dos|dos2unix|sendmail -t -i"


Guyzmo -- (don't let me programm after midnight)

So has there been any resolution to this? Has PHP made any modifications to their mail function? or provided a better work around?

what php needs is to make the $headers argument for the mail() function an array instead of a string and then php will automagically put the correct line endings depending on what OS it's running on. \n for unix, \r\n for windows, \r for mac

you can keep it backwards compatiable by accepting a string as well. also add another option in the php.ini to enable/disable the mangling of the header line endings.

could we get an update on this bug please?

nevermind, please delete my previous comment. qmail is broken and dead. let's just move forward instead of trying to support legacy software and holding technology back.

please close this ticket and label it as "will not fix," which i suppose is the correct status.

The PHP documentation now asks for "\n" , which is correct for its implementation in Unix systems, so the bug as originally reported is solved. I can't comment on whether this change might have caused problems in Windows, but I assume not.

Note: This was not just an issue with qmail; it also affected postfix's implementation of 'sendmail'.

Might I suggest to add a platform-dependant PHP constant (for example MAIL_HEADER_SEPARATOR) so we can use the mail() function with platform-independent code?

The constant value would be '\n' on unix and '\r\n' on windows.

http://www.php.net/manual/en/reserved.constants.php

PHP_EOL (string) 
Available since PHP 4.3.10 and PHP 5.0.2

I discovered another temporary solution. It's similar to @guy's but it is not using additional scripts that have to be installed (unix2dos,dos2unix). Also php didn't allow me to use piped sendmail in sendmail_path (php.ini)
I'm using qmail.

---
cd /var/qmail/bin
cat > sendmailfix

#!/bin/sh
sed 's/^M$//' | /var/qmail/bin/sendmail ${1+"$@"}
[Ctrl+D]

chmod 555 sendmailfix
chgrp popuser sendmailfix
---
^M is a combination of [Ctrl+V, Ctrl+M]

Finally set the value of sendmail_path in php.ini to our script

---
sendmail_path = /var/qmail/bin/sendmailfix -t -i

I just had a little run-in with the postfix developers over at postfix-users about this issue.

http://tech.groups.yahoo.com/group/postfix-users/message/244799

Quote:Wietse Venema:
>> Specifically, Postfix accepts local submissions in UNIX format
>> (LF) or MSDOS format (CRLF) format BUT YOU MIST NOT MIX FORMATS.
>
> So how does postfix determine what format you are using?
> Is there a way to explicitly tell it what to expect?
>
Postfix looks at the first input line. There currently is no
way to override this, so your best bet is to use the same line
terminator consistently (having a first line with CRLF might
work "best" for hybrid mail, but that behavior is not promised).

The current behavior originates from the time when binary transparency
was considered a good thing.
--

There seemed to me to be a marked hostility towards the idea of trying to be helpful about this, but on the other hand I got the impression they might not be hostile if someone offered a patch for a 
SENDMAIL_EOF_COMPAT_MODE or similar.

Personally I am not much good at C, but the challenge is hereby issued :)

Ok guys, if it's not mail() which is wrong then
it's a documentation problem.
---cut---
Note: If messages are not received, try using a LF (\n) only. Some poor quality Unix mail transfer agents replace LF by CRLF automatically (which leads to doubling CR if CRLF is used). This should be a last resort, as it does not comply with ? RFC 2822.
---cut---

This is _not_ about "poor quality" MTAs or a "last resort".

The note should read:
Note: mail() talks to the sendmail command on Unix/Linux which
expects line endings to be the platform's native line endings
which is LF (\n) only on Unix/Linux and CRLF (\r\n) on Windows.
The sendmail will replace LF (\n) by CRLF (\r\n) automatically
to comply with RFC 2822. Thus you should use the special PHP_EOL
constant to separate mail headers.

I agree totally with Philipp, the current documentation note is ridiculous.Can't developers understand that they're not dealing with a STMP server on Linux? If you don't want to fix it, at least document the flaw correctly.

This Code:
mail('nobody@example.com','test','Message Body',"From: me@example.com\r\nContent-Type: text/plain");

passes this to sendmail:

To: nobody@example.com\n
Subject: test\n
From: me@example.com\r\n
Content-Type: text/plain\n
\n
Message Body\n

(on a Ubuntu 10.04 installation from ubuntu repository)
So PHP uses \n to terminate the headers it creates on its own. It makes no sense to terminate additional headers with \r\n.