Let me try to summarise this thread so we don't have to do it all again (or at least not too often:-)
Please correct where I've missed things, or gotten stuff wrong. Where a particular message seems to contain a bunch of potentially useful text, I've included a link to the archive. Note that I don't mean that I think every word of the linked message is perfect, more that a document author might find it useful to go back to those messages. Stephen. The thread was kicked off by this post: [http://mipassoc.org/pipermail/ietf-dkim/2006q1/001753.html] Discussion ensued: - Mailing list servers can be thin (where they don't disturb existing DKIM signatures) or thick (where they do disturb a pre-existing signature). There might even be intermediate cases but both approaches are reasonable and its not our job to argue for one over the other. [http://mipassoc.org/pipermail/ietf-dkim/2006q1/001762.html] - There is merit in mailing lists DKIM signing messages - verifiers might be willing to whitelist some such mailing lists. This applies regardless of whether or not the message sent to the list was originally DKIM signed or not. [http://mipassoc.org/pipermail/ietf-dkim/2006q1/001818.html] - If the message sent to the list was originally signed, there can be merit in preserving the signature so that the original signature on the message received from the mailing list could still be verified. - There are arguments that supporting both original and mail-list signatures would be useful, but there are also difficulties with this in particular adding the mail-list signature will often break the original signature. (If the mail-list signature only covers the content and certain headers like List-Id then this might work better). - Some particular headers may cause difficulty when a mailing list is re-signing an originally signed message (e.g. "Reply-To", "Subject"). [http://mipassoc.org/pipermail/ietf-dkim/2006q1/001821.html] - The "l=" approach to modifications performed by mail lists might, or might not, be worthwhile. [Couldn't find that post when I went looking;-(] - There may be merit in a mailing list considering the SSP of the original message's domain before deciding how to process the message. [http://mipassoc.org/pipermail/ietf-dkim/2006q1/001774.html] - SSP was suggested as being a useful check to make during subscription processing. (Although there was no feedback on the suggestion, or else I missed it.) [http://mipassoc.org/pipermail/ietf-dkim/2006q1/001816.html] - There may be implementation issues that warrant consideration since mail-list code may be separate from the inbound and/or outbound mail handling code => processing of DKIM could be happening in different code bases. [http://mipassoc.org/pipermail/ietf-dkim/2006q1/001774.html] - We have a few different (though not necessarily conflicting) proposals for MUST/SHOULD/MAY language that can be considered later on. [http://mipassoc.org/pipermail/ietf-dkim/2006q1/001781.html] [http://mipassoc.org/pipermail/ietf-dkim/2006q1/001800.html] [http://mipassoc.org/pipermail/ietf-dkim/2006q1/001810.html] - There are reasons to not add >1 From to the message. [http://mipassoc.org/pipermail/ietf-dkim/2006q1/001825.html] My conclusions:- - There are conflicting possibilities allowed by the above, but each of the possibilities may be sensible. In other words, there is not a unique correct design that meets all of the above (and other real world) requirements. So the WG probably need to flesh out a few practical use-cases and try satisfy those. - Are there any documented surveys on the things that mail lists actually do? If so, I'd be interested in that for my own education. But we might also be able to use such a document to decide which use cases to try support. I don't think we need to get the ultimate survey document, but if there's something we can all agree lists some good-to-support cases that'd be enough. Of course, since no-one's posted a link that I spotted so far, that probably doesn't exist. _______________________________________________ ietf-dkim mailing list http://dkim.org
