SM wrote: >> This is just to jump start suggested text. Others can add/change >> whether they think helps: >> >> The DKIM public key TXT record MUST not be mixed or merged >> with other TXT records, i.e. SPF. In addition, make sure other >> TXT records with Wildcards do not conflict with DKIM public >> key lookups. > > That text adds a requirement in an informative note.
SM, You can tell me if I am wrong here cause I am trying to make sure I understand the IETF angle to this but I also a product developer and have to look at the customer support angles as well. 1) Verifier TXT record parsing I checked for this, but did not find it, but was a quick scan. If the DKIM specs says that verifiers MUST be ready for different TXT records merged in the DNS Query response, it MUST parse for the string v=DKIM1 If this is the case, then I don't think we need to add anything. Its all good. This would be an implementation bug in our software if indeed that is what happening with invalid selector DKIM fails. 2) If #1 isn't part of the specs.......... then I think there should be some note regarding working with other TXT records and to provide guidelines to DNS management software people to not enforce a wildcat only TXT record management solution for their customers. The note should not add a requirement for verifiers though (if this is going to an IETF RFC issue). However, in my personal engineering opinion, it probably should add a note for verifiers to be ready for multiple string responses. Note: For SPF, verifiers are already expecting and looking for the v=spfxxx strings in merged TXT records responses. This is required to support SPF and SENDERID. I see this as one of those things of an aged document drafted 4-5 years ago at the time where SPF was viewed as a competitive solution to DKIM and mentioning SPF or giving it credit for existing was probably not on editors mind. But today, SPF is real. Domain Hosting sites have tools to support it for the small to mid size market that are using their domain hosting name servers. DKIM should realize its wide presence from a DNS public key standpoint, not in a "How to" but to provide insight about the possible conflictive issues and I think its really just about those "pesky" wildcard DNS feature as Crocker put it. -- HLS _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html