On May 18, 7:03pm, "Eric A. Hall" <ehall@ehsco.com> wrote:
For a long time since then, backup MXs have been seen as a kind of value-added courtesy service; they serve no really useful purpose
well, they're handy for centralizing filters against multiple domains, if you're willing to put your various primaries at the mercy of the filter service, and if the filter knows your valid recipients. what with ldap-smart servers and fancy routing, this isn't even hard anymore.
But this only means that the primary, and only, MX should be the filter service MX; in turn, it would deliver sanitized email to its real destination. An amusing twist on this is then that the final recipients could be listed as less preferred MXs -- if the filter service MX is down, one would accept all mail unfiltered, rather than wait until the primary, filter service, MX is back on line. While this would be a legitimate use of less preferred MXs, even if it practically turns the original rationale upside down, I would generally suggest to opt for uncompromising reliablity on a filter service MX, and fall back on DNS changes for disaster recovery, rather than receive tons of junk unfiltered mail whenever there's a glitch on the primary, filter server, MX. But your point is technically correct. Only goes to show how much mileage there is to be had from an otherwise very simple protocol extension.-) Best, -- Per