----- Original Message -----
From: "Dave Crocker" <dhc(_at_)dcrocker(_dot_)net>
To: <ietf-dkim(_at_)mipassoc(_dot_)org>
Hence, the signing practices requirement would only exist
for unsigned messages.
This is already covered in the public SendMail DKIM source code
(dkim-milter-0.5.1) which has current support only for:
Signature Optional (o=~ DKIM_POLICY_SIGNSOME)
Signature Expected (o=- DKIM_POLICY_REQUIRED)
Signature Not Expected (o=. DKIM_POLICY_NEVER)
The 3rd party restrictive policy DKIM_POLICY_AUTHORITY (o=!) as defined in
SSP-01 is not support. There is no action for it and the philosophy
continues.
This is what's needs to be addressed.
Are we really dealing with a backward compatibility issue here more than
anything else?
In my opinion, I am taking both a precautionary and proactionary approach to
all this. From a precautionary standpoint, I think it is the burden on
those who don't want 3PS restrictions to show why there are not threats when
open-ended 3PS signings are done. From a proactionary standpoint, I believe
I have shown via the DSAP draft a low cost effective solution to address
some of the most common sense DKIM-BASE protocol inconsistency issues.
I really don't know what else, how else can be done. I concur that when a
1st party signature is validated, that the "threats" level is reduced when
3rd party signatures. But we have no evidence whatsoever that this removes
potential exploits. The solution is to provide the OPTION to those who do
not want expect it. We can't not eliminate all the risk, but we can
optimize risk with a lost cost effective solution.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html