AI.CLIVE@MCC.COM.UUCP (02/27/87)
The large number of recent messages about SMTP clients waiting for servers don't seem to have mentioned a related problem which is just as annoying: How long should an SMTP server process wait for a client before giving up? For many weeks our system constantly had two or three active server processes connected to a certain host. Investigation showed that the client host would stop sending data after the MAIL FROM: command, and our SMTP server would give up and close the connection 5 minutes later. A minute or two later, the client host would open another connection and try again, etc. etc. I finally had to increase the server timeout to FIFTEEN minutes, and the client was finally able to get the message through. People have suggested several reasons why a server might be delayed in responding to a client; but I see no excuse for a client to be so slow about it. The host in question was an overloaded 750 running Unix. I don't know many more details, but I'm told that the Unix mailer actually validates each address in the header after the connection is already open, and that furthermore this validation is repeated during each connection to the various hosts for which the message is destined. If a message has a couple of dozen addressees, this adds up to quite a bit of time. This sounds unbelievable to me, and I hope that Unix folks take the time to tell me that my info is wrong, or that the situation will soon be fixed. Mailers should get all of their validation, etc., done BEFORE opening any connection. Once the connection is open they should state their business quickly, expect a quick response, and then leave. A network connection is a valuable resource, and my system can't afford to tie up several in an idle state waiting for remote hosts to spin their wheels. Clive -------
hedrick@TOPAZ.RUTGERS.EDU.UUCP (03/01/87)
Sorry, but your diagnosis is quite correct. We modified sendmail a year or so ago to map nicknames into primary host names. We found that suddenly connections were timing out. Turns out the code to process headers was invoked after the connection was opened. My sensibilities were badly offended, but I found I could make things work by moving our host table to a dbm format. This speeded things up enough that the other end wouldn't time out. Now that we have moved to the domain system, it is quite possible that the problem has returned.