ID:               12335
 Updated by:       [EMAIL PROTECTED]
 Reported By:      [EMAIL PROTECTED]
 Status:           Open
 Bug Type:         Mail related
 Operating System: Sun Solaris 2.6
 PHP Version:      4.0.6
 New Comment:

More information:

Basically, the mail function was returning false even 
though the email was being sent.  Here is an example:

if ( mail( '[EMAIL PROTECTED]', 'test', 'test2', 
"From: webmaster@$SERVER_NAME\r\nReply-To: 
webmaster@$SERVER_NAME\r\nX-Mailer: PHP/" . phpversion(), 
"[EMAIL PROTECTED]" ) ) {
        echo "mail sent okay";
}
else {
        echo "mail cannot be sent!";
}

The problem only occurs if you include the 5th parameter 
and the -f email address is not set up on the local 
machine.  For example, PHP is running on the same machine 
as the webapproval.co.uk domain.  If the user 'stupid' 
hasn't been set up, then sendmail will complain:

sendmail[21956]: JAA21956: setsender: 
[EMAIL PROTECTED]: invalid or unparseable, received 
from httpd@localhost

but will still send the mail.  So essentially, sendmail is 
returning an error code, but still sending the mail.  The 
return address is set to httpd@<my server address>.


Previous Comments:
------------------------------------------------------------------------

[2002-03-13 11:58:36] [EMAIL PROTECTED]

I am experiencing this behaviour on a Cobalt RaQ3 (Linux) 
running PHP 4.1.2.  The mail function always returns false, 
regardless of whether the mail was sent or not:

if ( mail( '...', '...', '...' ) ) {
 echo "mail sent okay!";
}
else {
 echo "mail not sent!";
}

This code will always say "mail not sent!" whether the mail 
has been sent or not.

------------------------------------------------------------------------

[2002-01-15 03:46:40] [EMAIL PROTECTED]

I also has same trouble with Solaris8+PHP4.1.1+Apache1.3.22.
It seems that, pcloase(inside of mail.c) always return -1.
So php_mail function always return FALSE.

when I remove /usr/lib/sendmail and test mail().
Apache's error_log report that Apache cannot fork sendmail.
but sendmail=popen(...) still return not NULL and pclose()
return -1.

I think that mail.c must fix for apache I/F or not?

------------------------------------------------------------------------

[2001-08-07 07:45:11] [EMAIL PROTECTED]

I found out, that the problem is not the EX_OK or EX_TEMPFAIL but the
sendmail return value.
Sendmail (the sendmail qmail wrapper) is returning the value -1 when I
call it with php 4.0.6.
When I call it with 4.0.4pl than 0 is returned.
What could be the reason for this behaviour?



------------------------------------------------------------------------

[2001-08-01 05:20:35] [EMAIL PROTECTED]

I had a look on the mail.c sourcecode and I made a change. So I found
the part where the error appears.
But I do not know why, in version 4.0.4pl1 it is the same code and with
this version it works.

This is the extract from mail.c where the error appears:

                   ret = pclose(sendmail);
#if definded (EX_TEMPFAIL)
                   if ((ret != EX_OK)&&(ret != EX_TEMPFAIL)) {
#else
                   if (ret != EX_OK) {
#endif
                            return 0;
                   } else {
                            return 1;
                   }

If I change the 0 to 1 than I get true as response of the mail()
function.
So what could be the problem with EX_OK and EX_TEMPFAIL that the same
if query is working in 4.0.4pl1 and not 
in 4.0.6? Who is EX_OK and EX_TEMPFAIL defined?
 

------------------------------------------------------------------------

[2001-07-30 01:42:49] [EMAIL PROTECTED]

This was a misunderstanding.
I have the problems with version 4.0.6.
But this machine is not on the internet. Because it's our testmachine.

Our livesystem thats on the internet has version 4.0.4 and we want to
update this machine to 4.0.6 but we can't do 
that as long as we have the problem with the mail function. The both
systems are exactly the same.
I wrote this only to explain why I can't put the test script on the
internet.





------------------------------------------------------------------------

The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
    http://bugs.php.net/12335

-- 
Edit this bug report at http://bugs.php.net/?id=12335&edit=1

Reply via email to