ID: 15841 Comment by: philipp dot kempgen at amooma dot de Reported By: rha at juggernaut dot com dot au Status: No Feedback Bug Type: Mail related Operating System: Linux PHP Version: 4.1.2 Assigned To: yohgaki New Comment:
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. Previous Comments: ------------------------------------------------------------------------ [2008-10-16 13:12:44] devnull at div dot org 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 :) ------------------------------------------------------------------------ [2007-02-21 09:16:42] m_alpka at tlen dot pl 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 ------------------------------------------------------------------------ [2007-02-07 10:05:27] tony2...@php.net http://www.php.net/manual/en/reserved.constants.php PHP_EOL (string) Available since PHP 4.3.10 and PHP 5.0.2 ------------------------------------------------------------------------ [2007-02-07 09:55:43] bigtree at donotspam dot 29a dot nl 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. ------------------------------------------------------------------------ [2006-11-30 08:10:38] tech+ohtf dot cuc dot arg at onlineopinion dot com dot au 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'. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/15841 -- Edit this bug report at http://bugs.php.net/?id=15841&edit=1
