ICANNWatch
 
  Inside ICANNWatch  
Submit Story
Home
Lost Password
Preferences
Site Messages
Top 10 Lists
Latest Comments
Search by topic

Our Mission
ICANN for Beginners
About Us
How To Use This Site
ICANNWatch FAQ
Slash Tech Info
Link to Us
Write to Us

  Useful ICANN sites  
  • ICANN itself
  • Bret Fausett's ICANN Blog
  • Internet Governance Project
  • UN Working Group on Internet Governance
  • Karl Auerbach web site
  • Müller-Maguhn home
  • UDRPinfo.com;
  • UDRPlaw.net;
  • CircleID;
  • LatinoamerICANN Project
  • ICB Tollfree News

  •   At Large Membership and Civil Society Participation in ICANN  
  • icannatlarge.com;
  • Noncommercial Users Constituency of ICANN
  • NAIS Project
  • ICANN At Large Study Committee Final Report
  • ICANN (non)Members page
  • ICANN Membership Election site

  • ICANN-Related Reading
    Browse ICANNWatch by Subject

    Ted Byfied
    - ICANN: Defending Our Precious Bodily Fluids
    - Ushering in Banality
    - ICANN! No U CANN't!
    - roving_reporter
    - DNS: A Short History and a Short Future

    David Farber
    - Overcoming ICANN (PFIR statement)

    A. Michael Froomkin
    - When We Say US™, We Mean It!
    - ICANN 2.0: Meet The New Boss
    - Habermas@ discourse.net: Toward a Critical Theory of Cyberspace
    - ICANN and Anti-Trust (with Mark Lemley)
    - Wrong Turn in Cyberspace: Using ICANN to Route Around the APA & the Constitution (html)
    - Form and Substance in Cyberspace
    - ICANN's "Uniform Dispute Resolution Policy"-- Causes and (Partial) Cures

    Milton Mueller
    - Ruling the Root
    - Success by Default: A New Profile of Domain Name Trademark Disputes under ICANN's UDRP
    - Dancing the Quango: ICANN as International Regulatory Regime
    - Goverments and Country Names: ICANN's Transformation into an Intergovernmental Regime
    - Competing DNS Roots: Creative Destruction or Just Plain Destruction?
    - Rough Justice: A Statistical Assessment of the UDRP
    - ICANN and Internet Governance

    David Post
    - Governing Cyberspace, or Where is James Madison When We Need Him?
    - The 'Unsettled Paradox': The Internet, the State, and the Consent of the Governed

    Jonathan Weinberg
    - Sitefinder and Internet Governance
    - ICANN, Internet Stability, and New Top Level Domains
    - Geeks and Greeks
    - ICANN and the Problem of Legitimacy

    Highlights of the ICANNWatch Archive
    (June 1999 - March 2001)


     
    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 | Top | 1 comments | Search Discussion
    Click this button to post a comment to this story
    The options below will change how the comments display
    Threshold:
    Check box to change your default comment view
    The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
    Funny
    by eireson on Sunday September 28 2003, @08:12PM (#12317)
    User #3863 Info
    I actually sent them an email a while back about this, here it is:
    -------------Start email-------------
    I do not agree with your SiteFinder terms of use, specifically the following
    section:
    "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. "

    And according to your Terms of use....
    "Sole Remedy.
    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
    request.
    -------------End email-------------
    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-------------
    From:
    To:
    Subject: Re: Re : SiteFinder (#5947-000276-9069\2769069) (KMM982553V28534L0KM)
    Date: Thursday, September 18, 2003 9:59 PM

    Dear Edward,

    The terms of use are for the navigation/content use of the Sitefinder
    page, unfortunately we will be unable to remove your IP from the
    Sitefinder Service. Below are the technical issues surrounding
    Sitefinder currently:

    SITEFINDER INFORMATION

    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
    desired
    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.

    Use of Cookies

    VeriSign uses cookies on the Site Finder web page for aggregate
    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
    information on the use of cookies can be found in the privacy policy
    that's available on the Site Finder web server.

    Best Regards,

    Will Shorter
    Customer Service
    VeriSign, Inc.
    www.verisign.com
    sitefinder@verisign-grs.com
    -------------End email-------------

    Gotta love VeriSign
    [ Reply to This | Parent ]


    Search ICANNWatch.org:


    Privacy Policy: We will not knowingly give out your personal data -- other than identifying your postings in the way you direct by setting your configuration options -- without a court order. All logos and trademarks in this site are property of their 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