Rolf E. Sonneveld:
> 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="?
Because d= specifies the name of the public key.
Wietse
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
