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
_______________________________________________
swinog mailing list
[email protected]
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
