ietf-smtp
[Top] [All Lists]

Re: Defaulting to no mail

2008-03-30 20:54:00

Dave Crocker <dhc(_at_)dcrocker(_dot_)net> 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 <john(_at_)jlc(_dot_)net>