The fifth one doesn't work because it contains a space. Only one parameter without space is allowed currently . . .

Thanks for your extremely fast answer. Anyway, it is a real problem in that case. From the sendmail docs:  "Note that there _must_ be a space between the letter 'O' and the name of the option."

Btw, the combination of these two options worked in the 4.0.5/4.0.6 version of PHP.

I don't like this behaviour either but there are some pretty security concerns here. Maybe this can be sorted out, but I can't tell you anything right now. Don't count on this being changed soon.

Not allowing a space is not totally true. The parameter is escaped accoding the rules of shell_escape (which add's ' around the script and escapes existing ''s).

Derick

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.

Kudos to Derick, he fixed the issue.

Basically, if safe_mode is on, the fifth parameter is prohibited. If it's off, it now should work with spaces to (right Derick?), closing.

If there can be only ONE optional 5th parameter, then the PHP documentation needs to reflect that.  I tried to do a
"-f$SENDER -pHTTP:$SERVER_NAME ..." (i.e. 2 or more parameters) and found that it was all passed as a single string (the entire string treated as the target of the "-f").  I am using PHP 4.2.3 and Sendmail 8.12.6 under Linux (kernel 2.4.20).

Please fix this by chopping this up into the appropriate argv/argc type array when exec'ing the mail program.  If necessary, redefine the 5th parameter as type=ARRAY.

I looked at the source code for the mail function and noted that before the exec call, the string passed is effectively SENDMAIL_PATH+" "+5th_PARAMETER (i.e. system() usable!), but apparently, it's not being parsed correctly after that in the exec routine.  This would be the fault of the popen() function or the php_escape_shell_arg() function that was recently added as a prior workaround.  I suspect the workaround, as the popen() function is a system library function that does do a system()-type call in a pipe.

If I comment out the php_escape_shell_arg() call in ext/standard/mail.c, then the multiple parameters work, except for any "to" addresses also passed in this parameter list for setting the envelope (regardless of being bracketed by "<>" or not).  I haven't tried this with an addslashes() call.  Therefore, I conclude that your php_escape_shell_arg() call may have fixed one problem but also introduced another.