Greg Connor [gconnor(_at_)nekodojo(_dot_)org] wrote:
--Harry Katz <hkatz(_at_)exchange(_dot_)microsoft(_dot_)com> wrote:
I sincerely hope we DO NOT want to define a new RR type! I'm sorry
folks, but this is simply a non-starter. As Meng Wong pointed out
earlier on this thread, the requirement to upgrade DNS software to
handle a new RR makes this a huge adoption barrier. If we want to
have a solution deployed in anything less than geologic
time, TXT is
the only pragmatic option.
And please let's not fool ourselves that using TXT records
is only an
"interim" solution. It's permanent. There's no way we're going to
get administrators to publish their MTA IP addresses in TXT records
today and then at some point in the future get them to re-publish
using another RR. And of course any software that
for these records would forever have to check both TXT and whatever
new RR we come up with since there will inevitably be laggards.
Er, I disagree. Strongly. Sure, upgrading your DNS is a
hassle, but I think those servers will be upgraded anyway
regardless of what we do.
We shouldn't underestimate the hassle and cost involved here, nor
overestimate the frequency with which this happens. Most organizations
will require significantly greater business justification for upgrading
than just support of a new RR type.
We *are* talking about writing a new RFC here. Five years from
now, whoever puts their names on that proposal will probably
look sheepishly at their toes while describing "Yeah we
really though TXT (or A or SRV) records were not ideal but we
didn't want to wait and we didn't want to put in an interim solution".
Five years from now, if we have widespread deployment of MARID
information in TXT records and it has contributed to a reduction in
spam, I for one would be proud to have my name on the document that led
to that result.
Speaking of barriers to adoption, XML is a big one. So is an
underscore in the label. :-)
If underscore is truly a blocker -- and no one I've spoken to has yet
said that it is -- then we'll happily get rid of it.
Let's save the XML discussion for another day. :-)