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

[Dave Crocker <[e-mail]>]

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
[e-mail]
https://www1.ietf.org/mailman/listinfo/asrg