In a related note regarding yahoo.com, it needs to also address its hosted
domains too, such as geocities.com with DK headers and DNS records.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
----- Original Message -----
From: "wayne" <wayne(_at_)schlitt(_dot_)net>
To: "IETF MASS WG" <ietf-mailsig(_at_)imc(_dot_)org>
Sent: Thursday, July 07, 2005 12:02 AM
Subject: Re: What am I missing?
In
<20050707033819(_dot_)57235(_dot_)qmail(_at_)web40429(_dot_)mail(_dot_)yahoo(_dot_)com>
<domainkeys-feedbackbase02(_at_)yahoo(_dot_)com> writes:
What you're experiencing is a side-effect of the dig command. The
Are you sure about that?
Yes. If you have access to a DNS content server, why not create a TXT
record
with semi-colons and see what you see on the other side of dig.
Well, thanks for explaining this. I, too, was very confused by the
apparently "invalid" syntax of yahoo's own DK records. I figured I
was just missing something in the spec since I am *not* an expert on
DK.
That is exactly what is causing it. I was just thinking it would be
nicer to simply look at the "v=dk1" in these cases instead of
counting on a parsing error. Given the number of mistakes I'm seeing
with lots of other records, this would be a nice-to-have until there
is a dedicated RR.
Policy is waaaay nacent. I'd be surprised if the simplistic policy as
expressed
in the DK drafts survives - I certainly view it as a stop-gap until
smart
people can come up with better.
Well, it might be a good idea to determine when and why dig is
inserting these backslashes. I dunno about Andy, but while I'm not a
DNS expert, I probably know more about DNS than 99% of the sysadmins
out there (think: MSCEs). If it confused us, it probably will confuse
many others also.
-wayne