ID: 22355 Updated by: [EMAIL PROTECTED] Reported By: jotta at mailbox dot hu -Status: Open +Status: Closed Bug Type: Mail related Operating System: Linux 2.2.20 PHP Version: 4.2.3 New Comment:
This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. Keep in mind that your code will still not work as is, RFC 822 specifies that the "separator" must be CRLF followed by atleast one \t or a space. This means you should use \r\n\t and not \n\t. Previous Comments: ------------------------------------------------------------------------ [2003-02-24 09:17:12] jotta at mailbox dot hu It wasn't the sendmail binary, because after encountering the problem I've moved to call sendmail directly via popen(), and e-mail sending works this way properly (ofcourse I'm passing the same multiline $subject variable to sendmail through fputs). I've found the part of the code I believe to cause the problem in ext/standard/mail.c (in the source of the latest, 4.3.1 release, though I encountered the bug itself in 4.2.3 first): PHP_FUNCTION(mail) { /* ...cut... */ if (subject_len > 0) { for (; subject_len; subject_len--) { if (!isspace((unsigned char) subject[subject_len - 1])) { break; } subject[subject_len - 1] = '\0'; } for(i = 0; subject[i]; i++) { if (iscntrl((unsigned char) subject[i])) { subject[i] = ' '; } } } /* ...cut... */ The second 'for' cycle must be responsible for replacing all the new line characters to spaces. I think it was used because the developers wanted to avoid the extra leading/trailing linefeeds in the Subject: line (that also leads to send incorrectly formatted (and displayed) e-mails). If you agree, I'd suggest replacing this part of code to another one which is trimming only the leading/trailing control characters - or even a more sophisticated one that would format the subject line to conform to RFC 822, part 3.1.1 "Long header fields", part 3.4.8 "Folding long header fields". [In fact, I'd suggest doing these modifications also to the recipient address (the 'To:' field) for the same reason.] ------------------------------------------------------------------------ [2003-02-23 21:50:15] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip I've tried the code & looked over the source and there is nothing that would 'strip' newlines as you suggest. If they are still being stripped in the new code I would say it is the doing of your sendmail binary. ------------------------------------------------------------------------ [2003-02-21 09:09:22] jotta at mailbox dot hu Before sending an email, first I'm using mb_encode_mimeheader() to prepare the subject (it's very important because of the Central European national characters) $subject = mb_encode_mimeheader( trim($_POST['i_subject']), 'iso-8859-2', 'Q', "\n\t" ); \n\t is used, because e-mail RFCs state, that long lines should look be broken like this: Subject: very long subject etc. etc. and will continue here The problem exactly: mail() function strips the \n characters, this way the e-mails are sent in a non-standard way (even 200+ characters long subject lines), and therefore some servers and/or mail reading softwares fail to transfer/display the email correctly. ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=22355&edit=1
