SM wrote:
We could look at the question by asking whether the fallback MX
behavior should be an operational decision. But then we would be
treating IPv4 and IPv6 differently.
IPv4 and IPv6 really are different, in a number of ways that affect both
applications and operations. e.g. Scoped addressing, the assumption
that a network has multiple prefixes and a host has multiple addresses
and that applications need to cope with this. It should not be taken as
an axiom that IPv4 and IPv6 should be treated the same.
Also, the Internet is very different now than the ARPAnet was when it
adopted IPv4, and the IPv6 Internet will be different still. In the
early days of IPv4 nearly every host was a timesharing machine
supporting several users, hosts were big and expensive and needed
special maintenance, and so forth. It was natural in that world to
think in terms of "logging in" to a host, and it was natural in that
world to think of a host in terms of supporting a user community that
might want to exchange mail.
In today's PC world these assumptions are much less valid, and they are
less valid still in an IPv6 world where it becomes feasible to assign an
address to every device that might want to be monitored or controlled -
every power meter, parking meter, traffic signal, street lamp, light
switch, security camera, etc. The last thing you want to assume in an
IPv6 world is that every host is capable of receiving mail and doing
something useful with it. Nor do you want to burden DNS admins with
setting up a dummy MX record for every IPv6 host. For that reason, in
the IPv6 world, the default behavior when there's no MX record should be
to assume that the host does not accept mail.
(of course, this begs the question of what to do about other services
that don't have their own DNS records and don't use SRV. But that's not
a topic for rfc2821bis.)
Keith
_______________________________________________
IETF mailing list
IETF(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf