The methods of distributing mail between multiple servers presented here, represents a scalable solution for applications where hosting mail for a domain on a single server becomes impractical. The cost of this method is, typically mail delivery and retrieval must travel though one extra hop adding to latency and effectively doubling network utilisation for mail. The former is a problem inherent in any multi-step mechanism and the latter can be alleviated by running multiple physical interfaces on a machine and spreading traffic between the interfaces.
At this stage, the solution is somewhat incohesive and some work needs to be done, drawing the different aspects of this solution together. In particular, pulling together the pop map, aliases or the user_map and general rules, into a single resource would simplify management greatly. Migration is another area that requires significant work and a scalable way for the mail servers to communicate with each other needs to be developed. It would be advantageous, if the mail servers could constantly be updated each other on their current load and users, so that migrations could occur as bottle-necks manifested.
The architecture developed has placed emphasis on a single user's mail only ever being located on a single server. This alleviates contention between servers for locks and avoids having to query each server for knowledge of a mailbox, as all servers have access to information on where an mailbox is housed. It is of particular note that intelligent construction of pop maps and aliases or user_map entries could be designed to migrate users' mailboxes to one of the servers closest to the user. When used in conjunction with routing techniques, to force traffic for a particular port onto a specific host, the user could be forced to always access one of the closest servers. Hence, a mail system distributed amongst separate physical locations can easily be created, enhancing the quality of service to end users though faster, more reliable access.