Revelation.
As is becoming painfully regular, Pete Resnick once again took a
position that I under-appreciated until later. During the jabber
session, Pete suggested that we should develop a single mechanism that
can work for validating all of the headers. During the session, I
focused on the "all".
The "all" could mean that we have insufficient focus. It often means
that we are dealing with the complexity of a topic by failing to
understand and deal with any portion of it carefully enough. This is a
common error in developing solutions for complex problems, but it is
deadly to the results, because it produces "solutions" that are
complex or ineffective.
What I later realized was that Pete's comment was really about the
idea of a small, clean and generic mechanism. Even if it doesn't prove
all that successful for one requirement, it is likely to be useful for
another. This kind of robustness can be particularly important when
tackling a difficult problem and have no track record of success. That
is, in an area where we are all still learning how to attack the topic
effectively.
When dealing with a complex problem, in a complex system, it is just
too darned easy to create a complex, baroque and ultimately useless
solution. The way to fight against that outcome is to look for small,
incremental steps and make sure we understand them.
It think that the paradigm we should be taking for dealing with spam
is to distinguish between:
Components -- small units of functionality
Mechanism -- Collections of components that form a whole capability
for doing something useful in the problem space.
Policy -- Rules for determining use of the mechanism
Service -- Mechanisms and policies combined to achieve something
useful in solving the problem.
This sounds pretty cumbersome, but the dangers of attacking all these
at once are confusion in the design and, ultimately, a solution that
don't get used or don't work. By separating them, we must discuss and
understand them _separately_. We must develop consensus on each,
without the distractions of the others.
Thus we build a total service using pieces that we understand and
agree on, rather than essentially having to wave our hand over a whole
service proposal and do a single thumbs-up or thumbs-down popularity
contest.
For example, if we are going to do a DNS-based registration scheme,
then we should define it generically, so itt can be used for different
things. Then we should define a particular use for it. This is what
Pete is suggesting.
I agree sufficiently to be submitting a revised version of my own
proposal that separates the underlying components from its application
into a mechanism for MTA.Helo checking. (The policy of what to do with
that checking becomes yet-another discussion.)
We can then discuss the mechanics and implications of the underlying
components, to make sure their benefits and problems are explicit.
The new draft of my proposal contains examples of this. I'll post it
shortly.
d/
--
Dave Crocker <mailto:dcrocker(_at_)brandenburg(_dot_)com>
Brandenburg InternetWorking <http://www.brandenburg.com>
Sunnyvale, CA USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>