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