On 08/03/2010 12:56 AM, Steve Atkins wrote:
On Aug 2, 2010, at 3:37 PM, Rolf E. Sonneveld wrote:
Hi, all
in the light of the discussion about draft-ietf-dkim-mailinglists I'd
like to propose an alternative way to solve the MLM dilemma on how to
deal with original DKIM signature/message versus sending out a modified
version of the message. This proposal may be impractical or hard to
realize, but I'd just thought I had to share it with you.
The proposal is to preserve the original message + DKIM signature and to
add the new (probably partially rewritten) output message, combined into
a multipart/alternative structure. The combined message is sent by the
MLM to the recipient. For the original message + DKIM signature, we
could register a Content-Type of e.g. message/dkim-original-message with
IANA. The output message would be the other part of the
multipart/alternative, with the normal MIME structure of the MLM output
message. A sample message sent by an MLM (or more in general, by a
re-signer) would look like:
Does this mean that anyone can take their own content and
a message DKIM signed by someone else, and then send it out
such that their content will be displayed, but the (non-displayed)
signed message will be checked?
No, it means that for both message parts a DKIM signature is checked for
presence and the results of both are made available to the receiver
('receiver' as in Murrays draft defined in par. 3.1). So effectively it
means that in the situation you described, the 'own content' is
displayed but lacks a verified DKIM signature and as such should be
treated as a message without DKIM signature. The proposal just means to
provide a way to tunnel the original contents of a message + DKIM
signature and enable the verifier to verify not only the DKIM signature
provided by the resigner, but also the original DKIM signature as well.
The A-R results of the original DKIM signature, provided by the resigner
as part of the new DKIM signature can only be trusted if the
verifier/receiver trusts the resigner. With the original DKIM signature
+ message present, there is no need for this trust relation; the
verifier itself can verify.
/rolf
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html