Charles Lindsey wrote:
Which suggests that future use profiles may need tag hooks to hang their
features on, and so if there is some underused existing tag (such as i=)
already in the spec, then it is better left there to facilitate such
future profiles.
Good point.
The thing is, for a standard protocol, there should at least be the
basis for hooks defined, generalized or outlined for the tags already
provided.
That was done for the "Independent Trust Assessment Service" d= hook.
trust = HOOK(signer-domain)
The problem as I see it as that we have mixed specific implementation
service needs and limited the generalization of the protocol. As I
recall, when this was all debated regarding what "bits" should be
passed, the understanding was that d= would be the MINIMAL REQUIRED
parameter for any augmented DKIM "HOOK" technology for signature
evaluation. At least, that is how I understood it from an SOFTWARE
API implementation standpoint.
What does that mean?
What it means is how well the DKIM Interface Points are defined will
help how well the integration can be done.
Currently, that "interface point" is the Authentication-Results
header, which AFAIK, isn't a standard at this point. Nonetheless, A-R
also comes with TRUST issues and I believe it is understood the only
consumers who can trust these A-R headers would be the local or
internal system only. One part verifies and produces A-R and another
part interprets it for whatever usage, scoring, filtering and/or display.
--
HLS
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html