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 ;-)
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.
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).
Let's solve problems with completely different technlogies
later, and after we've seen that ADSP makes sense for email,
that will take more than a year.
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...
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.
Frank
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html