> > DKIM either needs stronger binding semantics, or > > it needs to limit when signing can be done. > > I think DKIM deals with this correctly right now. Binding to the > RFC2822.From header is not required BUT when it's missing an SSP check is > performed to discover and enforce the wishes of the domain owner.
This is by far the most dubious feature of DKIM. I think it's going to be very difficult to define policies that permit reasonable behavior (like forwarding or resending of messages) and yet deter phishing, and it's going to be really easy for admins to write policies that break legitimate behavior without realizing that they're doing so. For me it's not acceptable for DKIM to break mail forwarding or resending, or even to give a domain the ability to write a policy that breaks mail forwarding or resending. IMHO, MUAs are going to need to change. For example, it is essential that MUAs display a forwarded or resent message differently from a message for which the sender == author so that the reader can clearly see the difference. This isn't rocket science, it's just a departure from existing practice. And for DKIM to be successful it's going to need to provide some guidelines about what kinds of things MUAs need to display to their users. (stopping short of actually specifying _how_ such things are displayed) Keith _______________________________________________ ietf-dkim mailing list http://dkim.org
