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.
It might be entertaining to debate about the nuance of meaning in "incremental"
and how it does not mean "unimportant". But let's not go there.
Rather, you have identified two, very different, problems that could need to be
solved. From what I can tell, there is pretty clear consensus that we indeed
need to deal with both.
But they are different problems. To the extent that DKIM can respond to both,
that's great. To the extent that responding to one prevents responding to the
other, that is NOT fine... unless responding to that other is not a goal.
My view of taking a sequenced approach is that we can service both problems,
albeit in sequence.
Providing an essential tool to filtering engines is a natural enhancement to an
existing capability. We know how to use this enhancement.
The problem of rfc2822.From spoofing is involves some complex human issues and
we do not have much track record solving them. The nature of the human factors
complexity have been discussed repeatedly. They difficulties should serve to
make us cautious about the benefits that a straightforward verification of the
rfc2822.From field will provide. The issue is not that there will be no
benefit, but that it might well be far less than we would wish, since the
nature
of the problem involves tricking humans. It is not clear how much less they
will be tricked by having the From domain get validated.
That does not mean we should not pursue this, but it makes things much riskier
if we focus on this goal first and foremost.
In other words, delaying issuance of the base specification so that we can
issue
it with the SSP document makes the filtering engine benefit depend upon the
anti-spoofing benefit.
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.
You are probably right.
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
But apparently it is not valuable enough to issue on its own?
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
The debate is not whether to provide "all of dkim" it is whether to require
that
it all be provided at the same time, or whether to provide the base first.
d/
---
Dave Crocker
Brandenburg InternetWorking
+1.408.246.8253
dcrocker a t ...
WE'VE MOVED to: www.bbiw.net
_______________________________________________
ietf-dkim mailing list
http://dkim.org