89583 - courier imapd seems a bit weird with new moz mail client

Status: VERIFIED DUPLICATE of bug 92072

(MailNews Core :: Networking: IMAP, defect)

Description

[Will Yardley]

i use netscape 4.7 mail and pine with my work's mail machine.  we run courier
imapd and qmail; the messages are in Maildir format, and we use 'dot' subfolders
(ie INBOX is Maildir; a sub of that would be Maildir/.sub1/ and a sub of that
would be Maildir/.sub1/.subs_sub).  I have no problems checking my inbox mail,
but I get a 'connection refused' subsequently.  Obviously this may be a server
side problem (ie number of max connections) as I can't telnet to port 993 at
that time either (i'm using SSL IMAP over stunnel).

My guess is that when opening moz subfolders, it's somehow trying to open a new
connection while keeping the old connection active.... I don't know if that
qualifies as a bug or not, but it might be something to check out. Netscape 4.76
seems to work fine, and even when i'm getting the connection refused error on
moz, netscape will continue to work if i have an open connection (and yeah i've
tried closing netscape and killing the imapd procs and then checking my mail in
mozilla again; after checking a couple folders i get a 'connection refused'
error again.

 I know that Netscape used to hvae some wonky behaviour with Courier... 
here are the server settings;

#  Maximum number of IMAP servers started
#

MAXDAEMONS=40

#
#  Maximum number of connections to accept from the same IP address

MAXPERIP=4

so it looks like 4 connections per ip address are allowed at once.  Does mozilla
try to keep a connection open for each directory?

Comment 1

[Will Yardley]

Oh - and I'm running Mozilla 9.1 from the freebsd port on freebsd 4.3 stable. 
guess that might be pertinent info :>

Mozilla/5.0 (X11; U; FreeBSD 4.3-STABLE i386; en-US; rv:0.9.1) Gecko/20010701
<developer build>

And if the question isn't clear enough (it's early in the morning) the problem
I'm having is with Mozilla; not with Netscape 4.7

Comment 2

[Keyser Sose]

Markign NEW not sure if this is useful to anyone or what.

Comment 3

[Chris Bolt]

Dupe of bug 92072?

Comment 4

[Brian Haskin (Janzert)]

This does appear to be a dup of bug 92072. Reporter if you have a reason to
believe that it's not please reopen.

*** This bug has been marked as a duplicate of 92072 ***

Comment 5

[Gregg Meehan]

Marking as VERIFIED