|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #22355 mail func strips linefeeds from subject
Submitted: 2003-02-21 09:09 UTC Modified: 2003-02-24 13:44 UTC
From: jotta at mailbox dot hu Assigned:
Status: Closed Package: Mail related
PHP Version: 4.2.3 OS: Linux 2.2.20
Private report: No CVE-ID:
 [2003-02-21 09:09 UTC] 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 = 

\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.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2003-02-23 21:50 UTC]
Please try using this CVS snapshot:
For Windows:

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-24 09:17 UTC] 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):

/* ...cut... */ 
if (subject_len > 0) {
 for (; subject_len; subject_len--) {
  if (!isspace((unsigned char) subject[subject_len - 1])) {
  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-24 13:44 UTC]
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
In case this was a documentation problem, the fix will show up soon at

In case this was a website problem, the change will show
up on the 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.
 [2004-10-05 16:09 UTC] kawaiisteph at yahoo dot com
The subject line is in Japanese text and is extremely long, so that it takes several minutes to open.  It can not be deleted and also can not be opened.
PHP Copyright © 2001-2015 The PHP Group
All rights reserved.
Last updated: Mon Apr 27 17:02:08 2015 UTC