On Oct 1, 2004, at 3:34 AM, domainkeys-feedbackbase01(_at_)yahoo(_dot_)com
wrote:
By saying that TXT is inappropriate you are effectively saying that any
solution that uses the DNS is 5-10 years from practical deployment.
My own view is practical. If you can show that your use of TXT will
likely not cause truncation, use it. In my mind, SPF meets that goal
because both Wayne and I have run the scans to show it.
However, being practical also means that your claim of 5-10 years for
new RR use needs to be proven in the face of the current evidence...
which is that the majority of public-facing DNS servers support 3597.
And many of those that aren't 3597-capable are sporting
known-vulnerable code making it questionable that their admins care
much about MASS.
I don't see the value-add that NAPTR offers. It's a regex in DNS. Who
needs
that? What value does it add?
First, a regex isn't required. Second, its a pointer mechanism.
That's the value-add.
If it can't fit into a DNS packet, I actually favor an ESMTP extension
2048bit keys can fit in UDP DNS replies. Do you want more than that?
That's 342 bytes in base 64 (if my feeble math skills are working
correctly). I'd say you should use a prefix to avoid collisions.
Besides. ESMTP is point to point. We're talking about an end-to-end
solution
where intermediaries are irrelevant.
A lookup of the MX (for an ESMTP connection) vs. a key is just as
end-to-end or point-to-point. From a purely performance viewpoint, I
can see how this is unappealing. But getting back to the practical, I
said:
"I've talked to some email hosting providers that have a fairly big
hill to climb around the administration of adding another record (its
type doesn't matter). Their issue is that forward DNS is under the
control of another entity and just getting the MX to point to the right
place is headache."
-andy