> > 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
