On Jun 18, 2013, at 7:59 AM, Dave Crocker <dcroc...@bbiw.net> wrote:
> On 6/18/2013 7:18 AM, Tony Hansen wrote: >> I always thought it would be a nice follow-on to DKIM to provide a way >> for a site to specify how that site was using i=; that is, to provide >> some clarity and comprehension for that value. For example, our >> implementation placed the authenticated userid into i=. I know of one >> site that appears to use a hash of the authenticated userid. John L says >> his site uses "how the mail was injected (submit, webmail, whatever) and >> who the user was if it knows". When there is a deterministic mechanism >> used to create i=, and the mechanism is known, then it is possible for >> additional logic to be added to the receiving side as well. > > > I'm sure Tony already knows this, but just to make sure it's part of the > thread: > > Anyone can define a value-added protocol layer on top of DKIM. It > can define all sorts of additional semantics. > > It needs a method of declaring its presence, such as an extra > header field or a special external query, but after that, it's free to > define anything it wants, including a public meaning for i= > > One could, for example, imagine a layer that asserts that the domain in > the rfc5322.From field MUST match the domain in the DKIM d= field, or at > least have an "organizational domain" match (that is, match at the name > portion that was delegated by a registry. > > Oh, wait. That's DMARC. > > See? It's possible. > I found that too: http://tools.ietf.org/html/draft-fenton-dkim-reputation-hint-00 No traction either... I think, the lesson here is to not mix function in protocols. The authentication piece should be separated from the policy piece and same for the reputation. This makes better building blocks. _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
