Dave Crocker <[EMAIL PROTECTED]> wrote: > 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 > > 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.
That's overstating the case, Dave. That there are today some clue-challenged DNS administrators is unfortunate, but the requisite level of clue really isn't that great; and the deficiency is undobtedly correlated with the minuscule need to advertise MX records. The larger ISPs already have web-based programs to maintain DNS records, and the programming to accept a check-box to generate a MX record for "running an email server" is certainly no more than an hour's work. I doubt you'll find _any_ registrar two years from now that doesn't offer that. >> 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? That's a different question, Dave. > 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. Indeed. We do quite a bit of user support for email at JLC.net. The short of it is, we try to find evidence in our email logs. That tells us where it went, or if it's still pending. Users, indeed, do mostly hit the "reply" button, but typos are _not_ rare. I won't call it a "pressing operational problem" today; but if spam volume keeps doubling, I make no promises I won't call it "pressing" within five years. >> 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. Again, you overstate the case. The increased _rate_ is unlikely to be "dramatic", and the ease of debugging would be _significantly_ greater without a long delay between hitting the "send" button and getting an error message. The fact is, the substanital majority of email sent by our users is to domains that will act on it in a few seconds. > 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. Sounds like something the users would like... > One question is to impose this change on the entire email community, > rather than add it as a option. No doubt that would bother you, though I'm not sure why. A substantial majority of the users I know would prefer it, and don't like being faced with too many options. ==== Let me ask, seriously, doesn't this sound like a better design? -- John Leslie <[EMAIL PROTECTED]>
