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 = Alice(_at_)example(_dot_)com i=mallet(_at_)example(_dot_)com
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