ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] ISSUE: 3.6.2.1 - Working with other TXT records

2010-10-15 15:08:13
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

<Prev in Thread] Current Thread [Next in Thread>