Bug 31374 - sendmail not closing connections
sendmail not closing connections
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: sendmail (Show other bugs)
7.1
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Florian La Roche
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-03-10 17:27 EST by Travis Kelley
Modified: 2007-04-18 12:32 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-05-05 16:00:40 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Travis Kelley 2001-03-10 17:27:36 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.76 [en] (X11; U; Linux 2.4.0-0.99.11smp i686)


Sendmail appears to be not closing connections when a novell groupwise or
microsoft server attaches to it.  It appears that those servers are unable
to deliever the mail to sendmail and sendmail never closes the connection
with them.  When a ps aux is performed there are many sendmail processes
open after some time, and mail from these hosts is not flowing.  *nix based
hosts do not have any problem delivering mail.

Reproducible: Always
Steps to Reproduce:
1.Setup the mail server to receive mail.
2.test mail server using other *nix based machines (works properly)
3.send a message from an earthlink dialup account or novell gropwise to the
new mail server
	

Actual Results:  once earthlinks mail server attempt to connect to sendmail
the connection never closes and the sendmail process also never ends.  This
causes a memmory leak and eventually will crash the machine if left
unattended.   

Expected Results:  The mail should be delivered just as it would if it came
from a *nix machine.

 I am running the sendmail that came with redhat 7.1 beta.  After a while
of being online the machine slows to a crawl as it's memmory is slowly
eaten away by sendmail.  Another command "lsof -i +M" shows that there are
connections still open to the earthlink mail servers.
Comment 1 Travis Kelley 2001-03-11 15:00:06 EST
I recently upgraded sendmail to the newest version (8.11.3), but the problem
still persists.
Comment 2 Charles R. Anderson 2001-04-16 19:20:56 EDT
I noticed two things after upgrading a system to Red Hat 7.1:

1. sendmail now uses tcpwrappers by default.  If you have an /etc/hosts.deny
with ALL:ALL, then you must specifically allow connections to sendmail from
hosts you which to allow to connect in /etc/hosts.allow:

sendmail: smtp.domain1 smtp.domain2 ....

2. sendmail by default no longer listens on anything other than the loopback
interface.  If you want it to listen on all interfaces, you need to edit
/etc/mail/sendmail.cm, comment out this line with dnl like so:

dnl DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA'

then rebuild /etc/sendmail.cf with:

m4 /usr/share/sendmail-cf/m4/cf.m4 /etc/mail/sendmail.mc > /etc/sendmail.cf

then restart sendmail.
Comment 3 Stephen Walton 2001-05-05 15:56:27 EDT
I "upgraded" from RedHat 7.0 to 7.1 and still haven't succeeded in getting my workstation to accept incoming e-mail over the network, even after the 
above change to sendmail.mc.  'telnet localhost 25' on my workstation works, but the system is still refusing connections from anywhere else.  
/etc/hosts.allow and /etc/hosts.deny on my workstation are both empty (except for comments).
Comment 4 Stephen Walton 2001-05-05 16:00:36 EDT
My mistake.  I didn't realize that the 'dnl' string was how to comment it out.

Is there any good reason why Redhat made seemingly arbitrary changes to the mail configuration on 7.1 (defeating incoming mail, turning off the mbox 
handling in the imap daemon) without bothering to put a giant Release Note somewhere?
Comment 5 Florian La Roche 2001-05-08 16:50:05 EDT
The release notes had some comments about sendmail in them. I hope adding
further
sendmail docu for the next release is possible.

Thanks,

Florian La Roche

Note You need to log in before you can comment on or make changes to this bug.