Sendmail Five Second Greeting Delay

[Jon Radel]

On 4/2/10 11:49 AM, David Allen wrote:
>
> On 4/2/10, Jon Radel<jon at 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 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
>> 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 IDENT
>> 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 
program, whom to yell at.  (See below for references.)

Please don't make out like I'm advocating as this being of much utility 
these days; I'm not.  You can find all sorts of recommendations to turn 
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 
this one, coming up fairly frequently.  None of this is a problem until 
you have people who drop ident packets *and* get upset that there are 
servers out there that wait for a timeout.

And just think, we could be in the bad old days, when you *had* to wait 
for the IP stack to timeout and sendmail didn't have a handy place to 
set the timeout to a short value.

To paraphrase:  One of the underlying rules of getting along on the 
Internet is to be strict in what you send and forgiving in what you 
accept.  So do something sensible with IDENT requests or expect odd 
delays, and don't waste time wondering why there are still servers out 
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 knowledge
>>> of that protocol is superficial, but my understanding is that running an
>>> identity service is widely considered a security problem.  FreeBSD doesn'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, and
>> 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 last
>> night.
>>
>> These days, when so much traffic comes from individual workstations
>> where the user can frequently arrange for an IDENT server to return any
>> 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 RFC
>> 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 
delivery deserve to suffer, therefore I personally think the default 
behavior is fine the way it is.  But as I said, you can find many 
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.

-- 

--Jon Radel
jon at radel.com