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/
Hi,
I am curious whether Perdition has support for the AUTH=PLAIN
capability. A quick test indicates that it does not support it (I am
using version 1.19rc4). I issued the following two AUTHENTICATE commands
to test it in Perdition:
1 authenticate plain asdfasf
1 BAD Mate, try AUTHENTICATE <mechanism>
1 authenticate plain
1 NO AUTHENTICATE mechanism not supported, mate
A post by Simon Horman here:
http://lists.vergenet.net/pipermail/perdition-users/2010-December/002458.ht…
indicates that it does support AUTH=PLAIN, are there some undocumented
options that enable it?
Cheers,
Dominic.
Hi,
Scratch this I figured it out. It turns out the commas in the DN of the authenticating user need to be replaced by %2c, aka the hexadecimal representation for a comma. I wish that was documented better.
Jim
--
Jim Howell
Cornell University
CIT Infrastructure, Unified Comm.
Msging Group, Lead Email Specialist
email: jwh2(a)cornell.edu
Phone: 607-255-9369
From: Jim Howell <jwh2(a)cornell.edu<mailto:jwh2@cornell.edu>>
Date: Wednesday, July 25, 2012 11:09 AM
To: "perdition-users(a)vergenet.net<mailto:perdition-users@vergenet.net>" <perdition-users(a)vergenet.net<mailto:perdition-users@vergenet.net>>
Subject: [PERDITION-USERS] authenticated LDAP issue
Hi,
I'm trying to have Perdition use Active Directory as it's source of information but can't seem to get it to authenticate. This is Perdition v1.19-rc5 on Redhat Linux
88 %uname -a
Linux alva03 2.6.18-308.1.1.el5 #1 SMP Fri Feb 17 16:51:01 EST 2012 x86_64 x86_64 x86_64 GNU/Linux
Here is my lookup
#define PERDITIONDB_LDAP_DEFAULT_URL \
"ldap://query.ad.cornell.edu/DC=cornell,DC=edu?cn,extensionAttribute15?sub?(…
C=cornell,DC=edu,x-bindpw=SECRET"
It keeps giving me an error with credentials.
Jul 25 10:39:15 alva03 perdition.pop3[21678]: dbserver_get2: jwh binddn cn=perdition bindpw SECRET
Jul 25 10:39:15 alva03 perdition.pop3[21678]: dbserver_get2: err ldap_bind_s: Invalid credentials binddn cn=perdition bindpw SECRET
I have managed to get it working against a different test LDAP server that accepts anonymous binds just fine. But I really do need to get the authenticated version to work. Any suggestions?
Jim
--
Jim Howell
Cornell University
CIT Infrastructure, Unified Comm.
Msging Group, Lead Email Specialist
email: jwh2(a)cornell.edu<mailto:jwh2@cornell.edu>
Phone: 607-255-9369
Hi,
I'm trying to have Perdition use Active Directory as it's source of information but can't seem to get it to authenticate. This is Perdition v1.19-rc5 on Redhat Linux
88 %uname -a
Linux alva03 2.6.18-308.1.1.el5 #1 SMP Fri Feb 17 16:51:01 EST 2012 x86_64 x86_64 x86_64 GNU/Linux
Here is my lookup
#define PERDITIONDB_LDAP_DEFAULT_URL \
"ldap://query.ad.cornell.edu/DC=cornell,DC=edu?cn,extensionAttribute15?sub?(…
C=cornell,DC=edu,x-bindpw=SECRET"
It keeps giving me an error with credentials.
Jul 25 10:39:15 alva03 perdition.pop3[21678]: dbserver_get2: jwh binddn cn=perdition bindpw SECRET
Jul 25 10:39:15 alva03 perdition.pop3[21678]: dbserver_get2: err ldap_bind_s: Invalid credentials binddn cn=perdition bindpw SECRET
I have managed to get it working against a different test LDAP server that accepts anonymous binds just fine. But I really do need to get the authenticated version to work. Any suggestions?
Jim
--
Jim Howell
Cornell University
CIT Infrastructure, Unified Comm.
Msging Group, Lead Email Specialist
email: jwh2(a)cornell.edu
Phone: 607-255-9369
Hi!
I'm looking into perdition for a small case we have.
We would like to use perdition as a frontend for IMAP and only IMAP to choose between two system based on information in a OpenLdap database.
The information is in a object called "mailrouteaddress" and can be one of two user(a)box.domain.com or user(a)xob.domain.com
Hence I don't have an object just containing the systename.
Is there a way to parse the domainname from the object above?
(In pop I could use popmap I guess but I only need this for IMAP).
Regards
/Mats
Hi,
I'm trying to get Perdition to work as proxy for Mailenable IMAP
server. Apparently Mailenable has a broken IMAP implementation
which makes IMAP between Perdition and Mailenable unusable.
POP3 works fine, though.
A short description follows: Perdition tries to authenticate like
this (the double quotes are added by me):
"flim08 LOGIN {usernamelen}"
and receives from Mailenable:
"+ go ahead"
It then sends the username like this:
"adi2(a)aditestingwin.com.au {passwordlen}"
and receives:
"flim08 BAD LOGIN- Invalid username or password."
then sends the password:
"123qweasdzxc"
and Mailenable replies with:
"123qweasdzxc"
At this point Perdition closes the TCP connection and logs:
perdition.imap4[27975]: Fatal error authenticating user. Exiting child.
Hence, the IMAP session looks like this (Mailenable responds):
* OK IMAP4rev1 server ready at 07/18/12 10:04:13
flim07 CAPABILITY
* CAPABILITY IMAP4rev1 IMAP4 AUTH=LOGIN AUTH=CRAM-MD5 IDLE CHILDREN
flim07 OK CAPABILITY completed
flim08 LOGIN {25}
+ go ahead
adi2(a)aditestingwin.com.au {12}
flim08 BAD LOGIN- Invalid username or password.
123qweasdzxc
123qweasdzxc
BAD UNKNOWN Command
The IMAP authentication works with Mailenable if I manually use this
authentication string:
aaa login adi2(a)aditestingwin.com.au 123qweasdzxc
Is there a way to configure Perdition to use this authentication method
rather than the one it currently uses?
--
Adi Pircalabu, System Administrator
Discount Domain Name Services Pty Ltd, a Total Internet Company
PO Box 887, Hawthorn Vic 3122, Australia, T +61 3 9815 6868
Ask me about cloud hosting services
Hi,
I want to rewrite the username for authentication with managesieve.
If I authenticate with "\0original_username\0password", then everything
works fine, and perdition rewrites it to "\0rewritten_username\0password".
Unfortunatly some clients including squirrelmail/avelsieve and roundcube
send: "original_username\0original_username\0password", which gets
rewritten to:
"rewritten_username\0original_username\0password".
It looks like dovecot and cyrus only care for the username after the
first \0 which unfortunatly does not get rewritten via popmap.
Micha Krause
