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.
We're allowed to assume that the spec will be implemented by reasonably
competent programmers. I think reasonably competent includes
figuring how to maintain or communicate the external state needed
to do what you want to do.
Beside the point that there are conflicts, these are all valid points
and the issue is beyond validity or rather how DKIM-BASE goes beyond
the validity question.
The mandatory single output for SDID attempts to mandate a specific
receiver design implementation where the message is valid and trusted
if they have the local or query method available for evaluating trust
for SDID. It is a MUST design by DKIM-BASE standards and this SDID
trust policy design mandate is not the issue for the receiver. We get it.
The issue is that receivers also have serious security controls,
anti-abuse operational needs. With the #1 market of signers being
spammers increasing using DKIM in some silly idea that it will give
them brownie points, DKIM redundant abuse will not be tolerated and
it doesn't help DKIM to live in indeterministic world where SDID is
unknown or provides no trust results.
Reasonable competent manager, software engineers and programmers will
look at the pretty picture called "DKIM Service Architectures" - we
all like pictures - and determine very quickly what is the inputs and
outputs. It shows in graphically process flow iconic form what is
required and what is optional.
The design issue is that not all outputs are not spelled out in the
Functional Specification for DKIM. It doesn't match what RFC5595 calls
the "DKIM Service Architecture." RFC4871bis does not reflect what
receivers need for security controls.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html