From owner-freebsd-questions@FreeBSD.ORG Fri Apr 2 14:12:57 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 4EB321065677 for ; Fri, 2 Apr 2010 14:12:57 +0000 (UTC) (envelope-from jon@radel.com) Received: from wave.radel.com (wave.radel.com [216.143.151.4]) by mx1.freebsd.org (Postfix) with ESMTP id DE5528FC1A for ; Fri, 2 Apr 2010 14:12:54 +0000 (UTC) Received: by wave.radel.com (CommuniGate Pro PIPE 4.1.6) with PIPE id 9558718; Fri, 02 Apr 2010 10:12:53 -0400 Received: from [192.168.43.221] (account jon@radel.com HELO braeburn.local) by wave.radel.com (CommuniGate Pro SMTP 4.1.6) with ESMTP-TLS id 9558716 for freebsd-questions@freebsd.org; Fri, 02 Apr 2010 10:12:33 -0400 Message-ID: <4BB5FB51.60207@radel.com> Date: Fri, 02 Apr 2010 10:12:33 -0400 From: Jon Radel User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: freebsd-questions@freebsd.org References: <201004011751.27767.npapke@acm.org> <4BB58AC2.50009@infracaninophile.co.uk> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060303050904010303000403" X-Radel.com-MailScanner-Information: Please contact Jon for more information X-Radel.com-MailScanner: Found to be clean X-Mailer: CommuniGate Pro CLI mailer X-Content-Filtered-By: Mailman/MimeDel 2.1.5 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: Fri, 02 Apr 2010 14:12:57 -0000 This is a cryptographically signed message in MIME format. --------------ms060303050904010303000403 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 4/2/10 8:33 AM, David Allen wrote: > Secondly, it seems the cause of the OP's problem was a delay associated= > with an IDENT query. Specificially > > confTO_IDENT Timeout.ident [5s] The timeout waiting for a > response to an IDENT query. > > If he had local DNS configured, there would be no query, and therefore = no > issue, but setting the timeout to 0 seconds using > > define(`confTO_IDENT', 0s) > > does remove the delay, but not the underlying problem. You sure? IDENT has nothing to do with DNS, and I don't know of any=20 program that does an IDENT query solely if DNS data is not available. I = can't see why that would make any sense. What is most likely the OP's root problem is that he's sending e-mail=20 from a machine that's on the other side of a firewall that blocks IDENT=20 traffic but doesn't actively reject it. So sendmail has to sit around=20 and wait for the query to time out. This is why there's a school of thought that even if your default for=20 firewall configuration is to quietly drop unwanted packets, IDENT is a=20 protocol that you should actively reject. It makes things move along=20 more quickly. > > Put another way, I'm wondering why IDENT queries are made? My knowledg= e > of that protocol is superficial, but my understanding is that running a= n > identity service is widely considered a security problem. FreeBSD does= n't > run identd by default, for example, but it's possible that some Linux > distros do. The Wikipedia article suggests "It's an IRC thing", but th= at > doesn't address the default sendmail behavior. Things can make more sense when you realize that TCP/IP networks have=20 changed over the years. Long ago, when dinosaurs roamed the earth, and=20 timesharing servers were big things with professional admins and lots of = users, it could be helpful to know that if you got an irritating=20 connection from the Math Dept. server using source port X, and IDENT=20 said the owner of the process that was using port X was a user called=20 Jimbob, that you could go to the admin of that server and tell him to=20 slap Jimbob upside the head. After all, if his IDENT server had been=20 subverted, he would have mentioned it when you had a beer with him last=20 night. These days, when so much traffic comes from individual workstations=20 where the user can frequently arrange for an IDENT server to return any=20 fool information they want, if they have it running at all, the value=20 added is much less. Do remember that some of these things date from back when Linus was=20 still in diapers (well, actually, he was about 15 when the earliest RFC=20 with the genesis of IDENT was published), so trying to figure out why=20 they make sense based solely on what Linux does can be futile. ;-) --=20 --Jon Radel jon@radel.com --------------ms060303050904010303000403--