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 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
I apologize if this has been covered. The signal-to-noise ration in my
Google searching and GMANE/MARC searching didn't lead me to good results...
I see a few posts from ~2004 regarding passphrase protected SSL keys.
Mr. Horms indicated that he thought it ought to work, but was unable to
devote effort at the time, being 'snowed under' :)
Was this functionality added? I see in the .c code some callbacks to
the ctx 'passphrase' parts of libssl but can't tell where it's getting
sent along, if at all.
Can anyone provide tips?
Thanks!
--
Aaron Thoreson
aaront(a)midco.net
Hi,
I'm happy to announce the release of 1.18.
It has been a long, long time since the release of 1.17 and there have been
many improvements since then. Possibly of most note being the addition of
IPv6 support.
Thanks to everyone who tested the rc releases, a lot of problems were
resolved and I hope that this is the most solid release of perdition to
date. And thanks to everyone who contributed changes, bug reports and
ideas.
A full change log is provided by the Mercurial repository
http://hg.vergenet.net/perdition/perdition/
Perdition 1.18-rc3 and the vanessa libraries that it depends on
are available from:
http://www.vergenet.net/linux/perdition/download/1.18-rc2/
Debian unstable packages have been uploaded to Debian.Org
and should be available in the Debian archive within 24 hours.
http://packages.debian.org/source/unstable/perdition
Packages for various RPM based distributions are being built by the SUSE
build service and should be available shortly from
http://download.opensuse.org/repositories/home:/horms/
(Note: any perdition-1.18rc3 packages are slightly out of date)
Thank you for the explanation. How can I fix this ? I attach the
perdition.conf file
bind_address 0.0.0.0
connection_logging
imap_capability IMAP4
listen_port 143
no_lookup
protocol POP3
outgoing_server a.b.c.d
my perdition daemon runs as nobody user.
Luciano Sarra
Simon Horman ha scritto:
> On Wed, Nov 18, 2009 at 10:17:55AM +0100, Luciano Sarra wrote:
>
>> Hi everybody,
>>
>> I'm running the Perdition system on a SLES 11 with the following
>> packages installed
>>
>> libvanessa_adt0-0.0.8-16.3.x86_64.rpm
>> libvanessa_logger0-0.0.8-43.2.x86_64.rpm
>> libvanessa_socket1-0.0.10-1.1.x86_64.rpm
>> perdition-1.18rc3-1.1.x86_64.rpm
>>
>> all the system is up and running but on the console as a standard output
>> I get the following message
>>
>> vanessa_logger_reopen: __vanessa_logger_reopen
>> __vanessa_logger_reopen: fopen: Permission denied
>>
>>
>>
>> I have the same messages even if I have installed the older packages
>>
>> perdition-1.17-9.3.x86_64.rpm
>> vanessa_adt-0.0.7-3.50.x86_64.rpm
>> vanessa_logger-0.0.7-2.55.x86_64.rpm
>> vanessa_socket-0.0.7-5.44.x86_64.rpm
>>
>>
>> What does it mean ? Is a bad warning ? How can I fix it ?
>>
>
> I suspect that the logger (file) is initially opened when
> perdition is running as root, that the.reopen is occuring
> after perdition has dropped root privileges and that with
> the reduced privileges it can't open the logger (file)
> in question.
>
Hello,
I've different setup of perdition proxy (POP3 and IMAP4) and I wish to
have a kind of fallback server.
I'm using popmap.re regexp filtering to loadbalance over 2 mailboxes
server based on the name of the owner (a-l -> server a, n-z -> server
b). Both server are able to serve all mailboxes so I wish to know if I
can setup something like this :
^[a-l] : serverA:143,serverB:143
^[n-z] : serverB:143,serverA:143
If serverA fail to answer then perdition uses serverB and vice-versa.
Thanks
--
Alexandre Ghisoli
One of our client cannot connect to our incoming mail server. I have notice that their ip was having an error on the log
Nov 16 09:21:53 perdition[26724]: Fatal error writing to client 1.2.3.4->10.20.30.40.Exiting child.
Nov 16 09:51:56 perdition[31690]: Connect: 1.2.3.4->10.20.30.40
Nov 16 09:51:58 perdition[31690]: Fatal error writing to client 1.2.3.4->10.20.30.40.Exiting child.
Nov 16 10:06:24 perdition[1673]: Connect: 1.2.3.4->10.20.30.40
Nov 16 10:06:24 perdition[1673]: Fatal error writing to client 1.2.3.4->10.20.30.40.Exiting child.
Nov 16 10:08:25 perdition[1991]: Connect: 1.2.3.4->10.20.30.40
Nov 16 10:08:26 perdition[1991]: Fatal error writing to client 1.2.3.4->10.20.30.40.Exiting child.
This is the only client who is experiencing this problem. Anyone can give a hint about this problem and any possible
solution?
BODY { font-family:Arial, Helvetica, sans-serif;font-size:12px;
}(corrected, was the other way around)
In file options.h
this
#ifdef WITH_PAM_SUPPORT
int authenticate_in;
int authenticate_timeout;
#endif /* WITH_PAM_SUPPORT */
should read
#ifdef WITH_PAM_SUPPORT
int authenticate_in;
#endif /* WITH_PAM_SUPPORT */
int authenticate_timeout;
otherwise you get compile errors if no there is no PAM support in
the system, as the authenticate_timeout element is used througout the
code anyway.
(sorry no diff in the system I was working on :) )
BODY { font-family:Arial, Helvetica, sans-serif;font-size:12px; }In
file options.h
this
#ifdef WITH_PAM_SUPPORT
int authenticate_in;
#endif /* WITH_PAM_SUPPORT */
int authenticate_timeout;
should read
#ifdef WITH_PAM_SUPPORT
int authenticate_in;
int authenticate_timeout;
#endif /* WITH_PAM_SUPPORT */
otherwise you get compile errors if no there is no PAM support in
the system, as the authenticate_timeout element is used througout the
code anyway.
(sorry no diff in the system I was working on :) )
