Tony Finch - Mail switch naming and addressing at Cambridge

dotatfanf wrote
on 5th December 2011 at 18:24
Previous Entry Share Next Entry

Mail switch naming and addressing at Cambridge


(Leave a comment)
From:gerald_duck
Date:2011-12-06 01:12 (UTC)
(Link)
If I understand you correctly, in summary the reason for the single MX record pointing to a hostname with multiple IPs is a combination of historical legacy and a desire for consistency with the way other services are presented?

Without the history or the submission/relay smtp and pop/imap, is there any advantage to the single MX pointing to hostname with multiple IPs over multiple equal-priority MXes pointing to hostnames each with a single IP?
(Reply) (Thread)
From:fanf
Date:2011-12-06 10:02 (UTC)
(Link)
As far as I can tell they are functionally identical. Single MX is simpler, I think.

Also the priority mechanism in MX and SRV records is pretty much useless. Per-service indirection is the key useful function.
(Reply) (Parent) (Thread)
From:gerald_duck
Date:2011-12-06 11:25 (UTC)
(Link)
My hunch is that caching resolvers would treat them differently, though I've not worked through exactly what the differences might be. (Probably less if all the MX hosts were in the same zone as the MX record itself than if some lived elsewhere.)

The main attraction of a lower-priority backup MX has always seemed to be faster recovery after an outage: when the primary MX has recovered after a failure, the backup can be asked to flush its queue rapidly where without the backup one has to wait for countless MTAs around the world to notice you're open for business and retransmit.

However, given my mail server is currently showing a 431-day uptime and with not much care and feeding is showing at least four-nines reliability, with hindsight the backup MX might have been more trouble than it was worth.
(Reply) (Parent) (Thread)
From:fanf
Date:2011-12-06 11:52 (UTC)
(Link)
Your hunch is wrong. Much more relevant is the way MTAs treat them, and indeed there's no consensus on the right semantics - see section 5 of RFC 5321.

The right way to deal with outages is to have diverse locations for the MXs. Unless you are playing tricks they have to have the same accept/reject criteria, to avoid problems with backscatter, which implies they have to be basically configured the same way. The traditional third-party backup MX is generally a bad idea and has been for ten years or more.
(Reply) (Parent) (Thread)

(Leave a comment)

Powered by LiveJournal.com