Subject: [Imap-uw] problem between SnapperMail 2.3.2-01 and Imapd 2004c

From: Thomas Lohman <[email-masked]>
Date: Tue, 07 Feb 2006 17:17:29 -0500

Hello all,

We've recently had a rash of folks using Treo 650 phones with 
SnapperMail 2.3.2 installed to read their email via secure IMAP.  We're 
currently running Imap 2004c and there appears to be a strange problem 
in the initial authorization phase.  On the phone side, SnapperMail goes 
through some initial steps such as Authenticating, Securing and then it 
gets to Authorizing.  At this step, it will hang for a few minutes or 
more and then eventually continue on successfully.  While it works, our 
users are wondering if there is any fix to the long wait on initial 
connect.  In looking at the mail server side of things as well as 
network traffic, an imapd process is forked off from inetd and is 
sitting on a door_call system call. The last packet sent to the phone's 
network is from our mail server.  Then there is no traffic whatsoever 
for those few minutes.  After a few minutes, communication between the 
two resumes with the mail server sending the first packet after the 
delay and then things seem to function normally and users can 
send/receive mail.  But we're at a loss of what is going on during the 
Authorizing phase and in addition, we've done some tests against Courier 
and Cyrus IMAP servers and they don't seem to have the same delay during 
this part of the handshaking.

On the SnapperMail side, we have it configured to use Secure IMAP on 
port 993 with Always Trust Server selected.  As mentioned, it does seem 
to work ok except for this initial long delay.  So, I am wondering if I 
might get lucky and have someone else out there who has used SnapperMail 
with UW IMAPD and has either not had problems or have had similar 
problems.  And if you did have problems were you able to solve them?

thanks much,

--Thomas Lohman - [email-masked]
   Senior Systems/Software Developer
   Microsystems Technology Laboratories - MIT

_______________________________________________
Imap-uw mailing list
[email-masked]
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw

---

From: Mark Sirota <[email-masked]>
Date: Tue, 07 Feb 2006 17:25:25 -0500

--On February 7, 2006 5:17:29 PM -0500 Thomas Lohman <[email-masked]> 
wrote:
> SnapperMail 2.3.2 installed to read their email via secure IMAP.  On the
> phone side, SnapperMail goes through some initial steps such as
> Authenticating, Securing and then it gets to Authorizing.  At this step,
> it will hang for a few minutes or more and then eventually continue on
> successfully.  While it works, our users are wondering if there is any
> fix to the long wait on initial connect.

We had this problem, and found that our tcp wrappers were sending ident
(rfc 931) queries.  The intermediate server from which the IMAP requests
were coming dropped those packets rather than sending a TCP reset, which
caused long delays while the ident query timed out.  The same thing
happens with some firewalls.

My recommendation would be to verify whether you are sending ident queries
from tcp wrappers, and if so, turn that off and see whether the problem
goes away.

Mark

---

From: Mark Crispin <[email-masked]>
Date: Tue, 7 Feb 2006 15:05:00 -0800 (Pacific Standard Time)

On Tue, 7 Feb 2006, Mark Sirota wrote:
> (rfc 931) queries.

I agree with checking for ident queries.  This is the primary cause of 
long connect delays.

The most common way to configure/repair away ident is:

In your xinetd configuration files (such as /etc/xinetd.d/imap), check to 
see if there is any line with "USERID".  If so, delete all such lines with 
extreme prejudice.

In some systems, ident is invoked by other mechanisms; but the above is 
the most common.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
_______________________________________________
Imap-uw mailing list
[email-masked]
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw

---

From: Thomas Lohman <[email-masked]>
Date: Tue, 07 Feb 2006 22:35:13 -0500

> happens with some firewalls.

Thanks Mark (both Marks) for your replies.  We're currently not running 
imapd with tcp wrappers wrapping it.  A little more background on what 
we have - we have a Solaris 9 server and run imapd out of 
/etc/inetd.conf like so:

imaps   stream  tcp     nowait  root    /usr/local/imap/libexec/imapd 
imapd

Is there any other way imapd or inetd can be issuing ident queries?

thanks,

--tom

---

From: Mark Crispin <[email-masked]>
Date: Tue, 7 Feb 2006 19:40:11 -0800

> Is there any other way imapd or inetd can be issuing ident queries?

The other thing that you could look at is seeing if you are encountering 
DNS timeouts.  Can imapd do a reverse lookup on both its own IP address 
and on the client IP address without it taking forever?

-- Mark --

---

From: Thomas Lohman <[email-masked]>
Date: Tue, 07 Feb 2006 22:57:52 -0500

Thanks Mark.  I think you've hit the nail on the head and this also 
explains why it sometimes works normally for them - not often but the 
users claim every once in awhile it goes right through with no delay.  I 
just tried to do a reverse lookup of the IP address of the client and it 
hung and eventually timed out.  What is the best solution to this?  To 
somehow cache these addresses or is there a way to turn off this reverse 
lookup?

thanks,

--tom

---

From: Mark Crispin <[email-masked]>
Date: Tue, 7 Feb 2006 20:29:52 -0800

On Tue, 7 Feb 2006, Thomas Lohman wrote:
> I just tried to do 
> a reverse lookup of the IP address of the client and it hung and eventually 
> timed out.  What is the best solution to this?  To somehow cache these 
> addresses or is there a way to turn off this reverse lookup?

The first and best thing to try is to fix whatever is making the DNS fail.

In the case of the server's own name, it's probably best to make sure that 
/etc/hosts is set up properly.  Note that the FQDN *must* be first; many 
Solaris systems are set up with a non-FQDN first.

Fixing the DNS is also a good idea.

In your case, if you aren't in a position to fix the client's DNS address, 
you may be forced to turn off reverse DNS lookups.  I advise against doing 
so except as a LAST RESORT; it will make the logs less useful and it will 
break Kerberos authentication.

However, if you absolutely, positively, must, the thing to change is 
allowreversedns; it is set to T (allow it) and you would change it to NIL. 
The file is imap-****/src/osdep/unix/tcp_unix.c

Even if you find yourself forced to do this, I strongly advise that you 
try to get the DNS fixed (including, but not limited, to nagging the 
client network manager).  You may want to do something like have an imapd 
that does this be on an alternative port, or some other such mechanism so 
that most usage does the reverse DNS correctly.

-- Mark --

---

From: Thomas Lohman <[email-masked]>
Date: Wed, 08 Feb 2006 06:41:45 -0500

Thanks Mark.

> In the case of the server's own name, it's probably best to make sure 
> that /etc/hosts is set up properly.  Note that the FQDN *must* be first; 
> many Solaris systems are set up with a non-FQDN first.

Yes, the server's own name is fine and everything in /etc/hosts looks to 
be correct.  It seems to just be a problem with the reverse lookup of 
the Sprint client IP address.

> In your case, if you aren't in a position to fix the client's DNS 
> address, you may be forced to turn off reverse DNS lookups.  I advise 
> against doing so except as a LAST RESORT; it will make the logs less 
> useful and it will break Kerberos authentication.

Ok - thanks for the advice.  Unfortunately, I do not have any direct 
control over the DNS servers we use.  Those are controlled by MIT's main 
IS&T folks.  I am able to do a lookup from home so the problem doesn't 
appear to be the clients/Sprint's but the route that MIT is taking to do 
the lookup so I guess I should first contact them regarding this and see 
if something is misconfigured on their servers.

In the meantime, I'll try compiling it on a test server with 
allowreversedns set to NIL and see if the problem is fixed.  It also 
seems to be that running a local caching name server may also aid in 
speeding up the server and the lookups.  Is this something recommended? 
  We currently do not do this on our Solaris servers but it was on the 
to do list.  It seems the IMAP/POP server's performance might improve a 
little if this were done.

thanks much,

--tom

---

From: [email-masked]
Date: Wed, 8 Feb 2006 11:48:46 +0000 (GMT)

On Wed, 8 Feb 2006, Thomas Lohman wrote:
; set to NIL and see if the problem is fixed.  It also seems to be that running
; a local caching name server may also aid in speeding up the server and the
; lookups.  Is this something recommended?  We currently do not do this on our
; Solaris servers but it was on the to do list.  It seems the IMAP/POP server's
; performance might improve a little if this were done.

Solaris has a name service cache daemon (nscd) which should be running by
default. It might help if you increase the negative TTL in /etc/nscd.conf
for hosts entries (defaults to 5 seconds).

A.

---

From: Thomas Lohman <[email-masked]>
Date: Wed, 08 Feb 2006 07:06:31 -0500

> for hosts entries (defaults to 5 seconds).

Thanks - I had completely forgotten about Sun's caching daemon. 
Currently, the positive TTL is set to an hour and negative TTL is set to 
5 seconds - guessing these are the defaults.
_______________________________________________
Imap-uw mailing list
[email-masked]
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw