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