----- Original Message -----
From: "Wietse Venema" <wietse(_at_)porcupine(_dot_)org>
To: <ietf-dkim(_at_)mipassoc(_dot_)org>
At this stage we are talking about a minimum protocol. You are free
to implement SSP lookups that exceed the minimum protocol. However,
I would oppose recommending SSP lookup in a particularly important
scenario where now such lookup "must not be required".
Wietse,
Yes, I think we established implementators lead independent lives and in the
end we will provide the local policy options for administrators to use. :-)
But for that reason, I would still like to extract why one implementator
such as your astute person as yourself, opposes it from an engineering
standpoint?
Is it because the valid 1st party signature is well established as
sufficient to create high reliability in the result without needing a policy
confirmation? An optimization consideration?
Maybe we are just talking about adding an informative note?
[INFORMATIVE NOTE: Valid 1st party signatures satisfies the
DKIM-BASE requirements for an authenticated and authorized
message from the domain.]
Don't get me wrong, I understood the document. But the design now seems to
be predetermine as it is stated. When a modeler sees the finished minimal
requirements document, one minimal model can be outlined as:
if first party signature found then
if successful Validataton() then
return CLASSIFY_AS_PASS
if failed Policy() then
return CLASSIFY_AS_FAIL
if successful Validataton() then
return CLASSIFY_AS_PASS
return CLASSIFY_AS_FAIL
Do you agree with such a model fits the minimal requirements?
The problem?
It now goes back to the debate of "Exclusivity" or the present of a 3rd
party signature valid or not is allowed. I believe the provisional
requirement #5 (delegation) attempts to address this minimal optional need.
In such as case, the minimal model can be:
if failed Policy() then
return CLASSIFY_AS_FAIL
if successful Validataton() then
return CLASSIFY_AS_PASS
return CLASSIFY_AS_FAIL
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html