Sendmail Five Second Greeting Delay

David Allen the.real.david.allen at gmail.com
Fri Apr 2 15:49:11 UTC 2010


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 .

> 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?

> 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?

>> 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?  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?  ;-)

-- 
David
Off to reconfigure the firewall not to silently drop port 113 traffic.
And 70 and 79, just in case.


More information about the freebsd-questions mailing list