ietf-asrg
[Top] [All Lists]

[Asrg] Email service assumptions and making system-wide changes

2006-01-16 12:42:47
Folks,

From a "pure" point of view, it is clear that unwanted email never even
entered the equation when the requirements for email were first drawn up by
those pioneering boffins. They tacitly assumed that everyone who used email
would be like them and not even consider doing anything other than to play
nice together.
...
Sadly, and all of us here know it, the real answer to spam requires us to
re-analyse the requirements for electronic messaging and consider processes
for authenticating identity and for handling unwanted mail and malicious
content. We could probably knock together a modern interoperability
specification which would accomodate these, and many other, factors but
what use would it be? We would then have to convince every user of mail to
upgrade their software, and if we manage that what cost would it have?


Both of these statements suffer from being both true and misleading.

On the truth of the historical "deficiency" of initial requirements there was pretty much nothing all that organized about the effort, anymore than the current web represents a coherent requirements statement, formulated during initial development.

The nature of Internet applications is that they go through incremental change over extended periods of time, both adapting to changes in the environments and adding mechanisms to support added functionality. Much like a social process...

Folks need to observe that the other global communications services lack the kinds of authentication mechanisms that are so readily claimed to be "essential" for today's proper Internet mail operation. That those other services have other features, which tend to mitigate the abuses that dominate Internet mail, is a matter of accident, rather than planning.

On the matter of a redesign, we have two problems:

1. It is not clear that it is needed. Those claiming the need for a redesign take it on faith that one is needed. This is akin to ready-shoot-aim. A re-design effort makes sense only after two pre-conditions are met:

   a) new requirements are formulated and gain community consensus, and

b) attempts are made to retrofit the existing service to satisfy those requirements, but the efforts fail.

So far, we have been astonishingly successful at adding capabilities to Internet mail, so I strongly suspect that the real problem is in formulating the requirements. This leads to the second, basic problem:

2. We do not know what changes will have long-term efficacy, without also causing long-term damage. We need to ensure continued use of email for current and future purposes. Email fits into a complex human communication fabric that is dominated by human and group dynamics, and therefore is frankly not well understood. Change any interesting system -- especially one that is poorly understood -- and the changes will always have unintended consequences, most of which will be undesirable. That argues strongly for taking small steps, and taking them very, very carefully.

The heuristic I use for considering system-wide responses to spam, and the like, is to ask whether the feature would be good to have, even if abuses were not a major problem. Hence, current abuses serve merely as motivators.

d/

ps. Some of the above is predictably redundant with <http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_8-4/anti-spam_efforts.html>.
--

Dave Crocker
Brandenburg InternetWorking
<http://bbiw.net>

_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg

<Prev in Thread] Current Thread [Next in Thread>