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