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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf