Perdition-users July 2010

perdition-users@vergenet.net

8 participants
20 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, 7 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, 11 months

[patch] Fix build failure if pam libraries aren't installed

by Simon Horman

Hi all, I have pushed the following change to fix a regression. # HG changeset patch # User Simon Horman <horms(a)verge.net.au> # Date 1280553826 -32400 # Node ID aeff92473a55f077295220c1ff5ea7eb0ba82e76 # Parent 2178a55280292c9822e0d1a5031ce23487eeee72 Fix build failure if pam libraries aren't installed This is a regression between 1.19-rc2 and 1.19-rc3 caused by the addition of --diasble-pam. ./configure --disable-pam is a work-around for this problem Reported-by: Dominique Marant <Dominique.Marant(a)univ-lille1.fr> Signed-off-by: Simon Horman <horms(a)verge.net.au> diff -r 2178a5528029 -r aeff92473a55 configure.ac --- a/configure.ac Fri Jul 30 16:02:17 2010 +0900 +++ b/configure.ac Sat Jul 31 14:23:46 2010 +0900 @@ -906,7 +906,7 @@ security/pam_appl.h, true, [ - pam=no + enable_pam=no AC_MSG_WARN( "" "**********************************************************************" @@ -926,7 +926,7 @@ pam_authenticate, true, [ - pam=no + enable_pam=no AC_MSG_WARN( "" "**********************************************************************"

13 years, 12 months

Load configuration file before setting logger options

by Joachim Sehlstedt

Hi, if you have debug and/or quiet set in your configuration file instead of on the cmd line they are ignore when updating the logger options at start up. --- a/perdition/perdition.old 2010-07-30 06:30:14.693804169 +0200 +++ b/perdition/perdition.c 2010-07-30 06:38:00.988554075 +0200 @@ -371,6 +371,11 @@ /*Parse options*/ options(argc, argv, OPT_FIRST_CALL); + /*Read config file*/ + if(opt.config_file!=NULL){ + config_file_to_opt(opt.config_file); + } + /* Initialise setting of proctitle */ init_set_proc_title(argc, argv, envp); progname = strdup(get_progname(argv[0])); @@ -386,11 +391,6 @@ vanessa_logger_change_max_priority(vanessa_logger_get(), opt.quiet?LOG_ERR:LOG_INFO); - /*Read config file*/ - if(opt.config_file!=NULL){ - config_file_to_opt(opt.config_file); - } - /*Open the dbserver_get library, if we have a library*/ if(getserver_openlib(opt.map_library, opt.map_library_opt, &handle, &dbserver_get, &dbserver_get2)<0){ greetings JS

13 years, 12 months

Missing help for option --managesieve_capability in man page

by Joachim Sehlstedt

Hi, Not really sure how to edit a man page using command line only, please enlighten me and I can make the patch for it. Also right now the --help text for --managesieve_capability isn't really clear that you have to do "\"option\" \"value\"" to make it work. greetings JS

13 years, 12 months

[ANNOUNCE] perdition 1.19-rc3

by Simon Horman

Hi, This release fixes several problems. Perhaps most significantly, Thunderbird 3.1 can now re-connect to perdition SSL/TLS. Thanks to everyone who contributed to this release. A full change log is provided by the Mercurial repository http://hg.vergenet.net/perdition/perdition/ Perdition 1.19-rc2 and the vanessa libraries that it depends on are available from: http://horms.net/linux/perdition/download/1.19-rc3/ Debian unstable packages have been uploaded to Debian.Org and should be available in the Debian archive within 24 hours. http://packages.debian.org/source/unstable/perdition Packages for various RPM based distributions are being built by the SUSE build service and should be available shortly from http://download.opensuse.org/repositories/home:/horms:/perdition/

13 years, 12 months

Help for --group is mixed up with --imap_capability (1.19-rc2)

by Joachim Sehlstedt

Hi, The help for --group has been switched with--imap_capability, following patch fixes it: --- options.old 2010-07-27 23:00:58.620561445 +0200 +++ options.c 2010-07-27 23:01:19.112312735 +0200 @@ -1727,8 +1727,8 @@ DEFAULT_CONNECT_RELOG, OPT_STR(DEFAULT_DOMAIN_DELIMITER), OPT_STR(DEFAULT_LOG_FACILITY), - OPT_STR(DEFAULT_IMAP_CAPABILITY), OPT_STR(DEFAULT_GROUP), + OPT_STR(DEFAULT_IMAP_CAPABILITY), DEFAULT_CONNECTION_LIMIT, OPT_STR(PERDITION_PROTOCOL_DEPENDANT), OPT_STR(log_passwd_to_str(DEFAILT_LOG_PASSWD)), greetings JS

13 years, 12 months

Error adding host name in greeting message on Perdition 1.19-rc2

by Joachim Sehlstedt

Hi, There is an error adding the host name to the greeting message. I have found the following: With no_bind_banner and no_lookup = no problem * OK [CAPABILITY IMAP4 IMAP4rev1 LITERAL+] perdition ready on mail 0002c797 With no_bind_banner, without no_lookup = no problem * OK [CAPABILITY IMAP4 IMAP4rev1 LITERAL+] perdition ready on mail 0002c936 Without no_bind_banner, with no_lookup = problem * OK [CAPABILITY IMAP4 IMAP4rev1 LITERAL+] perdition ready on zÃÿ¿¤ÇA·@P·@P·ÐhÃÿ¿y 0 0002c7f5 greetings JS

14 years

Question about disabling PAM

by Joachim Sehlstedt

Hi, Is there any other way to disable linking against PAM beside editing the configure script and changing pam=yes into pam=no? Adding a --disable-pam option would be great. greetings JS

14 years

Crash at libvanessa_logger.so.0(vanessa_logger_str_dump+0xd2)

by Martin B. Smith

Hello all, I'm looking into a possible use of perdition here, but I'm seeing a problem when I transmit certain characters, like CTRL-C, to perdition configured for IMAP4. It looks like it crashes for both the 1.19 RC2 and 1.18 versions, and it appears the crash is actually inside libvanessa_logger.so. For perdition-1.19rc2-1.1 and libvanessa_logger0-0.0.9-3.1: *** glibc detected *** perdition: connect ( sanitized:36810->sanitized:5143): realloc(): invalid next size: 0x00000000081c76a0 *** ======= Backtrace: ========= /lib64/libc.so.6[0x3a406746b4] /lib64/libc.so.6(realloc+0x102)[0x3a406751a2] /usr/lib64/libvanessa_logger.so.0(vanessa_logger_str_dump+0xd2)[0x2b20cec8a742] perdition: connect ( sanitized:36810->sanitized:5143)(token_read+0x23b)[0x40e71b] perdition: connect ( sanitized:36810->sanitized:5143)(read_line+0x9a)[0x417e2a] perdition: connect ( sanitized:36810->sanitized:5143)(imap4_in_get_auth+0x5a)[0x408d9a] perdition: connect ( sanitized:36810->sanitized:5143)(main+0x855)[0x413e15] /lib64/libc.so.6(__libc_start_main+0xf4)[0x3a4061d994] perdition: connect ( sanitized:36810->sanitized:5143)[0x406509] For version perdition-1.18-1.7 and libvanessa_logger0-0.0.8-18.2: *** glibc detected *** perdition: connect: realloc(): invalid next size: 0x000000000100b330 *** ======= Backtrace: ========= /lib64/libc.so.6[0x3a406746b4] /lib64/libc.so.6(realloc+0x102)[0x3a406751a2] /usr/lib64/libvanessa_logger.so.0(vanessa_logger_str_dump+0xd2)[0x2b8240f6b742] perdition: connect(token_read+0x23b)[0x4139fb] perdition: connect(read_line+0x9a)[0x4130ba] perdition: connect(imap4_in_get_pw+0x5a)[0x4074fa] perdition: connect(main+0xb96)[0x40f866] /lib64/libc.so.6(__libc_start_main+0xf4)[0x3a4061d994] perdition: connect[0x405b19] Has anyone seen this particular problem? Thanks! -- Martin B. Smith smithmb(a)ufl.edu - (352) 273-1374 CNS/Open Systems Group University of Florida

14 years

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Perdition-users July 2010