MH Michael Hammer (5304) wrote:
[...]
> In any event, I perceive MLMs as the tail that appears to be wagging the dog.
> In the context of email authentication, there are so many much more
> interesting mail streams from my perspective.
>
+1
>>> The DKIM signature
>>> provides a simple piece of trace information ("I handled this mail")
>>> that is cryptographically bound to some header and body content.
>>>
>>> The receiver can use this trace information for any purpose that
>>> she deems suitable.
>>>
>> I think most of us can agree with this summary of what DKIM really is,
>> without all the bells and whistles we often like to attribute to it.
>> Next we add a quote from Dave about what the MLM does:
>>
>>
>>> An MLM creates the message. That the message might look a lot like
>>> one sent /to/ it is nice, but it's also confusing. The original author
>>>
>> is not,
>>
>>> ultimately, responsible for what the MLM chooses to send
>>>
>> Again, most of us will agree with this, I assume. Now combining the two,
>> and _without focussing on any hypothetical action of a verifier or
>> recipient_, the conclusion must be that the MLM adds its own
>> DKIM-signature, leaving the original DKIM-signature(s) untouched. After
>> all, removing the original DKIM signature would mean removing a piece of
>> trace information provided by the originating domain. And once it's
>> gone, it's gone. Leaving the original DKIM signature untouched is in
>> line with chapter 4 of RFC4871 including par. 4.2 that states:
>>
>>
>>> Signers SHOULD NOT remove any DKIM-Signature header fields from
>>> messages they are signing, even if they know that the signatures
>>> cannot be verified.
>>>
>>>
>> I haven't found any text in the erratum of 4871 / 5672 that obsoletes
>> this text. This means we can treat (regarding this particular aspect)
>> MLMs like any other re-signing agent, no exceptions are required.
>>
>>
>
> Rolf, you have sidestepped the issue of digests or do you feel this holds
> true for them as well?
>
Sidestepping the issue of digest was not intentional, I just forgot to
include them in my previous message. Most MLMs these days create digests
by concatenating a number of messages, where for each message a subset
of header lines + the body are presented. In that situation any
DKIM-signatures, which may have been present in the original message(s),
are lost.
Murray writes in the DKIM and Mailing Lists I-D about the digest type:
> digesting: A special case of the re-posting MLM is one that sends a
> single message comprising an aggregation of recent MLM submissons,
> which might be a message of [MIME] type "multipart/digest" (see
> [MIME-TYPES]). This is obviously a new message but it may contain
> a sequence of original messages that may themselves have been
> DKIM-signed.
If (repeat: if) the logic of my previous message applies (the MLM should
leave already present DKIM-signatures untouched) this could lead to the
following suggestion/recommendation for MLMs:
"MLMs should not remove DKIM signatures when assembling digest messages.
This can be achieved by using the following rules:
a) when digesting the multipart/digest MIME type/subtype should be used,
according to RFC2046 and
b) for each message that is part of the digest, copy the entire
(header+message) into a message/rfc822 part and
c) re-sign the message with the MLM DKIM Signature on the outer-level
header of the enclosing message
As a) will have impact on the recipients of those digest messages, the
MLM should insert a 'Table of Contents' of all contained messages before
the first message/rfc822 part (a number of MLMs already do this). And,
in addition to this, the MLM optionally can add Content-ID's for each
message/rfc822 part (if the Content-ID is not already present and not
part of the DKIM signature) . The ToC then can link items to the
corresponding Content-ID of the enclosed message. If the original DKIM
signature refers includes a content-id field, then the MLM must not add
a content-id to the header of the message/rfc822 bodypart."
Although DKIM does not specify (as far as I know) what to do with DKIM
signatures in inner bodyparts, I think DKIM signatures should never be
removed without a good reason.
/rolf
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
