On 4/11/11 2:06 AM, Charles Lindsey wrote: > I think you may have missed the point of my 'bob' example. It would have > been clearer if I had said: > > 3. From = [email protected] [email protected] d=example.com. > > Where mallet is some disgruntled example.com employee posing as Alice. A > human seeing that evidence (E.g. in an A-R header) might well conclude the > message was bogus. But it would be hard for an automaton to spot it. Charles,
DKIM does not make assertions beyond the domain verified within the signature that can be generally related with whatever message portions included within the signature's hash. DKIM makes no requirements on Display or Friendly Names, the only thing many see. What is contained in the i= field represents an optional opaque token based on recognitions by signing domains of the source, perhaps it contains the Radius or Diameter identifier for example. When there is a problem discovered, this information allows selective feedback that can assist in maintenance of their trustworthiness. One would hope example.com restricts use of originating email addresses to those confirmed using some type of ping-back. Even this measure would not allow reuse of email-addresses by different entities, nor a way to tell when access had been subsequently revoked. Selective feedback would help contain the possible spoofing allowed by non-federated methods of authentication, as might be used by a mailing-list. Review the charter exclusions. There can be no deeper meaning defined for the i= field. ,--- * Signatures that attempt to make strong assertions about the identity of the message author, and details of user-level signing of messages (as distinguished from domain-level keys that are restricted to specific users). * Duplication of prior work in signed email, including S/MIME and OpenPGP. '--- -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
