Murray,
I just wanted to touch base on something I missed in your last post. A
statement you made that now totally contradicts mthe model I thought
you were talking about. Maybe this discussion can help mold a better
understanding for DKIM integrators.
EXECUTE will now have to create the proper function prototype stack
with the variable list parameters in order to satisfy specific
ASSESSOR APIs with different functional prototypes.
No. Each assessor will feed a message to the DKIM API and get
back the result and "d=".
I thought I understood your model. I am not so sure now with the above
statement which made be read more carefully what the ERRATA is saying
and I simply can not comprehend it.
This somewhat conflicts with the layered DKIM model I had in mind
which was DKIM WG chartered direction of splitting DKIM into a base
spec to be integrated with higher layer policy, reputation and other
"assessment" technology as there invented, materialized and applies
to DKIM-BASE.
I thought "Assessors" were things like policy and reputations
protocols and others yet to be invented, that assess the verification
result of DKIM signature.
The thought the only required feed for DKIM-BASE was the 5322 payload:
5322 -> DKIM-BASE -> status, d= -> DKIM-ASSESSOR -> PASS/FAIL
and the ERRATA discussions was about what DKIM verification result and
additional data is needed for the next Assessor layer which ultimately
provided final pass/fail (accept/reject) result.
Your statement seems to describe something different.
Does the Assessors do verification, policy, reputation and anything
else with a final result of status and the d= tag?
If so, I was completely off base on what I thought this ERRATA was
above. I can see better why you described your API as so, but IMV this
is a prime example why should keep the API metaphor out of the errata
and get this better cleared up. It appears your idea of an API
perfectly shows where there would be conflicts with a more straight
forward understanding of DKIM layered framework.
SMTP feeds DKIM-BASE, the result and additional data feeds a
higher layer, which I thought were "assessors" but apparently
not.
Assessor is really not the best term for this because it seems to
applies it does everything, including the verification process and I
guess it does, right?
Sorry I didn't understand your API, but it is very odd. This ERRATA is
really complex and incomprehensible and in my opinion, it does seem to
somewhere alter implementations API libraries I explored, like the
ALT-N DKIM API library. This API used the basic idea of a three layer
approach:
SMTP FEED (5322 Message)
--> DKIM-BASE verification
--> Optional DKIM-POLICY Evaluation Hook (one only)
I thought we were talking a simple change to better support future
verification result analyzers, evaluators, policy, reputation, etc:
SMTP FEED (5322 Message)
--> DKIM-BASE verification
--> Optional DKIM-ASSESSOR Hooks (multiple possible)
Whatever.
--
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html