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/
Dear List,
I have plenty of "Closing session" entries in my log with Severity "Error".
This is very annoying as I observe my logs by filtering for severity and
I can hardly see anything else then these "clsong session" logs.
Example:
Oct 28 09:51:12 sv030 perdition.imaps[5353]: Closing session:
84.227.208.119:63038->10.10.5.30:993 authorisation_id=NONE
authentication_id="swells" received=50 sent=451
My System:
Debian Squeeze with Perdition 1.19-rc4-2 (standard package)
Perdition works with a lookup map and connects in any case to another
host inside my network
MX servers are Postfix with Postgrey, Amavis, ClamAV and Spamassasin
IMAP server is a Dovecot 1.2 (Debian Squeeze standard package)
My perdition.imap4.conf file looks like this:
--------------------------------------------------------------------------------------
quiet
log_passwd fail
connect_relog 0
username nobody
group nogroup
imap_capability IMAP IMAP4rev1 LITERAL+ ID ENABLE STARTTLS
outgoing_port 143
connection_limit 2048
username_from_database
map_library /usr/lib/libperditiondb_gdbm.so.0
map_library_opt /etc/perdition/fos4map.gdbm.db
ssl_mode tls_listen
ssl_cert_file /etc/ssl/mycerts/mail.domain.tld.crt
ssl_key_file /etc/ssl/private/mail.domain.tld.key.nopw
ssl_ca_chain_file /etc/ssl/mytrust/ca-path.pem
--------------------------------------------------------------------------------------
All other conf files (imaps, pop3, pop3s) are the same except for the
obvious differences.
Question:
How could the severity of the logging entry be changed -or- what is the
problem I have?
Is the closing session really a "Severity=Error" message?
Regards, Radim
Hi!
I have compiled perdition 1.9rc4 on Centos 5.6 (64bit) and I can only
start and run it with --no_daemon
Perdition quits immediately without any useful logentries when starting
without it.
I can handle that with nohup and & but I dont think that should be so ...
Can anybody give me a hint please?
regards
Maritn
All-
I searched through the mail archives looking for any other posts about
changes to domain_delimiter between 1.17.1 and 1.19-rc4 and didn't find
any, but I'm wondering if I missed something.
Until our mail system was outsourced last year, we had been happily using
perdition (most recently, 1.17.1) with IMAP backend systems and an LDAP
map. One of my coworkers still runs a separate mail system that also uses
the exact same config, though. He's switching from RHEL 4 32 bit to RHEL
6 64 bit, so I built new versions of the vanessa* packages and perdition
1.19-rc4.
Even once we update the config so that the LDAP map specifies the LDAP
protocol version, 1.19-rc4 doesn't work. I appears that something
relating to domain_delimiter is not being correctly applied.
Here's the perdition config file:
12:29 PM perdition ~$cd /etc/perdition/
12:29 PM perdition perdition$grep -v '^#|^ *$' perdition.conf
"\"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\""
debug
ssl_key_file /etc/perdition/subdomain.key.pem
ssl_cert_file /etc/perdition/subdomain.crt.pem
ssl_ca_chain_file /etc/perdition/subdomain.cacrt.pem
M /usr/local/lib64/libperditiondb_ldap.so
m 3:ldap://ldap.subdomain.nodak.edu:389/dc=subdomain,dc=nodak,dc=edu?iid,mailRoutingAddress?sub?(iid=%25s)
As you can see, the map looks up two attributes (iid, mailRoutingAddress)
in LDAP. The iid is the username to use for authentication, and looks
like e.g. Joe.User .
The mailRoutingAddress is the actual delivery account name, and looks like
juser(a)imapN.subdomain.nodak.edu .
Under 1.17.1, that lookup worked, and in particular perdition would look
up both attributes, apply the domain_delimeter (default: @), and end up
with Joe.User for the username to pass to the IMAP host and
imapN.subdomain.nodak.edu for the actual IMAP host. It successfully,
correctly discarded the juser@ part of mailRoutingAddress to arrive at the
backend IMAP host.
1.19-rc4 is doing the lookup, but not discarding the juser@ part of
mailRoutingAddress, so it's consequently trying to connect to a host named
"juser(a)imapN.subdomain.nodak.edu", and obviously failing.
Here's what gets logged by perdition:
Oct 5 10:07:34 perdition perdition.imap4[2237]: Starting perdition version=1.19-rc4 protocol=IMAP4
Oct 5 10:07:34 perdition perdition.subdomain.imap4s[2243]: Starting perdition version=1.19-rc4 protocol=IMAP4S
Oct 5 10:07:34 perdition perdition.subdomain.imap4s[2243]: add_domain="", authenticate_in=off, authenticate_timeout=1800, bind_address="", client_server_specification=off, config_file="/etc/perdition/perdition.subdomain.imap4s.conf", connection_limit=0, connection_logging=off, connect_relog=300, debug=on, domain_delimiter="@", explicit_domain="", group="nobody", imap_capability="IMAP4 IMAP4REV1", inetd_mode=off, listen_port="imaps", log_facility="mail", log_passwd="never", login_disabled=off, lower_case="", 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-rc4"", map_library="/usr/local/lib64/libperditiondb_ldap.so", map_library_opt="ldap://ldap.subdomain.nodak.edu:389/dc=subdomain,dc=nod!
ak,dc=edu?iid,mailRoutingAddress?sub?(iid=%25s)", no_bind_banner=off, no_daemon=off, no_lookup=off, tcp_keepalive=off, nodename="perdition.subdomain.nodak.edu", ok_line="You are so in", outgoing_port="143", outgoing_server="", pid_file="/var/run/perdition.subdomain.imap4s/perdition.subdomain.imap4s.pid", pop_capability="UIDL.USER", protocol="IMAP4S", server_resp_line=off, strip_domain="", timeout=1800, username="nobody", username_from_database=off, query_key="", quiet=off (mask=0x01400000 00000000)
Oct 5 10:07:34 perdition perdition.subdomain.imap4s[2243]: ssl_mode="ssl_listen", ssl_ca_file="", ssl_ca_path="/etc/perdition/perdition.ca/", ssl_ca_accept_self_signed="off", ssl_cert_file="/etc/perdition/subdomain.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/subdomain.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=0x00000400)
Oct 5 10:07:34 perdition perdition.subdomain.imap4s[2245]: Removed stale pid-file [/var/run/perdition.subdomain.imap4s/perdition.subdomain.imap4s.pid]
Oct 5 10:07:34 perdition perdition.subdomain.imap4s[2245]: vanessa_socket_daemon_setid: uid=99 euid=99 gid=99 egid=99
Oct 5 10:08:50 perdition perdition.subdomain.imap4s[2252]: Connect: 10.10.71.137:39994->10.10.111.80:993
Oct 5 10:08:50 perdition perdition.subdomain.imap4s[2252]: SSL connection using AES256-SHA
Oct 5 10:09:00 perdition perdition.subdomain.imap4s[2252]: username_add_domain: username_add_domain 0 1
Oct 5 10:09:00 perdition perdition.subdomain.imap4s[2252]: vanessa_socket_client_src_open: getaddrinfo dst: "juser(a)imap3.subdomain.nodak.edu" "143": Name or service not known
Oct 5 10:09:00 perdition perdition.subdomain.imap4s[2252]: main: vanessa_socket_client_open
Oct 5 10:09:03 perdition perdition.subdomain.imap4s[2252]: Auth: 10.10.71.137:39994->10.10.111.80:993 client-secure=ssl authorisation_id=NONE authentication_id="joe.user" server="juser@imap3.subdomain.nodak.edu:143" protocol=IMAP4S server-secure=plaintext status="failed: Could not connect to server"
I feel like there must have been some intended change between 1.17.1 and
1.19-rc4 and I just missed it, but searches so far haven't turned up what
I'm missing.
Thanks,
Tim
--
Tim Mooney mooney(a)dogbert.cc.ndsu.NoDak.edu
Enterprise Computing & Infrastructure 701-231-1076 (Voice)
Room 242-J6, IACC Building 701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
