These days, anyone who registers a domain name is bombarded by a whole series of emails. While this feels spammy, many of these emails are legitimate, sent by registrars who are required to fill the inboxes of their customers with notifications and verification requests, as mandated by an ever-increasing number of intertwined ICANN policies.
Even looking at each of these policies in isolation, it is not clear whether each achieves its intended, individual purpose. But the real “fun” starts when all these policies come together to create a living nightmare for domain name registrants. To illustrate this point, let’s look at a real-life example we’ve seen over the last couple of weeks.
Tucows has a global network of resellers who serve registrants all across the world, including India. One reseller in that region recently contacted us – in an understandable panic – because we had suspended several hundreds of their customers’ domains. Bizarrely, there was no way for those customers, or for us, to unsuspend the affected domains without breaching ICANN policy. What had happened?
Here’s the general scenario:
A customer in India registered a domain through their reseller at OpenSRS. This triggered a routine verification process, as required by our ICANN Registrar Accreditation Agreement. This process is generally pretty simple. We send an email to the registrant, asking them to confirm their contact details. If the registrant, for whatever reason, does not provide confirmation within 15 days, we are required to suspend the domain name. Now in this particular scenario, our verification request never made it to the registrant’s inbox, even after multiple attempts to resend it.
“No big deal,” you would think, “just change the email address and try again.” And that’s exactly what the customer did. Now, however, they had unknowingly entered into the mystifying realm of ICANN Transfer Policy. According to this policy, even the slightest change to a registrant’s first name, last name, organization, or email address is considered a Change of Registrant. Any such change requires the registrar to obtain confirmation from both the current and the new registrant before the update can be made. Of course, to obtain such confirmation, the registrar needs to send an email with a unique link to both the old and the new email address.
You’re probably thinking, “wait a minute – if you want to change the email address on file because it’s not working, you can only do so by replying to an email that was sent to this same address, an email you have no way to receive?”. Yes, that’s right. But to ICANN’s credit, the transfer policy does offer a way out of this would-be paradox: it also allows registrars to send a unique link via SMS instead.
So once again, the reseller took the next logical step and attempted to send the confirmation link via SMS. And once again, yet again, the registrant received nothing. The SMS never arrived, and in the meantime, the clock for the initial verification request kept ticking. The 15 days had passed, and the customer’s domain was suspended. The customer even updated their phone number to an alternative one, a change which, surprisingly enough, the policy allows for without completion of the usual verification cycle. Still, our SMS did not get through. Apparently, India recently introduced measures to protect their consumers from unsolicited SMS marketing, and our verification messages seem to be miscategorized as promotional.
Without the verification link in the SMS, the customer had no way to confirm the change of email address, and therefore no way to complete the verification process and lift the suspension on their domain. This scenario played out on a mass scale to produce hundreds of frustrated registrants, and the ICANN community should take note. It may have been created with the best of intentions, but ICANN policy that leads registrants to such dead-ends creates a terrible user experience and is, ultimately, a bad policy.
We are, of course, working with our SMS provider to resolve the filtering situation so we can get these domains back online as soon as possible. But the most customer-friendly solution would be for us to recognize this as an obvious failure of policy, and manually unsuspend the domains until the situation has been resolved. Unfortunately, this option is not available to us.
ICANN is rigorously (and blindly, we might add) enforcing all policies through their compliance department. Every day, we need to respond to multiple ICANN compliance investigations, and in each case, must demonstrate, in detail, that we have followed the exact language of all policy requirements. Deviations in the form of special exemptions, even if made in good faith, as in the situation described above, are not accepted, and can ultimately lead to a suspension of our ICANN accreditation. It seems it doesn’t matter how bad ICANN policy is – as long as it is in effect, ICANN compliance will enforce it without looking left or right.
The entire situation is deeply frustrating for everyone involved. The customer has purchased a domain and cannot use it. The reseller, try as they might to help their customer, has found themselves caught up in a series of policy dead-ends. We would love to help, but thanks to the iron fist of ICANN compliance, are forced to follow bad policy. We’re now left to hope that the Telcos in India will prove to be more open to reason and work with us to change the way our SMS messages are relayed to their clients.
This example doesn’t just illustrate how the ICANN organization is failing in its duty to reasonably enforce policy; it makes clear the fact that the entire ICANN community, as the body responsible for creating policy, is failing domain name registrants – the very group of people that ICANN, and all of us in this industry, are intended to serve.
ICANN’s policy development process is obviously broken. It’s equally obvious that the ICANN community’s approach to fixing it must be grounded in a solid understanding of their customers’ needs and a commitment to a better registrant experience. We need to refocus our efforts on creating policy that protects registrants, without creating unintended loopholes and dead-ends. Until then, all we can do is wish the best of luck to our customers in India and elsewhere in the world.