That nicely summarizes the problem I have with the fixation
of *requiring* a tie-in to the origination domain.
I've seen no evidence that such a fixation actually exists on this list so
you shouldn't have anything to worry with on this point.
It's not that the tie-in does not provide incremental benefit.
It is that it is incremental, rather than fundamental.
This is precisely the debate - whether the benefit of DKIM SSP is
incremental or fundamental. It largely depends on what your view is of the
problem DKIM is attempting to address. If your view of the problem is that
the world lacks a signature based filter input then DKIM base is fundamental
while DKIM SSP is incremental. If your view of the problem is that email is
plagued by unauthorized domain use in a RFC2822 identity header then DKIM
SSP is fundamental and DKIM base is merely an arbitrarily designed servant
of DKIM SSP.
I think that this group isn't going to go any further until it decides what
the problem is. I now fully embrace the wisdom of the "threat analysis"
doctrine.
Today we have no confirmable domain name identity to assess.
With the DKIM basic mechanism, we do. That's not a small
improvement in the world.
One side continually makes this point as if the other hadn't already agreed
to it a thousand times over. Once more, yes, DKIM base is useful. Yes, DKIM
base provides value. Yes, DKIM base is an improvement, etc, etc, so on, and
so on, ad nausium! BOTH sides in the SSP debate will take FULL advantage of
any "improvement in the world" that DKIM base can provide. It's just that
one side isn't content to stop there. One side wants _ALL OF DKIM_ - not
merely the mechanistic "how do I make a signature" half of it. One side
wants DKIM to play a role not only when a signature is found, but most
especially and importantly when one IS NOT found. Clearly, the authors
envisioned this as it's fully 1/2 of the DKIM specifications as we have them
today. Clearly, the parent technologies from whence DKIM is supposedly the
cross-product envisioned it as both have required SSP provisions. Beyond
doubt, the draft charter language assumes it.
The "threat analysis" will clear all this up. By defining the problem that
DKIM is meant to address we will also be defining the relative import of
DKIM's SSP provisions. So, you've seen our answers. What are the answers
to Russ' questions from the "signature-only" folks?
--
Arvel
_______________________________________________
ietf-dkim mailing list
http://dkim.org