John Levine wrote:
Under the current setup, any domain that has an A record is presumed
to be a mail domain, and if it's not, there's no good way to advertise
that fact.
Getting rid of the AAAA fallback flips the default to be in line with
reality
Flipping any 20-year default for an global installed base should be pursued with
an assumption that it won't work, not that it will. This puts the burden of
making the case on those lobbying for the change. And it should make the
barrier for adoption be pretty high. In other words, the case needs to be
compelling, not merely appealing.
That is, the first step in a discussion like this is to recognize that the
change being discussed in a very big architectural deal, not just minor
algorithm tuning.
Your assertion about that the change would "flip[] the default to be in line
with reality" is a helpful example of seeking to satisfy that requirement, since
it highlights core assumptions and permits debating them.
For example, changing a default alters the strategic orientation of a service.
An example impact is that it can substantially alter the barrier to entry. So,
for example, the proposed change would require a very different degree of
broad-based DNS administrative capability than is often available, as Ned observed.
As other people have pointed out, a no-mail default is far more robust
than the current default, since a fair number of non-mail hosts turn
out to be running some sort of default SMTP server which will swallow
and lose mail.
Here, again, is a helpful assertion, since it is concrete and pragmatic. But is
it correct?
Is this a real and serious problem that needs correcting? I had not heard about
this as a pressing operational problem, but I also don't claim to be deeply
connected into the SMTP operations community. Others on this list are.
Or even if they aren't running an SMTP server, it can
take a week for the message to time out and bounce. It'd be much
better for such messages to fail immediately so the sender will notice
and can do something about it.
This is an entirely different change to the service model, and one with some
potentially very large impact, such as dramatically increasing the rate of
delivery failure. In effect, it could move email more towards instant
messaging, in being a model of instantaneous success/failure, rather than being
the infrastructure-persistence model we now have.
That might sound appealing and it might not. In all likelihood it does have a
market that would benefit from it.
One question is to impose this change on the entire email community, rather than
add it as a option.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net