A new version of draft-ietf-dkim-mailinglists has been posted. This document
is in WGLC, closing 4/30; this new version contains those changes that are
shown in the WG's issue tracker for which there appears to be consensus or are
otherwise uncontested, and I've closed them in the tracker. You can use the
datatracker link
(http://datatracker.ietf.org/doc/draft-ietf-dkim-mailinglists/; click on the
History tab) to get a view of the diffs to make sure we have them right.
Things that have been edited or added as a result of tracker items are marked
with "{DKIM #}" tags. Text that has been removed has, well, been removed.
The only suggested change not yet made has to do with the choice of fields to
sign. Section 5.5 of RFC4871 (6.5 in bis) lists header fields to sign,
something the IESG had us add as I recall. Section 6.8 of the MLM draft
extends that list slightly, falling back on the justification given in RFC4871.
It does so largely with the intent of taking responsibility for fields it
added, especially Authentication-Results, so that downstream agents can have
some faith that they're "real".
As Dave pointed out (and he's free to correct me if I have this wrong), we
never ascribed any semantics to header fields covered by a signature. For X to
trust Y's signing of an Authentication-Results field, there's meaning being
assigned by both to a valid signature from X. But that's out-of-band as far as
DKIM is concerned, and to go back and add it now in bis would require recycling
at Proposed Standard. So, although there are people that want to (or maybe
even do) use DKIM this way, it's outside of DKIM's scope and the MLM document
shouldn't make this specific statement about which fields to sign.
At the same time, a lot of this document talks about possible applications of
DKIM that go beyond the scope defined in RFC4871 and bis to help MLMs in a DKIM
world, so maybe leaving it in is just fine, perhaps making that caveat explicit
yet again at that point in the draft. This is my (current) preference.
Suggestions welcome.
-MSK
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html