> Web registration systems now tell users to whitelist mail from their > domains, which would be cool if it could be done automatically rather > than through manual intervention, and users are now accustomed to > searching for important mail that hasn’t arrived in their junk folders. Consider that example as a touchstone to the larger set of issues, here: Anti-abuse mechanisms (and many other 'fixes') for email tend to be added piecemeal and locally, rather than considered as end-to-end systems issues. On the average, the focus of concern is local operations, rather than user interaction and user experience. It's simpler and quicker to work that way, but it winds up turning email into a technical and functional Tower of Babel. This approach to dealing with email problems has been an issue for at least 40 years. Recipients complained to local operators who put some local hack in place to deal with the symptoms. Often the originator of the problem never hears about it. Email is by far the largest and most complex distributed system on the Internet. Having complex objects travel multiple hops along many independent administrations is a pain. So let's minimize hops and administrations and eliminate the cases that need to greater flexibility email gave with the more highly distributed administrative and functional design. We need to properly distinguish identities from identifiers and we need to properly distinguish among the many independent actors in the handling sequence and we need to distinguish trust from mistrust. Each of these distinctions can produce very different approaches for proposals. For example, trying to look for bad actors is fundamentally different from looking for good actors. So is evaluating an operator versus an author. What most folk have moved to is a model in which a user's identity, identifier and operational support are all tightly integrated and controlled by a single administration. For simple scenarios, that works well enough to cause people to treat more varied scenarios as 'problems' rather than 'userful requirements'. The current evolution of systems changes for anti-abuse are largely reactive -- the abusers set the agenda -- and largely turn email into a Procrustean bed: Only usage scenarios that are supported and protected cleanly are the easiest and most restrictive on users. Since that satisfies the vast majority of current use, the disenfranchisement of the much smaller minority of other, legitimate scenarios can be ignored, independent of the problems caused to those who are disenfranchised. Producing general, end-to-end changes that afford necessary protections and support the widest possible range of functionality is much more work than doing localized, incremental hacks. (Not that the localized, incremental hacks are cheap or quick either.) We need to stop thinking we can eliminate abuse. We need to start thinking in terms of end-to-end trust models that scale and support varied usage scenarios. We need to focus on being able to use trust of operators, more than on trust of authors. And mostly, we need to stop creating one hack to fill in the gaps for another hack. Or rather -- since the hacks often are the result of an emergency -- we need to stop thinking the hacks actually 'solve' problems rather than merely creating new ones. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net