Dave Crocker wrote: > ... > This does not mean we should do nothing. Nor does it mean > that there should be no technical interventions. > > It *does* mean that we need to treat this as an incremental > systems change process. > > It *does* mean that we will need multiple types of changes, > not just one cure-all. > > It *does* mean that we should approach those changes very > cautiously, even experimentally.
I am with you up to here, with the comment that any modification to production services need to be approached incrementally, but new services can be radical as long as they are deployed in parallel. > > The place to start is with a modest, objective, > operationalizable definition of the thing we all agree needs > to be handled differently. We agree with the wording of this, but it looks like at this point we disagree about what should be changed. > So, let's not worry about the > all-encompassing definition of spam. > ... > In other words, the detail of the content > is irrelevant to me. It does not even need to be > soliciting.) > I agree completely with these points. At this point your thoughts appear to drop into the trap of trying to engineer a solution to the social problem, even though earlier you noted we don't know how to engineer solutions to complex social problems. > ... > For that matter, the number of addressees per message might > not be a useful attribute, as marketeers have become good at > tailoring content to individual recipients, thereby producing > one addressee per message. So "bulk" requires considering > behavior across multiple postings. Oh boy... And if they spread the individual messages across multiple relays, using multiple accounts, there is no chance to correlate postings. This shows that even by your own account of ignoring content, there is no technical way to stop even the simple case of unsolicited bulk mail. > > And that's why this is a research topic, no matter how > essential it is to to engineer some mechanisms sooner rather > than latter. Let's do the engineering and deployment, and > let's do it quickly, but let's appreciate that it is really research. We agree that engineering automated solutions to social problems is a research topic, and the IETF is not the place to do that work. Engineering tools that are useful to existing social management agencies is not research and something that the IETF can take on. Deployment of experimental technologies is necessary, and something that should begin ASAP. IMHO where we need to start is agreeing that the greater goal is reduction of spam, that we don't know of any way to automate the identification of billions of independent individual value decisions, that trying to do so at this point is a waste of time, and that existing social management agencies need tools to deal with the issue. I would like to see the outcome of a bof be identification of an approach to globally verifiable authenticated email. I have no doubt there will be many gaps in our current tool set (starting with a deployable PKI), and a truck load of operational guidelines to develop. This is something tangible we can do without extended research. If the research community comes up with a breakthrough and figures out another way to kill off spammers, authenticated email will still be useful as a replacement for the current legal requirements for fax. Tony
