Perdition-users April 2010

perdition-users@vergenet.net

3 participants
4 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

Port logging

by Micah Anderson

Since I'm on the subject of logging... I notice that even if I am coming in on port 993, the port field that is logged is the port of the outgoing connection: Apr 4 11:19:24 auk perdition[19421]: Auth: 0.0.0.0->0.0.0.0 ---- server="0.0.0.0" port="143" status="ok" In this case, my incoming imap connection was an imaps (993) connection to perdition, it then looked up my user and found the server to connect to, and then made the connection to that server over port 143. I expected it to connect to the remote server over 143, but I was expecting to get a log entry from perdition that the port it received the connection on is port 993. Is there a way to get a log entry that indicates the incoming port number, as well as the outgoing one? Thanks! micah -- "It is no measure of health to be well adjusted to a profoundly sick society." - J Krishnamurti

13 years, 5 months

username logging

by Micah Anderson

I've been trying to determine which users are using what ports, in an effort to transition people away from non-encrypted connections. However, i'm having difficulty because the perdition logs don't seem to log the username in any consistent way that I can determine. In many cases I see logs like this: Apr 4 06:26:43 auk perdition[23849]: Auth: 0.0.0.0->0.0.0.0 ---- server="0.0.0.0" port="143" status="ok" with no username logged, but in other cases I do see the username logged, although in an odd way: Apr 4 06:27:36 auk perdition[23147]: Auth: 0.0.0.0->0.0.0.0 ----micah(a)riseup.net" server="0.0.0.0" port="143" status="ok" What can I do to get the username logged properly? On a side note, I was expecting it to show up as 'username=micah(a)riseup.net' but it seems to be formatted funny. thanks for your work on perdition, micah -- "It is no measure of health to be well adjusted to a profoundly sick society." - J Krishnamurti

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

13 years, 8 months

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Perdition-users April 2010