ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Issue 1576: Revise wildcard discussion

2008-07-05 05:39:02
     A simple "MUST start with 'dkim='" (or similar) could fix it.

But to what end?  In what circumstance would a wildcard that stops at an 
existing label be at all useful?  This is where I have been bashing my head.

Let's pretend that we want to try to tell the world that we don't send
mail from all the subdomains we don't send mail from:

*.foo.com. mx 0 .                       ; MX says no mail
*.foo.com. txt "v=spf1 -all"            ; SPF says no mail
*.foo.com. txt "spf2.0/mfrom,pra -all"  ; Sender ID says no mail
*.foo.com. txt "dkim=discardable"       ; ADSP says no mail

So you can look up the MX or TXT for plugh.foo.com and get answers,
and you can also look up _adsp._domainkey.plugh.foo.com, only you get
the same answers.

Plan A: forget that silly prefixed name stuff and add yet another
magic string to tell our records apart from the other umpteen strings
that will soon overflow our 512 byte buffer.

Plan B: note that DNS wildcards, once again, don't do what you want
particularly when prefixed names are involved.  This issue is not
unique to ADSP and affects DKIM keys as well.

I believe we chose Plan B.

R's,
John

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html