On Wed, 01 Mar 2006 23:16:59 -0600, Graham Toal wrote: >Although I know where David is coming from with this slightly >contentious comment, he's wrong. The argument is that most >senders will do their own back-off, and the hassle of setting >up a *good* backup MX server is so high that the benefit scarcely >justifies it. > >However where he is wrong is not in the senders who don't resend >(they're just broken anyway) or in the local clients who are >sending outgoing mail via your server (bad idea anyway), but in >clients who back off *for a long time* when they think you're >down. In other words a backup MX lets you recover more quickly >and more gracefully than not having one. > >Also critical is backup DNS. Let's assume we're looking at a >disaster here, a long-term (5 day?) outage rather than a failed UPS. > >If your DNS is on the same net as the mailer, its down too. Senders >soon get no result at all when they look you up, with the result that >mail *bounces* (unknown address) rather than requeues.
NO - it does not! Well, not unless the sending MTA is broken. To quote from Postfix documentation referring to not getting an MX record from DNS: " By default, the Postfix SMTP client defers delivery and tries again after some delay. This behavior is required by the SMTP standard." It also neglects the fact that lots of caching nameservers elsewhere will have a copy of the records that likely will not expire for quite sometime. I know mine are set to 3600 but I have had the sad experience of changing a domain from one dns hosting service to another and the old one had a TTL good for a week. > So set up >a backup DNS even if you don't have a backup MX. Also for a major >disaster, you probably don't want to continue secondarying your >main (locally hosted) zone file. You may even want to replace the >zone file on the backup MX host with a different one pointing to >different servers, so you can have a web presence and maybe even >some way of accessing your mail. In this case make sure you have >a pre-prepared primary zone file that you can run on your backup DNS >host, and have a protocol (i.e. a human protocol, phone no's and >a password) so you can tell the remote person that it is time to >switch from being a secondary DNS server to being a primary. > >You might even have your disaster site always running in preparation, >just with no DNS normally pointing to it. (I do, and I'm not >telling you the address ;-) ) > >In the event of a truly major disaster, with no telephones even, >leave explicit instructions with this remote person on what >circmstances they can kick in your backup DNS automatically, >eg there is a national emergency reported on TV and your site >has not been reachable for <X> days. > >Personally I do believe in Backup MX, as long as it does proper >relay checking. It's nice if it also does spam checking, but >not critical because your primary MX will still do that. However >if you do spam checking *and rejection* on your backup MX, you'll >significantly lower the load on the primary when it returns. > >Note that 5 days of pent-up mail arriving at once can kill a >machine even if it is normally up to the peak loads you get, >so you want a throttling control both on what the backup MX >forwards to you when you return, and what you accept from >other sources when you return. > > 5 days of pent up mail will NOT all arrive at once. Not all of the senders will try again simultaneously and it is also likely that each of them will also not even flush all of the delayed messages in one batch. Rate limiting in decent MTAs mitigates the problem. That said, having backup DNS located elsewhere is never harmful as long as you can get it updated as fast as your master in house. >Graham > > >From the land "down under": Australia. Do we look <umop apisdn> from up over? Do NOT CC me - I am subscribed to the list. Replies to the sender address will fail except from the list-server.
