Perdition-users October 2012

perdition-users@vergenet.net

2 participants
4 discussions

by David Severance

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? thanks, David -- David Severance Enterprise Unix Services Office of Information Technology (949) 824-7552 sev(a)uci.edu

10 years, 10 months

Zombie pop3s (and imaps?) processes in connect state

by Christian Balzer

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/

11 years

Question about "user agent" & perdition log files

by Javier de Miguel Rodríguez

Hello We would like to see the user-agent (MUA) of the imap connections. For example, If I see detailed information of connections in gmail I see: _"name: iPhone Mail"_ _"os: iOS"_ _"os-version: 6.0 (10A403)"_ _"version: 10A403"_ IMAP (Thunderbird) ocultar detalles ID de cliente (sin verificar): _"name: Thunderbird"_ _"version: 15.0.1"_ How can we accomplish the same with perdition? Regards Javier -- Apoyo a la docencia e investigación Universidad de Sevilla

11 years, 1 month

Regarding perdition with SMTP-AUTH

by Arun Gupta

Hi, I am using perdition for IMAP authentication for differen IMAP servers located in different location, I don't want to use pop-before-smtp program, can we use SMTP-AUTH , if yes how it works if users are located on different different location. Thanks & Regards, Arun Kumar Gupta INDIA ------------------------------------------------------------------------------------------------------------------------------- This e-mail is for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies and the original message. Any unauthorized review, use, disclosure, dissemination, forwarding, printing or copying of this email is strictly prohibited and appropriate legal action will be taken. -------------------------------------------------------------------------------------------------------------------------------

11 years, 1 month

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Perdition-users October 2012