> As both of you know and understand, the email system was > built to be an any-to-any mesh. That's not just a design > goal. Folks have operated a lot of gateways, written a lot > of 8-to-7 code, and jumped through a lot of hoops to make > sure that the network effect of email was a great as > possible: that there were as few people left out of the > email system as possible. Funny thing is, that about 15 years ago, email was not an any-to-any mesh. I recall several occasions where I advised people to relay email off of aol.com or some other "centrally located" mail server to get around the 30 hop-count limit. One case that I remember was a professor in Peru who could not get email through to a colleage in Ukraine. In Peru, he used UUCP relaying to get to an ISP in Lima. In the Ukraine, I believe the only international connectivity was a 56k frame relay line into Poland. And people didn't understand IP network design as well in those days so unneccesarily high hop counts were common. But at the same time that the mesh was not truly any-to-any from the end-user perspective, it really was possible for any sender to send a message to any receiver without making prior arrangement. I am not suggesting that this be changed. What I am suggesting is that we revive the old principle of relaying which worked so well 15 years ago, but in an updated form where ONLY THE EMAIL RELAYING is done with prior arrangement. When SPAM grew by leaps and bounds, organizations like uu.net and aol.com turned off email relaying except for paying customers (prior arrangement). I would like to see these type of organizations extend that relaying to the core of the email mesh by making email peering agreements. In such a world, I would still be able to send a message to you anytime I like without phoning you first. I would not need to know the path that the email takes to get to you. You would not need to be registered in any directory service. However, my email would not go directly to your domain's mail server. It would go to the ISP or mail service operator with which I have prior agreement, using the submit protocol. If they have email peering with you, then they would send it directly to your domain's mail server. If not, they will likely have mail peering with some more central service, such as a larger ISP who will relay to you, an ISP consortium that operates a mail relay service with wide peering agreements, or some kind of commercial email relaying service. If you are upset about my email you can track it back to me via the relay headers which are now harder to forge. There are a number of ways this could be accomplished such as adding some kind of hash number to the header that is then retained for a few days in case of complaints. There are still ways that rogues can inject messages into the system. One is to arrange peering under false pretences. But this will not last long as too many complaints track back to the rogue. The other is to use the ISP's submit port but this requires signing up for an account. If an ISP's processes allow for a large number of account activations using forged credit cards, then they will appear to their mail peers as a rogue provider, and that will be incentive to keep some control over this. For instance rate limiting email for new customers kind of like the limited driving licences that some jurisdictions issue to under-21s. A lot of this is vague and generalized because it is only a concept at this point. But I hope that I have shown that a more structured email architecture with a relay hierarchy built into it could still provide much of the same capability that was intended by the original flat any-to-any mesh concept. I also expect that when this architecture is defined, whether it is done inside or outside the IETF, it will also provide some hooks/protocols to formally give reputation and filtering services a place in the architecture. As I said, a next generation and more robust email architecture will not eliminate SPAM. But it can reduce the volume of SPAM, and it can provide support so that mail receivers can implement more effective filtering of email. > Many of the efforts to thwart spam work against the design of > email, and, as a result they tend to be both deeply painful > and to have long term effects long after their effectiveness > at fighting spam is gone. I agree. And that is because SPAM was not known when the present architecture was designed and attempts to resolve the problem focus too narrowly on immediate problems, not on the larger architectural issues. When you travel through a modern city, you can tell which highrises are office buildings and which ones are apartment dwellings or hotels. That's because the architects design them differently. If you built only office buildings and then tried to convert them to dwellings, or vice versa, you would find it to be deeply painful and have long terms effects as well. The same thing happens when you try to convert 300 year-old buildings into any modern use. In London they often completely destroy and remove the building except for the shell of external walls. The new building then ties into the old walls in such a way that you would hardly know that the interior is entirel new construction unless you were there to watch the building process. I think that we can do this with email. Many of the shops on Regent Street have gone through this process if you are curious to see the results. > I, for one, am not ready to abandon the design goal. I think > email was the first "killer app" for the Internet, and it > remains one of the most powerful initial applications as > Internet applications are made available in new arenas. I think you are wrong about that. Many new Internet users now prefer IM over email even if IM's permission system seems onerous to you. And many use their mobile phone's SMS and ignore the Internet entirely. And a very large number of people prefer to use HTTP for their email services (Yahoo, Gmail). > RIM's success, for example, seems to me clearly due to > bringing any-to-any email to wireless users in ways others > did not. Others had done this i.e. Palm had such an email device and any Palm device could be used with a phone handset that supported IR to do email. The issue was one of packaging and marketing. And essentially, you are wrong. RIM did not bring Internet email to the masses. Instead it connected the masses to their corporate email systems while they were not at their desk. In a way, RIM highlights the point that I am trying to make. We need our email services to be mediated by an intermediary who can provide support services that we cannot. In an age where everyone has become the system administrator of their own network host, it is not feasible for the flat email architecture to work. That's why it has been chipped away into the bizarre collection of hacks that we now have. We need an architecture that recognizes the role of intermediaries to relay email, arrange email peering, cut off rogue sites, offer the use of filtering and recognition services, and so on. If we don't want to see the Internet reduced to applications-over-http, then we have to address the issue of architecture aging. Email is an area where it has been left too long, probably because everybody believes that the problem is SPAM and that since SPAM is a social problem a solution is outside the scope of the IETF. I believe that the problem is that email is no longer pervasive and Internet email is increasingly viewed as quaint, archaic and even BROKEN BEYOND REPAIR. We can fix this by refreshing the architecture, identifying what works well, and targeting the areas where new or revised protocols are needed. --Michael Dillon _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf