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
