We seem to be bush-whacking again, rather than staying on the trail.
I don't mind (actually I like) some level of general discussion, but
the chairs would like to focus on our immediate goal for now, so I'm
asking folks to refrain, for the moment, from discussion that isn't
directly addressing the text of 4871bis.
That includes discussion of MUA issues. We can go back to talking
about that later, but 4871bis is not the place for that, either from a
protocol point of view or from a procedural one.
We have reviews from Jim, SM, and John that the editors are working on
responding to (John's is new enough that I haven't digested it all
yet, and I'm sure the editors haven't either). We also have three
significant issues that we need to make sure we have resolved
satisfactorily:
1. How to handle a key record with empty "g=" and absent "v=" (section
6.1.2, list item 6).
Proposed change: Remove "g=" altogether, along with all references to
it. Surveys of what's out there show vanishingly few cases that use
"g=" with any value other than "*" or empty, so this can be removed as
an unused feature.
2. Advice about wildcards in TXT records.
Proposed change: Add a note in section 6.1.2 warning about the effect
of wildcard TXT records on finding DKIM key records.
3. The issue of multiple occurrences of header fields that may only occur once.
Proposed change: Add text to section 5.3 recommending that verifiers
check that the message complies with specs, and that they not validate
a non-compliant message. Add a new section 8.14 to the Security
Considerations, explaining the attacks that can be done using this
exposure.
We ask the editors to consider the latest batches of comments, respond
to them as necessary, produce an -03 version, and post it when they
have it ready.
We ask all participants to speak up specifically about the three
issues above, and let us know whether or not the proposed change is
acceptable. The editors can post the specific text they're using, if
we have anything to discuss about them. I believe we have agreement
on the text for number 2, so we should be set on that one. I haven't
seen a definitive poll about removing "g=" (number 1), but I *think*
we have consensus on that. Text for number 3 is still being worked
on.
Please start new threads for these discussions, rather than responding
directly to this one, and let's keep the threads for the three items
above separate.
And, again, we particularly ask all participants to refrain from other
discussions that are not specifically about text for 4871bis, so we
can get that document done.
Thanks, everyone.
Barry, as chair
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html