Eliot Lear wrote:
I responded to Charles privately, but there seems to be more general
confusion (and perhaps some on my part):
On 2/4/09 11:15 AM, Charles Lindsey wrote:
On Wed, 04 Feb 2009 07:00:25 -0000, Eliot Lear<lear(_at_)cisco(_dot_)com>
wrote:
absent additional information from the signer that is not exposed by
this
specification, verifiers SHOULD NOT rely on i= as any sort of identity,
because the value may not be present or stable.
No, SHOULD NOT is too strong. Normally, that would indeed be the case,
but
in specific cases the Assessor (not the Verifier) might have information,
obtained by some out-of-band means, what that particular i= meant, and be
able to act accordingly. Otherwise (and maybe always), assuming the d=
matched satisfactorily, the i= should just be passed on to the end user
who might make some sense out of it (e.g. Aunt Tillie vs Uncle George).
First, I stuck to terminology that was in RFC 4871 intentionally, with
an eye toward keeping the errata simple.
Second, there is a predicate prior to the SHOULD NOT statement which is
important. However, it has been lost by more than one person indicating
lack of clarity. Let's try this again:
The contents of i= may not be a stable, and hence may not be
suitable for programmatic consumption on their own. As such, it is
NOT RECOMMENDED that verifiers consume the contents of i= without
additional external inputs that are provided by the sender.
If you excluding the idea of syntax checking, then fine. But
according to RFC 4871, there was always the possibility of syntax
checking that can be performed and SHOULD be perform for protocol
consistency, and WILL be perform by our DKIM verification if that ever
comes to happen.
The problem as I see is that we are getting lost with the multiple
undefined application possibilities of DKIM, i.e, the presentation
part mostly.
It is important that once SMTP systems (en masse) begin to check for
the new DKIM level messages, that protocol expectations are honored
consistently across the board, including syntax checking.
The i= is opaque in format, but transparent to the verification
process, meaning, it is passthru just like the rest of the 2822
headers. The d= has its specific purpose, and the i= has a specific
syntax, if used, that must be DKIM 4871 compliant.
Message Integrity is not just in the repeatability of the message
hash, but in its complete signature as well. Failure detection is a
strength of the protocol because it helps raise the "email" bar above
and beyond standard 821/2821/5321 requirements. It is what will help
protect signing domains more so than verified signatures that have
little payoff without augmented undefined black/white/grey listing or
reputation technology. However, DKIM doesn't not "Required Batteries"
to fully function. When receivers detect failure, IMO, it is thee
major part of the payoff realization and benefit of the both domains,
signers and receivers.
So I think we need to separate the heuristic ideas from the
deterministic protocol ideas. The i=, if used, has a specific format
it must follow, but shouldn't be used for anything else. I believe
that is what this Errata is trying to make sure it is understood.
--
Sincerely
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