Re: [exim] Exim as a backup MX server

Startseite
Nachricht löschen
Nachricht beantworten
Autor: Mike Tubby
Datum:  
To: exim-users
Betreff: Re: [exim] Exim as a backup MX server
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/
>>>