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 :)
MDaemon 20.0.0 now includes support for clustering.
Thank you for sharing your idea with us!
Reji Vincent C commented
Is it required different license ?
is there any time schedule you can publish on this topic?
We would like to see that too as this is nowadays a must.
Hi, I wait for this important feature & hope present in new version 17, but still not present, please add it faster because of its value for keeping mail box of users safe & not worry about its backup too.
thanks a lot, Janet
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.
Stephen Yeong commented
Scale out deploy include,
1. multiple Worldclient on separate machine with mail store on cluster lookup
2. pop3 / imap proxy mode for client auth and access their mailbox through communication between cluster servers, and session log better store on mailbox cluster with debug info about client source IP Address.
3. SMTP/MSA auth support across cluster group
4. after Web, POP3, IMAP, SMTP-MSA can scale out on cluster group, we can use soft balancer like vmware vshield edge to increase single IP session capacity.
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.