ICANN/GNSO GNSO Email List Archives

[registrars]


<<< Chronological Index >>>    <<< Thread Index >>>

[registrars] Re: An Opportunity to Prove A Point - Hi-Jacked Name At GoDaddy

  • To: <john@xxxxxxxxxxxxxxxxx>
  • Subject: [registrars] Re: An Opportunity to Prove A Point - Hi-Jacked Name At GoDaddy
  • From: elliot noss <enoss@xxxxxxxxxx>
  • Date: Thu, 21 Feb 2008 12:27:45 -0500
  • Cc: "'Tim Ruiz'" <tim@xxxxxxxxxxx>, "'Christine Jones'" <cjones@xxxxxxxxxxx>, "'Adam Dicker'" <amd@xxxxxxxxxxxxxxxxxxx>, <registrars@xxxxxxxxxxxxxx>, "'Bruce Tonkin'" <Bruce.Tonkin@xxxxxxxxxxxxxxxxxx>
  • In-reply-to: <003701c874ad$4a8fee50$6a01a8c0@cubensis>
  • List-id: registrars@xxxxxxxxxxxxxx
  • References: <003701c874ad$4a8fee50$6a01a8c0@cubensis>
  • Sender: owner-registrars@xxxxxxxxxxxxxx


in order to be consistent with my position, we will need to add to the facts. I state i) that in fact registrars remedy these situations themselves in the vast majority (read, nearly ALL) circumstances and ii) I have absolutely no problem with reasonable transfer restrictions on a second registrant transfer, as opposed to a second registrar transfer. this second point is appropriate subject matter for the current transfer review but, again, is dealing with the EXTREME edge case (like every few years?).

in the first case the registrant should be dealing with MIT to establish their fact pattern. then MIT should be reaching out to go daddy. this is the way that we (the industry) have been solving our problems since Tucows was bailing out phil sbarbaro's sorry ass. then MIT should provide go daddy with an indemnity and go daddy should return the name.

you are right john, let's see what they do. I know what we do and I know what both those organizations have done in the past on countless occasions. and john, as you know, your buyer is now on notice as to the facts and is thus no longer a bona fide purchaser for value without notice (which I do not believe would protect a buyer here in any event).

let's see what they do!

*sitting back and passing popcorn to john*

On 21-Feb-08, at 12:14 PM, John Berryhill wrote:


For those that enjoyed the Delhi fireworks show between myself and Elliot on the subject of Godaddy's interpretation of the transfer policy, a unique
opportunity has arisen to provide an acid test of whether Godaddy is
sincere, or whether the Transfer Policy is broken.

As you know, Elliot Noss and others have expressed eloquent and enthusiastic skepticism concerning the "anti-hi-jacking" rationale of Godaddy's 60 day
hold.

Here's what landed in my lap this morning.

Married.com has been registered since 1995 to Marriage Ministries
International through Melbourne IT as follows:

Domain Name.......... married.com
  Creation Date........ 1995-05-31
  Registration Date.... 2002-11-23
  Expiry Date.......... 2008-05-30
  Organisation Name.... Marriage Ministries International
  Organisation Address. 9132 W. Bowles Avenue
  Organisation Address. _
  Organisation Address. Littleton
  Organisation Address. 80123
  Organisation Address. CO
  Organisation Address. UNITED STATES

Admin Name........... Jason Phillipps
  Admin Address........ 9132 W. Bowles Avenue
  Admin Address........ _
  Admin Address........ Littleton
  Admin Address........ 80123
  Admin Address........ CO
  Admin Address........ UNITED STATES
  Admin Email.......... jasonphillipps@[xxxx]

On or about February 5, 2008, it was hi-jacked and transferred to GoDaddy,
most likely by compromise of the admin contact email address.

Registrant:
   Domain Manager DomainManager2006@xxxxxxxxx
   Sattarkhan Blvd.
   Copenhagen,  2400
   Denmark

The hi-jacker entered into a deal to sell the domain name through escrow.com
for $100,000.

I was contacted by the prospective buyer, who had contacted the former
registrant in the course of his due diligence. The former registrant had no idea how the domain name was transferred to GoDaddy, and when they contacted GoDaddy support, he was told to "use the UDRP" and that there was nothing
else GoDaddy could do.

Of course, the UDRP is useless here, since "married" wasn't being used as a trade or service mark for marriage counseling, and GoDaddy support's advice is typical of the useless things that are told to parties in this instance.

So, as the situation stands, and as I tried to convey to Elliot, it is in circumstances such as this one that I am GLAD the name is at GoDaddy, since
it is at least not going anywhere for another 45 days.

The remaining questions are these:

1. Is GoDaddy actually going to look into the situation and USE the 60 day period to resolve a domain hi-jacking? The initial indication from GoDaddy
support is "no".

2.  What is the mechanism by which a registrant may request his/her
registrar to institute a Transfer Dispute Resolution Proceeding? This ball is in Bruce's court. Melbourne IT provides no information to registrants that is readily accessible which, as I have long argued, is the fundamental flaw of the TDRS - there is no coupling between the people who've had their
names transferred without authorization, and the people who are in a
position to invoke the policy.

Now it may be that the registrant's admin email address was compromised. Still, both Melbourne IT and GoDaddy will be able to determine whether the originating IP address of the authorization is localizable to Colorado or to
somewhere else.

So, Elliot, let's fire up the oven, put on some crow, and find out who gets to eat it. Either (a) GoDaddy does nothing to investigate or remedy this hi-jacking, and their justification for the 60 day hold is a farce; (b) Melbourne IT does nothing, and the Transfer Policy dispute mechanism is a farce; or (c) the situation is appropriately resolved, and it turns out that
GoDaddy's policy actually does help address hi-jackings.

But, as it stands, the only hopeful point in the situation is that since the
name is at GoDaddy, it is going to stay there for a while.

The point is GoDaddy's to prove, or not.


John Berryhill, Ph.d., Esq.
4 West Front St.
Media, PA  19063
(610) 565-5601
(267) 386-8115 fax






<<< Chronological Index >>>    <<< Thread Index >>>