php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #22947 mail function hang-up
Submitted: 2003-03-28 21:41 UTC Modified: 2003-08-11 13:08 UTC
Votes:5
Avg. Score:3.8 ± 1.6
Reproduced:4 of 4 (100.0%)
Same Version:2 (50.0%)
Same OS:2 (50.0%)
From: me at mattbeale dot plus dot com Assigned: edink
Status: Closed Package: Mail related
PHP Version: 4CVS-2003-04-29 (stable) OS: Windows 2000 SP4
Private report: No CVE-ID:
 [2003-03-28 21:41 UTC] me at mattbeale dot plus dot com
System Spec:
Pentium 2 350Mhz, 256MB RAM, Windows 2000 Professional SP3, Apache 1.3.27 Win32 PHP/4.3.2.2 RC (20030328 Win32 stable from snaps.php.net - Build Date: Mar 28 2003 18:11:34) using Apache ISAPI module with GD2 support enabled in php.ini. 

The Problem:
The mail() function in PHP hangs when talking to my ISP mail server, causing the Apache child process to hang indefinitely and ultimately requiring it to be closed forcefully by stopping and restarting the system service. There are never any errors reported by PHP, not even those of the maximum execution timeout variety, so this would indicate to me that something is very wrong somewhere. I can reproduce this 100% and it happens regardless of how the mail function is written, even a simple <?php mail('myemail@isp.com', 'Hello', 'Hello There'); ?> will cause it to hang.

To try and rectify this problem myself, I have formatted and reinstall Windows 2000, completely uninstalled and reinstalled both Apache and PHP several times, tried various recent versions of PHP and tried using only a very basic httpd.conf/php.ini, with only required settings for the SMTP support under Windows and it still does it. 

Using a packet-sniffer, I am able to monitor PHP as it is talking to my ISP's mail server. Unless I'm reading things incorrectly, PHP never gets past the initial HELO <machine name> command, even though my ISPs mail server does respond with 250 OK, indicating that it was successful. PHP blatantly ignores this and instead chooses to sit there like a lemon, as if nothing ever happened.

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2003-04-01 06:25 UTC] sniper@php.net
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.


 [2003-04-01 06:25 UTC] sniper@php.net
Not bug.

 [2003-04-01 08:29 UTC] me at mattbeale dot plus dot com
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.
 [2003-04-21 22:00 UTC] andrew at pirionsystems dot com dot au
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.
 [2003-04-23 04:29 UTC] sniper@php.net
Which SMTP server is it? Seems like it's a problem
with it if it hangs..

 [2003-04-24 17:26 UTC] me at mattbeale dot plus dot com

 [2003-04-25 14:09 UTC] me at mattbeale dot plus dot com
Just got a reply from my ISP. The mail software they use is Qmail. Hope that helps to resolve whatever the problem might be.
 [2003-04-29 09:57 UTC] me at mattbeale dot plus dot com
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
 [2003-06-02 23:42 UTC] andrew at pirionsystems dot com dot au
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.
 [2003-07-29 12:58 UTC] sfox@php.net
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?

 [2003-07-29 16:05 UTC] me at mattbeale dot plus dot com
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.
 [2003-07-30 02:05 UTC] sniper@php.net
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)

 [2003-07-30 07:54 UTC] me at mattbeale dot plus dot com
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?
 [2003-07-30 15:39 UTC] me at mattbeale dot plus dot com
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.
 [2003-08-02 18:28 UTC] phpbugs at pligplob dot com
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.
 [2003-08-03 09:05 UTC] me at mattbeale dot plus dot com
Does this not get acknowledgement unless the Status is set back to Open?
 [2003-08-11 04:43 UTC] lwillis at plus dot net
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 ...
 [2003-08-11 05:15 UTC] lwillis at plus dot net
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 */
 [2003-08-11 05:16 UTC] lwillis at plus dot net
Probably easier to grab the patch from here:

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

Lee
 [2003-08-11 10:23 UTC] me at mattbeale dot plus dot com
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
 [2003-08-11 13:08 UTC] iliaa@php.net
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.


 
PHP Copyright © 2001-2014 The PHP Group
All rights reserved.
Last updated: Wed Apr 23 14:02:33 2014 UTC