ietf-smtp
[Top] [All Lists]

Re: Defaulting to no mail

2008-03-30 08:37:12



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