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
them.
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.
Mike,
With respect, I believe you do /not/ understand the architectural point at
issue
here.
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
components.
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.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html