So I think it would be really cool if we could create a service for Mail-in-a-Box users to opt-in for, that would provide users with redundancy.
In the event that a user’s Mail-in-a-Box server does down, mail would be sent to Mail-in-a-Box Redundancy Service (let’s call it “MIABRS”). MIABRS would hold that mail until their server becomes online again, then send that mail to them and delete the mail. In the event that the server does not come back online again for 48 hours, the mail is deleted.
To further ensure the mail stays secure, a feature could be added to MIABRS where it encrypts the mail before storing it, so that the mail stays private. The MIABRS user would hold the decryption key, but not MIABRS, so that in the event of a security breach, no useful data is stolen.
Now, I understand that MIAB is privacy-focused. We could have MIABRS as a thing you must opt-in to, and not as a default feature. Also, MIABRS only has access to data IF/WHEN and only IF/WHEN the user’s server does not respond, which should not be often.
I understand that to the outsider, they would be trusting that MIABRS actually encrypts data before storing it and does not abuse the data in the process, and it also requires that the user stores the decryption key (which their server would remember, but still at risk of being lost).
Just a couple of ideas. Would be interested to see if it could be implemented, and ethically.
This is the purpose of a backup MX server … however backup MX servers are becoming rarer and rarer these days as email best practices suggest that mail delivery is retried for a minimum of 2 days before failing.
The negative of using a backup MX is that the sending mail server thinks that the mail is actually delivered when the secondary receives it - which is not the case … and should something happen to the secondary, the email is lost as the sender will not be attempting re-delivery as it believes that the email has already been delivered, rather then retrying delivery.
Actually you can do this yourself with a VPS service like DigitalOcean.
An example is:
Setup two MIAB Servers
Setup shared storage using DO’s Volume Block Storage System
Attach this new shared storage to both VM’s
while both VM’s are powered on, shutdown the MIAB services. (Mailinabox, dovecot, nginx, postfix, spamassassin, etc)
Move /home/user-data to the new external storage
Symlink the services, it’s files, etc (essentially /home/user-data/ folder) to the external folder
restart services.
Setup DO’s load-balancer service to do failover.
This hasn’t been tested, but we would be using load-balancing in a failover configuration. In theory it should work without a hitch, no data loss, and only 1-2 seconds of downtime while the failover switches.
What happens when an entire datacenter goes down from Digital Ocean? I have seen some of their emails, and sometimes an entire datacenter goes for down for a little bit of time.
Another way would be to take two VMs, setup rsync and keep one offline until the failover happens.
It would be easier to setup but has the potential of data loss or big down time due to either a failed rsync, or failed services starting.
I am not sure about having two MiaB servers with a shared home. The issue would be can two dovecot servers access the same data store.
The standard way of creating a backup mail server is to have a backup that just relays the mail (no local delivery) to the master server. When the master server goes down it just spools the mail to be relayed to the master server when it comes back up.
If we want to be serious about it (like research-level serious), we need to start with constraints.
What do we want to protect the service against?
Is it downtime, data loss, inconsistency, performance overhead, storage overhead?
Sure, we want to protect against them all, but we cannot (there is even a theorem about it - CAP theorem).
Once we decide on our goals and constraints, it will turn out that there are existing tools and methods to help.
It can be master-slave architecture, multiple levels of redundancy, heterogeneous servers in the cluster, consensus protocols, etc.
The tools range from quite complex distributed systems coordinators (e.g. ZooKeeper) to simple SQL configs (e.g. sharding the database).
All the methods have their pros and cons, and the cost of integrating and maintenance.
The conclusion I am trying to draw is that to properly turn MiaB into a distributed system with corresponding guarantees, it is not enough to just mount two instances to on drive or make more frequent data backups.
At the same time, trying to add resiliency in an ad-hoc manner may not be efficient.
If interested, let us raise this issue as a long term vision.
I feel like I’m missing something here. SMTP is designed to deal with downtime and unreachable servers. If I destination is unreachable, the delivery agent will attempt redelivery several times at different intervals. This actually works well and accomplished what you want better than a middleman relay.
Having a backup server is always nice, uptime is not just about external users delivering email, but also our internal users not being inconvenienced by a down server.
Please also consider the effect a backup MX has on greylisting. For that to function well you’ll need a shared DB to store the information and the temporary blocks. I’ve used a backup MX in the past but the greylisting problems created a pass through for all the spam. It wasn’t worth it.