On 9/26/06, Hector Santos <hsantos(_at_)santronics(_dot_)com> wrote:
Requirement #10 indicates:
10. The Protocol MUST NOT be required to be invoked if a
valid first party signature is found.
Suggestion:
Remove req #10, maybe add a new section that talks about the validation
value of 1st party signatures vs. 3rd party signatures.
Comments:
I don't get it this militant MUST NOT provision for a design decision. The
statement makes it sound like its already written in stone that software
developers WILL invoke the protocol and the author is trying to STOP it for
his own reasons.
If my software engineering experience gives me any insight into proper
designs, I will surely violate this requirement and I get the sense most
software implementators developing their own DKIM/SSP tools will realize how
this req #10 conflicts with their design needs.
It is unnecessary requirement that attempts to mandate a certain design
approach which has no proof of being the correct approach.
At best, it should be rephrase to maybe serve as a reminder that 1st party
validated signatures have a higher trust value and that by DEFAULT there
should be no conflict with the SSP policy.
But what is there is a conflict?
What does that mean? Should there be some tagging, notification, logging or
reporting by the receiver? Not saying this level of logic should be in the
requirements, but you have no control how the implementer will want to
approach this here.
In short, it is a implementator or software decision how they will approach
POLICY vs. SIGNATURE checking. I already see I will be ignoring this
requirement. I may check it always regardless of signed or no signed mail
simply because regardless of what the signature says, it must be consistent
with the policy. If the 1st party signature is valid but there is a
CONFLICT with the POLICY, then someone should be scratching their heads on
this.
Hector,
How about:
" 10. The Protocol MUST NOT be required to be invoked if a valid
first party signature *and* valid first party policy is found."
I believe that the _MUST NOT_ was put in so that implementers do not
continue to process even though a valid sig and policy are found and
this was the way to enforce it. Taking it out would open up a whole
new problem with "whose policy is most valid?" etc. My vote is for
leaving it in but changing the wording to address the issue you
brought up.
Regards,
Damon Sauer
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html