Perdition-users August 2010

perdition-users@vergenet.net

10 participants
11 discussions

Zombie pop3s (and imaps?) processes in connect state

by Christian Balzer

Hello, we've been using perdition as a pop3/pop3s/imap/imaps proxy for about four years now, first with Debian Sarge package and now under Etch. And throughout this time I've seen pop3s (and from the looks of it the same happens with imaps) processes stuck in connect, like this: --- 16836 ? S 5:31 0 120 32179 2204 0.0 perdition.pop3s 28070 ? S 0:00 0 120 32311 1564 0.0 \_ perdition.pop3s: connect 7782 ? S 0:00 0 120 32311 1564 0.0 \_ perdition.pop3s: connect 24468 ? S 0:00 0 120 32311 1568 0.0 \_ perdition.pop3s: connect 14180 ? S 0:00 0 120 32311 1568 0.0 \_ perdition.pop3s: connect 13503 ? S 0:00 0 120 32311 1564 0.0 \_ perdition.pop3s: connect --- They never die off, keep the connection open, there is no traffic and the other end might be long gone. Last trace in the logs is always like this: --- Feb 5 22:05:16 pp11 perdition[7782]: Connect: hi.mi.ts.u->203.216.5.113 --- It must be something related to the SSL'ness of these service, since I'm not seeing this happening ever for imap/pop3. Alas a lot of people do use TLS with those, so it's not a generic SSL issue. Maybe the master process could kick a child handling connections in the head after "timeout" seconds in connect state? If more information is needed I can try to provide it, but note that with a rate of roughly 35 pops per second I'm a bit weary to turn on debugging. ^_- This may or may not be related to another SSL related issue, which will be for the sake of making searches in the archive more likely to find good keywords in a separate mail. Regards, Christian -- Christian Balzer Network/Systems Engineer NOC chibi(a)gol.com Global OnLine Japan/Fusion Network Services http://www.gol.com/

11 years, 4 months

perdition 1.19-rc3 log_options_ssl_str() segv

by Doug Shearer

I am new to this list. We have been using perdition-1.17.1 for the better part of two years ... thank you! We are running perdition on Solaris 9 and 10. Some kind soul (can't remember who) posted source for mkdtemp and I was able to compile using gcc 3.4.6 from www.sunfreeware.com. We have been bitten by the Thunderbird 3.1 to perdition SSL/TLS bug. I am trying to build and run perdition-1.19-rc3 ... so far unsuccessfully. When run, perdition gives a segmentation fault. Many thanks in advance to anyone who can shed any light on this! I built and installed vanessa_logger-0.0.10, vanessa_adt-0.0.9, and vanessa_socket-0.0.12. perdition-1.19-rc3 compiled (with the addition of mkdtemp and the following patch): diff perdition.c.orig perdition.c 582c582 < fromv = malloc(((nfrom * 2) + 1)); --- > fromv = malloc(sizeof(*fromv) * ((nfrom * 2) + 1)); But when I ran it, it got a segmentation fault. gdb session showing segmentation fault: gdb GNU gdb 6.8 Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html > This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i386-pc-solaris2.10". (gdb) file /local/staff/mail3/opt/sbin/perdition.imap4 Reading symbols from /local/staff/mail3/opt/sbin/perdition.imap4...done. (gdb) b perdition.c:498 Breakpoint 1 at 0x8063e29: file perdition.c, line 498. (gdb) r -C -d --inetd_mode \ -p 26993 -M /usr/local/lib/libperditiondb_ldap.so. 0 --ssl_ca_path /etc/mail/certs \ --ssl_cert_file /etc/mail/certs/mail3.crt -- ssl_key_file /etc/mail/certs/private/mail3.key \ --ssl_ca_file /etc/mail/certs/CA.crt -- ssl_no_cn_verify --log_facility - Starting program: /local/staff/mail3/opt/sbin/perdition.imap4 -C -d -- inetd_mode -p 26993 -M /usr/local/lib/ libperditiondb_ldap.so.0 --ssl_ca_path /etc/mail/ certs --ssl_cert_file /etc/mail/certs/mail3.crt -- ssl_key_file /etc/mail/certs/private/mail3.key -- ssl_ca_file /etc/mail/certs/CA.crt --ssl_no_cn_verify --log_facility - Using LDAP version: 3 Breakpoint 1, main (argc=19, argv=0x8047b40, envp=0x8047b90) at perdition.c:498 498 if (log_options()) { (gdb) s log_options () at options.c:1473 1473 a = log_options_str(); (gdb) s log_options_str () at options.c:1432 1432 a = calloc(4, sizeof(char *)); (gdb) n 1433 if (!a) { (gdb) n 1438 a[0] = log_options_head_str(); (gdb) n 1439 if (!a[0]) (gdb) n 1441 a[1] = log_options_non_ssl_str(); (gdb) n 1442 if (!a[1]) (gdb) n 1445 a[2] = log_options_ssl_str(); (gdb) p a[0] $1 = 0x808e390 "Starting perdition version=1.19-rc3 protocol=IMAP4" (gdb) p a[1] $2 = 0x808f398 "add_domain=\"\", authenticate_in=off, authenticate_timeout=1800, bind_address=\"\", client_server_specification=off, config_file=\"/usr/local/etc/ perdition/perdition.imap4.conf\", connection_limit=0, connec"... (gdb) s log_options_ssl_str () at options.c:1330 1330 char *ssl_mode_p = NULL; (gdb) n 1331 char *out = NULL; (gdb) n 1333 out = malloc(MAX_LINE_LENGTH); (gdb) n 1334 if (!out) { (gdb) n 1339 switch (opt.ssl_mode) { (gdb) n 1347 ssl_mode_p=ssl_mode; (gdb) n 1348 if (opt.ssl_mode & SSL_MODE_SSL_LISTEN && (gdb) n 1351 else if (opt.ssl_mode & SSL_MODE_TLS_LISTEN && (gdb) n 1355 if (opt.ssl_mode & SSL_MODE_SSL_LISTEN) (gdb) n 1358 if (opt.ssl_mode & SSL_MODE_SSL_OUTGOING) (gdb) n 1359 LOG_OPTIONS_ADD_STR("ssl_outgoing", ssl_mode_p, (gdb) n 1361 if (opt.ssl_mode & SSL_MODE_TLS_LISTEN) (gdb) n 1362 LOG_OPTIONS_ADD_STR("tls_listen", ssl_mode_p, (gdb) n 1364 if (opt.ssl_mode & SSL_MODE_TLS_OUTGOING) (gdb) n 1367 if (ssl_mode_p == ssl_mode) (gdb) n 1372 if ((opt.ssl_mode & SSL_MODE_TLS_OUTGOING_FORCE) && (gdb) n 1377 if (opt.ssl_mode&SSL_MODE_TLS_OUTGOING_FORCE) (gdb) n 1380 if (opt.ssl_mode&SSL_MODE_TLS_LISTEN_FORCE) (gdb) n 1381 LOG_OPTIONS_ADD_STR("tls_listen_force", ssl_mode_p, (gdb) n 1385 snprintf(out, MAX_LINE_LENGTH - 1, (gdb) p out $3 = 0x80903a0 "" (gdb) p *out $4 = 0 '\0' (gdb) p ssl_mode $5 = "ssl_outgoing,tls_listen,tls_listen_force" (gdb) p opt_str(opt.ssl_ca_file) $6 = 0x808c028 "/etc/mail/certs/CA.crt" (gdb) p opt_str(opt.ssl_ca_path) $7 = 0x808ba00 "/etc/mail/certs" (gdb) p ((opt.ssl_ca_accept_self_signed)?"on":"off") $8 = "off" (gdb) p opt_str(opt.ssl_cert_file) $9 = 0x808cd48 "/etc/mail/certs/mail3.crt" (gdb) p ((opt.ssl_cert_accept_expired)?"on":"off") $10 = "off" (gdb) p ((opt.ssl_cert_accept_not_yet_valid)?"on":"off") $11 = "off" (gdb) p ((opt.ssl_cert_accept_self_signed)?"on":"off") $12 = "off" (gdb) p opt.ssl_cert_verify_depth $13 = 9 (gdb) p opt_str(opt.ssl_key_file) $14 = 0x808c9c0 "/etc/mail/certs/private/mail3.key" (gdb) p opt_str(opt.ssl_listen_ciphers) $15 = 0x80708a4 "" (gdb) p opt_str(opt.ssl_outgoing_ciphers) $16 = 0x80708a4 "" (gdb) p ((opt.ssl_no_cert_verify)?"on":"off") $17 = "off" (gdb) p ((opt.ssl_no_client_cert_verify)?"on":"off") $18 = "off" (gdb) p ((opt.ssl_no_cn_verify)?"on":"off") $19 = "on" (gdb) p opt.ssl_passphrase_fd $20 = 0 (gdb) p opt.ssl_passphrase_file $21 = 0x0 (gdb) p opt.ssl_mask $22 = 16918 (gdb) n Program received signal SIGSEGV, Segmentation fault. 0xfece58fc in strlen () from /lib/libc.so.1 Thanks! Doug Shearer Lamont-Doherty Earth Observatory of Columbia University 61 Route 9W Palisades, NY 10964

13 years, 7 months

perdition stops accepting connections?

by eric c

Hi, I've been running perdition (1.17.1) for about 4 years on a linux box and moved to freebsd and started experiencing that perdition would just die. Here are my specs: 8.0-RELEASE-p2 FreeBSD 8.0-RELEASE-p2 (amd64) perdition-1.18 vanessa_adt-0.0.8 vanessa_logger-0.0.8 vanessa_socket-0.0.10 openldap-client-2.3.43 perdition.pop3.conf: #debug #connection_logging map_library /usr/local/lib/libperditiondb_ldap.so map_library_opt "ldap://10.0.2.56 10.0.2.58/ou=EmailAccount,o=mywebber.com?uid,mailhost,port?one?(uid=%25s)" username_from_database pid_file /var/run/perdition.pop3.pid #log_facility /dev/null log_facility mail timeout 60 ## I haven't turned on full debug but this usually happens: Aug 7 18:21:28 proxy0 perdition[24335]: Fatal error accepting child connection. Exiting. Aug 7 18:21:28 proxy0 perdition[24335]: Could not remove pid file [/var/run/perdition.pop3.pid]: Permission denied I have a watchdog program that restarts perdition. This could affect pop3 or pop3s. There is not pattern of when it happens. Has anyone seen this? Thanks! eric c

13 years, 7 months

Problem configuring multiple LDAP servers

by Stephen Figgins

I can get perdition to query either of my ldap servers individually, but not when I specify both. This entry in my perdition.conf file works: map_library /usr/lib/libperditiondb_ldap.so.0 map_library_opt 3:ldap://ldap/ou=Accounts,dc=sunflower,dc=com?uid,mailhost?sub?(uid=%25s) This does not map_library /usr/lib/libperditiondb_ldap.so.0 map_library_opt 3:ldap://ldap ldap2/ou=Accounts,dc=sunflower,dc=com?uid,mailhost?sub?(uid=%25s) When using the second perdition fails to retrieve the mailhost. I don't see any logs of errors on my ldap servers. It's as if perdition never reaches them. Instead it appears to time out and then returns this: -ERR failed: Could not determine server My perdition server is running on Ubuntu 10.04 and perdition version 1.18-2 installed from ubuntu's packages. Any ideas on how to get this to work? -- Stephen Figgins Systems Administrator Sunflower Broadband

13 years, 7 months

[patch] OpenLDAP defaults in perdition

by Patrick Cernko

Hi Perdition Users, I developed a small patch, which makes it possible to delegate the specification of LDAP servers and default search base to OpenLDAP's configuration mechanisms (ldap.conf, .ldaprc, environment variables). The patch was developed by myself. I wanted to avoid to specify the LDAP servers and default search base twice. We have to provide these settings in /etc/ldap/ldap.conf anyway and so I thought, why not use OpenLDAP's auto-configuration in perdition too. I used perdition-1.18 to develop the patch and modified it to make it apply to the latest mercurial version. Unfortunately I cannot check this versions at the moment, but reading the code, I'm very convinced that it will work as expected. Patch is attached. Signed-off-by: Patrick Cernko <pcernko(a)mpi-sws.org> So long, -- Patrick Cernko | mailto:pcernko@mpi-sws.org

13 years, 8 months

Re: [PERDITION-USERS] upgrading from perdition-1.15 toperdition-1.18

by cami＠mweb.co.za

Hi, Just to follow up. The issue was fixed by enabling: # U|username_from_database: # Substitute username from popmap lookup. #U username_from_database Someone care to explain exactly what that is doing? Regards, Cami From: cami(a)mweb.co.za Sent:2010-08-13 20:32:46 To: perdition-users(a)vergenet.net Cc: Subject: Re: [PERDITION-USERS] upgrading from perdition-1.15 toperdition-1.18 Hi, Thanks for the help. I tried that but the SQL query isn't returning the correct data. mysql> select mail_host_map,mail_username,143 from access_maps where mail_host_map='cami(a)24.com' Empty set (0.51 sec) mysql> desc access_maps; +---------------+----------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +---------------+----------+------+-----+---------+-------+ | mail_username | char(60) | NO | PRI | | | | mail_host_map | char(60) | NO | | | | | loginid | char(32) | NO | MUL | NULL | | +---------------+----------+------+-----+---------+-------+ 3 rows in set (0.00 sec) mysql> select * from access_maps where mail_username = "cami(a)24.com"; +---------------+-------------------------------------------------+----------------------------------+ | mail_username | mail_host_map | loginid | +---------------+-------------------------------------------------+----------------------------------+ | cami(a)24.com | f2ef77fe86754109b347dd97a79444eb(a)152.111.194.93 | f2ef77fe86754109b347dd97a79444eb | +---------------+-------------------------------------------------+----------------------------------+ 1 row in set (0.00 sec) IMAP4_FLAGS="-l 143 -M /usr/lib64/libperditiondb_mysql.so.0.0.0 -m 152.111.194.116:3306:MAIL:access_maps:postfix:XXX:mail_host_map:mail_username:143 -d" Any other ideas? Is there any way to debug what Perdition is doing when it receives data from SQL? Cami From: uk(a)newstyledata.net Sent:2010-08-13 17:13:16 To: perdition-users(a)vergenet.net Cc: Subject: Re: [PERDITION-USERS] upgrading from perdition-1.15 toperdition-1.18 Hi, Seems you have the map_library_opt option in the wrong order, just switch mail_username and mail_host_map and it should work again. [:[:[:[:[:[:[:[:]]]]]]]] greetings JS On 2010-08-13 16:21, cami(a)mweb.co.za wrote: > Hi All, > > > I've been trying to upgrade from perdition 1.15 to perdition 1.18 > without any luck. > > The behaviour is different with regards to MySQL data which are returned. > > > The query: > > > select mail_username,mail_host_map,143 from access_maps where > mail_username='cami(a)24.com'; > +---------------+-------------------------------------------------+-----+ > | mail_username | mail_host_map | 143 | > +---------------+-------------------------------------------------+-----+ > | cami(a)24.com | f2ef77fe86754109b347dd97a79444eb(a)152.111.194.93 | 143 | > +---------------+-------------------------------------------------+-----+ > > > In 1.15 "f2ef77fe86754109b347dd97a79444eb" is correctly returned as seen > here: > > > Aug 13 16:18:25 mailstore01 imapd: LOGIN: DEBUG: ip=[::ffff:127.0.0.1], > command=LOGIN > Aug 13 16:18:25 mailstore01 imapd: LOGIN: DEBUG: ip=[::ffff:127.0.0.1], > username=f2ef77fe86754109b347dd97a79444eb > Aug 13 16:18:25 mailstore01 imapd: LOGIN: DEBUG: ip=[::ffff:127.0.0.1], > password=XXXX > Aug 13 16:18:25 mailstore01 imapd: authdaemon: starting client module > Aug 13 16:18:25 mailstore01 imapd: authdaemon: ACCEPT, username > f2ef77fe86754109b347dd97a79444eb > Aug 13 16:18:25 mailstore01 imapd: LOGIN, > user=f2ef77fe86754109b347dd97a79444eb, ip=[::ffff:127.0.0.1], protocol=IMAP > > (the imap server being used is Courier) > > > In 1.18 "cami(a)24.com" is being returned and passed onto Courier instead > of "f2ef77fe86754109b347dd97a79444eb" > > > Aug 13 15:07:15 mailstore01 imapd: LOGIN: DEBUG: > ip=[::ffff:152.111.194.109], command=LOGIN > Aug 13 15:07:15 mailstore01 imapd: LOGIN: DEBUG: > ip=[::ffff:152.111.194.109], username=cami(a)24.com > Aug 13 15:07:15 mailstore01 imapd: LOGIN: DEBUG: > ip=[::ffff:152.111.194.109], password=XXXX > Aug 13 15:07:15 mailstore01 imapd: authdaemon: starting client module > Aug 13 15:07:15 mailstore01 imapd: authdaemon: REJECT > > > Can anyone tell me how to revert back to the old behaviour to how to go > about trouble shooting this? > > > Regards, > > Cami > > > > ______________________________________________ > Perdition-users mailing list > Perdition-users(a)vergenet.net > http://lists.vergenet.net/listinfo/perdition-users ______________________________________________ Perdition-users mailing list Perdition-users(a)vergenet.net http://lists.vergenet.net/listinfo/perdition-users

13 years, 8 months

Re: [PERDITION-USERS] upgrading from perdition-1.15 toperdition-1.18

by cami＠mweb.co.za

Hi, Thanks for the help. I tried that but the SQL query isn't returning the correct data. mysql> select mail_host_map,mail_username,143 from access_maps where mail_host_map='cami(a)24.com' Empty set (0.51 sec) mysql> desc access_maps; +---------------+----------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +---------------+----------+------+-----+---------+-------+ | mail_username | char(60) | NO | PRI | | | | mail_host_map | char(60) | NO | | | | | loginid | char(32) | NO | MUL | NULL | | +---------------+----------+------+-----+---------+-------+ 3 rows in set (0.00 sec) mysql> select * from access_maps where mail_username = "cami(a)24.com"; +---------------+-------------------------------------------------+----------------------------------+ | mail_username | mail_host_map | loginid | +---------------+-------------------------------------------------+----------------------------------+ | cami(a)24.com | f2ef77fe86754109b347dd97a79444eb(a)152.111.194.93 | f2ef77fe86754109b347dd97a79444eb | +---------------+-------------------------------------------------+----------------------------------+ 1 row in set (0.00 sec) IMAP4_FLAGS="-l 143 -M /usr/lib64/libperditiondb_mysql.so.0.0.0 -m 152.111.194.116:3306:MAIL:access_maps:postfix:XXX:mail_host_map:mail_username:143 -d" Any other ideas? Is there any way to debug what Perdition is doing when it receives data from SQL? Cami From: uk(a)newstyledata.net Sent:2010-08-13 17:13:16 To: perdition-users(a)vergenet.net Cc: Subject: Re: [PERDITION-USERS] upgrading from perdition-1.15 toperdition-1.18 Hi, Seems you have the map_library_opt option in the wrong order, just switch mail_username and mail_host_map and it should work again. [:[:[:[:[:[:[:[:]]]]]]]] greetings JS On 2010-08-13 16:21, cami(a)mweb.co.za wrote: > Hi All, > > > I've been trying to upgrade from perdition 1.15 to perdition 1.18 > without any luck. > > The behaviour is different with regards to MySQL data which are returned. > > > The query: > > > select mail_username,mail_host_map,143 from access_maps where > mail_username='cami(a)24.com'; > +---------------+-------------------------------------------------+-----+ > | mail_username | mail_host_map | 143 | > +---------------+-------------------------------------------------+-----+ > | cami(a)24.com | f2ef77fe86754109b347dd97a79444eb(a)152.111.194.93 | 143 | > +---------------+-------------------------------------------------+-----+ > > > In 1.15 "f2ef77fe86754109b347dd97a79444eb" is correctly returned as seen > here: > > > Aug 13 16:18:25 mailstore01 imapd: LOGIN: DEBUG: ip=[::ffff:127.0.0.1], > command=LOGIN > Aug 13 16:18:25 mailstore01 imapd: LOGIN: DEBUG: ip=[::ffff:127.0.0.1], > username=f2ef77fe86754109b347dd97a79444eb > Aug 13 16:18:25 mailstore01 imapd: LOGIN: DEBUG: ip=[::ffff:127.0.0.1], > password=XXXX > Aug 13 16:18:25 mailstore01 imapd: authdaemon: starting client module > Aug 13 16:18:25 mailstore01 imapd: authdaemon: ACCEPT, username > f2ef77fe86754109b347dd97a79444eb > Aug 13 16:18:25 mailstore01 imapd: LOGIN, > user=f2ef77fe86754109b347dd97a79444eb, ip=[::ffff:127.0.0.1], protocol=IMAP > > (the imap server being used is Courier) > > > In 1.18 "cami(a)24.com" is being returned and passed onto Courier instead > of "f2ef77fe86754109b347dd97a79444eb" > > > Aug 13 15:07:15 mailstore01 imapd: LOGIN: DEBUG: > ip=[::ffff:152.111.194.109], command=LOGIN > Aug 13 15:07:15 mailstore01 imapd: LOGIN: DEBUG: > ip=[::ffff:152.111.194.109], username=cami(a)24.com > Aug 13 15:07:15 mailstore01 imapd: LOGIN: DEBUG: > ip=[::ffff:152.111.194.109], password=XXXX > Aug 13 15:07:15 mailstore01 imapd: authdaemon: starting client module > Aug 13 15:07:15 mailstore01 imapd: authdaemon: REJECT > > > Can anyone tell me how to revert back to the old behaviour to how to go > about trouble shooting this? > > > Regards, > > Cami > > > > ______________________________________________ > Perdition-users mailing list > Perdition-users(a)vergenet.net > http://lists.vergenet.net/listinfo/perdition-users ______________________________________________ Perdition-users mailing list Perdition-users(a)vergenet.net http://lists.vergenet.net/listinfo/perdition-users

13 years, 8 months

upgrading from perdition-1.15 to perdition-1.18

by cami＠mweb.co.za

Hi All, I've been trying to upgrade from perdition 1.15 to perdition 1.18 without any luck. The behaviour is different with regards to MySQL data which are returned. The query: select mail_username,mail_host_map,143 from access_maps where mail_username='cami(a)24.com'; +---------------+-------------------------------------------------+-----+ | mail_username | mail_host_map | 143 | +---------------+-------------------------------------------------+-----+ | cami(a)24.com | f2ef77fe86754109b347dd97a79444eb(a)152.111.194.93 | 143 | +---------------+-------------------------------------------------+-----+ In 1.15 "f2ef77fe86754109b347dd97a79444eb" is correctly returned as seen here: Aug 13 16:18:25 mailstore01 imapd: LOGIN: DEBUG: ip=[::ffff:127.0.0.1], command=LOGIN Aug 13 16:18:25 mailstore01 imapd: LOGIN: DEBUG: ip=[::ffff:127.0.0.1], username=f2ef77fe86754109b347dd97a79444eb Aug 13 16:18:25 mailstore01 imapd: LOGIN: DEBUG: ip=[::ffff:127.0.0.1], password=XXXX Aug 13 16:18:25 mailstore01 imapd: authdaemon: starting client module Aug 13 16:18:25 mailstore01 imapd: authdaemon: ACCEPT, username f2ef77fe86754109b347dd97a79444eb Aug 13 16:18:25 mailstore01 imapd: LOGIN, user=f2ef77fe86754109b347dd97a79444eb, ip=[::ffff:127.0.0.1], protocol=IMAP (the imap server being used is Courier) In 1.18 "cami(a)24.com" is being returned and passed onto Courier instead of "f2ef77fe86754109b347dd97a79444eb" Aug 13 15:07:15 mailstore01 imapd: LOGIN: DEBUG: ip=[::ffff:152.111.194.109], command=LOGIN Aug 13 15:07:15 mailstore01 imapd: LOGIN: DEBUG: ip=[::ffff:152.111.194.109], username=cami(a)24.com Aug 13 15:07:15 mailstore01 imapd: LOGIN: DEBUG: ip=[::ffff:152.111.194.109], password=XXXX Aug 13 15:07:15 mailstore01 imapd: authdaemon: starting client module Aug 13 15:07:15 mailstore01 imapd: authdaemon: REJECT Can anyone tell me how to revert back to the old behaviour to how to go about trouble shooting this? Regards, Cami

13 years, 8 months

SSL problem

by Christian Schoepplein

Hi, we use perdition v 1.17.1 on a FreeBSD box and I'd like to configure the following setup: 1. From outside only allow connections via ssl on port 993 2. Connect to the internal servers via tls or if not possible via normal imap I set --ssl_mode to "ssl_listen,tls_outgoing" and also -p to "143", but that results in an error and the tls connect to the internal server is not established :(. Unfortunatly I can't give more infos about the error, the BSD machine with perdition and the internal servers do not log more details. Has anyone more ideas how to get the described setup from above can be configured? Or, if not possible, is it possible to establish an internal connection without tls? Thanks for any hint, Christian -- Christian Schöpplein Landeshauptstadt München Schulreferat Zentrum f�r Informationstechnologie im Bildungsbereich (ZIB) - Netze und Servermanagement Postanschrift: Neuhauser Str. 39, 80331 M�nchen B�roanschrift: Bayerstr. 28, Raum 505, 80335 M�nchen T: +49 (0)89 233-43042 oder +49 (0)89 233-43080 F: +49 (0)89 233-42951 E: christian (at) musin.de

13 years, 8 months

Thunderbird 3.1 SSL/TLS Renegotiation

by John Feuerstein

Hi List, I've just searched the July 2010 Archives [1] for a problem with Mozilla Thunderbird 3.1 and a TLS connection to Perdition, but am still missing a solution. After connecting to Perdition, Thunderbird 3.1 emits warnings like: > Server "foo(a)bar.com" has disconnected. > The server may have gone down or there may be a network problem. Looking into the perdition logs reveals: > perdition[9088]: Connect: 121.121.121.121->123.123.123.123 > perdition[9088]: Fatal error establishing TLS connection The same when running perdition in debug mode: > perdition[10304]: Connect: 121.121.121.121->123.123.123.123 > perdition[10304]: SELF: "* OK IMAP4 Ready 121.121.121.121 0001cd8b\r\n" > perdition[10304]: CLIENT: "1 capability\r\n" > perdition[10304]: SELF: "* CAPABILITY IMAP4 IMAP4REV1 STARTTLS\r\n" > perdition[10304]: SELF: "1 OK CAPABILITY\r\n" > perdition[10304]: CLIENT: "2 STARTTLS\r\n" > perdition[10304]: SELF: "2 OK Begin TLS negotiation now\r\n" > perdition[10304]: __perdition_ssl_connection: error:140D9115:SSL routines:SSL_GET_PREV_SESSION:session id context uninitialized > perdition[10304]: __perdition_ssl_connection: SSL_accept > perdition[10304]: __perdition_ssl_connection: no shared ciphers? > perdition[10304]: perdition_ssl_server_connection: perdition_ssl_connection > perdition[10304]: main: perdition_ssl_server_connection TLS > perdition[10304]: Fatal error establishing TLS connection I think the "no shared ciphers" is misleading here, it's the first message that looks b0rked: > perdition[10304]: __perdition_ssl_connection: > error:140D9115:SSL routines:SSL_GET_PREV_SESSION: > session id context uninitialized This could be related to the SSL/TLS renegotiation [2] done by the recent Mozilla stack because of CVE-2009-3555, as pointed to by Thierry Hotelier some days ago [3]. There is another mail by Giorgio Paolucci [4] indicating a problem with the ssl/tls session caching (which really matches the error message). Too bad the proposed fix (patch?) did not end up in the mailing list archive. Could someone (Georgio?) please re-post this patch inline so others will find it without being subscribed? After a quick search on openssl-users it looks like this can be fixed using SSL_CTX_set_session_id_context. Any news on this? Thanks. [1] http://lists.vergenet.net/pipermail/perdition-users/2010-July/thread.html [2] https://wiki.mozilla.org/Security:Renegotiation [3] http://lists.vergenet.net/pipermail/perdition-users/2010-July/002336.html [4] http://lists.vergenet.net/pipermail/perdition-users/2010-July/002341.html

13 years, 8 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Perdition-users August 2010