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: Connect: hi.mi.ts.u->220.127.116.11
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
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.
Christian Balzer Network/Systems Engineer NOC
chibi(a)gol.com Global OnLine Japan/Fusion Network Services
I'm sure this is a newbie-level question, but I can't find it clearly
answered in the docs or example configurations.
Assuming a single instance of Perdition is bound to multiple IP addresses,
can Perdition rewrite requests based solely on what IP address receives a
I'm replacing an old mail system where each domain has a separate IP
address, and there are multiple instances where folks have the same
username and password on different domains. Their mail clients are often
configure with a user name of 'bob' as opposed to 'bob(a)domain.com', so I
really need the IP address in addition to the username/password to figure
out where a connection should go.
I know I could get around this by having multiple instances of Perdition,
each bound to a separate IP address, but there are about 40 domains (and 40
IPs) involved in this process. If there's an easier way to do it, I'd love
to avoid having all those nearly-identical configuration files floating
around, waiting to confuse me.
I am in the process of migrating from one mail server to the other, and
have discovered that we are running perdition on the firewall server to
proxy the incoming requests, which is nice because my migration plan has
just got a little easier.
The issue that I am having is that I cannot find much helpful
documentation or code snippets anywhere that helps me achieve a round
robin approach to adding another server, or to confirm the configuration
can handle IMAP and IMAPS servers in the round robin setup.
What I would like perdition to do is try the original mail server,
mail.x.com.au on imap port 143 (running gordano mail system on centos),
if it fails then try exchange.x.com.au imaps port 993 (Exchange 2010SP1
running on Windows 2008R2SP1 server)
The perdition config is currently as follows;
If anyone can shed some light, that would be greatly appreciated
Climate Technologies P/L
Mob: 0488 261 085
The contents of this e-mail (including any attachments) are strictly confidential
and may be commercially sensitive. If you are not, or believe you may not be, the
intended recipient, please advise the sender immediately by return email, delete this
e-mail, and destroy any copies. In these circumstances, any use or dissemination of this
e-mail, or any other dealing based on this e-mail, is strictly prohibited and may be a
breach of Australian law. No warranty is given by us that the integrity or security of
this e-mail (including any attachments) has been maintained through transmission nor
that it is free of virus or any other defect or error. Formatting may have altered in
transmission. It is the recipient's responsibility to virus scan and otherwise test the
information hereby provided before loading onto any computer system.