On 2012-05-24 16:55 , Benoit Panizzon wrote:
Heya Swinog
We have business customers with an own mailservers asking us to provide a backup MX for their mailserver. Usualy we deny such request, because such a backup MX would bounce all spam which cannot be relayed, and anyway, the sending server usualy queues the email usualy about the same amount of time a backup mx would queue it. So we see not advantage, but a big disatvantage.
You should not configure it as a backup, it should just be a part of the primary, all configured the same, all doing full validation, virus checking etc. You do not have any bounces then as it is fully ready to accept that message, which then can be stored on a backend (disk full is then the only issue you could run into if the storage is a separate thing)
This does require that your customers can push their config to you and that your customers reveal their userbase (then again sniff can do so much more)
eg, have 3 front-end boxes (which might be loadbalanced) at different network/physical locations: hostA hostB hostC
then you configure:
$ORIGIN example.com. @ MX 10 mx1 MX 20 mx2 MX 30 mx3
mx1 A h.o.s.tA AAAA h::os:tA A h.o.s.tB AAAA h::os:tB
mx2 A h.o.s.tC AAAA h::os:tC A h.o.s.tA AAAA h::os:tA
mx3 A h.o.s.tB AAAA h::os:tB A h.o.s.tC AAAA h::os:tC
This way, randomly A or B is picked, if they soft-fail (thus not a 500 reject or so), but a connection failure/timeout etc, then most SMTP clients will fail over to the next MX (postfix for instance tries the next address and then all of them) and retry there till they receive a fatal error from the smtp-frontend.
The way that the hosts are ordered above gives full chance for things to break into multiple locations without it hurting if one randomly breaks.
Btw, dovecot & dsync is awesome for these kind of setups ;)
Greets, Jeroen