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)
ietf-dkim mailing list