Perdition: FAQ

| Vanessa | More Projects | Perdition-PBS |
| Main | Download | Releases | Git Repository | Documentation | FAQ | Deployments | Support |

1. Microsoft™ Outlook Express 5™ won't connect to Perdition when SSL is in use
2. Perdition will not accept more than a couple of simultaneous connections
3. Establishing connections via perdition take a long time or time-out completely

1. Microsoft™ Outlook Express 5™ won't connect to Perdition when SSL is in use
The version of Microsoft™ Internet Explorer™ (IE) that ships with Microsoft™ Windows™ 2000 only has very weak, RC2 40bit encryption available. OpenSSL, which perdition uses for encryption, does not support any of the cipher suites available with that version of IE. As Outlook :Express uses IE's SSL subsystem, this means that it cannot connect to perdition.
This may result in an error message along the lines of:
Your server has unexpectedly terminated the connection. Possible causes for this include server problems, network problems, or a long period of inactivity. Account: 'XXX', Server: 'abc.xyz.com', Protocol: POP3, Port: 995, Secure(SSL): Yes, Error Number: 0x800CCC0F"
As the US government has relaxed its arcane export restrictions on encryption technology there is no longer any reason to use weak 40bit encryption. So To resolve this problem you should upgrade IE to a version that has a stronger encryption. Both IE 5.5 (preferred) and IE 5.01 support stronger encryption.
Windows 2000 requires an additional. patch.
To change your account to use stronger encryption that will work with perdition:

From the menu bar go to (Tools -> Accounts) and select the account that you are using to connect to perdition.
Click on properties
Goto the security tab, the encryption method chosen should be 3DES (if this option isn't available then you need to install the updates above.

October 2002: Jake Wallace, Amanda Lin and Horms
2. Perdition will not accept more than a couple of simultaneous connections
Perdition is able to limit the number of simultaneous connections using the connection_limit option. If you have having troubles with connections being refused you should check this value in your configuration file.
However, even if this value is not set (unlimited connections), connections may be dropped if the real servers also have a process or IP connection limit. The following discusses this problem when Courier IMAP is used on the real server(s):
All connections to the real POP/IMAP servers will originate from systems running Perdition. The software does not pass through client IP's in the manner of a load balancing switch. Only logs generated by Perdition will contain username to IP mapping.
Under load, the number of connections between the Perdition systems and real mail servers will increase. This occurs as more users are simultaneously receiving traffic. The number of these connections can easily exceed "per IP" client limitations specified on the real servers. For example, Courier-IMAP's POP3 daemon configuration file contains a line for "Maximum number of connections to accept from the same IP address" (called MAXPERIP). It is set to 4 by default. This limitation will need to be increased to handle additional connections.
Symptoms of exceeding mail server "per IP" limits are connections that unexpectedly close. If this condition occurs, Perdition logs will contain several lines of diagnostic messages that indicate that real server connection was closed with no data being passed.
__token_fill_buffer: zero bytes read: Success Zero bytes read

October 2002: Eric Fagan and Horms
3. Establishing connections via perdition take a long time or time-out completely
Some times perdition can take a long time to establish a connection to a real-server or the connection can time out completely. This may result in log message like the following:
...: gethostbyaddr: Connection timed out.

If this problem occurs then it may be caused by DNS timeouts on the linux-director. The real solution to this problem is to make sure you are using a DNS server that will reliably give fast results to the perdition-director.
A quick fix to this can be to put entries in the /etc/hosts file on the perdition director for each of the real-servers and the IP addresses of the perdition director.
An alternative approach is not to tell perdition not to perform DNS lookups by using the no_lookup option. Be warned, that this will turn all host-name lookups off, so you will need to use the IP addresses of real servers in your popmap instead of hostnames.
November 2002: Horms
4. perdition.managesieve can't be controlled by the init script on older Red-Hat based systems.
On Fedora 8, and probably others, process names are truncated to 15 characters in their /proc filesystem entries. On RedHat-ish systems, at least, the rc script functions and programs make heavy use of these entries, via their use of the pidof and other system programs. Here is an entry for perdition.managesieve:
# cat /proc/26539/stat 26539 (perdition.manag) S 1 26538 26538 0 -1...
The typical init script functions in /etc/rc.d/init.d/functions make heavy use of the pidof command (another name for killall). That command fails to find your perdition.managesieve processes
# /sbin/pidof -c -x perdition.managagesieve # /sbin/pidof -c -x perdition.manag 26539
This means that the script will never stop or restart the managesieve process, nor will it properly report status. This problem does not exist on modern Ubuntu systems, from what I can see, nor with Fedora 12.
A work-around is to over-ride the __pids_pidof() function in the init script by inserting the following fragment into the init script, near the top, right after ". /etc/rc.d/init.d/functions".
# Hack to get around broken pidof program - replace __pids_pidof from above # library. __pids_pidof() { proc=`echo $1 | cut -c1-15` pidof -c -o $$ -o $PPID -o %PPID -x "$proc" || \ pidof -c -o $$ -o $PPID -o %PPID -x "${proc##*/}" }

June 2010: Nic Bernstein