On Jul 7, 2008, at 3:14 PM, Jim Fenton wrote:
John Levine wrote:
Well, maybe. There's plenty of other ways a record can be ill-
formed.
*.foo.example TXT "dkim=none dkim=discard"
*.foo.example TXT "dkim=a total crock nobody is gonna use"
Of course I didn't mean to imply that checking the first five bytes of
the ADSP record was going to guarantee validity of the rest of it.
The
key word in my statement above was "unintended".
Section 4.1 will be problematic when ADSP records are concurrent with
other TXT records also published at a wildcard domain.
,---
|A domain MUST NOT publish more than one ADSP record; the
|semantics of an ADSP lookup that returns multiple ADSP
|records for a single domain are undefined.
'---
The ADSP record is _any_ TXT record that exists below _adsp._domainkey
domain prefixes. While the "dkim=" tag is required, it could be
anywhere within the record.
When a domain attempts to shield address records from being considered
a valid source for unsigned messages, including the _domainkey prefix
as well can be considered detrimental since this will increase zone
size and administrative efforts. In addition, for smaller domains,
whenever the _domainkey zone is delegated to a third-party email
provider, ADSP will also be controlled. When separate domains below
the _domainkey are delegated to enable use of multiple third-party
providers, or to isolate ADSP control, then the third-party provider
remains reliant upon the domain to publish the ADSP record, or to
separately delegate the _adsp prefix as well.
ADSPs records below _adsp.<Author Domain> can be delegated, or
controlled separately in the same manner as the _domainkey record.
Placing the ADSP record below additional prefixes provides little
benefit, especially when tag placement for the required dkim= tag is
mandated as beginning the record. Concerns related to potential TXT
record confusion is reduced to an even greater degree than that
provided by the additional prefixes since these prefixes offer no
isolation for wildcard domains. In addition, placing _adsp below
_domainkey simply wastes an additional 11 bytes of payload. Why
attempt to optimize domain delegations for adsp records? MX records
are also likely involved when dealing with third-party providers.
Unlike DKIM public key roll-over, there should be little reason for
ongoing changes to ADSP records once established.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html