Correct me if I'm wrong, but i think this PR doesn't resolve issue in all cases. If mail.add_x_header is On bug will still reproduce. I've tested on PHP 5.6.10, but on 5.4 should be the same.
Look at php_mail:

if (PG(mail_x_header)) {
    const char *tmp = zend_get_executed_filename(TSRMLS_C);
    char *f;
    size_t f_len;

    php_basename(tmp, strlen(tmp), NULL, 0,&f, &f_len TSRMLS_CC);

    if (headers != NULL) {
        spprintf(&hdr, 0, "X-PHP-Originating-Script: %ld:%s\n%s", php_getuid(TSRMLS_C), f, headers);
    } else {
        spprintf(&hdr, 0, "X-PHP-Originating-Script: %ld:%s", php_getuid(TSRMLS_C), f);
    }
    efree(f);
}

If headers != NULL (e.g. empty string) option mail.add_x_header will generate mallformed header.
Test script:

<?php
$to = 'user@company.com';
$subject = 'Test Subject';
$message = 'A Message';

var_dump( mail($to, $subject, $message) );
var_dump( mail($to, $subject, $message, '') );
var_dump( mail($to, $subject, $message, null) );

Output when mail.add_x_header=Off:

$ ./sapi/cli/php -c php.ini-development -d sendmail_path='tee mailBasic.out >/dev/null' -d mail.add_x_header=Off -f test.php
bool(true)
bool(true)
bool(true)

And if mail.add_x_header=On:

$ ./sapi/cli/php -c php.ini-development -d sendmail_path='tee mailBasic.out >/dev/null' -d mail.add_x_header=On -f test.php
bool(true)
PHP Warning:  mail(): Multiple or malformed newlines found in additional_header in /home/dharrya/work/sources/php-5.6.10/test.php on line 7

Warning: mail(): Multiple or malformed newlines found in additional_header in /home/dharrya/work/sources/php-5.6.10/test.php on line 7
bool(false)
PHP Warning:  mail(): Multiple or malformed newlines found in additional_header in /home/dharrya/work/sources/php-5.6.10/test.php on line 8

Warning: mail(): Multiple or malformed newlines found in additional_header in /home/dharrya/work/sources/php-5.6.10/test.php on line 8
bool(false)

Why is this against 5.4? Is there a security issue related to this?

@smalyshev I was working on the branch. That's the main reason.

@buglloc Thank you for your comment. I'll handle it later.
BTW, did you test this code?

@yohgaki is this caused by your recent patch? We may have then to fix it in 5.4 if it's a recent regression.

@smalyshev Yes. I think it can be in 5.4.

It seems to me this is a recent regression introduced by 448013a, which doesn't really fix any security issue (prematurely ending the email headers is not the main issue wrt. email header injection, if any at all) , but rather breaks some code which is relying on the former behavior.

Anyhow, PHP 5.4. is in security fix mode now, so any bug fix that is not security related is out of scope.

@cmb69 since this problem is a regression caused by a recent fix to 5.4, I think it should be fixed in 5.4 even if strictly speaking it's not a security bug.

Merged as cd9c39d. @yohgaki please check it is ok and doesn't have any issues.

Hmm...
@yohgaki Just as @buglloc already posted, if mail.add_x_header is On, the bug still occurs on PHP 5.6.11.

@elkangaroo I can confirm the issue for Windows only. On which OS did you test?

I can confirm the issue for Windows only.

No, 5.6.11 is broken in this regard on all systems, but the bug has already been fixed in 5.6.12RC1.

@cmb69 tested on Ubuntu 14.04 with PHP 5.6.11.

Thanks for the info, that it will be fixed in the next release - do you know which commit? Cause it's not meantioned under https://github.com/php/php-src/blob/php-5.6.12RC1/NEWS.

@elkangaroo Well, the relevant commit is the one which closed this PR on June, 29th (cd9c39d). Apparently, it was too late to include it into PHP 5.6.11. Most likely the fix is not mentioned in NEWS, because there has been no explicit bug report about it.