At 4:59 PM +0100 1/10/07, Eliot Lear wrote: > >The reason I'm concerned is that any form of OPES might invalidate a DKIM signature. What can we say in a DKIM sense about OPES trace information? Do you mean, should a DKIM server sign OPES trace information? The DKIM base document says: 4. Semantics of Multiple Signatures A signer that is adding a signature to a message merely creates a new DKIM-Signature header, using the usual semantics of the h= option. A signer MAY sign previously existing DKIM-Signature header fields using the method described in section Section 5.4 to sign trace header fields. and Signers should be careful of signing header fields that might have additional instances added later in the delivery process, since such header fields might be inserted after the signed instance or otherwise reordered. Trace header fields (such as Received and DKIM- Signature) and Resent-* blocks are the only fields prohibited by [RFC2822] from being reordered. if and when the protocol requirements in this document are embodied in protocol specifics, the mechanics of carrying the trace information would need to be fleshed out. The consistent use of the term trace information leads me to believe, though, that the protocol would put this information in a trace header field (as DKIM does its signature). >In addition, an OPES server might choose to resign a message with DKIM. However, we in the DKIM group wouldn't at this point know what to do with that. But it might be a consideration for SSP as an authorized third party signature. Anyway, my point is that there are considerations here that have not been thought out (at least not by me ;-). The document says this: 2.2 Non-standardized SMTP adaptations at SMTP gateways A large number of email filters are deployed at SMTP gateways today; in fact all usecases listed in "OPES SMTP Use Cases" [6] are already deployed, often in non standardized ways. This opens a number of integrity, privacy and security concerns that are not addressed, and SMTP itself does not provide effective measures to detect and defend against compromised implementations. In other words, if you will be worried about what OPES might do, you should already be worried about what existing systems do do. >Eliot regards, Ted _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf