ietf-dkim
[Top] [All Lists]

[ietf-dkim] MLMs and the use of multipart/alternative to preserve original DKIM signature and at the same time add a new DKIM signature

2010-08-02 17:40:10
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:

From: "Rolf E. Sonneveld"<R(_dot_)E(_dot_)Sonneveld(_at_)sonnection(_dot_)nl>
To: DKIM List<ietf-dkim(_at_)mipassoc(_dot_)org>
Date: Mon, 02 Aug 2010 11:43:39 +0200
Subject: Re: [ietf-dkim] Feedback on draft-ietf-dkim-mailinglists for discussion
DKIM-Signature: ... DKIM signature provided by re-signer goes here ...
MIME-version: 1.0
Content-Type: multipart/alternative; boundary=boundary1234

--boundary1234
Content-Type: message/dkim-original-message

... original version of message including all original headers and _original 
DKIM signature_ goes here ...

--boundary1234
Content-transfer-encoding: 7BIT
Content-type: text/plain; CHARSET=US-ASCII

... output message of MLM goes here ...

--boundary1234--


As per MIME  RFC 2046 (par. 5.1.4) multipart/alternative provides a 
means of presenting multiple versions of the same information, where the 
receiving MUA can decide which one to display to the recipient. In a 
sense we can view the original message and the one, that is being sent 
out by the MLM, more or less as two incarnations of the same message, 
and as such I think the multipart/alternative can be used. As the 
message/dkim-original-message subtype will not be recognized by MUA's, 
we can be sure that the end user will be presented by the MLM rewritten 
version of the message.

The advantages of using this approach are:

- the original DKIM-signature is preserved. The verifier can verify both 
the original DKIM signature of the author domain, as well as the DKIM 
signature of the MLM domain.
- any FBL can use the message/dkim-original-message information to send 
the feedback to the proper place
- no need to rewrite From address (and Sender, Reply-To)
- this approach can be used for other 're-signing' mail agents in the 
chain between sender and recipient
- it can also be used when there is more than one re-signer in the chain 
(nested multipart/alternative structure) to provide a generic solution

Disadvantages of this approach are:

- it requires the verification paragraph of DKIM to be rewritten
- the size of MLM redistributed messages is doubled roughly (hey, nobody 
complained about the extra size of text/plain + text/html messages ;-))
- it will probably require more changes in MLM software than the other 
proposals

I'm sure there is a whole lot more to say about this proposal, more 
pros, more cons etc. I solicit your comments!

/rolf



_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

<Prev in Thread] Current Thread [Next in Thread>