5.2. POP / IMAP
The physical location of the single mailboxes on the various servers is determined by the host attribute of the corresponding LDAP object. This location is hidden for users since we have to be able to move the mailboxes transparently without the users being aware of it, for example when the hardware of one server fails or simply to balance traffic among the various servers. This is why we need to provide users with connection parameters that never change, independently of the physical box location.
The problem is that mail reading protocols do not allow redirection easily (IMAP redirection is included in an RFC that no client actually implements). The initial solution we had sorted out defined for each user a CNAME that pointed at the appropriate mail server and could be used by users in their client configuration (something like UTENTE.users.dominio.org). Unfortunately this solution was not very functional, since it does not work properly when SSL comes into play: in fact, the validation of the name and certificate CN would never happen in such a system and the user would have to click on a security warning each other second.
The choice had then to be made between losing flexibility giving the user the specific server they had to configurate in their client (but in this way moving mailboxes around servers when it comes to be needed becomes practically impossible) and using a IMAP/POP proxy like Perdition, handling independently to move the data between servers (you can watch out for the same numerical analysis done for SMTP traffic). For the moment being we are trying out this second option monitoring the traffic and bandwidth consumption: if it turns out to be not sustainable then we will have to switch to the previous option.
The configuratoin parameter for the users' client will then be all the same:
POP/IMAP host: mail.domain.org
SMTP host: smtp.domain.org
With these configurations the client connect to the front-end server (Perdition) on any of the boxes and their connection is then forwarded internally (through the VPN) to the back-end server of the appropriate box. For the back-end server we chose dovecot because among all the different possibilities it seemed to us the lightest and most performing software.
The picture shows the IMAP connection flow considering the two different access hypothesis:
The users connection through an autonomous IMAP client on their computer (as any mail client for example) will connect to Perdition that redirects them directly (through the VPN) to the dovecot server on the server where their mailbox stands.
The users checking their mail through the webmail instead will be forwarded directly to the "correct" server (since the connection can be forwarded playing with HTTP redirect). The webmail application connects to an specific imapproxy (up-imapproxy) on the server itself. This proxy is needed to keep track of persistent connections and it's very useful since the web php application has to do a new IMAP connection for each new page. With the local imapproxy we avoid this unpleasant waste of connections. Finally the local proxy connect to the true IMAP server and serves the mail to the user.
This table shows the configuration parameter we used to implement the mechanism described above:
- perdition (ports 143 and 995)
in perdition.conf:
map_library /usr/lib/libperditiondb_ldap.so.0 map_library_opt "ldap://127.0.0.1/ou=People,dc=infra,\ dc=org,o=Anarchy?mail,host?sub?(&(mail=%s)\ (status=active))" outgoing_port 10143 ssl_ca_file /etc/ssl/certs/imap.pem ssl_key_file /etc/ssl/private/imap.keyTo have the host attribute correspond to the IP we need (the internal VPN address in this case, resolved by the host-vpn hostname), we installe perdition in a appropriate chroot with its own /etc/hosts file. We had to do this since perdition LDAP backup does not support the rewriting of the result as Postfix does. This daemon is the only one receving SSL connections from the outside.- up-imapproxy (port 11143)
in imapproxy.conf:
server_hostname 127.0.0.1 server_port 10143 listen_address 127.0.0.1 listen_port 11143
In this way the proxy knows it has to forward the connections only towards the IMAP local server.- dovecot (port 10143)
in dovecot.conf:
imap_listen = 127.0.0.1:10143 ssl_disable = yes
The configuration of the users' authentication (in dovecot-ldap.conf) has been already described in the previous chapter.
When a mailbox will need to be moved from one server to the other (apart a very bad scenario in which the first box is completely crashed and data are not accessible anymore) it will be possible to use rsync after having edited LDAP database objects to move the old mailbox physically on the new server (that will be already receiving incoming messagges by then).