Doc #63778 [Opn->Asn]: RFC-2822 does NOT permit LF without CR

Edit report at https://bugs.php.net/bug.php?id=63778&edit=1 ID: 63778 Updated by: aharvey@php.net Reported by: Andy_Schmidt at HM-Software dot com Summary: RFC-2822 does NOT permit LF without CR -Status: Open +Status: Assigned Type: Documentation Problem Package: Documentation problem PHP Version: Irrelevant -Assigned To: +Assigned To: aharvey Block user comment: N Private report: N New Comment: Since we just went through this process with headers (long story short: we still recommend \r\n there), we should line the message documentation up with that. Previous Comments: ------------------------------------------------------------------------ [2012-12-18 14:29:36] Andy_Schmidt at HM-Software dot com I beg to disagree and hope to be clarify with this follow-up. I believe we do agree that this section of the manual gives specific samples with respect to SMTP headers - it IS about SMTP messages. In this case, there are written standards the designate the proper format of such messages - revised SPECIFICALLY to clarify previous ambiguity regarding the line-end (because of programmers in certain operating systems getting it consistently wrong). If you can, would you kindly point me to the standard that defines that MTAs "must" or even "should" REPLACE single LF with LF/CR combinations? I have run into very many that do NOT (which is the reason why I see hundreds of these malformed message bodies in our gateway filters every single day - usually from PHP form handlers). IF there are MTAs out there that have a LF to CF/LF "fix-up" feature that the standards neither call for nor require, then this optional feature obviously should have been implemented in a way that VALID message bodies are NOT garbled by it. It would be trivial to fix this bug so that only stand-alone LFs are translated, but existing CF/LFs are not. I therefore submit that any MTA that takes a VALID message body (with CR/LF line endings) and turns it into CF/LF/LF is itself not standards compliant and such a bug should be reported -- instead of perpetuating this incorrect behavior in the PHP manual. ------------------------------------------------------------------------ [2012-12-17 20:27:18] mail+php at requinix dot net Actually no. What you're missing is that PHP itself does not send the email. It goes through sendmail (and whatever application that may be). MTAs will convert \n to \r\n but some do so regardless of the actual line ending used, so if you provide \r\n yourself then it may become \r\r\n. Using \n is best for compatibility. ------------------------------------------------------------------------ [2012-12-15 15:09:26] Andy_Schmidt at HM-Software dot com Description: ------------ --- From manual page: http://www.php.net/function.mail#refsect1-function.mail-parameters --- Your manual incorrectly states for the "Message" parameter: "Each line should be separated with a LF (\n). Lines should not be larger than 70 characters." Refer to the governing Internet standard on SMTP emails: http://www.ietf.org/rfc/rfc2822.txt 2.1 "A line is a series of characters that is delimited with the two characters carriage-return and line-feed; that is, the carriage return (CR) character (ASCII value 13) followed immediately by the line feed (LF) character (ASCII value 10)." and it clarifies further: 2.3 "CR and LF MUST only occur together as CRLF; they MUST NOT appear independently in the body." Your manual should be updated to read: "Each line should be separated with a CRLF (\r\n). Lines should not be larger than 78 characters." ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=63778&edit=1