Mr. Aumont,
I think
deployment of DKIM require a good support of DKIM by some of the major
mailing list software. I am one of the author of Sympa mailing list
software and I feel concerned by this. What a mailing list manager
must do with DKIM ?
>From my understanding, the minimum is to preserve existing
DKIM-Signature: header and not modify the message in a way that will
alter the signature. For this issue, existing specification are quite
clear (the difficulties are only related to headers that must be
preserved where most availible libraries to modify message headers
don't garanty headers lenght line and headers order).
My memory matches that of Stephen's that this was an issue raised in
the BoF, and that there was at least a tacit understanding that the
matter would be addressed by the working group. I think there is
already some guidance in the base draft.
Thus far discussions seem to conclude along the following lines:
- If a mailing list manager is going to mangle a message that was
signed it SHOULD resign it. This has all the UI problems that Doug
mentioned in his message.
- The original spec had a length attribute just so that the text of
a message could be preserved while some sort of mailing list blurb
could be added. This is not a perfect solution. For one, if a mailing
list manager is too smart and attempts to modify multipart/alternative
components, the game is lost because you have to delve deep into the
message to do that. Fortunately I don't know of mailing list software
that does this. Some guidance here would be useful.
- Some guidance will need to be given about protection of the
"Subject:", "Sender:", and any other headers that are protected. This
goes beyond mailing list maintainers. If the signing domain protects
either, then the mailing list system should be reticent to make
changes. But should the signing domain sign these things in the first
place?
Eliot
|
_______________________________________________
ietf-dkim mailing list
http://dkim.org
