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