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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf