In my last, rather facetious, post I poked fun at John Levine for trying to prevent the ASRG from falling out, once again, over the definition of spam.
The catalyst for the current attempt was a post on the list that took issue with a paper I drew up (draft-irtf-asrg-criteria-00.html) a couple of years ago. At the time I attempted to define spam, but the whole review process became quickly tar-pitted in a debate in which despite the general agreement of the group the detailed differences were irreconcilable.
As one correspondent put it yesterday:
attempting to define "spam" is the very best way to ensure that a document is never finished.So I plumped for this:
Any Message or Messages of the class of Messages which the Recipient wishes to prevent from ever being presented with. It is implicit in this definition that it is unnecessary to ever transport Spam. Spam in this context can also be defined as Messages which it is never necessary to transport. It is not in the scope of this document to attempt to distinguish or justify any more detailed definition of this term. Nor is it in the scope of this document to analyse the reasons why the Recipient wishes not to be presented with the Message or Messages.
My intention was to encapsulate some of the critieria which the ASRG applies to the ideas with which it is presented, some well reasoned but flawed, many bordering on the insane, a very few containing ideas of real merit. I set out to highlight common pitfalls, and ensure that proposals have a net benefit. Some don't. Go figure! Some would be more expensive to operate than transporting and filtering the spam would be, others appear to benefit someone, but only by passing on the real work to an innocent 3rd party.
So it occurred to me yesterday that the document is also addressing the problem of defining spam.The problem being not that a definition cannot be drafted, rather that no definition is universally agreed, and unfortunately each reason for disagreeing with any definition that I've heard has some genuine merit.
So my approach is this, if we cannot agree an academic definition of the problem, but we agree that the problem exists because we can recognise it when we see it, then perhaps we should apply the same standard to any proposed solution.
If we can agree that it smells like a solution, we don't need to agree about what the problem actually is.
Of course the risk with that approach is that by avoiding defining the detail of the problem we're never going to arrive at a solution that successfully addresses the detail , and not just the big picture, because we don't agree what the detail is.
Then again, anything which improves the big picture is beneficial, hence the success of DKIM and SPF, so this may not be a real concern.
