Jeff Macdonald wrote:
On Tue, Mar 13, 2007 at 10:01:03AM -0700, J.D. Falk wrote:
On 2007-03-12 16:51, Hector Santos wrote:
I tend to side with the high probability that blindly signing MAIL in a
DKIM-BASE only manner (with no helper support, and I presume you are
just against SSP, not other kind of helpers, like DAC or some other yet
to be established reputation helper)
Hmm, not sure who you're arguing with here -- can't be me, I'm not
against SSP. Never have been. I just don't think it's a good idea to
continue telling the world that DKIM isn't ready.
I don't think the 'world' understands that DKIM is just a building
block.
I don't think the "world" understands that a building block does not
mean it is a public consumption technology without the helper blocks.
In fact, putting out a "building block" before it the required parts are
ready can do more harm than good.
The easiest issue to envision is that this can build a new legacy market
of "DKIM-BASE" systems that now the receiver has to deal with.
Lets say you finally (by you, I am speaking in general), finally realize
that DKIM-BASE by itself, although theoretically usable, it is not
practical to be used on its own. You realize you need something else
before you can turn it on.
What then? What are the rules for the receiver?
- Support DKIM-BASE only systems?
- Don't Support DKIM-BASE only systems?
This is exactly the same problem that the industry evolved to over the
past two decades and what has brought us together here. The problem is
dealing with the legacy market of old SMTP systems and how the bad guys
use this to gain entry into systems. If that wasn't the problem then we
would have FULL control of all anonymous transactions.
So by drinking your wine before its time, we risk wasting the potential
of a promising technology being forced into the market place before
essential elements are at the very least, settled for final development.
I'm not against DKIM-BASE. I'm against premature decisions that will
ruin it.
--
HLS
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html