Re: Last Call: draft-klensin-rfc2821bis

[Keith Moore <[e-mail]>]

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
[e-mail]
https://www.ietf.org/mailman/listinfo/ietf