Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Backup MX #591

Open
benyanke opened this issue Sep 15, 2018 · 6 comments
Open

Backup MX #591

benyanke opened this issue Sep 15, 2018 · 6 comments

Comments

@benyanke
Copy link

@benyanke benyanke commented Sep 15, 2018

Is there an official Mailu way of running a backup MX? If not, would you accept an alternate docker-compose file and configuration options to run a similar easily-configured backup MX?

@hoellen
Copy link
Member

@hoellen hoellen commented Sep 16, 2018

I believe you want something like #177

@kaiyou
Copy link
Member

@kaiyou kaiyou commented Sep 19, 2018

Also, I agree about providing an alternate compose file for running a backup MX. My initial idea on the matter was providing a separate Postfix image with a special configuration and startup script, that given an api token would lookup the list of domains from the primary MX and serve these automatically.

This will become really easy to setup once we have a proper api. Until then, maybe we can have an IP based authentication and an env variable for authorizing backup MX.

@muhlemmer
Copy link
Member

@muhlemmer muhlemmer commented Oct 13, 2018

Why want a backup MX? You'll expose yourself to high levels of spam. Some (or most?) spammers tend to skip the primary MX record and go straight for the secondary. Secondly, if it does happen your single MX is down, mails are just hold in a queue at the sender's side until available again.

I've read this article in the past, and I do feel they are right.

On the modern internet there are more elegant solutions available for failover /HA. (Swarm, kubernetes, rancher). See also #177.

@Nebukadneza
Copy link
Member

@Nebukadneza Nebukadneza commented Aug 18, 2020

Hi There,

The Mailu-Project is currently in a bit of a bind! We are short on man-power, and we need to judge if it is possible for us to put in some work on this issue.

To help with that, we are currently trying to find out which issues are actively keeping users from using Mailu, which issues have someone who want to work on them — and which issues may be less important. These a less important ones could be discarded for the time being, until the project is in a more stable and regular state once again.

In order for us to better assess this, it would be helpful if you could put a reaction on this post (use the 😃 icon to the top-right).

  • 👍️ if you need this to be able to use Mailu. Ideally, you’d also be able to test this on your installation, and provide feedback …
  • 🎉 if you find it a nice bonus, but no deal-breaker
  • 🚀 if you want to work on it yourself!
    We want to keep this voting open for 2 weeks from now, so please help out!
@benyanke
Copy link
Author

@benyanke benyanke commented Sep 30, 2020

For future notice: perhaps backup MX servers could work partly with #1044, providing dovecot replication. That way each local MX server has a list of accounts and can accurately bounce mail, receive mail to it's local DB, and replicate (assuming the other side is up, or replicate once it does come up).

Perhaps an alternative docker compose config without the admin/webmail containers could be helpful for this.

A bit of stream of consciousness here, but perhaps these two issues could work together.

@lub
Copy link
Member

@lub lub commented Sep 30, 2020

Originally a backup MX was basically a big mail queue without the ability to directly deliver emails to mailboxes and I don't think this behavior makes much sense anymore, because as @muhlemmer already pointed out there are more modern and more general approaches for ensuring a highly available message submission without the downsides of a spammers attracting 'classic' backup MX.

A replicated dovecot setup also imo doesn't really help with email submission, because afaik postfix should already defer emails when dovecot is not reachable via LMTP. Also dovecot is not necessary to e.g. bounce emails for invalid recipients, as these should already be handled by front/nginx before even hitting postfix or dovecot itself.

I think the proper way to solve this (having multiple MX in case one isn't reachable) is to use a HA database setup (there are solutions for postgres and mariadb to achieve this) and have multiple instances of front/nginx, smtp/postfix and admin, but I'm not sure if anyone ever tested running multiple instances of admin.

That way there would be no difference in scaling your setup for better load distribution or for better reliability.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
6 participants