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
Hi,
I'm happy to announce the release of 1.18-rc2,
with a view to turning this into 1.18.
There are very few changes since 1.18-rc1:
* Fix a problem in the LDAP library whereby user, host and port information
was never returned.
* Add authenticate_timeout configuration.
* Various rpm and deb packaging fixes.
A complete list of changes is available in the changelog provided
mercurial.
http://hg.vergenet.net/perdition/perdition/
Perdition 1.18-rc2 and the vanessa libraries that it depends on
are available from:
http://www.vergenet.net/linux/perdition/download/1.18-rc2/
RPM packages built with CentOS 5.3 and Debian packages for Sid are
also available. These have been built for x86_32 (i386). I hope
to provide x86_64 (amd64) packages shortly. I will also push the Debian
packages onto Debian.Org and they should be available there
in a day or so.
I'm not sure if this affects all ldap users, but since 1.18rc1 I
couldn't login anymore using user(a)domain.tld like used in ispman.
We used to use
http://server/?o=ispman?mailRoutingAddress?sub?(uid=%25s)
Since it's not using serverdb_get2 I updated that line to use
http://server/?o=ispman?mailRoutingAddress,mailHost?sub?(uid=%25s)
Which works 100% using ldap search It returns
mailRoutingAddress = user_domain_tld@mailHost
mailHost = mailHost
so I had to also add to perdition.conf
strip_domain remote_login
Now that being said even with all that I'd get server null, looking
into perditiondb_ldap.c I found that it wasn't setting the ref
values. I had to changes these lines
/* Build the return string */
if (returns[0])
user_str = &returns[0];
if (returns[1])
server_str = &returns[1];
if (returns[2])
port_str = &returns[2];
to look like this
/* Build the return string */
if (returns[0])
*user_str = returns[0];
if (returns[1])
*server_str = returns[1];
if (returns[2])
*port_str = returns[2];
Now everything works 100%, server gets set as does the user, hope this
helps others cause it was 4 days of hell for me :D
---
TS
http://southofheaven.org/
Chaos is the beginning and end, try dealing with the rest.
Hi,
I am testing perdition-pbs and I am not sure how the information should
appear in the popauth.bd. I see that the IP address of my external
machine that I used for IMAP4s access is being added to popauth.db (but
there are some extra characters on it):
VERSION=3
format=print
type=hash
h_nelem=4
db_pagesize=4096
HEADER=END
POP:XX.XXX.XX.XX\00
POP:XX.XXX.XX.XX\00
TIME:POP:XX.XXX.XX.XX\00
\d0\f4\afJ
TIME:POP:XX.XXX.XX.XX\00
B\ec\afJ
DATA=END
The sendmail map lookup always fails for the key, but the IP is on the db.
map_lookup(popauth, POP:XX.XX.XX.XX, %0=POP:XX.XX.XX.XX) => NOT FOUND (0)
check_rcpt returns: $# error $@ 5 . 7 . 1 $: "550 Relaying denied"
Please would perdtion-pbs work with Sendmail 8.14 and the sendmail
POPAUTH hack from sendmail.org?
Thank you very much,
Zane
Hi Horms!
Modifications on *spec.in ( for vanessa_logger vanessa_adt
vanessa_socket perdition) are need for "rpmbuild -ta <name>.tar.gz" on
Fedora >7 ? systems (rpm ver 4.4.xx)
-> Copyright: GNU Lesser General Public Licence
-< License: GNU (or wherever)
Thanks for your magnific work ! :-)
This series of patches implements an authentication_timeout configuration
option and relegates the existing timeout option to only being used
after authentication has occured.
As suggested by Christian Balzer.
Hi,
I'm happy to announce the release of 1.18-rc1,
with a view to turning this into 1.18.i Please test.
There are numerous changes since 1.18. Perhaps the most significant
being the inclusion of IPv6 support which is in part provided
by vanessa-logger 0.0.8, which was also released today.
A complete list of changes is available in the ChangeLog,
the 1.18-rc1 portion of which was generated from the logs
in mercurial.
http://www.vergenet.net/linux/perdition/ChangeLog.shtml
Perdition 1.18-rc1 and the vanessa libraries that it depends on
are available from:
http://www.vergenet.net/linux/perdition/download/1.18-rc1/
