Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!hp4nl!charon!piet
From: piet@cwi.nl (Piet Beertema)
Newsgroups: comp.protocols.tcp-ip.domains
Subject: Re: problems with nsfnet-relay.ac.uk
Message-ID: <3115@charon.cwi.nl>
Date: 5 Mar 91 15:03:30 GMT
References: <1666.667855170@xtel.co.uk> <9103021528.AA09106@rimfaxe.diku.dk> <kre.668023269@mundamutti.cs.mu.OZ.AU>
Sender: news@cwi.nl
Distribution: inet
Organization: CWI, Amsterdam
Lines: 29


		That is *wrong*, it should accept the connection, send a 421
		reply code (service unavailable), and close the connection.
	This sounds like a good thing to do, but in practice,
	it can be a disaster. It takes some cpu time to do
	this, which isn't something you have available in these
	circumstances (and remember, its not just one of these
	things, is possibly dozens, all at once).
	But worse - the characteristics are wrong, on receiving
	a 421, servers typically queue the message and attempt
	to send it again later.
Nevertheless it can be a good idea:
Most sendmail daemons enter an infinite sleep() loop as
long as the load is too high, so the sending host times
out and (re)queues the message for later attempts anyway.
Hosts (major mail/relay hosts) with very long queues do
suffer from this, since all the timeouts severely hold
up the processing of the queue. If the recipient host
would send a 421 reply code and exit, the queue would be
processed much faster and mails that can be delivered in
a particular queue run thus delivered much faster.
In sendmail-5.61/IDA the #define BUSYEXIT allows you to
choose the preferred action (if you want the 412 reply
to be given, you should fix srvrsmtp.c around line 143 to
do so in the !batched case instead of the batched case).


-- 
	Piet Beertema, CWI, Amsterdam	(piet@cwi.nl)