When we originally implemented perdition v1.17 on RHEL4 several years
ago we had a customized the /etc/pam.d/perdition file to use the
pam_access.so module so we could lock out accounts for
administrative/maintenance purposes. This worked well for many years.
Within the last year we upgraded to RHEL5 and perdition 1.19rc4 and then
rc5. It would appear that since this update perdition no longer seems to
pay any sort of attention to the contents of the pam file and will
always assume success. Nothing seems to be logged either unlike before.
Although we are now compiling perdition to be located in /usr/perdition
with it's conf files in /etc/perdition I don't see how that would affect
pam operations, at least I would think it shouldn't. ldd on perdition
does show pam libraries being linked. Any ideas?
Enterprise Unix Services
Office of Information Technology
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
imap4 supports a simpler version of the login string than perdition uses. Some older imap servers do not understand the newer login string that perdition uses. The disadvantage of the simple login is that user names can not contain spaces or other special characters. The patch adds a flag to have perdition use the simpler login method. It also corrects a spelling error with DEFAULT being typed as DEFAILT.
This e-mail and any attachments are intended only for use by the addressee(s) named herein and may contain confidential information. If you are not the intended recipient of this e-mail, you are hereby notified any dissemination, distribution or copying of this email and any attachments is strictly prohibited. If you receive this email in error, please immediately notify the sender by return email and permanently delete the original, any copy and any printout thereof. The integrity and security of e-mail cannot be guaranteed.
I have several mail realms under my command (example1.netexample2.net etc).
Now I would like to use Perdition to set up a imap/pop3 proxy with it.
Is it possible that Perdition switches the backend (real imap/pop3)
server depending on the ralm the user authenticates with?
For example, if the user sends a login like "user1(a)example1.net",
then perdition redirects the auth info (imap or pop3) to
mail.example1.net and if
the user sends login "user1(a)example2.net" then perdition redirects to
Thanks for any advice,
I am updating our Perdition proxies from RHEL4 to RHEL6.
Are there source RPM? I was hoping to just be able to do
rpmbuild --rebuild with latest version.
"The universal aptitude for ineptitude makes any human accomplishment an incredible miracle." - Stapp's Law