| ||At Large Membership and Civil Society Participation in ICANN||
This discussion has been archived.
No new comments can be posted.
Sitefinder's TOS - What if you don't agree to it?
Log in/Create an Account
| 1 comments
The Fine Print:
The following comments are owned by whoever posted them.
We are not responsible for them in any way.
I actually sent them an email a while back about this, here it is:|
"NATURE OF THE VERISIGN SERVICES.
You may have accessed the VeriSign Service(s) by initiating a query to our
DNS resolution service for a nonexistent domain name. We are unable to
resolve such queries through the DNS resolution service. "
YOUR USE OF THE VERISIGN SERVICES IS AT YOUR OWN RISK. IF YOU ARE
DISSATISFIED WITH ANY OF THE MATERIALS, RESULTS OR OTHER CONTENTS OF THE
VERISIGN SERVICES OR WITH THESE TERMS AND CONDITIONS, OUR PRIVACY STATEMENT,
OR OTHER POLICIES, YOUR SOLE REMEDY IS TO DISCONTINUE USE OF THE VERISIGN
SERVICES OR OUR SITE. "
Therefore, I wish to no longer use VeriSign's services. I demand that you
disable this feature for my IP address, which will be surrendered on
Blah blah blah, I knew they can't block me, or rather - wouldn't block me. But I did it to make a statement. And the cocky little support guys actually managed to get a canned response out to me:
-------------Start their response email-------------
Subject: Re: Re : SiteFinder (#5947-000276-9069\2769069) (KMM982553V28534L0KM)
Date: Thursday, September 18, 2003 9:59 PM
page, unfortunately we will be unable to remove your IP from the
Sitefinder Service. Below are the technical issues surrounding
Technical Issues and Information
SMTP Server Issues
We are developing and testing a software modification to reject SMTP
connections in a better fashion. This modification will be deployed as
quickly as possible.
VeriSign is not logging and has no plans to log any email address sent
to the Site Finder response server via SMTP. The SMTP server exists
only to bounce messages as described in our guidelines document.
Network diagnostics and spam detection
Utilities that currently use the DNS to determine if a domain exists can
use VeriSign's Whois server to accurately determine if a domain exists.
Many of the problems encountered when using spam detection utilities
that contain outdated domain existence data can be avoided by
maintaining up-to-date configuration data.
A domain with a nonexistent mail server in an MX record will be affected
by the wildcard. For example:
example.com. in mx 5 mail.example.com.
example.com. in mx 10 .com.
Before the introduction of the wildcard A record in .com and .net, in
the event that the mail server with preference 5 became unavailable,
mail transport agents (MTAs) sending mail to example.com would encounter
a Name Error when attempting delivery to the mail server with preference
10 and queue the message for later delivery. With the wildcard A record
present, an MTA will attempt delivery to VeriSign's mail servers. The
message will be rejected as described in our guidelines document.
Domain registrants must be diligent to ensure that nonexistent host
names do not appear as MX record targets. Before the wildcard, an MX
record with a nonexistent domain name as a target did not have the
effect: mail remained queued on MTAs throughout the Internet, not
flowing to a single server under the domain registrant's control as
intended. While some may consider this a benefit, it is in reality a
serious mis-configuration. For example, before the wildcard a malicious
third party could potentially re-register a nonexistent domain appearing
as an MX record target and subvert a domain's mail traffic.
In the example mis-configuration described above, mail destined for the
domain is not routed as the administrator believes. No feedback is
provided when a mail server with a registered name in the MX list fails.
(Under optimum circumstances, mail is silently queued and delivered,
provided the registered server becomes available soon enough.) One
could make the argument that actively bouncing mail (which is the case
with the presence of the wildcard A record in .com and .net) highlights
this serious mis-configuration.
Wildcards vs. Name Errors and the DNS Protocol
DNS wildcard syntax and resolution are fully documented and described in
RFC 1034. The DNS protocol is not violated in any way if a wildcard is
implemented in the DNS as described in our guidelines document.
Proprietary markings on the Site Finder implementation paper
The Site Finder implementation paper has been modified to remove all
"VeriSign Proprietary" markings. The document is freely available and
subject only to common copyright restrictions.
Registrar advantage with VeriSign link on the Site Finder page
The Site Finder page contains no direct links to the VeriSign home page.
Registrar name/site availability checking
Domain registrars should use VeriSign's Shared Registration System
service to determine if a domain name is available for registration.
Others should use Whois. In addition, the .com and .net name server
response to a query for a wildcard A record is deterministic and can be
recognized to note that a wildcard match will occur.
reporting purposes and to allow individuals to set preferences to filter
adult content. No personal information is collected. In addition, many
popular web browsers now allow users to block cookies. Blocking the
Site Finder cookie will prevent the cookie from being placed. More
that's available on the Site Finder web server.
Gotta love VeriSign
[ Reply to This | Parent
respective owner. The comments are property of their posters, all the rest © 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008 by ICANNWatch.Org. This web site was made with Slashcode, a web portal system written in perl. Slashcode is Free Software released under the GNU/GPL license.
You can syndicate our headlines in .rdf, .rss, or .xml. Domain registration services donated by DomainRegistry.com