Date: Fri, 02 Apr 2010 12:46:24 -0400 From: Jon Radel <jon@radel.com> To: David Allen <the.real.david.allen@gmail.com> Cc: freebsd-questions@freebsd.org Subject: Re: Sendmail Five Second Greeting Delay Message-ID: <4BB61F60.5010202@radel.com> In-Reply-To: <g2m2daa8b4e1004020849j6d89309cp635646cf94b57fb4@mail.gmail.com> References: <201004011751.27767.npapke@acm.org> <4BB58AC2.50009@infracaninophile.co.uk> <p2y2daa8b4e1004020533u16d3c5a5hc48eb7ec4ceea7b8@mail.gmail.com> <4BB5FB51.60207@radel.com> <g2m2daa8b4e1004020849j6d89309cp635646cf94b57fb4@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This is a cryptographically signed message in MIME format. --------------ms030108070505010408070809 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 4/2/10 11:49 AM, David Allen wrote: > > On 4/2/10, Jon Radel<jon@radel.com> wrote: >> On 4/2/10 8:33 AM, David Allen wrote: >> >>> Secondly, it seems the cause of the OP's problem was a delay associat= ed >>> 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 therefor= e 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 >> program that does an IDENT query solely if DNS data is not available. = I >> can't see why that would make any sense. > > Well, I'm sure that on a network with functional DNS, sendmail sends > no IDENT queries. And by extension, there are no delays due to > timeouts of unaswered queries . Very odd. Why on earth would that be the case? > >> What is most likely the OP's root problem is that he's sending e-mail >> from a machine that's on the other side of a firewall that blocks IDEN= T >> traffic but doesn't actively reject it. So sendmail has to sit around= >> and wait for the query to time out. > > That much I get, but the question is why sendmail, by default sends > those queries? Historical reasons. So that you know, when bad mail is sent to you from = the Math Dept. server by Jimbob playing around with his own SMTP=20 program, whom to yell at. (See below for references.) Please don't make out like I'm advocating as this being of much utility=20 these days; I'm not. You can find all sorts of recommendations to turn=20 this off if you look around. > >> This is why there's a school of thought that even if your default for >> firewall configuration is to quietly drop unwanted packets, IDENT is a= >> protocol that you should actively reject. It makes things move along >> more quickly. > > Fair enough. But that reasoning is based on a premise that IDENT is > widely depended upon (and implicitly widely used), yes? It's still deployed enough to result in tedious discussions, such as=20 this one, coming up fairly frequently. None of this is a problem until=20 you have people who drop ident packets *and* get upset that there are=20 servers out there that wait for a timeout. And just think, we could be in the bad old days, when you *had* to wait=20 for the IP stack to timeout and sendmail didn't have a handy place to=20 set the timeout to a short value. To paraphrase: One of the underlying rules of getting along on the=20 Internet is to be strict in what you send and forgiving in what you=20 accept. So do something sensible with IDENT requests or expect odd=20 delays, and don't waste time wondering why there are still servers out=20 there that do things that don't really make a lot of sense anymore. > >>> Put another way, I'm wondering why IDENT queries are made? My knowle= dge >>> of that protocol is superficial, but my understanding is that running= an >>> identity service is widely considered a security problem. FreeBSD do= esn'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 = that >>> doesn't address the default sendmail behavior. >> >> Things can make more sense when you realize that TCP/IP networks have >> changed over the years. Long ago, when dinosaurs roamed the earth, an= d >> timesharing servers were big things with professional admins and lots = of >> users, it could be helpful to know that if you got an irritating >> connection from the Math Dept. server using source port X, and IDENT >> said the owner of the process that was using port X was a user called >> Jimbob, that you could go to the admin of that server and tell him to >> slap Jimbob upside the head. After all, if his IDENT server had been >> subverted, he would have mentioned it when you had a beer with him las= t >> night. >> >> These days, when so much traffic comes from individual workstations >> where the user can frequently arrange for an IDENT server to return an= y >> fool information they want, if they have it running at all, the value >> added is much less. >> >> Do remember that some of these things date from back when Linus was >> still in diapers (well, actually, he was about 15 when the earliest RF= C >> with the genesis of IDENT was published), so trying to figure out why >> they make sense based solely on what Linux does can be futile. ;-) > > Interesting reading. Thanks for elaborating. > > So the IDENT protocol was relied on in the time of the dinosaurs, it's > value today is "so much less" (a polite way of saying "not used at > all"?), and IDENT packets are commonly dropped by firewalls. Do I > have that right? Yes, except for the "not used at all" bit. > If so, then a reasonable conclusion is that the > default sendmail behaviour with respect to IDENT (sending queries and > then waiting for a reply) is an anachronism. And the workaround > (setting a timeout of zero) is a fix for that anachronism. Should I > consider those two points as "features", or should I just get off your > lawn before I get yelled at? ;-) > People who get all bent out of shape about 5 second delays in e-mail=20 delivery deserve to suffer, therefore I personally think the default=20 behavior is fine the way it is. But as I said, you can find many=20 sendmail "cookbooks" on the Internet that recommend that you set it to 0 = sec and get on with your life. Or you could just set all your firewalls to reject the traffic with much = the same end result. --=20 --Jon Radel jon@radel.com --------------ms030108070505010408070809--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4BB61F60.5010202>