----- Original Message -----
From: "Arvel Hathcock" <arvel(_at_)altn(_dot_)com>
To: <ietf-dkim(_at_)mipassoc(_dot_)org>
I'm not convinced there is sufficient installed base that
should preempt making DKIM work right, the "first time."
What sort of deployed base would you consider "sufficient"? Speaking for
myself alone I've had many tens of thousands of downloads (and I assume
installs) of my software since DK/DKIM support was added. For me, that's
significant and I'm nothing compared to some of the other vendors
interested
in this topic.
If that includes automatic installation of DKIM for each customers, then
that would be significant for your customer base.
But we have over 100,000 customers using WCSMTP and we also added SPF among
other things. This does not suggest we have 100,000 customers using SPF. We
are not automatically enabling SPF, adding DNS records, and so on for each
domain. That is left up to the sysop and it took awhile to convince people
to add SPF records.
But the industry has lots of packages and just because SendMail and ALTN
added DKIM support, does in in way indicate we have a sufficient install
base. We have MS EXCHANGE, EXIM and a slew of popular systems to deal with
as well.
If this is a concern now, then what you are implying we now have a big
compatibility problem and I will add to this concern, a major threat vector
because if we have to support the early adopters, exploiters will make sure
there are using "version 1" and stay away from a more secured system. Thats
a given and in my view, it defeats the purpose of this work.
Also, if early adopters were adventuous enough to add early support, I am
sure they will also be eager to make whatever changes need be to work with
the more secured official standard. You might be in a position to have to
worry or deal about backward compatibility, but I will venture that most
packages will not worry about a vastly un-supported, non-standard, unsecured
early rendition.
So early adopters, who well knew in advance that the value
of this work had no meaningful value with by-far a
non-compliant world, was incomplete and/or was plagued
with serious security issues, and only added this stuff for the
most part for marketing reasons,
I'd be careful in making assumptions like that. The last time I checked,
you weren't part of my decision making process (maybe you are for others
here). Speaking for myself, I added DK and DKIM for the same reason I
added
SPF et al - because I care about the future of email which is under threat
today (and my customers do too).
That's nice Arvel. Too bad you were sensitive to that statement. For
whatever reasons you added support, I won't be completely off base marketing
and promotion was part of your business strategy, but thats neither here or
there.
My only point is that if we are concern about backward compatibility now,
especially for what? at most two vendors?, then we its all a moot point.
Whats the point of a VERSION 2 when exploiters will just need to AVOID it?
It is the same problem with have today with SMTP. If we didn't have to deal
with SMTP backward compatibility and legacy issues, we wouldn't be here
today. By far, DKIM and/or DK deployment is not at the levels of standard
SMTP development where such issues is extremely important.
But we are not there with DKIM. We need a strong DKIM system out of the
gate. Not a weak DKIM system. We already have a weak system and added more
ambiguity to it isn't going help weak system get stronger.
Please note I don't think you need to change your software other than SSP
verification which I think is paramount for DKIM success. That is my main
concern with DKIM. Without SSP verification, there is little to no value in
signing and/or verify mail with loose interpretations. It is the same idea
with 2821.MAIL FROM. The SMTP specs has it written in STONE that Validation
of the MAIL FROM is not required, hence the #1 basis for the SMTP spoofing
problems and reason we are trying to find something to AUGMENT SMTP to
secure the transaction.
Finally, I think the WG charter, if its written to protect legacy early
adopters, then what it is basically saying that the current specification,
as written today, is the current BASE model. So maybe it is just a matter
of rewording it to say that the current BASE specification is the current
working model and moving away from this model if out of scope. However, if
legacy support is not important, then we are open to modify the BASE
specification. To suggest, the reason for not changing it because of a
perceived installed base, I think create a loophole into the security DKIM
is trying to offer. You don't need me to say this. SMTP is all the proof
you need to show what unverified information can bring about. It is too
late for SMTP. It is not too late for DKIM.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
ietf-dkim mailing list
http://dkim.org