The DNS is a conspicuous success.
Exactly my point. The domain naming system is a
conspicuous success. Fiddling with the DNS is not
going to make that success rub off on SMTP et al.
The problem with the mail system has nothing to do with the protocol
performance. The problems are caused by PEOPLE.
SMTP, POP, IMAP and SUBMIT just don't fit the use cases
that these PEOPLE require. That means that the problems
with the protocols are caused by inadequate engineering.
In particular the protocols do not anticipate what is necessary to
deal with a population of a billion users. That is a problem but not
an operational problem, the problem is architectural.
Agreed. The problem is with the *EMAIL* architecture. In the
beginning there was apparently only a very simple architectural
idea that involved leveraging IP networks to transfer the files
which were sitting in mail server spool directories. SMTP did
that job well but, even with band-aids applied, does not suit
the email architectural needs of the present day.
a different directory scheme (Hello John) or network architecture
(Hello David) won't help unless the new architecture takes account
of the real issue - people.
Agreed. A new email architecture must take into account the current
use-cases which involve large numbers of people, multiple languages
with no lingua-franca, primarily non-technical users, financially
motivated criminal gangs attempting to leverage weaknesses in the
architecture, and the knowledge that hierarchy tames complexity.
Fortunately it is possible to retrofit infrastructure for dealing
with people into the legacy systems which turn out to be rather
better than the councils of despair would imply.
I don't disagree that band-aids can make things better for
a while. Or that huge efforts to create new band-aids are
better than tossing the whole thing out. But I also believe
that the band-aids are not a long term solution and that
a series of band-aids is an extremely expensive way to reach
a satisfactory email architecture.
As far as I can see there is no good reason why the IETF
shouldn't undertake work to define a new email architecture
and then define the protocols required to create that new
email architecture.
The early SMTP system held together because there was
ACCOUNTABILITY. There were few limits on what you could do but if
you messed up there were consequences.
Yes, there was accountability, but it was not in the email
architecture and it was wholly unconnected to the email
protocols and services. It turns out that a reliable email
system needs accountability imbedded in it, not tacked on
as an afterthought. Here is where the lessons of hierarchy
taming complexity can be applied. Instead of a flat system
where millions of hosts talk SMTP to random other hosts,
we could have an architecture where hosts play a defined
role in a hierarchy of roles. There would be protocols
use for hosts to communicate with peers at the same level
of the hierarchy and others for end-hosts to communicate
up the hierarchy. And a CHAIN OF TRUST to bind them all
together in a single cooperative architecture.
Mail servers will still exchange messages with known and
trusted peers. A new mail server operator will have to
arrange a trusted peer relationship with one or more
existing operators at some point in the hierarchy. A mail
user will have a trusted relationship with a local server
operator. Many messages will have to be relayed because
there is no one-level trust relationship between sender
and recipient. Mail will flow along the chain of trust.
And everybody will be motivated to keep those chains
intact because when they break, messages stop flowing.
Knowing who sent an email with a high degree of confidence is the
first step towards knowing whether they can be held accountable.
Even knowing the last email hop with a high degree of
confidence will allow accountability. In order to know
this with a high degree of confidence, the organizations
must have a relationship, probably contractual, and must
be in contact. The fact that a chain-of-trust email architecture
encourages organizations to maintain functional contacts
is a very good thing from an operational point of view.
On the contrary, I get calls from a new VC-backed startup touting
exactly that type of scheme roughly every three months.
VC-backed schemes cannot solve such a large problem which
requires many organizations to participate in building a
chain of trust.
--Michael Dillon
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf