Add support for clustering
Allow for a two machine setup so that a user's mailbox can be located on two servers, such that the two mailboxes are synchronised in an IMAP like fashion. Both mail servers can receive mail via alternate MX records and update the user's local mailbox, which in turn gets synchronised with the corresponding mailbox in the alternate server.
Likewise a user can connect to either servers to read, delete or send mail and the other server's corresponding mailbox will get synchronised accordingly.
DNS caching could be limited to say 10 minutes, so within 10 minutes or less after the DNS gets changed, users would get redirected to the alternative site. After the problem is fixed, the failed server resynchronises the files and the DNS entries get reversed and we are back to normal.
The result is a redundant fully distributed email system and you can charge for two email servers, since they are both active. OK, if you could guarantee that only duplicated mail boxes exist, you might want to charge 50% for the backup server or make it free since the total active mailboxes will not exceed the licensed amount :)
Sync data and config between 2 MD servers (active-passive)
It would be very nice and absolut necessary in enterprise environments to make the mail server ready for high availability with redundant mailstores. Separation of mdaemon and wc should be more performant and scalable, also load balanced wc.
Add the functionality into Mdaemon to allow for true Fault-Tolerant and High-Availability via load balancing all services across two servers (which would include all inbound client connections).
Add the ability to run a real MDaemon Cluster with 2 or more
Thank you everyone for submitting and supporting this idea. We will consider this for future versions of MDaemon.
In case anyone is interested we have published a whitepaper on a system we setup here in an acitve/passive cluster. While it does not accomplish everything requested it does provide redundancy.
Active/Active HA clustering is a MUST! However this was shared in 2012 and it is still not in MDaemon considering it is the number 1 requested idea... Why is that?
Our company has a need to be able to service clients seamlessly from two different MDaemon servers - an "on board" server when they are on the move without a reliable Internet connection, and a "terrestrial" server when they are on a reliable Internet connection.
All actions they carry out on either server (e.g. marking emails as read, deleting them, or moving them to an IMAP folder) need to be reflected on the other server. Obviously changes can only be reflected when there happens to be a connection.
We can accept the constraint that things might get a bit confused if the user tries to carry out work on both servers simultaneously!
I *think* the clustering idea might be able to achieve this if I have understood it correctly.
Gabriel Medina commented
I have mdaemon mounted in a virtualized server with hyper-v which in turn is clustered. No but I will serve them if high availability and works perfect.
Tomas Ralfs commented
I would love this. One of the companies I work with has 14 offices around the world, Africa, Europe, USA, Asia.. Some of the offices has internet lines that pre-dates the dinosaurs. Something that would work with the unstable lines they have would be great.
Emanuele Aliberti commented
You could use the extended IMAP4rev1 (that you already developed for Outlook Connector) to mirror a mailbox between two or more MDaemon servers running in shared-domain mode.
Emanuele Aliberti commented
Extend the functionality of "shared domain" in MDaemon.
First, extend it to perform as a limited HTTP/IMAP/POP3 proxy.
Add a new mailbox attribute: a user's home server, where a mailbox is located permanently.
When a client connects to a server of the shared domain group, if the logging-in user is in his/her home server, behave as usual and complete local authentication. If it is not, user MINGER to query other server in the shared domain group. As soon as you find the loggin-in user's home server, authenticate using the pending session credentials provided by the client. If remote authentication succeeds, proxy the client protocol to the remote (home) server.