The RFC just talks about returning PERFMAIL when the evaluation fails for one reason or another. It's abstract, of course; the implementer is free to decide what that actually means in each case. In the implementation I did, the library receives all the details and returns a status (with its own detail) about each signature, and the caller is free to do what it wants with that information.
This is a very basic point about protocols vs. implementations. A protocol defines the 4 walls of its sandbox. It owns that sandbox and defines whatever it needs to, within the confines of that space.
To be reliable and accurate, it has to be objective and precise. Specific inputs, specific outputs. It might distinguish permanent failures, such as a cryptographic value not validating -- the passage of time is not going to change that; versus a temporary failure, such as a failure to get a DNS response; the passage of time might change that. The liberal-vs-strict cliche applies to the interpretation of protocol specification details that might legitimately permit alternative interpretations, because prose can be ambiguous, in spite of efforts for it not to be.
But a protocol spec is not supposed to call on subjective judgement -- ie, whim.
An implementation of the protocol, also has no freedom, in terms of strict conformance.
However a real-world implementation, in which the protocol implementation is incorporated as a part, will tend to demonstrate all sorts of programmer and organization whim in deciding what to /do/ with the available information. DKIM is precise. A filtering engine that uses it well might not be. Heuristics don't belong in a protocol spec but usually /do/ belong in a filtering engine.
But again, this is protocol and standards 101. Seems odd to be rehashing something this basic, in a forum like this
d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net mast:@[email protected] _______________________________________________ Ietf-dkim mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf-dkim
