painful sendmail
 

Hi,

I have got a problem with my sendmail daemon on a cobalt 5.0 system.

Sendmail version is: sendmail-8.9.3-C7

The daemon has stopped accepting incoming email from other mx hosts. netstat shows a lot of connections (ESTABLISHED & CLOSE_WAIT) from other hosts, but the daemon does not exchange any data with the hosts. When I telnet to port 25, the TCP connection is opened, but there is no welcome message from the server and it does not respond to the HELO command. And it begins to refuse connections, when it reaches the maximum number of defined children processes.

It seems that the daemon is not talking to the hosts at all. However I can send outgoing mail from the machine.

maillog shows entries like this:
Sep 25 00:22:06 www sendmail[26121]: NOQUEUE: SYSERR: putoutmsg (mta4.realage.com): error on output channel sending "220 www.MYHOST.net ESMTP Sendmail 8.9.3/8.9.3; Thu, 25 Sep 2003 00:22:06 +0330": Broken pipe
Sep 25 00:22:06 www sendmail[26121]: NOQUEUE: Null connection from mta4.realage.com [209.75.40.47]

Please advice me. I'm stuck.

This problem has happened since a few days ago. I tried replacing sendmail.cf and sendmail.cw with original ones and I empties access and relay files, but the problem persists.

Here is the output of tcpdump on the server when I telnet to port 25:

[root@www /etc]# tcpdump -n port 25 and host 213.217.56.14
tcpdump: listening on eth0

21:42:11.330906 213.217.56.14.54644 > SERVERIP.25: S 1135194239:1135194239(0) win 2920 <mss 1460,nop,nop,sackOK> (DF)
21:42:11.330952 SERVERIP.25 > 213.217.56.14.54644: S 955710487:955710487(0) ack 1135194240 win 32120 <mss 1460,nop,nop,sackOK> (DF)
21:42:12.147579 213.217.56.14.54644 > SERVERIP.25: . ack 1 win 2920 (DF)

And there is no output at the telnet screen. and when I close using ^]:

21:42:29.577846 213.217.56.14.54644 > SERVERIP.25: F 1:1(0) ack 1 win 2920 (DF)
21:42:29.577892 SERVERIP > 213.217.56.14.54644: . ack 2 win 32120 (DF)

Please let me know what I can do! The sendmail binary is dated 1999, so this could not be related to the file, and since the TCP connection is stablished, the network is also OK!