Tuesday, June 30, 2009

Why we don't need a definition of spam

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.

Quote of the [specify period]

This [specify period] sees two quotes, both of them from John R. Levine erstwhile chairman of the ASRG of the IRTF.

The first is redolent of Lewis Caroll:

I think that as soon as you start quoting the dictionary, you've lost
the argument.
The second is priceless given the context:
No, we're not going to define spam
Well done John, you do a great job, keep it up.
Have *two* awards!!

Saturday, June 27, 2009

Blog Design

Well I've finally got round to creating my own skin for this blog. Its a blogger blog by the way.

It was the new head of creative at work, Dino, who showed us www.gridsystemgenerator.com which I used to lay the whole think out by doing little more than setting the class of the blogger "sections" to one of the grid's generated classes.

Tuesday, June 02, 2009

Marvin the martian

I was accused at Apachecon EU a year or two ago by Steve of relying on "architect tools" i.e. visio, powerpoint etc., instead of programmer tools, (like what? emacs!) For which he proposed a test framework here.

Well today I was discussing some of the finer points of separation of concerns with the guys and had cause to exhume (and re-label for php) a diagram I drew a couple of years ago for a former employer to illustrate the layering in our java systems to an interested, but unenlightened group of Oracle developers.

It would be a good test case for Steve's framework, because it has to be a particular shape, no matter what information it has to convey.

I could plead that I drew it first then recognised the shape, but I won't bother because life's too short.

Colleague Ed suggested it should be recorded for posterity so here is the original Java version...

I know nothing, I'm not a fortune teller, and you'd be insane to think that I am. This disclaimer was cribbed from an email footer I once received. It is so ridiculous I had to have it for myself.

Statements in this blog that are not purely historical are forward-looking statements including, without limitation, statements regarding my expectations, objectives, anticipations, plans, hopes, beliefs, intentions or strategies regarding the future. Factors that could cause actual results to differ materially from the forward looking statements include risks and uncertainties such as any unforeseen event or any unforeseen system failures, and other risks. It is important to note that actual outcomes could differ materially from those in such forward-looking statements.

Danny Angus Copyright © 2006-2013 (OMG that's seven years of this nonsense)