Docker-mailserver: Easy config for secondary / backup MX server

Created on 12 Aug 2016  路  18Comments  路  Source: tomav/docker-mailserver

Note for later...

enhancement frozen due to age help wanted priority 2 [MEDIUM]

Most helpful comment

Here is how i run docker-mailserver as a backup MX.

Create postfix-main.cf in config directory and add the following:

relay_domains = hash:/tmp/docker-mailserver/backupmx/relays
transport_maps = hash:/tmp/docker-mailserver/backupmx/transport
relay_recipient_maps = hash:/tmp/docker-mailserver/backupmx/relay_recipients
maximal_queue_lifetime = 14d

Create a directory called backupmx and the following files relays, transport and relay_recipients.

relays should contain the domains you would like to queue & relay mail for. E.g.

domain1.com OK
domain2.com OK

transport should contain the final destination mail server to relay the queued email to. E.g.

domain1.com smtp:mail.domain1.com
domain2.com smtp:mx1.domain2.com

relay_recipients should contain a list of valid recipients that will be accepted, queued and relayed. E.g.

[email protected] OK
[email protected] OK

For the above to work, the following commands must be run inside the container:

cd /tmp/docker-mailserver/backupmx/
postmap relays
postmap transport
postmap relay_recipients
service postfix restart

I haven't had time to create a PR for this, but hopefully this helps someone.

All 18 comments

+1

  • SERVER_TYPE with primary as default, secondary as other possible value
  • keep file generation on primary server
  • disable services like IMAP on secondary
  • synchronize recipient list from primary to secondary using scp and reload postfix

What about dovecot master/master replication: http://wiki.dovecot.org/Replication ?

@Neikius yep why not, have you tried to?

after hacking some stuff into the #254 branch. secondary and primary is ok for 2 node clusters. should we care about 3? if we do master master (#430), this naming scheme is not relevant as both are master. thinking about it.

function _setup_ha_nonprimary() {
....
}

it should act as being a master, unless it is tagged as a slave (dont like that name)
or failover node (failover does not "work" for master/master setup as a name).

:+1:

@voti is also interested in this feature in case you want to feed the discussion.

+1
would be greate to have a backup MX server with postfix _relayhost=_ option in main.cf
:)

So is setup with multiple MX records with more hosts working in some way?
I think it's a must for a mailserver

I'm considering trying docker-mailserver, however having no HA is a no-go for me for email. Was there any progress regarding this issue?

It seems not. I agree that it would be useful but someone needs to invest the time and submit a PR.

Would poping two instances with the same shared volume for data be enough?
I suppose we'd also need to share the LDAP and configuration files right?

Not really, a HA configuration must be able to run on separate physical machines. Docker does not support distributed read/write volumes and even if you run in some cloud solution that does there would be other issues. A dedicated backup server is probably the easiest approach.

@LukeMarlin you have to be aware, though that having a backup mx is something quite different than HA (it just receives your mails for you and once your primary system is back online, relays them to it).

For replication within Dovecot one could use dsync (some more details in https://wiki.dovecot.org/Replication).

Here is how i run docker-mailserver as a backup MX.

Create postfix-main.cf in config directory and add the following:

relay_domains = hash:/tmp/docker-mailserver/backupmx/relays
transport_maps = hash:/tmp/docker-mailserver/backupmx/transport
relay_recipient_maps = hash:/tmp/docker-mailserver/backupmx/relay_recipients
maximal_queue_lifetime = 14d

Create a directory called backupmx and the following files relays, transport and relay_recipients.

relays should contain the domains you would like to queue & relay mail for. E.g.

domain1.com OK
domain2.com OK

transport should contain the final destination mail server to relay the queued email to. E.g.

domain1.com smtp:mail.domain1.com
domain2.com smtp:mx1.domain2.com

relay_recipients should contain a list of valid recipients that will be accepted, queued and relayed. E.g.

[email protected] OK
[email protected] OK

For the above to work, the following commands must be run inside the container:

cd /tmp/docker-mailserver/backupmx/
postmap relays
postmap transport
postmap relay_recipients
service postfix restart

I haven't had time to create a PR for this, but hopefully this helps someone.

@j-marz that is excellent. Some possibly stupid follow-up questions:

  1. Is this in a container with SMTP_ONLY, or what services should be running?
  2. How about DKIM keys and SPF? Separate DKIM keys for each container and both servers listed as valid senders in the SPF policy?
  3. Can/should the backup run postgrey, spamassassin and so on, or should it just accept everything?
1. Is this in a container with SMTP_ONLY, or what services should be running?

No, but it should work in SMTP_ONLY mode. All the backup MX config is related to postfix, so that's the minimum required service for this to work.

2. How about DKIM keys and SPF? Separate DKIM keys for each container and both servers listed as valid senders in the SPF policy?

SPF and DKIM aren't required as the backup MX is only queuing and relaying mail originally destined for your domains to your primary server. It's not acting as a backup outbound SMTP server, only inbound.

Having said that, Sender Rewriting Scheme (SRS) should be enabled to avoid any potential SPF issues (e.g. primary MX server thinks your backup MX is sending email on behalf of the original sender).

3. Can/should the backup run postgrey, spamassassin and so on, or should it just accept everything?

It's personal preference i guess, but I would recommend it. It will:

  1. Reduce load/anti-spam processing on the primary MX (once it's back online)
  2. Ensure spam is not hosted on the backup MX and made available to mail clients should you provide direct access to the backup MX server

This issue has stalled and is marked as frozen. Due to age and inactivity, I will close it off in 10 days.

EDIT: If there is something new here, feel free to post or re-open.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

domdorn picture domdorn  路  4Comments

cottonthread picture cottonthread  路  4Comments

dragonito picture dragonito  路  5Comments

landergate picture landergate  路  4Comments

strarsis picture strarsis  路  5Comments