Hector,
It'd make it easier for the WG to make a decision (whether positive
or negative) if you could suggest text for such a new section.
Thanks,
S.
PS: A "MUST NOT be required" is the same as a MAY. Nothing militant
there at all IMO.
Hector Santos 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 Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html