Linda,
Using multiple MX at multiple locations is common for lager
implementations, big business, ISPs etc.
Even my personal domain (tubby.org) follows this design with two servers
at my company and a third at another site.
root@public:~# dig tubby.org mx
; <<>> DiG 9.11.5-P4-5.1-Debian <<>> tubby.org mx
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27874
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 4, ADDITIONAL: 14
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 203e26feb0425bb4dd398e8c5ebd0b5f1dafd0fc6f30d929 (good)
;; QUESTION SECTION:
;tubby.org. IN MX
;; ANSWER SECTION:
tubby.org. 86400 IN MX 10 relay1.thorcom.net.
tubby.org. 86400 IN MX 20 relay2.thorcom.net.
tubby.org. 86400 IN MX 30 relay3.thorcom.net.
;; AUTHORITY SECTION:
tubby.org. 86400 IN NS ns2.thorcom.net.
tubby.org. 86400 IN NS ns1.bt.net.
tubby.org. 86400 IN NS ns0.thorcom.net.
tubby.org. 86400 IN NS ns1.thorcom.net.
;; ADDITIONAL SECTION:
relay1.thorcom.net. 86400 IN A 195.171.43.32
relay2.thorcom.net. 86400 IN A 195.171.43.34
relay3.thorcom.net. 86400 IN A 82.68.212.66
ns0.thorcom.net. 86400 IN A 195.171.43.10
ns1.bt.net. 51069 IN A 217.32.105.91
ns1.thorcom.net. 86400 IN A 195.171.43.12
ns2.thorcom.net. 86400 IN A 82.68.212.66
relay1.thorcom.net. 86400 IN AAAA 2a00:2381:19c6::3200
relay2.thorcom.net. 86400 IN AAAA 2a00:2381:19c6::3400
relay3.thorcom.net. 86400 IN AAAA 2a02:8010:7010::6600
ns0.thorcom.net. 86400 IN AAAA 2a00:2381:19c6::100
ns1.thorcom.net. 86400 IN AAAA 2a00:2381:19c6::200
ns2.thorcom.net. 86400 IN AAAA 2a02:8010:7010::6600
;; Query time: 20 msec
;; SERVER: 195.171.43.12#53(195.171.43.12)
;; WHEN: Thu May 14 10:11:59 BST 2020
;; MSG SIZE rcvd: 501
root@public:~#
And this provides seamless failover without the need for HA clusters, etc.
This is pretty standard stuff - we've been doing this for 20+ years.
Mike
On 12/05/2020 18:53, Linda Pagillo via Exim-users wrote:
Hi everyone. As far as I can see, I never received a response about my last
question. However, I have a different question. I understand that a lot of
you think a backup MX is not a good idea and i understand why you feel that
way. My question is this... As a matter of best practices, if my primary,
in-house mail server which is hosting 500 domains/10,000 users was offline
for 24+ hours, would a backup MX not make sense in this scenario? Or if
this is not the best solution, what is the alternative? Thanks.
On Thu, Apr 9, 2020 at 3:19 PM Linda Pagillo <[email protected]> wrote:
Thank you all for this valuable information and advice. I appreciate it. I
have been thinking a lot about this over the past few days. Currently we
have Backup MX servers (Windows-based) in place for a few of our
Windows-based mail servers and they have been working quite well. We really
don't have much of a problem with spam because Message Sniffer,
SpamAssassin for Windows, and a few other AS/AV programs we are using are
doing a really great job in keeping spam to a minimum.
I was chatting with one of my colleagues about the advice that you guys
and the Postfix list members provided. A saw a few times during those posts
that MX backup servers are probably not a good idea in general and the
reasons all seem to be pointing to the spammer problem. Since this is the
case, I brought up the subject of anti-spam gateways since we use those as
well in our environment. In the event of a primary server outage, our
gateways spool the mail until the primary server becomes available again,
however, if the gateway had an outage or failure, we would be in the same
boat. The mail would be rejected/bounced. I'm aware that most commercial
gateways use a round-robin so that they can essentially be "always up", but
what about the smaller clients who run their own mail server from their
offices and cannot afford a good gateway solution? I think folks in that
situation would benefit from a backup MX. That is why we implement them for
a lot of our smaller clients. So far, so good. :)
With that being said, besides the issues with spammers which we feel we
have a good handle on, are there any other reasons why a backup MX is still
not a good idea?
Thanks again!
On Wed, Apr 8, 2020 at 6:48 AM Gedalya via Exim-users <[email protected]>
wrote:
On 4/8/20 4:33 AM, Andrew C Aitchison via Exim-users wrote:
Exim does recipient callouts and cutthrough delivery.
Are either of these useful for an MX backup ?
Callout caching can be potentially useful when the primary is down. Not a
complete solution of course.
--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
