Perdition-users September 2009

perdition-users@vergenet.net

6 participants
9 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

[ANNOUNCE] perdition 1.18-rc2

by Simon Horman

Hi, I'm happy to announce the release of 1.18-rc2, with a view to turning this into 1.18. There are very few changes since 1.18-rc1: * Fix a problem in the LDAP library whereby user, host and port information was never returned. * Add authenticate_timeout configuration. * Various rpm and deb packaging fixes. A complete list of changes is available in the changelog provided mercurial. http://hg.vergenet.net/perdition/perdition/ Perdition 1.18-rc2 and the vanessa libraries that it depends on are available from: http://www.vergenet.net/linux/perdition/download/1.18-rc2/ RPM packages built with CentOS 5.3 and Debian packages for Sid are also available. These have been built for x86_32 (i386). I hope to provide x86_64 (amd64) packages shortly. I will also push the Debian packages onto Debian.Org and they should be available there in a day or so.

14 years, 11 months

perdition 1.18rc1 + ldap + email login

by TheSin

I'm not sure if this affects all ldap users, but since 1.18rc1 I couldn't login anymore using user(a)domain.tld like used in ispman. We used to use http://server/?o=ispman?mailRoutingAddress?sub?(uid=%25s) Since it's not using serverdb_get2 I updated that line to use http://server/?o=ispman?mailRoutingAddress,mailHost?sub?(uid=%25s) Which works 100% using ldap search It returns mailRoutingAddress = user_domain_tld@mailHost mailHost = mailHost so I had to also add to perdition.conf strip_domain remote_login Now that being said even with all that I'd get server null, looking into perditiondb_ldap.c I found that it wasn't setting the ref values. I had to changes these lines /* Build the return string */ if (returns[0]) user_str = &returns[0]; if (returns[1]) server_str = &returns[1]; if (returns[2]) port_str = &returns[2]; to look like this /* Build the return string */ if (returns[0]) *user_str = returns[0]; if (returns[1]) *server_str = returns[1]; if (returns[2]) *port_str = returns[2]; Now everything works 100%, server gets set as does the user, hope this helps others cause it was 4 days of hell for me :D --- TS http://southofheaven.org/ Chaos is the beginning and end, try dealing with the rest.

14 years, 12 months

Perdition PBS

by Zane Cirne

Hi, I am testing perdition-pbs and I am not sure how the information should appear in the popauth.bd. I see that the IP address of my external machine that I used for IMAP4s access is being added to popauth.db (but there are some extra characters on it): VERSION=3 format=print type=hash h_nelem=4 db_pagesize=4096 HEADER=END POP:XX.XXX.XX.XX\00 POP:XX.XXX.XX.XX\00 TIME:POP:XX.XXX.XX.XX\00 \d0\f4\afJ TIME:POP:XX.XXX.XX.XX\00 B\ec\afJ DATA=END The sendmail map lookup always fails for the key, but the IP is on the db. map_lookup(popauth, POP:XX.XX.XX.XX, %0=POP:XX.XX.XX.XX) => NOT FOUND (0) check_rcpt returns: $# error $@ 5 . 7 . 1 $: "550 Relaying denied" Please would perdtion-pbs work with Sendmail 8.14 and the sendmail POPAUTH hack from sendmail.org? Thank you very much, Zane

15 years

rpm .spec modification

by No Body is Perfect

Hi Horms! Modifications on *spec.in ( for vanessa_logger vanessa_adt vanessa_socket perdition) are need for "rpmbuild -ta <name>.tar.gz" on Fedora >7 ? systems (rpm ver 4.4.xx) -> Copyright: GNU Lesser General Public Licence -< License: GNU (or wherever) Thanks for your magnific work ! :-)

15 years

[patch 0/4] Add authentication_timeout

by Simon Horman

This series of patches implements an authentication_timeout configuration option and relegates the existing timeout option to only being used after authentication has occured. As suggested by Christian Balzer.

15 years

[ANNOUNCE] perdition 1.18-rc1

by Simon Horman

Hi, I'm happy to announce the release of 1.18-rc1, with a view to turning this into 1.18.i Please test. There are numerous changes since 1.18. Perhaps the most significant being the inclusion of IPv6 support which is in part provided by vanessa-logger 0.0.8, which was also released today. A complete list of changes is available in the ChangeLog, the 1.18-rc1 portion of which was generated from the logs in mercurial. http://www.vergenet.net/linux/perdition/ChangeLog.shtml Perdition 1.18-rc1 and the vanessa libraries that it depends on are available from: http://www.vergenet.net/linux/perdition/download/1.18-rc1/

15 years

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Perdition-users September 2009