> 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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf