On 05/04/2011 05:04 AM, John R. Levine wrote:
For a scenario where a caller is calling a DKIM milter which in turn calls an
API, this is all true. But DKIM will be/is deployed in many more scenarios.
Indeed, but you're misunderstanding the point of a standard. The DKIM
spec tells signers how to create a signature that recipients can verify,
and it tells verifiers how to check whether a signature is valid. The
spec is not an implementation guide for every possible implementation
scenario.
Indeed, this is precisely why it's silly to say there is a single
"output" of the protocol. Take IKE and KINK, for example: the
"output" is a complex set of parameters that eventually lead
to the keying of a SA given the identity in the cert/ticket. They
are *all* relevant and not just "internals". Similarly, DKIM
signatures have a lot of relevant information for filters to do
the magic that filters do, and they by their nature find utility
in information that is being walled off by -bis as being "internal".
And please stop trying to have it both ways: it's either "internal"
or it isn't. Developers have a funny way of taking these documents
literally and when you say it's "internal", they make them internal
in fact. We need to pick a lane, and "single output" clearly does
not match the real needs of all DKIM consumers.
4871 had it right on this account. Everything since then has
screwed the pooch. Put it back.
Mike
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html