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 <lpadnet@???> 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 <exim-users@???>
>> 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/
>>>
