Douglas Otis wrote:
RFC2822 specifies "Internet Domain".
Yeah, good enough for ADSP. There is a note in 2822upd-06:
| A liberal syntax for the domain portion of addr-spec is
| given here. However, the domain portion contains addressing
| information specified by and used in other protocols (e.g.,
| [RFC1034], [RFC1035], [RFC1123], [I-D.klensin-rfc2821bis]).
| It is therefore incumbent upon implementations to conform to
| the syntax of addresses for the context in which they are used.
name spaces within corresponding services resolving addresses
and services could be introduced under differing TLDs.
They could, and they will do the right thing, or publish a
draft explaining what "the right thing" is if it's unclear.
PRNP was given as an example, since this scheme resolves
address structures needed to navigate through gateways and
tunnels.
AFAIK MS still thinks that SenderID solved the spam problem
in 2006, everybody uses it, and nobody bothered to inform
them that they confused PRA and SPF among other things. ;-)
Seriously, you don't want to discuss the "Cesidian root"
and Apple Talk on the DKIM list, or do you ? That's fun
stuff for edit wars in Wikipedia, or flame wars on the
Namedroppers list...
unique identifiers which may overlap DNS name space.
...their problem, they broke it, they fix it. Of course
odd things happen when name spaces overlap, e.g., what is
a "unique identifier" in this case ? For a unique number
in a name space UUID take 122 SHA-1 bits, that is "better"
than 122 MD5-bits. Some RFCs are hilarious, or I missed
the clue, completely.
using a scheme like name._group for example. With ADSP
imposing "existence" requirements, now only DNS determines
what is an Internet Domain.
Where do you want to get _adsp_.domainkey.name._group from ?
If the existence of name._group does not matter, what about
the uniqueness of _adsp._domainkey.name._group ? And under
what circumstances would IANA survive the introduction of a
_group TLD violating RFC 1123 and my 1123-erratum ? Don't
mess around with RFC 3696 :-(
The suggestion is to avoid conflicts by binding ADSP policy
assertions specifically to email addresses _suitable_ for
SMTP/DNS.
The existence check is at worst bound to class IN (please
check this) and limited to non-existence, where SMTP, HTTP,
NNTP, etc. don't enter the picture. FWIW "NXDOMAIN" also
means no WKS, no RP, no HINFO, no SRV (please check this).
When the ADSP existence scheme depends upon an NXDOMAIN,
this will fail to offer protections when either a network
or TLD provider introduces wildcards
Not for what we are talking about. As long as "something"
exists at claranet.de. TLD de. cannot create any wildcard
affecting xyzzy.claranet.de., www.xyzzy.claranet.de., etc.
or when the domain itself uses wildcards.
Yes, that's the case for xyzzy.claranet.de. So what ? It
is a stupid wildcard, permanently disabled due to abuse by
spammers sending more spam to @xyzzy than claranet.de was
willing to let me kill with POP3 over V.90. (They gave up,
JFTR, but admittedly I didn't insist on reviving @xyzzy :-)
By depending upon NXDOMAIN, ADSP protections just not
possible when wildcards are introduced.
ADSP and DKIM are not designed for wildcard tricks, we know
this, this has nothing to do with NXDOMAIN, it is just a
consequence of using _adsp._domainkey "property-subdomain-
labels" (correct term TBD, compare Dave's draft).
[Off Topic about 2821bis]
It is ludicrous to suggest domains publish bogus MX
records to avoid undesired SMTP traffic, but those
implementing SMTP can not be expected to publish valid
MX records. This is shameful.
I don't disagree. But obviously the PTB prefer to handle
it elsewhere, in separate RFCs.
Frank
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html