--"Eric A. Hall" <ehall(_at_)ehsco(_dot_)com> wrote:
DNS is prickly enough (and there are enough weird apps) that delicate
architecture is necessary if you want things to work smoothly. In
hotmail's case, for example, things eventually work sure, but the weird
systems have to fail out at least once. Should the infrastructure be
designed around reality?
Now, this is just one person's opinion, but I think you are looking for
some other word than "designed".
Please, use an RR that holds a URL pointing to an XML document
instead.
I think we are in the MARID working group (Mail Authorization Records
_In_DNS_). Are you in the right place? :)
So stick the XML documents into an ESMTP verb instead. Really. We're
talking about SMTP here and if the SMTP client knows that it needs these
policy documents, well golly, let him go fetch and cache somewhere that's
useful for him. Why are we jamming SMTP policy into DNS anyway when the
SMTP client is what's going to be making the policy decisions?
OK, I was half-joking the first time, but it was meant to be a reminder
that the IN DNS is part of this group's charter. You are
describing/advocating something that is outside this group's charter. For
sure.
If you disagree with the group's charter, please don't try to derail it.
You can go off and start a MARIH or MARIS group and leave the MARID group
alone.
Personally, I will be working on solutions that put the authorization info
in DNS. I will not be spending any more time and effort explaining myself
in this area. I will also politely remind you of the three posts per day
limit; we have found this limit to be useful in making sure that our
bandwidth and our attention is being used for topics that are in scope and
of interest to everyone.
MARID: mx://mydomain.com/policy
smtp-c: connects MX
smtp-s: 220-POLICY
smtp-c: POLICY
smtp-s: <xml...>
done.
--
Eric A. Hall http://www.ehsco.com/
Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>