- deepOfix Mail Server
Do you have multiple offices or branches and large number of users at different locations? Do you wish that each user across different locations could access their mail servers from the server closest to them?
Welcome to the paradigm of a Distributed Email setup.
Imagine an organisation with 500 users. You have 5 offices across the country. You have each of these 5 locations which have a large number of users in each of these offices and you wouldn't want to spend a lot of internet bandwidth getting users just to talk to a mail server setting in one central location.
You would want to build a system such that each user, sitting in their own office can access a local mail server and access their emails at a very high local mail speed. The advantage of having a system wherein users can access emails from a server physically close to them also has other benefits like that of Unified Authentication across all offices, a single User Directory that can be used across all offices and so on.
If you have a single mail server, you'd create all the mailboxes of users on that mail server in a single location and on one physical server. This action of creating mailboxes for each user happens when you add the user to the server i.e. when you create an account for that user.
Now, let's suppose, you are starting to replicate this whole mail setup across two (or multiple) locations. In that case, you'd have a property for each user saying which location the user primary belongs to. A user could also could be travelling between both the locations (or offices) but the user would necessarily have a home location and that is what we need.
Classify each user into location A or location B and put this property into the account of that user and the user is added into the mail server. You now have 'a' number of users in 'Server A' and 'b' number of users in 'Server B' with the mail delivery server property set to their corresponding home servers. Email to the users within such a setup gets routed based on that property of that user (which entails details about their home location, their mail delivery server or mail server location, etc.).
You can build in redundancy in a two specific ways. Suppose, you have two locations, then you could have two MX Records pointing to both the locations. So when a mail is received in location A for a user who is in location B, then that server talks to the server in location B and pushes the mail to location B where it gets delivered to the user mailbox. Similarly, when server B in location B receives a mail for a user whose mailbox is in location A, it pushes the mail to the location A server and consequently delivers it to the user's mailbox.
Additionally having multiple MX Records pointing to both these servers means that if one of these servers is down, at least the users in the locations whose servers are working would receive their mails.
Now, what happens to the mails which is received by a server but is not pushed to the other server because this recipient server is down. This mail is held in queue and is not delivered to anyone, it is in transit and it would reach the other server as soon as it comes up. A very critical part of this whole setup is the way we incorporate Directory Services into deepOfix.
deepOfix Mail Server supports LDAP based Directory Services and by virtue of the fact that every single account information that is used to deliver and route mails to users is stored in LDAP, you can replicate the LDAP across members of the distributed Mail setup and ensure the availability of exactly the same accounts across all the locations without having to go to each and every server and add those accounts. So, you have an account in one place and owing to LDAP's synchronisation property, you could replicate that account to all the locations. All these locations would route emails to the correct server of a specific user based on the location property of that user. Hence, this is the way in which the routing of emails happen.