Steve,
I agree, but I think the efforts has been shown there are unrestricted 3rd
party signing concerns and there are technical sound recommendations to help
control it.
And yet, these concerns has been just pushed aside and labeled as
unwarranted, unimaginable guess work when in fact, the concerns are
technical sound, illustrated real potential issues with a very high
potential to exist.
The simplest case is when the DKIM switch is turned on (deployed).
Receivers will continue to receive as they do now, indirect attacks with
non-signed mail. It is not guess work to envision this to be a problem
when the domain expects his mail to be signed in the new DKIM world.
And there are other obvious deployment potentials that have been expressed
which are being pushed as aside as "guess work as the only counter argument.
If we don't want to continue this line of thinking, then at the very least
it should be the burden of those who don't want it to show that unrestricted
3rd party signatures are indeed safe and would be desirable and acceptable
by 1st party domains in all cases.
Just implying to "trust us. unrestricted 3rd party signing engines are ok
for everyone," is guess work and in my opinion, surely not sound
engineering.
So yes, I agree, I prefer this would all be completely and decided by now,
but to have all the technical work and expressed concerns labeled as
questionable guess work, well, frankly, I find that professionally offensive
and rude.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
----- Original Message -----
From: "Stephen Farrell" <stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie>
To: "Hector Santos" <hsantos(_at_)santronics(_dot_)com>
Hector,
Independent of DKIM, there's a problem with your argument.
You seem to be requiring those on the other side of the argument
to demonstrate the absence of vulnerabilities, and that can never
be done. One can argue (endlessly;-) but can never demonstrate the
total absence of badness.
But, we've been here before, so we don't need to go around all
this yet again,
Stephen.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html