Al Iverson wrote: > On Thu, Jan 29, 2009 at 1:35 PM, Dave CROCKER <[email protected]> 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=stri...@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
