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
