On 01/Apr/11 23:08, Murray S. Kucherawy wrote: > *2.3**. Identity* > > A person, role, or organization. In the context of DKIM, examples > include the author, the author's organization, an ISP along the > handling path, an independent trust assessment service, and a mailing > list operator.
Besides assessment services, there have been several discussions about operators along the handling path, who sometimes break signatures. I propose to clarify the text that discusses the interpretation, in Section 4.2, by adding a sentence to the fourth paragraph, something like so: Signers SHOULD NOT remove any DKIM-Signature header fields from messages they are signing, even if they know that the signatures cannot be verified. Instead, when a relay alters a message such that any valid signature gets broken, it SHOULD re-identify the message by synthesizing a new Message-ID for it, according to Section 3.6.4 of RFC 5322. Would that help deterring on-the-fly auto-conversions? _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
