On item number 3. I object that the verifier needs to be doing anything other that verifying that the signed headers and other parts match the signature. Its out of scope to have dkim scurrying about enforcing other RFC's compliance. A policy change would be a better solution. Adding a section to the Security considerations is fine.
This should be fixed by Policy On Oct 22, 2010, at 11:28 AM, Barry Leiba wrote: > 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 _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
