Murry,
How else can this be said?
Think SMTP and think how a SMTP system will provide the process
environment variables to either embedded filtering system or external
SMTP filtering system.
Most SMTP servers with an "ACL" or similar concept, including SendMail
with its mfilters, our ours with WCX hooks, etc do not limit the
external interface prototyping to just one or two variables. The
process variables are fixed:
2821 (envelope)
2822 (payload)
How these are provided to the "filters" differ from SMTP to SMTP
system, by in general, both are available.
Here's the problem.
You have generalize ASSESSORS to have two minimum inputs:
BOOLEAN (DKIM verification result)
STRING (DKIM D= value)
1) Why? Do you have a specific ASSESSOR in mind that is only
privy to certain people?
2) How does a DKIM implementation generalize the fixed prototype
to satisfy newer ASSESSOR that require different input? You
are going to need some protocol that defines the input
requirements for the specific and different assessor.
The more general function prototype is to provide the entire process
environment variables, this is 1000% better for the general population
of developers of accessor routines:
ASSESSOR_RESULT is a function of SMTP data + DKIM result
this allows for example,a SMTP system to run a wildcard filter
FOR EACH ASSESSOR in ASSESSORS.LIST
RESULT = EXECUTE( ACCESSOR, ENVELOPE, PAYLOAD)
IF NOT RESULT
THROW EXCEPTION, RETURN FALSE or whatever
END IF
END FOR
That is general fit all never fail model. I'm pretty sure it applies
to everyone, even you.
In short, it is the unspoken ASSESSOR API limited to two fields that
needs to change to better fit a generalize global SMTP/DKIM model.
If don't your suggested way, then its becomes harder to program
because it will look like this:
FOR EACH ASSESSOR in ASSESSORS.LIST
PARAMETERS = QUERY_ASSESSOR_REQUIRED_DATA(ACCESSOR)
RESULT = EXECUTE( ACCESSOR, PARAMETERS)
IF NOT RESULT
THROW EXCEPTION, RETURN FALSE or whatever
END IF
END FOR
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.
Just providing feedback on years experience of developing an a high
end SDK/API for C/C++, DELPHI, JAVA, PHP, VB, .NET languages and three
basic API models; native, COM and .NET.
--
HLS
Murray S. Kucherawy wrote:
BTW, What is the definition of an Application Programming Interface
and what portion of DKIM is like an API definition.
I'm quite comfortable with drawing an implicit "you must be this
tall" line and assuming someone reading this, i.e. an implementer
(e.g. YOU), will know what an API is.
Or would you rather require even the definitions of words like
"framework", "authentication", "email", "public key", "verification",
"source", "messages" and "transfer", all of which appear in the first
sentence of the abstract of RFC4871, be included?
Let's not be absurd here.
_______________________________________________
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