Subject: Re: [ietf-dkim] ISSUE: Revise wildcard discussion

From: "Frank Ellermann" <[email-masked]>
Date: Sun, 1 Jun 2008 18:34:21 +0200

Dave Crocker wrote:

>> However multiple wildcard TXT records produce an undefined ADSP
>> result, which means you cannot also publish both ADSP records
>> and records for any other TXT-using protocol (such as SPF) for
>> a wildcard domain.

Identifying TXT records by initial "tags" such as "v=spf1" is easy
as long as the desired TXT record has an unambiguous version tag.

The various ADSP drafts fail to provide the essential version tag
for their identification, this is no general TXT wildcard problem.

The general TXT problem is the *size* of all RXT records combined,
and the various ADSP drafts refuse to share SPF records for their
limited size needs.

 Frank

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

---

From: Eliot Lear <[email-masked]>
Date: Mon, 02 Jun 2008 09:59:30 +0200

> and the various ADSP drafts refuse to share SPF records for their

While I myself am leaning away from TXT records for other reasons, this 
is not one of them.  ADSP is a bit more safe because like DKIM it uses a 
_adsp label.  If you look up a TXT record with that label it makes less 
sense to expect anything other than ADSP.

Eliot

---

From: "Frank Ellermann" <[email-masked]>
Date: Mon, 2 Jun 2008 10:44:10 +0200

> While I myself am leaning away from TXT records for other reasons,
> this is not one of them.  ADSP is a bit more safe because like DKIM
> it uses a _adsp label.  If you look up a TXT record with that label
> it makes less sense to expect anything other than ADSP.

As explained in Dave's message:  The "label" approach does not work 
with *wildcards*, for that you'd need a separate record type and/or
a "tag" for the identification in the case of a shared record type
(TXT, SPF, whatever).  But his reasoning was backwards, with a "tag"
for the identification of a desired record in a RR set it would also
work for wildcards until the size issue for shared RR types kills it.

See <http://tools.ietf.org/html/draft-iab-dns-choices#section-3.1>
for an "authoritative" (from my POV) statement about these issues.

 Frank

---

From: Eliot Lear <[email-masked]>
Date: Mon, 02 Jun 2008 11:22:01 +0200

Frank Ellermann wrote:
> See<http://tools.ietf.org/html/draft-iab-dns-choices#section-3.1>

Ok, I understand what you're saying.  Then actually I agree with this 
logic, and this WAS where I was pondering whether we should move to a 
new RR type, but I don't know if it is sufficient justification.  As I 
was reminded, because other child labels would countermand an ADSP 
wildcard, it's not clear to me that wildcards truly buy anything in this 
case.  Am I missing something?

Eliot

---

From: "Frank Ellermann" <[email-masked]>
Date: Mon, 2 Jun 2008 21:07:55 +0200

> Ok, I understand what you're saying.  Then actually I agree with
> this logic, and this WAS where I was pondering whether we should
> move to a new RR type, but I don't know if it is sufficient
> justification.

Apparently the WG didn't like new RR type, and it also didn't like
"sharing SPF" (dubbed as "subtyping" by the IAB).  For the reasons
stated in the IAB draft "subtyping" TXT is officially a non-starter.

I think we're free to specify an ADSP format with an initial string
allowing "subtyping" for the wildcard case, e.g., we could say that
ADSP reords MUST start with the five characters "dkim=", instead of
saying that they contain a "dkim" [FWS] "=" not necessarily at the
begin.

> it's not clear to me that wildcards truly buy anything in this 

I've no idea how popular MX / A / AAAA wildcards still are today,
wrt mail (i.e. spam) they can be a PITA.  So bad that the ISP of
[see my From address] decided to disable the mailbox after getting
too much spam for it - and maybe they even know that this resulted
in [see my Reply-To address] showing up in Internet drafts instead
of my old address in their domain.  

 Frank