Are you sure the path is actually set? Try this:

php -d sendmail_path=/foo/bar -r 'var_dump(ini_get("sendmail_path"));'

> Are you sure the path is actually set? Try this:

Yes:
| D:\PHP>php -d sendmail_path=/foo/bar -r \
| "var_dump(ini_get('sendmail_path'));"
| string(8) "/foo/bar"
|
|D:\PHP>

Of course, setting "sendmail_path" from the command line was just for you. The same happens if I set a wrong sendmail_path in "php.ini".

And as I've written above:
mail() returns also TRUE, if "sendmail_path" is correct, but the sendmail binary exit with an error code != 0.

Propably due to wrong usage of popen() and not VCWD_POPEN(). I don't have win32 dev environment setup so someone else should deal with this.

I have confirmed this issue under a Windows Server 2003 environment, and it continues to exist in 5.3 dev. Using the imap_mail.dll and changing all references from mail() to imap_mail() seems to resolve the problem, although changing that reference everywhere is not a reasonable solution for most everyone (including us).

Pierre, this is the real issue, sendmail_path is not checked or something?

After some delay...

If've just test this with PHP 5.3.0 and mail() still returns TRUE, even if PHP can't find the sendmail binary or the sendmail binary returns an errorlevel != 0.

Regards,
Carsten)

This occurs because popen_ex executes the command using the comspec ('cmd.exe'), which will always create a valid process--but intended actual child process fails.

I'm patching this so that it skips using cmd.exe--there is really no reason this should be here, if this introduces other problems (which I can't see what they could possibly be), then those should be fixed appropriately.

Patched in all branches (5.2.11-dev, 5.3.1-dev and trunk)

or, it will be once I get some karma in /TSRM ...

Carsten, 

Can you retest with the latest 5.3 snapshot, and post feedback?

Thanks

Hi Garrett,

> Can you retest with the latest 5.3 snapshot, and post feedback?

I can do this. Just some remarks first:


> This occurs because popen_ex executes the command using the comspec
> ('cmd.exe'), which will always create a valid process--but intended
> actual child process fails.

That's correct. No error during creation of the process ("cmd.exe" / "GetLastError == 0"). But in this case, "cmd.exe" returns an exit code != 0, which is available with "GetExitCodeProcess()".  So you know there's a problem.

Regarding mail():
- mail() does not detect that "cmd.exe" can't start "sendmail.exe"

- it also does not detect, if "cmd.exe" can start "sendmail.exe",
  but "sendmail.exe" is returning an exit code != 0
  --> if "cmd.exe" can start a program, it's returning the exit
      code from that program, and so this is available with 
      GetExitCodeProcess().

So there is the question, why does mail() does not test the return value of pclose() in a correct way on windows? At the moment it looks like:
| #ifdef PHP_WIN32
| if (ret == -1)
| {
|     MAIL_RET(0);
| } else {
|    MAIL_RET(1);
| }

But I think it should be also something like?:
| if (ret != 0)


> I'm patching this so that it skips using cmd.exe--there is really
> no reason this should be here,

Some hints:
- If you want start an executable with just the name and without the
  extension (like ".com, *.pl"), you must do this through "cmd.exe"
  (only for "*.exe" files you can use just the name).
- In the MSDN you can read, that you have to use "cmd.exe" to start
  a batchfile with CreateProcess. Ok, for me that's working without
  "cmd.exe". But maybe this depends on the Windows version or
  compiler.

Regards,
Carsten

Reopened, fix was reverted.

Still unresolved.  The culprit indeed appears to be that FALSE
will only be returned, if pclose() returns -1[1], but pclose()
actually returns the exit code[2], where other values may signal
failure as well.

[1] <https://github.com/php/php-src/blob/PHP-7.2.4/ext/standard/mail.c#L618>
[2] <https://github.com/php/php-src/blob/PHP-7.2.4/TSRM/tsrm_win32.c#L633-L637>