How to run backup mx ?
- Thread starter abnoba
- Start date
You need to pick any MTA of your preference and configure it as a secondary MX. We prefer Exim, because it's what we are best at. The secondary MTA needs to be aware about the domains it is going to act as a fallback server for. It should also be known to what IP the secondary mailserver should send its e-mail to.
Perhaps there are some more pointers or partially made howto's on how to accomplish this posted here. But you'll have to use the search function.
Perhaps there are some more pointers or partially made howto's on how to accomplish this posted here. But you'll have to use the search function.
tillo
Verified User
It's also very important to constantly synchronize the entire list of active mailboxes, to limit bounceback spam. Synchronizing the list of local domains is not enough anymore.
abnoba
New member
- Joined
- May 20, 2009
- Messages
- 4
able to spread bys me more information about the bounceback spam ?
tillo
Verified User
soulshepard
Verified User
- Joined
- Feb 7, 2008
- Messages
- 120
tillo,
do you do this for your servers?
care to share the idea's?
as i look in this for this first time, (to sync the lists)
would that be the syncing of the /etc/virtual/domains, /etc/virtual/domains/aliases and passwd? with the whitelist* and blacklist* ?
thanks soul.
tillo
Verified User
I never run a backup MX because I found them absolutely useless, unless:
- you run a set of MX with the same priority
- your MX is within a broken network, or in a network with a bad route with the rest of the world
The first case is the same as doing load balancing, but you will have to find an MTA that manages very well race conditions when using the same DB, which I never did, so don't do it unless you can write your own MTA or can pay for a very advanced one.
The second... well, set ASSP or another SMTP reverse proxy as your primary MX in a better network, pointing to your original MX. That's what I did recently, for an office network periodicly under DDoS attack.
If you are concerned about the fact that the primary MX can be down and the messages won't reach the destination... the SMTP protocol itself asks the sender to retry for a very long time, so don't be.
- you run a set of MX with the same priority
- your MX is within a broken network, or in a network with a bad route with the rest of the world
The first case is the same as doing load balancing, but you will have to find an MTA that manages very well race conditions when using the same DB, which I never did, so don't do it unless you can write your own MTA or can pay for a very advanced one.
The second... well, set ASSP or another SMTP reverse proxy as your primary MX in a better network, pointing to your original MX. That's what I did recently, for an office network periodicly under DDoS attack.
If you are concerned about the fact that the primary MX can be down and the messages won't reach the destination... the SMTP protocol itself asks the sender to retry for a very long time, so don't be.