Perdition-users May 2011

perdition-users@vergenet.net

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

Managesieve bug recurring?

by Jesse Jarzynka

Hello All, I'm setting up perdition for IMAP and Managesieve proxying with LDAP. LDAP proxying is working fine, I'm getting my mailhost from there, but for managesieve I keep getting: "perdition.managesieve[7871]: Exiting on signal 11" and I'm wondering if it's a recurrence of this bug - http://lists.vergenet.net/pipermail/perdition-users/2010-July/002332.html . I'm using the Debian Squeeze with has the following packages in the repos: ii perdition 1.19~rc4-2 POP3 and IMAP4 Proxy server ii perdition-ldap 1.19~rc4-2 Library to allow perdition to access LDAP based popmaps Here is more of my log: Mar 30 14:40:00 perdition-dev perdition.managesieve[7871]: Connect: 10.30.40.197:37245->10.30.40.163:4190 Mar 30 14:40:00 perdition-dev perdition.managesieve[7871]: SELF: "\"IMPLEMENTATION\" \"perdition\"\r\n\"SIEVE\" \"comparator-i;octet comparator-i;ascii-casemap fileinto reject envelope encoded-character vacation subaddress comparator-i;ascii-numeric relational regex imap4flags copy include variables body enotify environment mailbox date\"\r\n\"SASL\" \"PLAIN\"\r\n\"NOTIFY\" \"mailto\"\r\n\"VERSION\" \"1.19-rc4\"\r\nOK \"predition ready on perdition-dev.localnet.sys 0002b5e3\"\r\n" Mar 30 14:40:04 perdition-dev perdition.managesieve[7871]: CLIENT: "AUTHENTICATE \"PLAIN\" \"AHRlc3RhY2NvdW50MDBAbG9jYWxuZXQuY29tAFRlY2g5OTk=\"\r\n" Mar 30 14:40:04 perdition-dev perdition.managesieve[7871]: username_add_domain: username_add_domain 0 1 Mar 30 14:40:04 perdition-dev perdition.managesieve[7871]: username_add_domain: username_add_domain 0 4 ///////////////////////////// THIS RESPONSE IS FROM THE CORRECT MANAGESIEVE SERVER SO THE PROXY IS WORKING ///////////////////////////// Mar 30 14:40:04 perdition-dev perdition.managesieve[7871]: REAL: "\"IMPLEMENTATION\" \"dovecot\"\r\n\"SIEVE\" \"comparator-i;octet comparator-i;ascii-casemap fileinto reject envelope encoded-character vacation subaddress comparator-i;ascii-numeric relational regex imap4flags copy include variables body enotify environment mailbox date spamtest spamtestplus virustest\"\r\n\"SASL\" \"PLAIN LOGIN\"\r\n\"STARTTLS\"\r\n\"NOTIFY\" \"mailto\"\r\n\"VERSION\" \"1.0\"\r\nOK \"Dovecot ready.\"\r\n" Mar 30 14:40:04 perdition-dev perdition.managesieve[7871]: Exiting on signal 11 So as you can see it exits after it connects to the correct managesieve server. I can provide any more logging and answers if someone has an idea where to look. Thanks, Jesse

12 years, 5 months

Fatal error negotiating setup

by David Severance

I've been having this once in a blue moon problem with the latest perdition 1.19-rc4 compiled on RHEL5 so I turned on debug and caught this today. If I restart perdition then everything works until the next blue moon. > Apr 13 10:29:33 proxyx perdition.imaps[22437]: Connect: > 128.200.62.206:2170->128.200.80.50:993 > Apr 13 10:29:33 proxyx perdition.imaps[22437]: SSL connection using > AES256-SHA > Apr 13 10:29:33 proxyx perdition.imaps[22437]: SELF: "* OK > [CAPABILITY IMAP4 IMAP4REV1 LITERAL+] perdition ready on > proxyx.es.uci.edu 0002376b\r\n" > Apr 13 10:29:33 proxyx perdition.imaps[22437]: CLIENT: "2 login > \"jbrancal\" \"XXXXXX\"\r\n" > Apr 13 10:29:33 proxyx perdition.imaps[22437]: username_add_domain: > username_add_domain 0 1 > Apr 13 10:29:33 proxyx perdition.imaps[22437]: username_add_domain: > username_add_domain 0 2 > Apr 13 10:29:33 proxyx perdition.imaps[22437]: > vanessa_socket_daemon_setid: uid=99 euid=99 gid=99 egid=99 > Apr 13 10:29:33 proxyx perdition.imaps[22437]: username_add_domain: > username_add_domain 0 4 > Apr 13 10:29:33 proxyx perdition.imaps[22437]: REAL: "" > Apr 13 10:29:33 proxyx perdition.imaps[22437]: token_read: > token_fill_buffer > Apr 13 10:29:33 proxyx perdition.imaps[22437]: read_line: token_read > Apr 13 10:29:33 proxyx perdition.imaps[22437]: imap4_out_response: > read_line > Apr 13 10:29:33 proxyx perdition.imaps[22437]: imap4_out_setup: > imap4_out_response greeting > Apr 13 10:29:33 proxyx perdition.imaps[22437]: main: > protocol->out_setup -1 > Apr 13 10:29:33 proxyx perdition.imaps[22437]: Fatal error negotiating > setup. Exiting child. Not sure what to do next, any ideas? thanks, David -- David Severance Central Computing Services Office of Information Technology (949) 824-7552 sev(a)uci.edu

12 years, 6 months

pop3s to gmail connection problem

by singodiwirjo, hermantino

Hi, I need to deploy perdition to allow a user to get pop3 access to his Gmail account. >From the machine that hosts perdition I can connect to Gmail server without problems : # openssl s_client -connect pop.gmail.com:995 [..] +OK Gpop ready for requests from 80.169.130.254 s9pf17928550wby.23 user my_user +OK send PASS pass my_pass +OK Welcome. LIST works etc .. Then here are my perdition config files : /etc/sysconfig/perdition: RUN_PERDITION=yes POP3=no POP3S=yes IMAP4=no IMAP4S=no MANAGESIEVE=yes /etc/perdition/perdition.conf : protocol POP3S outgoing_port 995 outgoing_server pop.gmail.com ssl_mode ssl_listen #managesieve_capability \ "\"IMPLEMENTATION\" \"perdition\" "\ "\"SIEVE\" \"comparator-i;octet "\ "comparator-i;ascii-casemap "\ "fileinto "\ "reject "\ "envelope "\ "encoded-character "\ "vacation "\ "subaddress "\ "comparator-i;ascii-numeric "\ "relational "\ "regex "\ "imap4flags "\ "copy i"\ "nclude "\ "variables "\ "body "\ "enotify "\ "environment "\ "mailbox "\ "date\" "\ "\"SASL\" \"PLAIN\" "\ "\"NOTIFY\" \"mailto\" "\ "\"VERSION\" \"1.18\"" To get maximum debug info I launch : #perdition.pop3s --debug --connection_logging When trying to connect localhost : # openssl s_client -connect pop.gmail.com:995 I can send the user and pass, in my logs I got: [..] May 17 17:00:03 vk2-prx01 perdition.pop3s[21176]: Connect: 127.0.0.1:56037->127.0.0.1:995 May 17 17:00:03 vk2-prx01 perdition.pop3s[21176]: SSL connection using AES256-SHA May 17 17:00:03 vk2-prx01 perdition.pop3s[21176]: SELF: "+OK POP3 perditon ready on localhost 0002914b\r\n" May 17 17:00:33 vk2-prx01 perdition.pop3s[21176]: CLIENT: "user my_user\n" May 17 17:00:33 vk2-prx01 perdition.pop3s[21176]: SELF: "+OK USER my_user set, mate\r\n" May 17 17:00:44 vk2-prx01 perdition.pop3s[21176]: CLIENT: "pass my_pass\n" May 17 17:00:44 vk2-prx01 perdition.pop3s[21176]: username_add_domain: username_add_domain 0 1 May 17 17:00:47 vk2-prx01 perdition.pop3s[21176]: username_add_domain: username_add_domain 0 4 May 17 17:01:49 vk2-prx01 perdition.pop3s[21176]: REAL: "" May 17 17:01:49 vk2-prx01 perdition.pop3s[21176]: token_read: token_fill_buffer May 17 17:01:49 vk2-prx01 perdition.pop3s[21176]: read_line: token_read May 17 17:01:49 vk2-prx01 perdition.pop3s[21176]: pop3_out_response: read_line May 17 17:01:49 vk2-prx01 perdition.pop3s[21176]: pop3_out_setup: pop3_out_response 1 May 17 17:01:49 vk2-prx01 perdition.pop3s[21176]: main: protocol->out_setup -1 May 17 17:01:49 vk2-prx01 perdition.pop3s[21176]: Fatal error negotiating setup. Exiting child. I can't really get where the problem is, it looks like I don't get any response from the server ? Thanks. Hermantino.

12 years, 6 months

Exiting on signal 11

by YANG ChengFu

Hello, I have perdition installation with imap and managesieve service, imap works very well, but managesieve never works. my setup: Debian Squeeze 6.01 perdition 1.19~rc4-2 Each time I tried to login from perdition server to real server(managesieve works on it, it is dovecot). $ telnet email.tst.gameloft.org 2000 Trying 10.137.0.45... Connected to email.tst.gameloft.org. Escape character is '^]'. "IMPLEMENTATION" "perdition" "SIEVE" "comparator-i;octet comparator-i;ascii-casemap fileinto reject envelope encoded-character vacation subaddress comparator-i;ascii-numeric relational regex imap4flags copy include variables body enotify environment mailbox date" "SASL" "PLAIN" "NOTIFY" "mailto" "VERSION" "1.19" OK "predition ready on email.tst.gameloft.org 0002a618" AUTHENTICATE "PLAIN" "AGNoZW5nZnUueWFuZ0BnYW1lbG9mdC5jb20AUjNsMGFkZWQ4" Connection closed by foreign host. I got the following error message. I can find perdition.managesieve forward my authentication information to real server from tcpdump Apr 4 18:05:35 email perdition.imap4[26316]: Exiting on signal 15 Apr 4 18:05:35 email perdition.managesieve[26319]: Exiting on signal 15 Apr 4 18:05:37 email perdition.imap4[29577]: Starting perdition version=1.19-rc4 protocol=IMAP4 Apr 4 18:05:37 email perdition.managesieve[29580]: Starting perdition version=1.19-rc4 protocol=MANAGESIEVE Apr 4 18:05:37 email perdition.managesieve[29580]: add_domain="", authenticate_in=off, authenticate_timeout=1800, bind_address="", client_server_specification=off, config_file="/etc/perdition/perdition.managesieve.conf", connection_limit=0, connection_logging=on, connect_relog=300, debug=on, domain_delimiter="@", explicit_domain="", group="nogroup", imap_capability="IMAP4 IMAP4REV1", inetd_mode=off, listen_port="2000", log_facility="mail", log_passwd="always", login_disabled=off, lower_case="all", managesieve_capability=""IMPLEMENTATION" "perdition" "SIEVE" "comparator-i;octet comparator-i;ascii-casemap fileinto reject envelope encoded-character vacation subaddress comparator-i;ascii-numeric relational regex imap4flags copy include variables body enotify environment mailbox date" "SASL" "PLAIN" "NOTIFY" "mailto" "VERSION" "1.19"", map_library="/usr/lib/libperditiondb_gdbm.so.0", map_library_opt="/etc/perdition/manamap.gdbm.db", no_bind_banner=off, no_daemon=off, no_lookup=off, tcp_keepalive=off, nodename="email.tst.gameloft.org", ok_line="You are so in", outgoing_port="2000", outgoing_server="", pid_file="/var/run/perdition.managesieve/perdition.managesieve.pid", pop_capability="UIDL.USER", protocol="MANAGESIEVE", server_resp_line=off, strip_domain="", timeout=1800, username="nobody", username_from_database=off, query_key="", quiet=off (mask=0x00000000 00000000) Apr 4 18:05:37 email perdition.managesieve[29580]: ssl_mode="", ssl_ca_file="", ssl_ca_path="/etc/perdition/perdition.ca/", ssl_ca_accept_self_signed="off", ssl_cert_file="/etc/perdition/perdition.crt.pem", ssl_cert_accept_expired="off", ssl_cert_not_yet_valid="off", ssl_cert_self_signed="off", ssl_cert_verify_depth=9, ssl_key_file="/etc/perdition/perdition.key.pem", ssl_listen_ciphers="", ssl_outgoing_ciphers="", ssl_no_cert_verify="off", ssl_no_client_cert_verify="off", ssl_no_cn_verify="off" ssl_passphrase_fd=0, ssl_passphrase_file="(null)", (ssl_mask=0x00000000) Apr 4 18:05:37 email perdition.managesieve[29582]: vanessa_socket_daemon_setid: uid=65534 euid=65534 gid=65534 egid=65534 Apr 4 18:05:45 email perdition.managesieve[29584]: Connect: 10.137.0.45:46365->10.137.0.45:2000 Apr 4 18:05:45 email perdition.managesieve[29584]: SELF: "\"IMPLEMENTATION\" \"perdition\"\r\n\"SIEVE\" \"comparator-i;octet comparator-i;ascii-casemap fileinto reject envelope encoded-character vacation subaddress comparator-i;ascii-numeric relational regex imap4flags copy include variables body enotify environment mailbox date\"\r\n\"SASL\" \"PLAIN\"\r\n\"NOTIFY\" \"mailto\"\r\n\"VERSION\" \"1.19\"\r\nOK \"predition ready on email.tst.exmaple.org 0002a618\"\r\n" Apr 4 18:05:56 email perdition.managesieve[29584]: CLIENT: "AUTHENTICATE \"PLAIN\" \"AGNoZW5nZnUueWFuZ0BnYW1lbG9mdC5jb20AUjNsMGFkZWQ4\"\r\n" Apr 4 18:05:56 email perdition.managesieve[29584]: username_add_domain: username_add_domain 0 1 Apr 4 18:05:56 email perdition.managesieve[29584]: username_add_domain: username_add_domain 0 4 Apr 4 18:05:56 email perdition.managesieve[29584]: REAL: "\"IMPLEMENTATION\" \"dovecot\"\r\n\"SIEVE\" \"comparator-i;octet comparator-i;ascii-casemap fileinto reject envelope encoded-character vacation subaddress comparator-i;ascii-numeric relational regex imap4flags copy include variables body enotify environment mailbox date spamtest spamtestplus virustest\"\r\n\"SASL\" \"PLAIN LOGIN GSSAPI\"\r\n\"STARTTLS\"\r\n\"NOTIFY\" \"mailto\"\r\n\"VERSION\" \"1.0\"\r\nOK \"Dovecot ready.\"\r\n" Apr 4 18:05:56 email perdition.managesieve[29584]: Exiting on signal 11 tcpdump information: 18:05:56.319139 00:12:79:8f:f1:ee > 00:12:79:3a:44:b5, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 64, id 57476, offset 0, flags [DF], proto TCP (6), length 60) 10.137.0.45.57274 > 10.137.0.130.2000: S, cksum 0x2352 (correct), 10062289:10062289(0) win 5840 <mss 1460,sackOK,timestamp 483486037 0,nop,wscale 9> 18:05:56.935100 00:12:79:3a:44:b5 > 00:12:79:8f:f1:ee, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60) 10.137.0.130.2000 > 10.137.0.45.57274: S, cksum 0x567a (correct), 2822211310:2822211310(0) ack 10062290 win 5792 <mss 1460,sackOK,timestamp 60267065 483486037,nop,wscale 9> 18:05:56.935166 00:12:79:8f:f1:ee > 00:12:79:3a:44:b5, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 64, id 57477, offset 0, flags [DF], proto TCP (6), length 52) 10.137.0.45.57274 > 10.137.0.130.2000: ., cksum 0x9b40 (correct), ack 1 win 12 <nop,nop,timestamp 483486193 60267065> 18:05:56.935532 00:12:79:3a:44:b5 > 00:12:79:8f:f1:ee, ethertype IPv4 (0x0800), length 460: (tos 0x0, ttl 64, id 7228, offset 0, flags [DF], proto TCP (6), length 446) 10.137.0.130.2000 > 10.137.0.45.57274: P 1:395(394) ack 1 win 12 <nop,nop,timestamp 60267219 483486193> 18:05:56.935572 00:12:79:8f:f1:ee > 00:12:79:3a:44:b5, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 64, id 57478, offset 0, flags [DF], proto TCP (6), length 52) 10.137.0.45.57274 > 10.137.0.130.2000: ., cksum 0x991a (correct), ack 395 win 14 <nop,nop,timestamp 483486193 60267219> 18:05:56.936890 00:12:79:8f:f1:ee > 00:12:79:3a:44:b5, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 64, id 57479, offset 0, flags [DF], proto TCP (6), length 52) 10.137.0.45.57274 > 10.137.0.130.2000: F, cksum 0x9919 (correct), 1:1(0) ack 395 win 14 <nop,nop,timestamp 483486193 60267219> 18:05:56.937112 00:12:79:3a:44:b5 > 00:12:79:8f:f1:ee, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 64, id 7229, offset 0, flags [DF], proto TCP (6), length 52) 10.137.0.130.2000 > 10.137.0.45.57274: F, cksum 0x9919 (correct), 395:395(0) ack 2 win 12 <nop,nop,timestamp 60267220 483486193> 18:05:56.937140 00:12:79:8f:f1:ee > 00:12:79:3a:44:b5, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 64, id 57480, offset 0, flags [DF], proto TCP (6), length 52) 10.137.0.45.57274 > 10.137.0.130.2000: ., cksum 0x9917 (correct), ack 396 win 14 <nop,nop,timestamp 483486193 60267220> /etc/perdition/perdition.managesieve.conf connection_logging debug log_facility mail managesieve_capability \ "\"IMPLEMENTATION\" \"perdition\" "\ "\"SIEVE\" \"comparator-i;octet "\ "comparator-i;ascii-casemap "\ "fileinto "\ "reject "\ "envelope "\ "encoded-character "\ "vacation "\ "subaddress "\ "comparator-i;ascii-numeric "\ "relational "\ "regex "\ "imap4flags "\ "copy i"\ "nclude "\ "variables "\ "body "\ "enotify "\ "environment "\ "mailbox "\ "date\" "\ "\"SASL\" \"PLAIN\" "\ "\"NOTIFY\" \"mailto\" "\ "\"VERSION\" \"1.19\"" listen_port 2000 log_passwd always lower_case all map_library /usr/lib/libperditiondb_gdbm.so.0 map_library_opt /etc/perdition/manamap.gdbm.db protocol managesieve outgoing_port 2000

12 years, 7 months

perdition-1.19-rc4 segv's

by Doug Shearer

I am trying to adapt perdition-1.19-rc4 for use on Solaris 10, and have used what may be some obscure options - these cause segv's. Simon Horman asked me to post the patches I made to this list. These patches work for me, but it would be good if someone more familiar with the code would have a look at them to see that they are done properly. My impression is that there is not much interest in using perdition on Solaris - if you are interested in my experiences please contact me directly. Cheers, Doug Shearer #################### perdition/options.c segv when opt.ssl_passphrase_file is not specified and we are logging options #################### diff -u perdition-1.19-rc4/perdition/options.c.orig perdition-1.19-rc4/perdition/options.c --- perdition-1.19-rc4/perdition/options.c.orig Thu Mar 17 10:42:51 2011 +++ perdition-1.19-rc4/perdition/options.c Thu Mar 17 10:41:17 2011 @@ -1417,7 +1417,7 @@ BIN_OPT_STR(opt.ssl_no_client_cert_verify), BIN_OPT_STR(opt.ssl_no_cn_verify), opt.ssl_passphrase_fd, - opt.ssl_passphrase_file, + OPT_STR(opt.ssl_passphrase_file), opt.ssl_mask); out[MAX_LINE_LENGTH - 1] = '\0'; #################################### perdition/db/ldap/perditiondb_ldap.c segv when -p OUTGOING_PORT is specified on the command line (not in the .conf file) and attrcount = 2 (so returns[2] and therefore *port_str becomes undefined) NOTE: I put in a check when attrcount = 1 also - I have no idea whether this can actually happen #################################### diff -u ./perdition-1.19-rc4/perdition/db/ldap/perditiondb_ldap.c.orig ./perdition-1.19-rc4/perdition/db/ldap/perditiondb_ldap.c --- ./perdition-1.19-rc4/perdition/db/ldap/perditiondb_ldap.c.orig Thu Sep 9 08:31:02 2010 +++ ./perdition-1.19-rc4/perdition/db/ldap/perditiondb_ldap.c Tue May 3 11:43:44 2011 @@ -606,9 +606,9 @@ else { if (returns[0]) *user_str = returns[0]; - if (returns[1]) + if (attrcount > 1 && returns[1]) *server_str = returns[1]; - if (returns[2]) + if (attrcount > 2 && returns[2]) *port_str = returns[2]; }

12 years, 7 months

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Perdition-users May 2011