Hi,
Are you sure that you can connect a second time from
the same thunderbird session? I don't have a ca_file handy
to test with, but with the rest of the optoins set I see the problem.
Well there
still is something wrong it seems. Here is what I get in the
log when I start TB and it tries to connect:
Jul 27 15:19:49 mail perdition[31439]: Fatal Error reading
authentication information from client X:59820->Y:994: Exiting child
However directly followed by that error I get valid logins in Cyrus imap:
Jul 27 15:19:49 mail imap[29007]: login: localhost [127.0.0.1] u0001
plaintext User logged in
Jul 27 15:19:55 mail imap[29127]: login: localhost [127.0.0.1] u0001
plaintext User logged in
Jul 27 15:19:56 mail imap[29011]: login: localhost [127.0.0.1] u0001
plaintext User logged in
Jul 27 15:20:25 mail imap[31196]: login: localhost [127.0.0.1] u0001
plaintext User logged in
Process list
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
nobody 31434 0.0 0.0 6008 1288 ? S 15:19 0:00
perdition: daemon
nobody 31438 0.0 0.0 6144 2228 ? S 15:19 0:00 \_
perdition: connect (u0001)
nobody 31441 0.0 0.0 6144 2048 ? S 15:19 0:00 \_
perdition: connect (u0001)
nobody 31443 0.0 0.0 6144 2048 ? S 15:19 0:00 \_
perdition: connect (u0001)
nobody 31445 0.0 0.0 6144 2048 ? S 15:20 0:00 \_
perdition: connect (u0001)
And when I close TB I get logs for each of the processes saying Closing
session: X:59809->Y:994 authorisation_id=NONE authentication_id="u0001"
received=XX sent=XX
But on the client side I don't notice anything wrong and I can switch
between folders and read mail without any problems, in version 1.18 I
would get the SSL error by just switching to a new imap folder. I'll
switch to run perdition in debug mode to see if I can give you anything
better to work with.
I however wonder if Mozilla changed something to get around the error
seeing as TB using 4 sessions all of a sudden, or is that a change in
Perdition?
No.
Due to a lack of understanding on my part when I added SSL support to
perdition, SSL and TLS do not have their normal meanings
in relation to the parameters to ssl_mode :-(
In a nutshell
* ssl_* means use SSL/TLS (i.e. port 993, 995, ...)
That is, the starts an SSL/TLS negotiation on connect
* tls_* means use STARTTLS, STLS...
That is, the user can upgrade a session from plantext tos
encrypted (using SSL/TLS) after connecting.
Thank you for the clarification :)
Is that this line?
ssl_method = SSLv23_method();
Yes it is, should have included that for you.
I'm not seeing the warniing here.
Which version of gcc and libssl do you have?
Alternatively, do you know what the problem is?
Running gcc 4.3.3 here and OpenSSL
1.0.0a.
Lastly, taking a stab in the dark, does this help?
Index: perdition/perdition/ssl.c
===================================================================
--- perdition.orig/perdition/ssl.c 2010-07-27 18:35:15.000000000 +0900
+++ perdition/perdition/ssl.c 2010-07-27 18:35:44.000000000 +0900
@@ -492,7 +492,6 @@ SSL_CTX *perdition_ssl_ctx(const char *c
const char *cert, const char *privkey,
const char *ca_chain_file, const char *ciphers, flag_t flag)
{
- SSL_METHOD *ssl_method;
SSL_CTX *ssl_ctx, *out = NULL;
const char *use_ca_file = NULL;
const char *use_ca_path = NULL;
@@ -519,10 +518,9 @@ SSL_CTX *perdition_ssl_ctx(const char *c
* Initialise an SSL context
*/
SSLeay_add_ssl_algorithms();
- ssl_method = SSLv23_method();
SSL_load_error_strings();
- ssl_ctx = SSL_CTX_new(ssl_method);
+ ssl_ctx = SSL_CTX_new(SSLv23_method());
if (!ssl_ctx) {
PERDITION_DEBUG_SSL_ERR("SSL_CTX_new");
return NULL;
Not only does it take away the build warning, it also removes the error
I get on the first connect I listed above.
greetings
JS