Al Iverson wrote:
On Thu, Jan 29, 2009 at 1:35 PM, Dave CROCKER <dhc(_at_)dcrocker(_dot_)net>
wrote:
1. I can easily believe that the Errata text needs to be even more clear
about this string. Submissions to improve it are eagerly sought...
I hear you. I wish I understood better, so I could contribute more usefully.
So the UAID is essentially a sender-created identifier used for
whatever purpose a sender wishes.
I think I am +1 fine with your errata. But I think from the
perspective of almost, "who cares...it's just a random sender-used
string." As an ESP, perhaps I would populate it with a client
identifier for my own purposes. But I'd be surprised if an ISP
actually cared/read the identifier.
One of the concerns I always had with this group is when the party on
the left side of the room has/had play down the potential on how
verifiers, creatively or not, employ DKIM and simply extract the new
level of information and run a protocol consistency check before
applying a high overhead hash verification.
There was always a DKIM-BASE rule for i=. If used by the signer, it is
not random, or at least not 100%. Using Dave's format, it must
conform to:
i=string1(_at_)string2
where
string1 is signer defined
string2 MUST equals d= or is a subdomain of d=.
That is an deterministic rule which verifiers can legitimately employ
in its implementation. If protocol consistency can not be reached, I
personally find no use for DKIM - or rather, it will be waste on many
systems and such features will be ignored and/or lost for its lack of
correctness and/or usefulness. The last thing I would hate to see are
DKIM signatures that are incorrectly formatted yet, hashing waste is
done to a high degree of failure thus helping kill DKIM in the long
run. Protocol consistency and expectations for correctness must be top
consideration for DKIM to be successful.
It appeared to me that issue here is what is the string1 and as a
whole, how does it apply to the entire payload, transaction or some
post verification concept, i.e., possibly presentation to the user.
--
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