On 06/20/2013 03:05 AM, John R. Levine wrote: >> Now on the other hand, if an administrative domain wanted to go to the >> trouble to authenticate down to the user level, we didn't want to prevent >> that, either. The primary audience for DKIM includes regulated industries, >> after all. > Seems to me that works fine as is. If a stock broker wants to set up its > mail system to put an i= into DKIM that reliably identifies the person who > sent the mail, they can do that. > > But unless I have external knowledge that they do that, and trust them to > do it right, I can't depend on it,
Why do you raise this concern for "i=" and not for "d="? Simply looking at "d=" we can't differentiate between a Good Guy and a Bad Guy, until we have built some history/reputation for that particular "d=" domain. Why wouldn't the same logic hold for "i="? That is: if a Signer, despite the wording of RFC6376 par 3.5 on "i=", chooses to use a non-default "i=" then the Verifier may assume the Signer is intentionally signing with "i=" and the Verifier is allowed to use the information of "i=" for whatever purpose it is verifying the signature (e.g. building a reputation profile of that "d=,i=" combination. If we wanted the Verifier to never ever use the "i=" information, we should have written this as a 'MUST NOT' in RFC6376 (and not only in an informational section). /rolf _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
