Closed Bug 333661 Opened 18 years ago Closed 7 years ago

Incorrect error message with Courier IMAPd and SSL? "Unable to connect to your imap server. You may have exceeded ..."

Categories

(MailNews Core :: Networking: IMAP, defect)

Product:
MailNews Core
Component:
Networking: IMAP
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 315713

People

(Reporter: bugzilla.mozilla.org, Unassigned)

References

(
URL
)

Details

(Whiteboard: [psm-tcpip]) 

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060313 Debian/1.5.dfsg+1.5.0.1-4 Firefox/1.5.0.1
Build Identifier: version 1.5 (20060228)

When connecting to a courier imap server through SSL, while the connection is setup correctly and data is transferred fine, Thunderbird keeps popping up an error window saying "Unable to connect to your imap server. You may have exceeded ..." (etc) after some time, seemingly when reusing previously opened connections.

In the same moment the client reports this error the server logs "couriertls: accept: error:140D9115:SSL routines:SSL_GET_PREV_SESSION:session id context uninitialized". This makes me think the error message displayed by Thunderbird is incorrect and gives a false impression of the real error. This behaviour goes away when switching from SSL to StartTLS. It does not seem to be related to the maximum opened connections setting for the imap daemon.


Reproducible: Always

Steps to Reproduce:
1. Create IMAP account with SSL connection to Courier IMAPd server
2. Get messages from server 
3. Quit Thunderbird
4. Error message pops up while Thunderbird is closing down

Actual Results:  
Warning with supposedly incorrect error description pops up repeatedly.

Expected Results:  
No error message should be displayed, or correct error message should be given. The email account the error message relates to should be given.

This behaviour is the same on Thunderbird 1.5.0 and 1.0.7. Please refer to the forum post referenced above (Posted: Apr Tue 11th 2006 2:59pm) for additional information.
Maybe related: 315713, 298974
have you tried doing tools | account settings | server settings | advanced and changing the number of connections TB caches to 4, from the default of 5?
I had decreased it to 3. By the time I was testing this, mine was the only client accessing the IMAP daemon, quering a single account only, and the server was set to MAXPERIP=20 (Debian default). It also works fine when using StartTLS or without encryption, no error message pops up then. I do not think the connection count causes the error message.
Yes, that error message is just a guess based on the unique Courier-specific behaviour of connecting and then immediately dropping the connection. I don't know if there's any difference between your scenario and the maxperip scenario, as far as TB can tell. We do say "you MAY have exceeded"
Hmm, I don't think I'm getting what you're trying to say here: "I don't know if there's any difference between your scenario and the maxperip scenario, as far as TB can tell." Can you please say this differently?

Is it that you're saying "I assume the problem you are running into *is* in fact caused by the server side setting of MAXPERIP=20."? Seeing the fact that there never were 20 concurrent server connections when I was testing, this would seem like an incorrect diagnosis to me.

Maybe I should stress that there does not seem to be a problem with the data transfer, all information is transferred fine, and I believe suppressing this error message if it is caused by exactly this error (and only then) would probably suffice to fix the problem. 

But maybe it is just not possible to determine whether it's exactly *this* error situation because courier-imap does not provide the client with sufficient information on the exact error that occurred. Is this what the real problem is like? I should probably try that myself using telnet-ssl or netcat, but I'm afraid I'm lacking the time right now.

If that is so then I would also understand why the error message says "you MAY have exceeded". But it's only me, and I only understand this now after discussing this with you, and other courier-imapd admins will have a hard time diagnosing this with their users who may have less technical background than me. So it'd be nice to improve this situation if there are any options to do so. The worst but still sufficient solution would be a tick box which allows for "Do not display this warning again for this account" and another option in the account preferences which allows for forgetting this setting so the warning will show again.
As I said, we put up this error when we've successfully connected to the server, but the connection is immediately dropped, before we received a greeting from the server. That's the unique behavior I was referring to. When the connection is dropped, we're not told why.

I'm surprised that everything is working for you - when we encounter this error, we don't retry the current operation. And obviously, since we didn't even get a greeting, we weren't able to do anything. The server has to return a greeting before we can do any IMAP operations.

I'm wondering if there's something misconfigured on your server. This is the only report I've heard of this problem, and configuring cert stuff can be tricky.

An IMAP protocol log might be interesting:

http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#imap

"When the connection is dropped, we're not told why." -> I was not aware of this before, sorry if I missed it.

I created a new TB 1.5 profile to exclude possible influences by extensions and to have just a single account and thus no garbage on the logs.

I created the account, set the SSL connection and checked 'check for new messages on startup', set the maximum concurrent connections for this account to 1, clicked the inbox (triggering a server connection), imported the (valid) SSL certificate, inserted my password, then restarted TB. The inbox inbox contents had transferred fine, *no error* message popped up even when TB was quitting.

I then set the max. cached connections to 2 and quit. I started logging on the server and on the client then and started TB. The inbox was updated. I then quit TB and the error message popped up. I then stopped logging on the server and client. I sent the logs to you directly.

"I'm surprised that everything is working for you" -> So this is probably because a single connection *is* set up successfully and correctly but any additional connections are dropped.

I also revisited the server configuration and relaized that the caching functionality of courier-imapd is marked 'experimental', so this might explain the issues we're running into.

Here's what the config file says about caching:
--- quote start ---
# A TLS/SSL session cache may slightly improve response for IMAP clients
# that open multiple SSL sessions to the server.  TLS_CACHEFILE will be
# automatically created, TLS_CACHESIZE bytes long, and used as a cache
# buffer.
#
# This is an experimental feature and should be disabled if it causes
# problems with SSL clients.  Disable SSL caching by commenting out the
# following settings:

TLS_CACHEFILE=/var/lib/courier/couriersslcache
TLS_CACHESIZE=524288
--- quote end ---

This file does indeed exist ont he server
# ls -la /var/lib/courier/couriersslcache
-rw------- 1 root root 524288 Apr 12 21:33 /var/lib/courier/couriersslcache
and was last written when I connected the server with max. cached connections = 2.

If you think it's not worth wasting your time on what seems to be a configuration issue on my side (and assumely an issue with the debian package as this seems to be the default setting) then I can understand that pretty well. On the other hand, if you'd like to continue investigating this, I'll be grateful.
I was asked to prefix bug IDs by the word 'bug' so that bugzilla is able to link them.

Bugs which maybe related to this one: bug 315713, bug 298974
q.v. http://bugs.debian.org/364450
"courier-imap-ssl: TLS/SSL session caching conflicts with widespread MUAs"
Rereading my previous post, I realized it may have sounded unfriendly. This was not intended, sorry if it did. Thanks for your help so far, David.

As suggested by you, I had sent the imap client log files to you on April 12th, accompanied by a summary of the relevant server log files.

However, even though I continue to think it is partially a Mozilla issue, I'm only slightly interested in continuing to research this issue. As such, I'm fine with this bug being closed.
sorry for dropping the ball - I think you're right that we're dropping an error code from the SSL layer (or never getting that error propagated to us...) We've been getting other reports more recently of similar errors...
david, => NSPR ?
Wayne, it would be NSS, not NSPR, and it's not clear if we're dropping an error somewhere, or not getting it from NSS.
I don't know what you think might be an error in NSS.  
What do you think it might be doing wrong?  
Also, don't forget PSM.  The IMAP code goes to NSS through PSM.

The server log excerpt in comment 0, together with the other comments 
about the connection being dropped by the server (some of which are in 
the debian URL cited above), tell me that this is a bug in the SSL 
implementation in the server.  The server is unable to restart SSL 
sessions using session IDs that it has previously given to the client, 
and when it encounters its own error, instead of merely negotiating a 
new session (as the SSL protocol allows), it drops the connection.

Depending on the operation being performed when the error occurred
(e.g. PR_Write, PR_Recv, etc.) I would expect that NSS would either
- return 0 (indicating EOF on read) or
- return -1 (PR_FAILURE) with one of the following error codes
  - PR_END_OF_FILE_ERROR
  - PR_CONNECT_RESET_ERROR
If the server is sending any of the SSL error records to the client before
disconnection, then the error code might be any of the SSL error codes that
contain the word ALERT. 
If the server is committing any SSL protocol violations, then any of the 
numerous SSL errors that signify protocol violations could be used.  

The full list of NSPR, SSL and other NSS error codes may be seen at
http://lxr.mozilla.org/security/source/security/nss/cmd/lib/SSLerrs.h
http://lxr.mozilla.org/security/source/security/nss/cmd/lib/NSPRerrs.h
http://lxr.mozilla.org/security/source/security/nss/cmd/lib/SECerrs.h

We can try to improve the error reporting in the relevant PSM/Mail code paths
and/or wordsmith that error dialog, but I believe the ultimate solution to 
this user's problem will be to get the server fixed.
Assignee: mscott → nobody
Bienvenu, wrt comment 13, should we pursue a wordsmith change?  (I didn't look yet, but this sounds like another imap error message bug)

Moritz writes "Unfortunately, I cannot contribute to testing this
any further. Due to this and other problems I replaced Courier by
Dovecot some time ago in the production environment this issue occurred
in, and could not change it back now for testing"
Component: General → Networking: IMAP
Product: Thunderbird → MailNews Core
QA Contact: general → networking.imap
If it's a server configuration issue, it should be pretty rare, whereas the general Courier issue of limiting to 4 connections is not rare, or at least, wasn't a few years ago. We are saying that "You may have"...I'm not sure we could extend the error message to describe this issue, unless we got a specific error code from NSS (I'm not saying we couldn't get that error code, but we don't have it right now...)
Whiteboard: [psm-tcpip]
dup to Bug 315713 - Unclear error dialog Unable to connect to your IMAP server ?
Status: UNCONFIRMED → RESOLVED
Closed: 7 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.