Perdition-users October 2009

perdition-users@vergenet.net

5 participants
7 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

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

13 years, 8 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

13 years, 12 months

bad file descriptor

by Nelson Serafica

I just installed perdition in my FC11. However, I'm having a problem running it. I encounter the ff error Oct 28 16:50:41 perdition[20675]: vanessa_socket_daemon_setid: uid=511 euid=511 gid=511 egid=511 Oct 28 16:50:46 perdition[20682]: __vanessa_socket_server_accept: accept: Bad file descriptor Oct 28 16:50:46 perdition[20682]: vanessa_socket_server_accept: __vanessa_socket_server_accept Oct 28 16:50:46 perdition[20682]: main: vanessa_socket_server_accept Oct 28 16:50:46 perdition[20682]: Fatal error accepting child connection. Exiting. Oct 28 16:50:46 perdition[20675]: Connect: 176.67.237.183->48.68.237.183 Oct 28 16:50:46 perdition[20675]: SELF: "* OK IMAP4 Ready li90-88 00012c69\r\n" Oct 28 16:50:46 perdition[20675]: io_write: write: Bad file descriptor Oct 28 16:50:46 perdition[20675]: str_vwrite: io_write: Bad file descriptor Oct 28 16:50:46 perdition[20675]: imap4_write: str_vwrite Oct 28 16:50:46 perdition[20675]: greeting: protocol->write Oct 28 16:50:46 perdition[20675]: main: greeting Oct 28 16:50:46 perdition[20675]: Fatal error writing to client. 176.67.237.183->48.68.237.183 Exiting child. Oct 28 16:51:40 perdition[20702]: __vanessa_socket_server_accept: accept: Bad file descriptor Oct 28 16:51:40 perdition[20702]: vanessa_socket_server_accept: __vanessa_socket_server_accept Oct 28 16:51:40 perdition[20702]: main: vanessa_socket_server_accept Oct 28 16:51:40 perdition[20702]: Fatal error accepting child connection. Exiting. Oct 28 16:51:40 perdition[20670]: Connect: 176.3.238.183->48.4.238.183 Oct 28 16:51:40 perdition[20670]: SELF: "+OK POP3 Ready li90-88 00012c65\r\n" Oct 28 16:51:40 perdition[20670]: io_write: write: Bad file descriptor Oct 28 16:51:40 perdition[20670]: str_vwrite: io_write: Bad file descriptor Oct 28 16:51:40 perdition[20670]: pop3_write: str_vwrite Oct 28 16:51:40 perdition[20670]: greeting: protocol->write Oct 28 16:51:40 perdition[20670]: main: greeting Oct 28 16:51:40 perdition[20670]: Fatal error writing to client. 176.3.238.183->48.4.238.183 Exiting child. Can anyone advise what went wrong? Trying to Google it but nothing relevant to perdition. I remember before I encountered an error Bad File Descriptor and it was a hardware error. This server wherein I install perdition was a virtual pc so I believe it is not a hard disk issue

14 years, 1 month

[ANNOUNCE] perdition 1.18-rc3

by Simon Horman

Hi, I'm happy to announce the release of 1.18-rc3 Summary of changes since 1.18-rc3: * Fix problems relating to IPv6 connections failing on FreeBSD and OpenSolaris * Fix a separate IPv6 connection problem that manifested when either the real-server or end user used IPv4. * Make sure that the IMAPv4 STARTLS command is enabled when configured. * Fixed various packaging and build problems. 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/ Note that vanessa_socket 0.0.10 is required as part of the fix for the IPv6 connection problems. Debian unstable packages have been uploaded to Debian.Org and should be available in the Debian archive shortly. http://packages.debian.org/source/unstable/perdition Packages for various RPM based distrubiutions are being built by the SUSE build service and should be available shortly from http://download.opensuse.org/repositories/home:/horms/

14 years, 1 month

Red Hat Enterprise linux v 5

by Paul Dudley

Does anyone know if perdition will run on Red Hat Enterprise linux version 5? Regards Paul -- Paul Dudley pdudley(a)fastmail.fm -- http://www.fastmail.fm - Or how I learned to stop worrying and love email again

14 years, 1 month

trouble with downloading the sources

by M. Meiarashi

Hi, I'm having a trouble on downloading perdition and vanessa sources. I'm trying to download perdition and vanessa sources from http://www.vergenet.net/linux/{vanessa,perdition}/download/ It seems the site redirects to the site itself. Redirect occurs even for the toplevel of the site http://www.vergenet.net/. I wonder if something is wrong with the site, or does anyone please advise me if the problem is on my side. Thank you so much and best regards, --- M. Meiarashi - mes(a)yki.jp

14 years, 1 month

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Perdition-users October 2009