From owner-freebsd-questions@FreeBSD.ORG Sat Apr 3 08:11:18 2010 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D707B1065670 for ; Sat, 3 Apr 2010 08:11:18 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (unknown [IPv6:2607:f678:1010::34]) by mx1.freebsd.org (Postfix) with ESMTP id 9610D8FC0A for ; Sat, 3 Apr 2010 08:11:18 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id o338BCLX013897 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 3 Apr 2010 01:11:13 -0700 (PDT) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id o338BCvs013896; Sat, 3 Apr 2010 01:11:12 -0700 (PDT) Received: from fbsd61 by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA00563; Sat, 3 Apr 10 00:00:25 PST Date: Sat, 03 Apr 2010 00:59:54 -0700 From: perryh@pluto.rain.com To: m.seaman@infracaninophile.co.uk, freebsd-questions-local@be-well.ilk.org Message-Id: <4bb6f57a.wld7n7exwvUX7+a9%perryh@pluto.rain.com> References: <201004011751.27767.npapke@acm.org> <4BB58AC2.50009@infracaninophile.co.uk> <4BB62E5D.5030400@infracaninophile.co.uk> <44iq89lo3v.fsf@be-well.ilk.org> In-Reply-To: <44iq89lo3v.fsf@be-well.ilk.org> User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-questions@freebsd.org Subject: Re: Sendmail Five Second Greeting Delay X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Apr 2010 08:11:18 -0000 Lowell Gilbert wrote: > Matthew Seaman writes: > > Ident queries like this will cause a delay if the other side > > doesn't respond respond to the ident query ... > I consider it polite for firewalls to actively refuse to open > the connection (TCP reset) rather than just dropping the request, > though. There's really no downside to doing so. Other than giving port-scanners an affirmative indication that there is a device of some sort at the IP address involved. Some firewalls even drop pings for exactly this reason. If the request comes from an address to which I've recently* initiated a connection -- so he already knows that my address is currently alive -- I ought to either respond per protocol or reset. If it comes from who-knows-where, it may be safer to drop it. The ident protocol is useful for the purpose for which it was designed: to pass "whom to blame" info between servers which have reason to trust one another's identity (based on, e.g., stable IP addresses) and administration. Granted the circumstances in which these conditions are met are a lot less prevalent than they once were. * for some resonable definition of recently