[ietf-dkim] Output summary
dhc at dcrocker.net
Thu Apr 28 07:53:57 PDT 2011
On 4/28/2011 2:47 AM, MH Michael Hammer (5304) wrote:
>> Mike, I believe you are continuing to different parts of the architecture.
>> The DKIM verifier does not know anything about the "type" of the signature,
>> such as whether it is first party or third. An architectural function
>> that is outside of DKIM signing makes those sorts of higher-level,
>> integrative analyses.
>> The current discussion is only about signature validation and how to report
> I understand that Dave. My point is that if we follow the logic that John
> laid out and we end up with outcomes that leave one scratching their head,
> there is a potential issue. We have been round and round the block on the 1st
> party vs 3rd party issue but this specific point is in the context of
> multiple signatures on a single message rather than the general discussion of
> evaluating a message with a single signature.
With respect, I believe you do /not/ understand the architectural point at issue
The confusion that you are experiencing is between the component of the system
that validates and reports signatures, versus other components that evaluate
additional aspects of signatures, such as the correlation of the SDID with other
identifiers in the message..
The fact that the current discussion is about multiple signatures does not
change the scope of DKIM Signing, nor does it change the fact that correlation
with other identifiers is outside the scope of DKIM Signing.
I believe that the core confusion here is a tendency to think only in terms of
the whole system rather than being able to isolate aspects of the system into
Nothing in the current discussion prevents:
a) other parts an implementation to make correlations
b) specific implementations from reporting more information that is
specified formally for DKIM Signing. (The only issue with reporting more is
making sure that no one believes that both sides of the signing process will
know about these extensions.)
>> To make this more direct: For DKIM signing, there is no such concept of
>> "From domain signature".
>> The issue for payload at the level of DKIM Signing, the issue needs to be
>> kept quite simple: Report signatures that validate and I guess also
>> report signatures that get a temporary failure.
>> No other formal payload comes out of the DKIM Signing spec, no matter what
>> other sorts of cleverness a particular implementer might provide. The
>> cleverness is fine, but it goes beyond the spec.
> That's what I said. Report the domain and the outcome for each signature and
> leave something else to sort things out. Don't try and do it within DKIM
> itself. The decision choices by that something else could be based on
> reputation or authoritative assertion, or a combination of the two. I was
> simply responding to the choices within DKIM that John was laying out.
If, by this, you mean report validation failures then you are trying to change a
core aspect of DKIM. The reason for treating verification failures equivalent
to the absence of a signature is a fundamental feature of DKIM. We should not
have to re-discuss that issue.
Again, a particular software implementation might choose to do more, but the
formal DKIM Signing specification MUST NOT.
More information about the ietf-dkim