I suspect it has nothing to do with PHP and everything to do 
with the sendmail binary. It maybe hanging waiting for data, 
try to test the sendmail binary to see if it can be used to 
send e-mail.

When I attempt to use the sendmail binary directly, I 
have no problems:
$ /usr/local/sbin/sendmail -t -i -v -X /tmp/sendmail.log 
myrealemail@mac.com
To: myrealemail@mac.com
From: someemail@bzflag.bz
Subject: this is a test...

testing.
[CTRL-d]

The message is successfully delivered both with and 
without the above shown header provided.  Looking at the 
-X debug logs, the difference running the command 
directly versus what I'm seeing when php runs is a lack 
of the EOF, shown below as follows:

From PHP:
70503 <<< To: myrealemail@mac.com
70503 <<< Subject: Hi!
70503 <<< 
70503 <<< Hi,
70503 <<< 
76330 <<< To: myrealemail@mac.com
76330 <<< Subject: Hi!
76330 <<< 
76330 <<< Hi,
76330 <<< 
76330 <<< How are you?

(Notice the lack of an EOF, it hangs)

Directly on the command line:

40466 <<< From: web@bzflag.bz
40466 <<< To: myrealemail@mac.com
40466 <<< Subject: testing
40466 <<< 
40466 <<< testing2
40466 <<< [EOF]
40466 >>> myrealemail@mac.com... Connecting to 
[127.0.0.1] via relay...
40466 === CONNECT [127.0.0.1]

Please try to reproduce it with only one Apache process (httpd -X) and if yes - get a GDB backtrace of the place where it freezes.

I'll give that a try, though this is on a very heavy 
loaded production machine (hundreds of web hits per 
minute) -- I'll need to wait for the load to settle a 
little, hopefully later tonight.

That said, in the meantime I thought I'd share some more 
insight testing.  I fully replaced sendmail with qmail 
to make sure it wasn't something particular with the 
configuration of sendmail.  Again, the machine has no 
problems sending e-mail on the command line or with mail 
clients, but mod_php5 hangs on the mail() call.  

Curiously enough, before installing qmail if I made the 
clientmqueue dir unreadable so that sendmail reported an 
error/failure, the mail() call does return immediately 
(reporting a failure return code) so the hanging does 
seem to be specific to when the mail 'should' go through 
correctly.

Not sure how helpful this will be, but here are several 
stack traces while it was hung.  Interestingly enough, 
if I ctrl-c'd in gdb during the hang and continued, the 
page would unhang and return a mail() failure.

(gdb) run -X -f /usr/local/etc/apache2/httpd.conf
(no debugging symbols found)...(no debugging symbols 
found)...(no debugging symbols found)...(no debugging 
symbols found)...(no debugging symbols found)...(no 
debugging symbols found)...(no debugging symbols 
found)...(no debugging symbols found)...
^C
Program received signal SIGINT, Interrupt.
0x283d92af in poll () from /lib/libc.so.5
(gdb) where
#0  0x283d92af in poll () from /lib/libc.so.5
#1  0x2847ba51 in _thread_kern_sched_state_unlock () 
from /usr/lib/libc_r.so.5
#2  0x2847b445 in _thread_kern_scheduler () from /usr/
lib/libc_r.so.5
(gdb) c
Continuing.
[ NOTE: HERE THE PAGE UNHUNG ]
^C
Program received signal SIGINT, Interrupt.
0x283d92af in poll () from /lib/libc.so.5
(gdb) where
#0  0x283d92af in poll () from /lib/libc.so.5
#1  0x2835977e in apr_poll () from /usr/local/lib/
apache2/libapr-0.so.9
#2  0x28359f32 in apr_wait_for_io_or_timeout () from /
usr/local/lib/apache2/libapr-0.so.9
#3  0x2835052a in apr_socket_recv () from /usr/local/
lib/apache2/libapr-0.so.9
#4  0x28350e9d in apr_recv () from /usr/local/lib/
apache2/libapr-0.so.9
#5  0x080705f0 in ap_lingering_close ()
#6  0x080640ab in child_main ()
#7  0x0806417c in make_child ()
#8  0x080642c2 in startup_children ()
#9  0x080646c2 in ap_mpm_run ()
#10 0x0806b7d3 in main ()
#11 0x0805cfd2 in _start ()
(gdb) c
Continuing.
^C
Program received signal SIGINT, Interrupt.
0x283d92af in poll () from /lib/libc.so.5
(gdb) where
#0  0x283d92af in poll () from /lib/libc.so.5
#1  0x2847ba51 in _thread_kern_sched_state_unlock () 
from /usr/lib/libc_r.so.5
#2  0x2847b445 in _thread_kern_scheduler () from /usr/
lib/libc_r.so.5
(gdb) c
Continuing.
[ NOTE: HERE THE PAGE UNHUNG ]
^C
Program received signal SIGINT, Interrupt.
0x283d92af in poll () from /lib/libc.so.5
(gdb) where
#0  0x283d92af in poll () from /lib/libc.so.5
#1  0x2835977e in apr_poll () from /usr/local/lib/
apache2/libapr-0.so.9
#2  0x28359f32 in apr_wait_for_io_or_timeout () from /
usr/local/lib/apache2/libapr-0.so.9
#3  0x2835052a in apr_socket_recv () from /usr/local/
lib/apache2/libapr-0.so.9
#4  0x28350e9d in apr_recv () from /usr/local/lib/
apache2/libapr-0.so.9
#5  0x080705f0 in ap_lingering_close ()
#6  0x080640ab in child_main ()
#7  0x0806417c in make_child ()
#8  0x080642c2 in startup_children ()
#9  0x080646c2 in ap_mpm_run ()
#10 0x0806b7d3 in main ()
#11 0x0805cfd2 in _start ()
(gdb) quit

Please try using this CVS snapshot:

  http://snaps.php.net/php5.2-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php5.2-win32-latest.zip

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".

I am seeing the same behavor in 4.4.3. I wrote a script to replace sendmail and confirmed that the data is being written to the pipe, but that the pipe is not being closed. I then stuck debuging statements in mail.c and found the it hangs on pclose().  Again, this is only in apache, not from the command line.

There may be a connection to this FreeBSD bug report:

http://www.freebsd.org/cgi/query-pr.cgi?pr=86421

To hopefully revive this issue, I'm using the latest release 
5.2.1 version of php (from FreeBSD ports), with the same setup 
and constraints as mentioned before in this report and still 
see the same crashes (httpd exits on signal 6) during a mail() 
call from mod_php5.

Doesn't look like PHP problem to me, more like FreeBSD bug.

For what it's worth, I don't believe the problem (at least 
as I've reported) is so much related to the previous 
poster's freebsd bug report link.  It may very well be 
specific to FreeBSD and even this version of the OS, but it 
also seems to be rather isolated to PHP5. I've tested with 
other Apache modules and none of them have trouble sending 
mail like PHP seems to be having, and sending mail directly 
works like a charm.

What's perhaps useful to note, and that I perhaps didn't 
emphasize enough, is that with version 5.1.2 it would just 
hang the httpd process and the web page request would simply 
never terminate.  Now with whatever change was made in mail
() since 5.2.1, it crashes the httpd.  It's curious that 
httpd is dying via signal 6 (SIGABRT, abort()) and not a 
usual segv or bus error, etc.

>Now with whatever change was made in mail() since 5.2.1,
> it crashes the httpd. 

A gdb backtrace is worth of thousand words.

<whine>Yes, but such a pain in the arse to set up as it's a 
live production system...where's the magical intuition and 
devine insight??</whine> :-)

I'll see if I can get an updated backtrace.  Cheers!

Do not touch the production Apache, setup an Apache instance in your $HOME dir, listening on a different port.

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".

This error still exists.... My PHP still hangs at the command mail()

Any news?

I've got a similar system with the exact same problem. It appears to be related to the way php is communicating with the sendmail process. I'm not yet sure if it is sending an EOF or a simple line with a '.' as that may be the difference between the two.