only the app (not the entire network) needs to know which port to
use, and this doesn't require that every port be assigned to a
specific app.
You can't have it both ways. Either the app is so widespread that the
port in use is at least a de facto standard or it is a "de jure"
standard.
False. Many ports have neither a de factor nor a de jure assignment.
Either way it is possible to respond appropriately.
False. As I pointed out earlier, there is no SMTP respose which is
equivalent to "this domain does not exist". Furthermore there are
failure modes associated with the wildcard MX record that do not
exist if the server returns NXDOMAIN. For instance, if their SMTP
server is down or unreachable (as it might be from time to time), the
sender will keep retrying to send the message when it should have failed
immediately with NXDOMAIN.
Frankly, your apologies for Verisign's abuse aren't very credible.
The only appropriate response to this situation is to punish Verisign.
But I do agree that in the general case there are a lot of ports to
worry about. I just don't think the general case is a practical
concern. So perhaps we just disagree?
Perhaps. I actually care about preserving the Internet's ability to
support a wide variety of applications. So arguments of the form
"it works for the web and email, therefore the practical concerns
are taken care of" don't wash. Particularly when it doesn't even
do the right thing for either the web or email. Hint: just because
the protocol is HTTP doesn't mean that the client has a human
typing URLs in and looking at the output.
> in fact, a 550 response in SMTP is a different condition
> from NXDOMAIN, and sometimes the difference is important -
> as the spam filter folks have discovered.
>
> Yes and this could be fixed with a new well-defined error code
NO Jim. VERISIGN DOES NOT HAVE THE RIGHT TO IMPOSE DISRUPTIVE
CHANGE ON THE INTERNET, not even with advance notice.
I'm not so sure. Others on this list and other lists, some more
qualified than I, have been asserting there are no rules -- technical
or otherwise -- to prevent Verisign and others from doing what they've
done.
Nothing gives VeriSign the right to misrepresent the contents of the
registry. If it's wrong for businesses to register individual
misspelled domain names in the hopes of getting misspelled queries
redirected to their sites, it is surely wrong for VeriSign to do the
same thing for ALL unregistered domains within COM and NET.
Oh we can certainly debate philosophical positions like "do not
harm," but what exactly is the disruption here?
Have you not been paying attention? When you try to download a web page
that doesn't exist, you don't get a "host does not exist" error, you get
a redirect to a web page. That's fraud. When you try to verify that a
domain is valid, you don't get NXDOMAIN, you get an A record. That's
also fraud. When you try to talk to another port, you get connection
refused, so instead of getting the error that corresponds to "no such
host" you'll probably think it is a temporary error (say, the server is
down) and try again later.
It is a gross protocol violation to take an explicit error indication
that has a very specific meaning and instead map it to what in some
cases looks like valid output, and in other cases looks like a very
different kind of error.
Correct me if I'm wrong, the principle disruption -- and I want to
emphasize disruption here -- I've seen is that a particular spam
indicator no longer works as expected.
You are wrong.
Okay, yes, there may be technical DNS issues but it is still not
disruptive to the Internet infrastructure in general as far as I can
tell.
It's broken the ability to detect misspelled domains for every
application and every protocol, for every name under .COM or .NET.
Yes, let's focus on the issue. But let's not ignore who is doing
it either.
Ignore, no. But let's not start Verisign bashing either.
It's not bashing them to speak the truth about what they are doing.
Keith