Perdition-users November 2009

perdition-users@vergenet.net

10 participants
14 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, 9 months

Problems with IMAP4S LOGIN command

by TOPdesk Systeembeheer (beheer＠TOPdesk.com)

Hi everybody, Since an upgrade to our backend IMAPS server (Zarafa 6.20.7), we have some trouble authenticating via our perdition IMAP4S proxy (version 1.17-7etch1). I've enabled debug and connection logging, and I see that the LOGIN command is splitted in 3 lines instead of sending the whole command in one. Is that normal? Can I configure it somewhere? Here is the log I get: Jul 2 14:33:45 floor perdition[9781]: Connect: xx.xx.xx.xx -> [IP proxy] Jul 2 14:33:45 floor perdition[9781]: SSL connection using AES128-SHA Jul 2 14:33:45 floor perdition[9781]: SELF: "* OK IMAP4 Ready floor 0001d839\r\n" Jul 2 14:33:46 floor perdition[9781]: CLIENT: "1.584 CAPABILITY\r\n" Jul 2 14:33:46 floor perdition[9781]: SELF: "* CAPABILITY IMAP4 IMAP4REV1\r\n" Jul 2 14:33:46 floor perdition[9781]: SELF: "1.584 OK CAPABILITY\r\n" Jul 2 14:33:46 floor perdition[9781]: CLIENT: "2.584 LOGIN piekjepuk 6012417\r\n" Jul 2 14:33:46 floor perdition[9781]: username_add_domain: username_add_domain 0 1 0x807bd1c Jul 2 14:33:46 floor perdition[9781]: getserver: do_dbserver_get Jul 2 14:33:46 floor perdition[9781]: SSL connection using AES256-SHA Jul 2 14:33:46 floor perdition[9781]: REAL: "* OK Zarafa IMAP gateway ready\r\n" Jul 2 14:33:46 floor perdition[9781]: SELF: "flim07 CAPABILITY\r\n" Jul 2 14:33:46 floor perdition[9781]: REAL: "* CAPABILITY IMAP4rev1 CHILDREN XAOL-OPTION IDLE\r\n" Jul 2 14:33:46 floor perdition[9781]: REAL: "flim07 OK CAPABILITY Completed\r\n" Jul 2 14:33:46 floor perdition[9781]: SELF: "flim08 LOGIN {6}\r\n" Jul 2 14:33:46 floor perdition[9781]: REAL: "flim08 BAD LOGIN must have 2 arguments\r\n" Jul 2 14:33:46 floor perdition[9781]: imap4_out_response: invalid tag from server 1 Jul 2 14:33:46 floor perdition[9781]: imap4_out_authenticate: imap4_out_response login Jul 2 14:33:46 floor perdition[9781]: SELF: "piekjepuk {7}\r\n" Jul 2 14:33:46 floor perdition[9781]: REAL: "piekjepuk BAD Command not recognized\r\n" Jul 2 14:33:46 floor perdition[9781]: imap4_out_response: invalid tag from server 1 Jul 2 14:33:46 floor perdition[9781]: imap4_out_authenticate: imap4_out_response name Jul 2 14:33:46 floor perdition[9781]: SELF: "6012417\r\n" Jul 2 14:33:46 floor perdition[9781]: REAL: "* BAD Command not recognized\r\n" Jul 2 14:33:46 floor perdition[9781]: SELF: "* BAD Command not recognized\r\n" Jul 2 14:34:46 floor perdition[9781]: REAL: "* BYE Connection closed because of timeout\r\n" Jul 2 14:34:46 floor perdition[9781]: SELF: "* BYE Connection closed because of timeout\r\n" Jul 2 14:34:46 floor perdition[9781]: REAL: "" Jul 2 14:34:46 floor perdition[9781]: token_read: token_fill_buffer Jul 2 14:34:46 floor perdition[9781]: read_line: token_read Jul 2 14:34:46 floor perdition[9781]: imap4_out_response: read_line Jul 2 14:34:46 floor perdition[9781]: imap4_out_authenticate: imap4_out_response passwd Jul 2 14:34:46 floor perdition[9781]: main: protocol->out_authenticate -1 Jul 2 14:34:46 floor perdition[9781]: Fatal error authenticating user. Exiting child. Any ideas? Thank you very much in advance! Best regards, -- Xesc

14 years, 5 months

Fatal error during/after TLS negotiation

by Robert C. Sheets

Hello list, My perdition director seems to be working fine with unencrypted POP and IMAP connections, but logs the following when I try to connect from Thunderbird using TLS: Connect: 128.146.221.167->206.71.169.193 SELF: "* OK IMAP4 Ready yankee 0001de1f\r\n" CLIENT: "1 capability\r\n" SELF: "* CAPABILITY IMAP4 IMAP4REV1\r\n" SELF: "1 OK CAPABILITY\r\n" CLIENT: "2 STARTTLS\r\n" SELF: "2 OK Begin TLS negotiation now\r\n" username_mangle: username_strip main: username_mangle STATE_GET_SERVER Fatal error manipulating username for client "128.146.221.167": Exiting child What should I do to get TLS working? Thanks! -- Robert C. Sheets Picosecond Software

14 years, 9 months

SSL key passphrase

by Aaron Thoreson

I apologize if this has been covered. The signal-to-noise ration in my Google searching and GMANE/MARC searching didn't lead me to good results... I see a few posts from ~2004 regarding passphrase protected SSL keys. Mr. Horms indicated that he thought it ought to work, but was unable to devote effort at the time, being 'snowed under' :) Was this functionality added? I see in the .c code some callbacks to the ctx 'passphrase' parts of libssl but can't tell where it's getting sent along, if at all. Can anyone provide tips? Thanks! -- Aaron Thoreson aaront(a)midco.net

14 years, 9 months

[ANNOUNCE] perdition 1.18

by Simon Horman

Hi, I'm happy to announce the release of 1.18. It has been a long, long time since the release of 1.17 and there have been many improvements since then. Possibly of most note being the addition of IPv6 support. Thanks to everyone who tested the rc releases, a lot of problems were resolved and I hope that this is the most solid release of perdition to date. And thanks to everyone who contributed changes, bug reports and ideas. A full change log is provided by the Mercurial repository http://hg.vergenet.net/perdition/perdition/ Perdition 1.18-rc3 and the vanessa libraries that it depends on are available from: http://www.vergenet.net/linux/perdition/download/1.18-rc2/ 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/ (Note: any perdition-1.18rc3 packages are slightly out of date)

14 years, 9 months

Re: [PERDITION-USERS] Vanessa_logger problem

by Luciano Sarra

Thank you for the explanation. How can I fix this ? I attach the perdition.conf file bind_address 0.0.0.0 connection_logging imap_capability IMAP4 listen_port 143 no_lookup protocol POP3 outgoing_server a.b.c.d my perdition daemon runs as nobody user. Luciano Sarra Simon Horman ha scritto: > On Wed, Nov 18, 2009 at 10:17:55AM +0100, Luciano Sarra wrote: > >> Hi everybody, >> >> I'm running the Perdition system on a SLES 11 with the following >> packages installed >> >> libvanessa_adt0-0.0.8-16.3.x86_64.rpm >> libvanessa_logger0-0.0.8-43.2.x86_64.rpm >> libvanessa_socket1-0.0.10-1.1.x86_64.rpm >> perdition-1.18rc3-1.1.x86_64.rpm >> >> all the system is up and running but on the console as a standard output >> I get the following message >> >> vanessa_logger_reopen: __vanessa_logger_reopen >> __vanessa_logger_reopen: fopen: Permission denied >> >> >> >> I have the same messages even if I have installed the older packages >> >> perdition-1.17-9.3.x86_64.rpm >> vanessa_adt-0.0.7-3.50.x86_64.rpm >> vanessa_logger-0.0.7-2.55.x86_64.rpm >> vanessa_socket-0.0.7-5.44.x86_64.rpm >> >> >> What does it mean ? Is a bad warning ? How can I fix it ? >> > > I suspect that the logger (file) is initially opened when > perdition is running as root, that the.reopen is occuring > after perdition has dropped root privileges and that with > the reduced privileges it can't open the logger (file) > in question. >

14 years, 9 months

Fallback server

by Alexandre Ghisoli

Hello, I've different setup of perdition proxy (POP3 and IMAP4) and I wish to have a kind of fallback server. I'm using popmap.re regexp filtering to loadbalance over 2 mailboxes server based on the name of the owner (a-l -> server a, n-z -> server b). Both server are able to serve all mailboxes so I wish to know if I can setup something like this : ^[a-l] : serverA:143,serverB:143 ^[n-z] : serverB:143,serverA:143 If serverA fail to answer then perdition uses serverB and vice-versa. Thanks -- Alexandre Ghisoli

14 years, 9 months

Fatal error writing to client

by Nelson Serafica

One of our client cannot connect to our incoming mail server. I have notice that their ip was having an error on the log Nov 16 09:21:53 perdition[26724]: Fatal error writing to client 1.2.3.4->10.20.30.40.Exiting child. Nov 16 09:51:56 perdition[31690]: Connect: 1.2.3.4->10.20.30.40 Nov 16 09:51:58 perdition[31690]: Fatal error writing to client 1.2.3.4->10.20.30.40.Exiting child. Nov 16 10:06:24 perdition[1673]: Connect: 1.2.3.4->10.20.30.40 Nov 16 10:06:24 perdition[1673]: Fatal error writing to client 1.2.3.4->10.20.30.40.Exiting child. Nov 16 10:08:25 perdition[1991]: Connect: 1.2.3.4->10.20.30.40 Nov 16 10:08:26 perdition[1991]: Fatal error writing to client 1.2.3.4->10.20.30.40.Exiting child. This is the only client who is experiencing this problem. Anyone can give a hint about this problem and any possible solution?

14 years, 9 months

compile problem in perdition 1.18-rc3

by Joel A. Chornik

BODY { font-family:Arial, Helvetica, sans-serif;font-size:12px; }(corrected, was the other way around) In file options.h this #ifdef WITH_PAM_SUPPORT int authenticate_in; int authenticate_timeout; #endif /* WITH_PAM_SUPPORT */ should read #ifdef WITH_PAM_SUPPORT int authenticate_in; #endif /* WITH_PAM_SUPPORT */ int authenticate_timeout; otherwise you get compile errors if no there is no PAM support in the system, as the authenticate_timeout element is used througout the code anyway. (sorry no diff in the system I was working on :) )

14 years, 9 months

compile problem in perdition 1.18-rc3

by Joel A. Chornik

BODY { font-family:Arial, Helvetica, sans-serif;font-size:12px; }In file options.h this #ifdef WITH_PAM_SUPPORT int authenticate_in; #endif /* WITH_PAM_SUPPORT */ int authenticate_timeout; should read #ifdef WITH_PAM_SUPPORT int authenticate_in; int authenticate_timeout; #endif /* WITH_PAM_SUPPORT */ otherwise you get compile errors if no there is no PAM support in the system, as the authenticate_timeout element is used througout the code anyway. (sorry no diff in the system I was working on :) )

14 years, 9 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Perdition-users November 2009