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/
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
Hi,
Perdition has the option "ssl_mode" which can be used to set both
listening and outgoing connections. Its made up of options that are
prefixed either by 'ssl' or 'tls'.
From my experimentation, it seems as if the 'tls' options aren't
actually TLS, but rather the STARTTLS extension for IMAP and POP.
So what is the difference? The difference is that an actual TLS
connection would be one whereby the client and server negotiate a
stateful connection by using a handshaking procedure where they agree on
various parameters that will be used to establish the connection's
security. This is all done during the bring up of the connection, and
the client wont send a login/password until the connection has been
properly setup.
STARTTLS, by contrast, proceeds by the client making a clear-text
connection to the server, noting that the server has the STARTTLS
capability (to use the IMAP terminology), requests that a STARTTLS
negotiation process begins and then you promote up to an actual TLS
connection. After you've promoted, then your connection is encrypted.
Why is the distinction important? With STARTTLS the potential for
credential leak exists during the clear-text window. Perdition offers
the tls_listen_force/tls_outgoing_force/tls_all_force settings to
'ssl_mode', but all this does in IMAP4/IMAP4S is have the LOGINDISABLED
set, which doesn't stop a client from attempting to login, it just
refuses their login after they've sent it over the clear-text
connection. As the RFC (2595) referenced in the man page states:
Servers advertising this capability will fail to interoperate with
many existing compliant IMAP clients and will be unable to prevent
those clients from disclosing the user's password.
I think that the option 'ssl_mode' is a confusing name. TLS and SSL are
different things (although many people still call TLS connections
SSL). Additionally the use of the name 'tls' in the potential options is
confusing, when the actual behavior is STARTTLS.
It seems to me that the existing 'tls' options should be renamed
'starttls_*' and an actual TLS option be added.
I also notice that the man page says, "TLS is defined in RFC 2595". This
isn't really correct, again its STARTTLS that is defined in RFC
2595. This RFC, although titled this way in 1999, is known as the
canonical reference defining STARTTLS for IMAP and POP3 (there are
others for things like SMTP). TLS, on the other hand, is actually
detailed in RFC 5246.
micah
0. http://tools.ietf.org/html/rfc2595
1. http://tools.ietf.org/html/rfc5246
We've been using perdition in production since early 2003 and has worked
great with over 70K users configured.
We need to remap userA --> userB but we don't have the username_from_database
option set and our database has simple entries, basically username key
and realhost (e.g., userA xyz.d.umn.edu).
We can set username_from_database and rewrite the database entries
as 'userA userB*xyz.d.umn.edu', where '*' is the domain delimiter,
but this will create an outage during the update, and we only need to
remap around 50 users.
Question: If username_from_database is set and some users have entries like
'userA userB*xyz.d.umn.edu' and some have 'userC xyz.d.umn.edu' or maybe
'userC *xyz.d.umn.edu', will or can perdition use userC, as in the latter
case, if the name in the server portion is empty?
We don't have a test system otherwise I would try it...
--
scott hollatz net shollatz(a)d.UMn.eDu
information technology systems and services tel +1 218 726 8851
university of minnesota duluth mn usa fax +1 218 726 7674
--
"Asn aD ta zlAp em uT zt33rg"
Hi,
I upgraded an debian lenny installation to squeeze. This Server runs courier
pop/pop-ssl/imap/imap-ssl at 127.0.0.1 and perdition at external interface.
After upgrading perdition does not start anymore and I find out three
things:
1st - (perhaps debian related) the init script returns an error at checking
for pid file after starting perdition processes, insterting 'sleep 1'
between starting the deamon and checking for the pid file resolves this
issue
2nd - using "log_facility /some/file" does not work anymore; I checked the
path and files permissions - all right, I set up 'debug' and logfille is
filled with all start parameters but no error and the deamon is not running.
How to get my special perdition.log back?
3rd - I can't use ssl anymore. Testing ports 995 and 993 at localhost
(remember: courier itself) using nagios check_imap/pop plugin everything
works fine. Using the same check to external IP (perdition) I get the
following error:
[...]
ns1:/etc# /usr/lib/nagios/plugins/check_pop -H 78.xx.xx.xx -S -p 995
CRITICAL - Cannot make SSL connection
14878:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown
protocol:s23_clnt.c:607:
[...]
How to get SSL back?
I think at first we have to repair the log function and afterwards we can
use it to remove the SSL problem.
Here folows my configuration:
/etc/default/perdition
[...]
RUN_PERDITION=yes
POP3=yes
POP3_FLAGS=" --ssl_mode tls_listen --outgoing_port 110"
POP3S=yes
POP3S_FLAGS=" --ssl_mode tls_listen --outgoing_port 995"
IMAP4=yes
IMAP4_FLAGS=" --ssl_mode tls_listen --outgoing_port 143"
IMAP4S=yes
IMAP4S_FLAGS=" --ssl_mode tls_listen --outgoing_port 993"
MANAGESIEVE=no
MANAGESIEVE_FLAGS=
[...]
/etc/perdition/perdition.conf
[...]
bind_address 78.xx.xx.xx
imap_capability "IMAP4rev1 UIDPLUS CHILDREN NAMESPACE THREAD=ORDEREDSUBJECT
THREAD=REFERENCES SORT QUOTA AUTH=CRAM-MD5 AUTH=CRAM-SHA1 AUTH=CRAM-SHA256
IDLE"
connection_limit 128
server_resp_line
outgoing_server 127.0.0.1
ssl_cert_file /etc/perdition/perdition.crt.pem
ssl_cert_accept_self_signed
ssl_key_file /etc/perdition/perdition.key.pem
ssl_no_cert_verify
ssl_no_cn_verify
[...]
What else do you need?
I hope somebody can help. Thanks.
Mit freundlichen Grüßen / With kind regards
Ronny Seffner
--
Ronny Seffner | Alter Viehweg 1 | 01665 Triebischtal
www.seffner.de | ronny(a)seffner.de | +49 35245 72950
Hi!
I am in the planning stage for an upgrade of my employers mail system.
In the backend I will be using dovecot which supports IMAP COMPRESS
<http://www.ietf.org/rfc/rfc4978.txt>,
<http://wiki2.dovecot.org/Plugins/Compress>.
In the frontend I would like to continue using perdition.
>From the RfC I assume, perdition should cope with IMAP COMPRESS, since
everything after a successful authentication is just passed through.
>From the RfC:
,----
| The following example illustrates how commands and responses are
| compressed during a simple login sequence:
|
| S: * OK [CAPABILITY IMAP4REV1 STARTTLS COMPRESS=DEFLATE]
| C: a starttls
| S: a OK TLS active
|
| From this point on, everything is encrypted.
|
| C: b login arnt tnra
| S: b OK Logged in as arnt
| C: c compress deflate
| S: d OK DEFLATE active
|
| From this point on, everything is compressed before being
| encrypted.
`----
Is my assumption correct that it is safe to use perdition in such a
setup? Or am I threading on thin ice here, bound for disaster?
Grüße,
Sven.
--
Sig lost. Core dumped.
