--On Friday, December 17, 2010 7:59 AM +0100 Patrik Fältström
<paf(_at_)Cisco(_dot_)COM> wrote:
3a. Let's say I have these DNS records:
baz.example MX 10 mail1.baz.example
baz.example MX 20 mail2.baz.example
mail1.baz.example A 1.2.3.4
mail1.baz.example AAAA a:b::c:d
mail2.baz.example A 2.3.4.5
mail2.baz.example AAAA b:c::d:e
...
I would say 3a is the only safe way of setting up DNS, but I
am also a person that do not like multiple MX records as I
think non-deliverable mail should be queued on the sender side.
Well, 3c would also work and has the advantage of making the
intent of the operator of the delivery system perfectly clear,
perhaps based on that operation's knowledge of her configuration.
3c would look like the following or any of the obvious
variations, i.e., one MX record, one target, no same-preference
randomness.
baz.example. MX 10 mail1a.baz.example.
baz.example. MX 15 mail1b.baz.example.
baz.example. MX 20 mail2a.baz.example.
baz.example. MX 25 mail2b.baz.example.
mail1b.baz.example. A 1.2.3.4
mail1a.baz.example. AAAA a:b::c:d
mail2a.baz.example. A 2.3.4.5
mail2b.baz.example. AAAA b:c::d:e
Because of this, I think one should strongly recommend 3a as
"the correct setup", possibly without the secondary MX.
Well, we are in a world in which the minimum requeueing time at
a client is widely ignored, often to retry for a day or less and
then reject/bounce. If I'm the operator of a delivery server
and I know that my server, network, and/or connection are not
super-robust, multihomed, etc., it actually makes perfect sense
for me to set up a secondary MX that will accept the mail and
hold it as long as _I_ think necessary to overcome potential
outages (or to deliver it via some means that might not involve
SMTP-over-TCP). Indeed, the same principle should apply in
this that applies to the rest of the network and we should treat
mechanisms that provide robustness through redundancy across the
network to be at least a reasonable tradeoff with, if not
superior to, super-hardened internally-redundant equipment and
networks. I suggest that is especially true in a world in which
we have carefully and systematically made multihoming a small
network a PITA at best.
...
john