I've been running my own mail servers since the mid-90s, and always only a single server. SMTP keeps retrying, so you can be offline. The transport layer was designed to deliver mail to servers even if those servers only dialled in to one of the "internets" once per day, so it's fine to have some downtime.
It's totally up to you how you prioritise getting a server back up again, and frankly if the message can't handle at least a few hours delay then email probably isn't the right medium for it.
> frankly if the message can't handle at least a few hours delay then email probably isn't the right medium for it.
This may have been the case in the mid-90s, but it is certainly not the case today. I frequently receive emails that require immediate attention, whether from my employer, my bank, or any number of other notifications. Normal email users expect emails to be delivered in seconds, not hours.
Of course not, like most things email is best-effort. But it's hard to blame users when for the last 10 years we've been able to send/receive email in <10s.
I feel sorry for you if you base everything on user expectations... I sure hope you do not work in professional IT if that is the case because if you do you must be one stress out person...
Most email on the Internet is delivered all the way from the original sender to the end recipient in seconds. Many user experiences require this, such as password reset interactions or email address verification upon new account creation.
When email isn't nearly instantaneous, it's definitely upsetting to users and a violation of the norm. Email is only not instantaneous in well-managed systems when one of the parties is experiencing an operational problem of some kind.
There are exceptions to this, such as large scale marketing systems that deliberately send at a slow rate to avoid overwhelming recipients. Once deciding to actually send a message, though -- if not rate-limited by the receiver -- messages tend to arrive in the inbox in moments.
Email isn't that complicated of a protocol, when you get down to the mechanics of email delivery. Loading a web page is orders of magnitude more complicated than sending an email; there's no reason why sending an email would need to take longer.
This is actually frustrating, e.g. with a large power outage when you expect an important message. I run my mailhost (single-node) since 2005 and I thought that I need HA more than once or twice.
Sadly, I haven't figured out a proper fully-redundant solution. Syncing mailboxes with e.g. Syncthing is way too fragile. Recently, I wanted to experiment with DBMail + CockroachDB cluster but haven't yet found time for that.
Never found any MRA that uses document-oriented database like RethinkDB; and GlusterFS is way too sensitive to high latencies - so DBMail+CRDB looks like the only readily accessible option sans of trying more "raw" programmable solutions like Salmon or Haraka and writing own storage backend.
Haven't seen this project before - and I've tried to search for mail servers using document-oriented DBs, although not sure if I've searched specifically for MongoDB. Will definitely take a look.
I guess the project is too new and it is hard to stand out amongst other players that have been around for 20 years by now. Even though not having been around so long has advantages as well, for example it allows skipping non-needed features and adding new stuff like full unicode support – I host андрис@уайлддак.орг on my WildDuck test instance (even though I can only communicate with Gmail using this address, other servers either refuse my messages or do not send to such address).
Dovecot has an excellent implementation of 2-way synchronization of mailboxes: run Dovecot on 2 different servers in different physical locations, set up MX records and a SMTP software on both servers and you have your HA solution.
keep your DNS up always - so have a backup if this is running DNS - many mailing list programs and other things will drop a mail immediately if the destination cant be resolved..
It's totally up to you how you prioritise getting a server back up again, and frankly if the message can't handle at least a few hours delay then email probably isn't the right medium for it.