> hangText="NOTE:"> The use of wildcard TXT records in > the > DNS will produce a response to a DKIM query that is > unlikely to be valid DKIM key record. This problem > applies to many other types of queries, and client > software that processes DNS responses needs to take > this > problem into account.</t>
I realize that 4871 is already too long, but this is too simplistic. Wildcards within the _domainkey subtree can do reasonable things, e.g., this revokes any unknown key: *._domainkey.example.com. TXT "v=DKIM1; p=; n=revoked" _adsp._domainkey.example.com. TXT "DKIM=unknown" ;; override wildcard I agree wildcards higher up the tree are unlikely to produce useful results. >> 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. > > Those are two different changes. My own sense is that each has some > controversy, with the first being pretty substantial and with the first having > some significant counter-proposals. My preference is still that verifiers reject messages that are likely to display misleadingly in MUAs, e.g., multiple copies of headers that MUAs render one of. This is a rathole if you consider all the junk a bad guy can do in HTML body parts, but at if you insist that the entire body is signed, you can at least say that the garbage the user sees is same garbage that was signed. R's, John _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
