Douglas Otis wrote:
Modifying the message is already a common practice by
list-servers and resigning a modified message may not
overcome restrictions imposed by a From email-address
policy.
Then it's not more the original message, they could send
it as "digest" (multipart/digest, a single message/rfc822,
or maybe some kind of application/mbox) or resend it with
their own Resent-* header fields, above all with their
own Resent-Message-ID.
Substantially different messages need different Message-IDs,
otherwise it breaks horribly (e.g. in mail2news scenarios).
Adding a signing role avoids difficulties in classifying
the nature of the source
There's no need to sign a message that is already signed as
long as it's still the same message. If it's some kind of
"derived message" see above. For the clumsy Resent-* cases
they could remove the old signature. Or we could offer some
Resent-DKIM header field. Or "we" decree that Resent-* is
"out of scope" for all kinds of DKIM-signatures.
It may also require that the From email-address be moved
entirely into the body of the message and replaced with
the email-address of the mailing-list.
NAK.
This would be a follow-on of the closed policy issue when
dealing with message changes.
If what you're talking about is the "use digest or Resent-*
for modified messages" case, then the old From could be in
fact moved into a complete message/rfc822 part (for digests).
Its DKIM signature (incl. any signing policy) would still
work perfectly for this message/rfc822 part. "We" (TINW)
better make sure that it also survives in application/mbox.
That should cover all cases of "digest mode". No need to
manipulate the From-header for mailing lists. The worst
case is PRA and its Resent-zoo.
But mailing lists wishing to be PRA-compatible are already
in deep sh*t, and it's no DKIM-issue that PRA breaks Sympa-
lists. We discussed this 18 months ago in MARID. [See also
<http://www.ietf.org/IESG/APPEALS/?C=M&O=D> for those who
don't know this, Sympa and Yahoogroups are famous examples]
But nowhere will DKIM force mailing lists to "forge" the From
header field, "we" just won't let it pull this stunt. That's
a new WG in the security area, "we" are not working on orders
from Redmond.
Bye, Frank
_______________________________________________
ietf-dkim mailing list
http://dkim.org