Subject: gethostbyaddr() delays in tcp_clienthost()

From: Rich Graves <[email-masked]>
Date: Wed, 9 May 2001 10:50:23 -0400 (EDT)

A local cable modem provider messed up their DNS delegations last Friday,
and there's been a 90-second DNS timeout for every IMAP connection ever
since.

May  4 23:29:53 larry imapd[873]: imaps alternative service init from
 216.195.16.30
May  4 23:31:15 larry imapd[873]: Authenticated user=atomecka
 host=[216.195.16.30]

Is tcp_clienthost() needed anywhere but for logging? Opinions on turning it
into a no-op or maybe wrapping an alarm(10) around it?
-- 
Rich Graves <[email-masked]>
UNet Systems Administrator

-- 
------------------------------------------------------------------
 For information about this mailing list, and its archives, see: 
 http://www.washington.edu/imap/c-client-list.html
------------------------------------------------------------------

---

From: Mark Crispin <[email-masked]>
Date: Wed, 9 May 2001 10:50:04 -0700 (PDT)

> into a no-op or maybe wrapping an alarm(10) around it?

Thre is an option to turn off the use of gethostbyaddr(); however, it isn't
recommended except in temporary emergency situations (such as your cable modem
provider messing up).  The option is under a compile option in imap-2000; in
imap-2001 there's a configuration parameter that is checked at runtime.

tcp_name() (the routine which actually calls gethostbyaddr()) is for the most
part only used by logging.  However, SASL also uses it.  The most important
thing that will break if you turn off tcp_name() is Kerberos.

The bottom line is that the cable modem provider should be beaten up to fix
their problem.  Turning off gethostbyaddr() should be seen as an short term
band-aid only.  I'll grant that most cable modem providers are incompetant
slime; my community had one and tried to persuade those of us with other forms
of IP connectivity to switch to them.  I told them to buzz off when a few
simple questions put them into prevarication mode.  Needless to say, they
suddenly pulled the plug last year and left a lot of people high and dry.

---

From: Rich Graves <[email-masked]>
Date: Wed, 9 May 2001 15:14:38 -0400 (EDT)

> thing that will break if you turn off tcp_name() is Kerberos.

I.e, set allowreversedns = NIL in c-client/tcp_unix.c. I don't think I'll
do that because AFAIK only one person (my boss) is seriously impacted.

It'd be nifty if I could switch allowreversedns on and off with TCP
wrappers, but that doesn't work for the alternate SSL port. (Any clues why
yet?)

I'll grep through a bit more, but I don't believe we care about SASL. We
only do cleartext passwords, with a strong push for SSL and SSH. We're
planning to adopt Kerberos just in time for single DES to be _totally_
worthless.

Would kerberos still break if tcp_serverhost() does a reverse lookup but
tcp_clienthost() doesn't?

> The bottom line is that the cable modem provider should be beaten up to fix

In principle that's true, but nobody even tries to do reverse lookups on
web servers anymore. I know it's not really the same thing, but there is
still a performance issue.

In theory, causing pain to people whose clients do stupid things like
flapping the connection to check mail every 5 minutes might put pressure on
them to fix or replace the clients with something that actually talks IMAP,
but in the meantime I've got a service to run. I don't want to deadlock for
90 seconds due to something out of our control just because it's the right
thing to do.
-- 
Rich Graves <[email-masked]>
UNet Systems Administrator

---

From: Mark Crispin <[email-masked]>
Date: Wed, 9 May 2001 12:21:36 -0700 (PDT)

On Wed, 9 May 2001 15:14:38 -0400 (EDT), Rich Graves wrote:
> I.e, set allowreversedns = NIL in c-client/tcp_unix.c.

Yes, that's the imap-2001 way.

> wrappers, but that doesn't work for the alternate SSL port. (Any clues why

I don't know why TCP wrappers don't work with SSL port.

> tcp_clienthost() doesn't?

Yes it would, because the SASL setup code won't do the right thing either.

> still a performance issue.

Unfortunately, there are still requirements (as in Kerberos) to do reverse
lookups.  Note that some sites do reverse lookups as an anti-spam/anti-hacking
measure; that is, they refuse connections from sites whose reverse lookup name
doesn't resolve to a name that doesn't resolve to an A or MX.

> them to fix or replace the clients with something that actually talks IMAP

:-)

What makes things worse is that some people actually think that such clients
are good...  :-(  :-(