On Apr 15, 2008, at 7:33 PM, Frank Ellermann wrote:
Douglas Otis wrote:
This is still assuming use of DNS in conjunction with some future
transport.
Yes, ADSP is published using DNS, and it's about "mail", the
abstract says. ADSP flags in Fido nodelists for the purposes of
Fidomail is not discussed in RFC 5016 (sorry, couldn't resist after
you forced me to figure out what "PNRP" is ;-)
Okay.
It seems using DNS to assert policy necessitates use of DNS by all
possible transports.
When I mentioned missing domain literals I meant it, but in essence,
yes, the format of mail addresses in 2822upd is for DNS lookup, not
for Fido, UUCP, or X.500.
Since it is impossible for domain literals to represent a signing
domain for DKIM, it would seem obvious literal addressing is a matter
not covered by ADSP.
RFC2822 specifies "Internet Domain". While the term Internet Domain
infers a single name space, name spaces within corresponding services
resolving addresses and services could be introduced under differing
TLDs. PRNP was given as an example, since this scheme resolves
address structures needed to navigate through gateways and tunnels.
While this scheme is proprietary, existence of an enhanced name
service represents a current need being fulfilled. PRNP allows groups
to assign "friendly names" with unique identifiers which may overlap
DNS name space. Even so, this name space could be defined in a
complaint manner using a scheme like name._group for example. With
ADSP imposing "existence" requirements, now only DNS determines what
is an Internet Domain.
Unless consensus surrounding ADSP being forever linked to SMTP/DNS
can be established, an assumption of 'existence' checks seems
rather dubious.
DKIM isn't bound to SMTP, and existence checks for something that's
no domain might not need DNS. But the discussed ADSP draft wants us
to look up _adsp._domainkey.example. in DNS if example. exists in
DNS (swapping steps 1 and 2).
Agreed, DKIM is not bound to SMTP. The suggestion is to avoid
conflicts by binding ADSP policy assertions specifically to email
addresses _suitable_ for SMTP/DNS. The current ADSP draft requires
RFC2822 Internet Domains "exist" within DNS, which is not currently
required. ADSP stipulates DNS. ADSP is to benefit SMTP.
Let's solve problems with completely different technologies later,
and after we've seen that ADSP makes sense for email, that will take
more than a year.
Agreed. So limit the scope of the policy assertion to just SMTP/DNS.
Consensus should be reached about what ADSP "existence" requirements
really imply.
The NXDOMAIN existence check also ignores issues related wildcards
There are no wildcard issues I'm aware of. Nothing outside of a
zone, neither below nor above it, can create wildcards affecting the
zone. Please correct me if that's wrong, and give an example of
what you have in mind...
When the ADSP existence scheme depends upon an NXDOMAIN, this will
fail to offer protections when either a network or TLD provider
introduces wildcards, or when the domain itself uses wildcards. By
depending upon NXDOMAIN, ADSP protections just not possible when
wildcards are introduced.
It is rather ironic a well considered alternative policy scheme
depended upon use of wildcards and publishing records at every node
blocking the wildcard.
...dunno what you mean. A single existing node blocks any wildcard
above it for the complete subtree where it is the root, doesn't
it ? If you are interested in domain.example. make sure that it has
an A or MX or whatever, and there is no wildcard that could affect
anything below domain.example.
Skipping your 2821bis rant, I supported you as good as I could, when
Keith gave up the battle was lost from my POV.
Perhaps pride inhibits an ability to impose necessary discipline,
similar to a proud parent ignoring their misbehaving child. 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.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html