Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 3 Oct 2000 21:55:58 -0700
From:      "Crist J . Clark" <cjclark@reflexnet.net>
To:        Garrett Wollman <wollman@khavrinen.lcs.mit.edu>
Cc:        David Pick <D.M.Pick@qmw.ac.uk>, security@FreeBSD.ORG
Subject:   Re: cvs commit: src/etc inetd.conf
Message-ID:  <20001003215558.W25121@149.211.6.64.reflexcom.com>
In-Reply-To: <200010031722.NAA41823@khavrinen.lcs.mit.edu>; from wollman@khavrinen.lcs.mit.edu on Tue, Oct 03, 2000 at 01:22:27PM -0400
References:  <200010031705.LAA23799@nomad.yogotech.com> <E13gVfo-0006bL-00@xi.css.qmw.ac.uk> <200010031722.NAA41823@khavrinen.lcs.mit.edu>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Oct 03, 2000 at 01:22:27PM -0400, Garrett Wollman wrote:
> <<On Tue, 03 Oct 2000 18:16:12 +0100, David Pick <D.M.Pick@qmw.ac.uk> said:
> 
> > gets no response (after a time-out) it would be entitled to retry a
> > few times in case of packet loss. *But* if it gets a RST, which is a
> 
> If net.inet.tcp.blackhole is set, an RST will not be emitted.

OK, we're drifting from the point here. 

Someone suggested that auth be turned on by default in inetd.conf. One
of the reasons given was to prevent sendmail delays. It was then
/correctly/ pointed out that when sendmail receives a RST[0], an
indication that there is no auth listener, the mail transfer will
occur without delay.

net.inet.tcp.blackhole is not turned on by default. Someone who knows
enough to fiddle with that setting can be expected to be able to turn
auth on or off in inetd.conf depending on how they want things to
run.

So, since in the _default_ setup, there actually is no delay to
sendmail if auth is not activated, there is no argument to have it
turned on in the default.

Someone mentioned firewalls dropping the auth connection causing
delays. It is a moot point. If the firewall drops the incoming auth,
it makes no difference if the mail server has auth running or not
since the connection never reaches it.

[0] Yes, technically this is really happening at the transport layer
within TCP. sendmail does not know aything about SYNs, ACKs, RSTs, and
timeouts. sendmail tries to connect to the auth on the remote
machine. The TCP connection fails slowly if it makes several retries
and times out. The TCP connection fails quickly if it gets a
RST. Either way, this is not directly related to sendmail, but the
TCP/IP stack. 
-- 
Crist J. Clark                           cjclark@alum.mit.edu


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20001003215558.W25121>