Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. 

Thank you for your interest in PHP.

Set the relevant php.ini options correctly.

Not bug.

You'll have to trust me when I say I _have_ set the appropriate commands in php.ini and checked them and double checked them again (paranoid moi?) and I can confirm that both the SMTP and sendmail_from settings are the same as used in my mail client and that has no problems sending mail whatsoever. If I put an invalid server address, one that doesn't exist, then PHP does correctly fail to connect and returns false.

I don't know if it will make a difference at all, but to make sure my ISPs mail server is working OK I ran a few tests by using telnet to connect to it and sent it the same commands that PHP sends it. This always works fine and the server always replies with 250 success. Using telnet I can even go as far as to issue the relevant MAIL FROM, RCPT TO and DATA commands and successfully send myself or anyone else an e-mail. I don't know why or how but PHP is most definitely not acting on the reply it gets from the initial HELO <machinename> command it sends, even though it is seemingly receiving it just fine.

If you're at all interested, this is what the communication between PHP and my ISPs mail server looks like:

SMTP: 220 warrior.services.quay.plus.net - Plus.Net, The smarter way to Internet - ESTP
PHP : HELO server
SMTP: 250 warrior.services.quay.plus.net - Plus.Net, The smarter way to Internet -

And that's it. Nothing more happens and PHP sits there in a loop, doing nothing until I forcefully stop and restart the Apache process. 

Just a suggestion, feel free to ignore it and smite me if you will, but if this isn't a specific bug with PHP, might it be wise to employ a timeout on the SMTP functions so that if this does happen for whatever reason then the connection is terminated after say 30 seconds and the mail() function then returns false.

Our SMTP server is localised to the same LAN, however we experience the same issue.

Examining the output of netstat reveals that an open SMTP connection is left lingering, however this session is completely dead, and any clients that hit a page attempting to session_start with the same session ID result in a hung page.

The mail is never sent.

Any subsequent attempts to use the web server's PHP functionality continues with poor reliability, and external commands are never executed. (Processes spawned, and left hung)

This has been tested in Netscape 4.61, Internet Explorer 6.0.2800.1106, and Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312

The server is a Pentium 3 550, 192MB RAM, Windows 2000 Server SP3, Apache 1.3.27/Win32, PHP 4.3.2RC1.

Which SMTP server is it? Seems like it's a problem
with it if it hangs..

I'm uncertain as to which SMTP server it is as there is no specific identification, but I have emailed someone I know who works for them to see if he can find out for me. If not, then I wouldn?t know, sorry.

Just got a reply from my ISP. The mail software they use is Qmail. Hope that helps to resolve whatever the problem might be.

Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip

No change. PHP still gets stuck in a never ending loop until I forcefully stop the Apache service. If it is of any use I have a csv export from a packet monitoring program which has all the raw header data that is being sent and received by PHP.

http://www.mattbeale.plus.com/phpbug22947/phpbug22947.csv

The SMTP server doesn't appear to be relevent, nor the IP on which it is listening. I have this problem both with using the Microsoft SMTP service on localhost, or sendmail running on a smarthost system 1 hop away over 100Mbit ethernet.

I can't replicate this on win98 with either 4.3.2-RC3-dev
or 5.0.0b2-dev (though it's noticeably faster with PHP 5).

Can someone on a later version of windows please test with a recent PHP snapshot and confirm whether there's still a problem?

There does appear to be a very slight change. PHP now appears to be replying to the server after the initial HELO <machinename> command, but the reply always consists of just header and no data. I have created a second csv export which shows the changes if it is of any use: 

http://www.mattbeale.plus.com/phpbug22947/phpbug22957-4.3.3RC2.csv

I have also tested this snapshot on my Windows XP machine, as well as on my Windows 2000 machine (which has now been upgraded to Service Pack 4) both running Apache 1.3.28 and the latest PHP snapshot and have also tried using a non-NAT connection via ye-olde-faithful Alcatel Speedtouch USB Modem rather than my DSL router, but the same problems still occur on both machines.

I can't reproduce this either, must be local problem to you only. (we'd have hundreds of reports about this if it really was a bug)

I wouldn't know what else to try and eliminate. I've tried two operating systems with different service packs and two methods of Internet Connection (Router and USB Modem). The only thing I can't change is my ISP.

I can only conclude that there must be something 'up' with my ISPs mail server, but if that is the case why do I only get problems with PHP? Everything else works fine - I can send mail from Outlook/Outlook Express/Mozilla fine and I also use POPFile 0.19.1 on my server which has no problems with communicating with my ISPs mail server. If there were really problems with my ISPs mail server, wouldn't I experience similar problems in the other applications I use?

In addition to my previous message: 

This PHP code works fine on both machines that have problems. I doubt I need to tell you what it does?:

<?php

    function bytesleft($fp) {
        $status = socket_get_status($fp);
        $bytes  = $status['unread_bytes'];
        return $bytes;
    }

    function sendtext($str) {
        global $fp;
	echo $str;
	flush();
        fwrite($fp, $str);
	$ret = fread($fp, 1);
	$ret.= fread($fp, bytesleft($fp));
	return $ret;
    }

    $fp = false;

    if ($fp = fsockopen('relay.plus.net', 25, $errno, $errstr, 1)) {

        socket_set_timeout($fp, 1);

	$hash = md5(uniqid(rand()));

	echo sendtext("HELO server\r\n");
	echo sendtext("MAIL FROM: me@mattbeale.plus.com\r\n");
	echo sendtext("RCPT TO: me@mattbeale.plus.com\r\n");
	echo sendtext("DATA\r\n");
	echo sendtext("From: Matt Beale <me@mattbeale.plus.com>\r\n");
	echo sendtext("Subject: [PHP] Test Subject - {$hash}\r\n");
	echo sendtext("To: Matt Beale <me@mattbeale.plus.com>\r\n");
	echo sendtext("\r\n");
	echo sendtext("This is a test message sent from PHP\r\n");
	echo sendtext("\r\n");
	echo sendtext("Hash: {$hash}\r\n");
	echo sendtext(".\r\n");
	echo sendtext("QUIT\r\n");

	fclose($fp);
    }
?>

If Andrew happens to read this, I'd be interested to know if it works for him. Plus I'd be very interested in what the PHP developers think might be going on.

This does seem to be a fault in the Windows code, the Ack() function in sendmail.c:

win32/sendmail.c(Ack):
...
	if ((buf[Received - 4] == ' ' && buf[Received - 3] == '-') ||
...

It is specifically disallowing SPACE HYPHEN at the end of the SMTP reply text that PlusNet's server is sending, but that seems to be allowed by RFC2821.

However, since someone has deliberately blocked this pattern there must be a reason for it, but it seems invalid to me.

When I modifed the php4ts.dll to use EHLO instead of HELO the SMTP exchange completed successfully.  PlusNet's server avoids the "illegal" SPACE HYPHEN in its extended reply, so the hangup doesn't occur.

Does this not get acknowledgement unless the Status is set back to Open?

As far as I can see from section 4.1.1.1 of RFC 2821 the response given to the HELO command is perfectly valid.

http://www.faqs.org/rfcs/rfc2821.html

The check for a space and then dash was introduced into win32/sendmail.c at version 1.20 with the following log entry:

--------------------------------------
revision 1.20
date: 2000/09/05 00:26:15;  author: sterling;  state: Exp;  lines: +5 -2
This should fix the multiple-line problem.
--------------------------------------

Not sure which "multiple line problem" though - possibly bug 6537

Either way, the response we're sending looks like it should be handled fine by PHP - and it certainly shouldn't cause a hang (I expect PHP is waiting for more data trying to get the next line of a multi-line response - but it should be doing this as the response code (250) is followed by a space, not a dash ...

The patch below (I can't find anywhere to add this as an attachment - shoot me if I'm being stupid) may fix the problem (Matt - could you try it?). Not sure whether it will work correctly with multi-line responses. This is untested - I don't have access to a win32 platform to build on right now (Or a mail server that sends multi-line responses to a HELO ...)

Index: win32/sendmail.c
===================================================================
RCS file: /repository/php-src/win32/sendmail.c,v
retrieving revision 1.55
diff -u -r1.55 sendmail.c
--- win32/sendmail.c    23 Jul 2003 16:03:10 -0000      1.55
+++ win32/sendmail.c    11 Aug 2003 10:10:54 -0000
@@ -882,11 +882,10 @@
        /* Check for newline */
        Index += rlen;
                                                                                                                            
-       if ((buf[Received - 4] == ' ' && buf[Received - 3] == '-') ||
+       if ((buf[3] == '-') ||
            (buf[Received - 2] != '\r') || (buf[Received - 1] != '\n'))
                /* err_msg          fprintf(stderr,"Incomplete server message. Awaiting CRLF\n"); */
-               goto again;                             /* Incomplete data. Line must be terminated by CRLF
-                                          And not contain a space followed by a '-' */
+               goto again;                             /* Incomplete data OR multi-line response. Line must be terminated by CRLF */
                                                                                                                            
        if (buf[0] > '3') {
                /* If we've a valid pointer, return the SMTP server response so the error message contains more information */

Probably easier to grab the patch from here:

http://www.lwillis.plus.com/php_sendmail_patch.patch

Lee

Woohoo, Everything works fine. Excellent work Lee!

I've only compiled a CGI version (not debug), but if anyone else (Andrew?) wants to test it, it is here: http://www.mattbeale.plus.com/phpbug22947/phpbug22947.tar.gz

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.