ICANN's recently released report, ICANN's Whois Data Accuracy and Availability Program: Description of Prior Efforts and New Compliance Initiatives [72KB PDF], is a summary of the Whois Data Problem Report System's (WDPRS) reports spanning a one-year period that concluded at the end of Fenruary 2007. In case you're not familiar with the WDPRS, it's system that tracks complaints about inaccurate or incomplete whois entries.

Notable facts from the report include:

• There were 50,189 reports for which ICANN received follow-up responses during the year.
• From these 50,189, 34,029 were unique domain names; the remaining 16,160 are duplicates.
• There's a “Tipping Point” going on here: most of the reports were filed by a few people: 1% of the, reporters are responsible for 90% of the reports. One individual was responsible for almost 40% of the reports.

According to the report, .info domains had the highest number of WDPRS reports, with 6.77 unique reports per 10,000 registrations. This is not a surprise given that inaccurate whois information is often the sign of a spammer and since .info domains are often used by spammers as they are relatively cheaper.

In response to the problem, ICANN will hold accuracy audits later this year in an attempt to clean up whois records. Each accredited registrar can expect to have their domain sampled by ICANN, and those with inaccurate data will be reported to WDPRS under an alias. For those domains that it reports for bad whois data, ICANN will double-check the domain's accuracy 45 days after its initial report to WDPRS.

Maybe I should go double-check my personal domains…

A Simple Explanation That's Long Overdue

Every now and again, I get requests for a simple explanation on the basics of writing an OpenSRS client app that's capable of provisioning and managing domain names. In the process of answering these requests, I found that there wasn't any clear and dirt-simple documentation on rolling your own client, nor was the necessary information all in one place.

I've decided to rectify the problem by writing an article that covers coding your open OpenSRS client from the ground up. My plan is to first post it here on the Tucows Blog and eventually have it added to the official Tucows API documentation.

XML over HTTPS POST: The Simplest Way to Communicate with the OpenSRS Server

Messages to and from the OpenSRS servers are formatted as XML documents, and the simplest way to send and receive them is to use HTTPS POST. It's the method that requires the least setting up, it uses libraries that are very likely to be in the default installation of your favorite programming language and it minimizes the amount of code you have to write. For these reasons, I prefer using the HTTPS POST method when building OpenSRS clients.

I'll spend most of this article covering two major aspects of communicating with the OpenSRS servers:

• Authenticating your client
• Building and sending a message

Authenticating Your Client

In order to communicate with the OpenSRS servers, you client needs to be able to authenticate itself by meeting three requirements:

• It must provide the server with your OpenSRS username
• It must provide the server with a message digest based on the message content and your OpenSRS private key
• It must be at an IP address that is on the “approved” list for your OpenSRS  username.

I'll cover these requirements in the next few sections.

Your OpenSRS Username

This is the easiest requirement to fulfill. If you have an OpenSRS account, you have an OpenSRS username.

(If you don't have an OpenSRS account, you can sign up for one here!)

Generating Your Private Key

As I mentioned earlier, one of the requirements for communicating with the server is a message digest generated using the message you want to send to the server and your OpenSRS private key.

Remember that there are two systems: the Live system and the “Horizon” testing system. Each is its own separate system, and your private key on one system will not work on the other.

If you've never generated your OpenSRS private key before, or if you've forgotten or lost your private it, you'll need to generate a new one.

To generate a new private key, navigate your browser to the appropriate Reseller Web Interface (RWI) page. Here's a link for the RWI for the Live system, and here's a link for the RWI for Horizon. Log in and scroll to the Profile Management section near the bottom of the page:

Near the bottom of the Profile Management section is a link marked Generate New Private Key. Click on it. You'll be greeted with the following dialog box:

Click OK. This will take you to the following page:

Right below the text that reads Cut and paste the private key listed below into your OpenSRS.conf file: is your new private key. Copy it and paste it somewhere for now — we'll use it shortly.

Two things to note about the private keys:

• A newly-generated private doesn't become active until about two minutes after it's generated. Wait the two minutes before using it!
• Private keys are 112 characters long.

Validating Your IP Address

As an added security measure, OpenSRS will only accept requests from IP addresses on the “approved” list for your OpenSRS account.

The link for adding an IP address to the “approved” list is just above the Generate New Private Key link, in the Profile Management near the bottom of the RWI main page:

Click on that link to take you to the OpenSRS Script/API Access page, where you can add your computer's IP address to the approved list.

A couple of things to note about the IP address list:

• Remember that the IP address list applies only to your account and for the specific environment (Live or Horizon).
• If you need to specify a range of IP addresses, use the Net Block drop-down menu to specify a range of 2, 4, 8, 16, 32, 64 or 128 addresses.
• You can add up to 5 IP addresses or ranges of IP addresses to the “approved” list.
• Once added to the “approved” list, it takes about an hour for the addition to take effect.

Constructing the Message

Now that we've got the authentication details out of the way, let's take a look at how a message to the OpenSRS servers is built when sending it via HTTPS POST.

It's pretty simple:

• The actual XML of the message goes into the body section of the message
• Additional information — such as authentication credentials — go into the message's headers.

The table below shows which headers are required and what goes in them, as well as what goes in the body:

                                                                             

Structure of Tucows API Messages Sent Using HTTPS POST
Headers	Content-Type	text/xml
	X-Username	Your Tucows API username goes here
	X-Signature	The message digest (see below) goes here
	Content-Length	The message length goes here
Body	The message goes here

Let's take a look at the trickiest part: the message digest.

Building the Message Digest

The message digest is built using the message that you want to send to the OpenSRS servers, your OpenSRS private key and an MD5 hash function that outputs its results in hexadecimal.

Here are the steps to generating the message digest:

1. Concatenate your private key to the end of the message that you want to send to the OpenSRS servers.
2. Generate an MD5 hexadecimal hash of that string.
3. Take the resulting hash and concatenate your private key to the end of it.
4. Generate an MD5 hexadecimal hash of that string.

The result of these steps is the message digest, which should be put into the X-Signature header.

Here's a graphic that illustrates generating a message digest:

A Simple API Command

The only thing left to do is choose the command that we want to send to the server. The structure of every possible API call is described in the OpenSRS API Specification [ online version | PDF version ], which includes request and response examples in both Perl and XML.

The example I use all the time is the Lookup Domain command because it's very simple. Here's the XML from page 198 of the OpenSRS API Specification for this command. which returns the status of a domain, which can be either “available” or “taken”.

Let's take a look at the XML for a Lookup Domain command that checks the availability of example.com. I've highlighted the parts that are of the most interest for this particular example.

<?xml version="1.0" encoding="UTF-8" standalone='yes'?>
<!DOCTYPE OPS_envelope SYSTEM 'ops.dtd'>
<OPS_envelope>
 <header>
   <version>0.9</version>
 </header>
 <body>
   <data_block>
     <dt_assoc>
       <item key=”protocol”>XCP</item>
       <item key=”action”>LOOKUP</item>
       <item key=”object”>DOMAIN</item>
       <item key=”attributes”>
         <dt_assoc>
           <item key=”domain”>example.com</item>
         </dt_assoc>
       </item>
     </dt_assoc>
   </data_block>
 </body>
</OPS_envelope>

The first area of highlighted text specifies that we're sending a message using the XCP protocol, which is the protocol for provisioning and managing domain names (the other one, which is for all other Tucows services except Blogware, is called TPP). It also specifies that the command that we want to execute is the Lookup Domain command.

The second area of highlighted text specifies the domain name whose status we'd like to look up: example.com. (RFC 2606 states that example.com, example.org and example.net are reserved and cannot be registered; they are “taken” by definition.)

Once the message above is received and acted upon by the OpenSRS servers, a response similar to the one below is returned. Once again, I've highlighted the parts that are of the most interest:

<?xml version='1.0' encoding="UTF-8" standalone="no" ?>
<!DOCTYPE OPS_envelope SYSTEM “ops.dtd”>
<OPS_envelope>
 <header>
  <version>0.9</version>
  </header>
 <body>
  <data_block>
   <dt_assoc>
    <item key=”protocol”>XCP</item>
    <item key=”object”>DOMAIN</item>
    <item key=”response_text”>response_text_goes_here</item>
    <item key=”action”>REPLY</item>
    <item key=”attributes”>
     <dt_assoc>
      <item key=”status”>domain_status_goes_here</item>
      <item key=”match”></item>
     </dt_assoc>
    </item>
    <item key=”response_code”>response_code_goes_here</item>
    <item key=”is_success”>either_0_or_1</item>
   </dt_assoc>
  </data_block>
 </body>
</OPS_envelope>

The two most important parts of the response are:

• The <item key="is_success"> element, which specifies whether or not the command was successfully executed. This element appears in the response for every OpenSRS API command and should be the first thing that a client application checks. The value returned is 1 if the command was successfully executed, 0 otherwise.
• The <item key="response_code"> element, which is a numeric code that describes the response. This element also appears in the response for every OpenSRS API command and should be the second thing that a client application checks.

Im the case of the Lookup Domain command, the response codes that you'll see most of the time are:

• 210 : Domain available.
• 211 : Domain taken.

You might have noticed the <item key="response_text"> and <item key="status"> elements in the the XML for the response. The information returned in these elements the same as the information in the <item key="response_code"> element; they're just spelled out in English. For example, if a domain is taken…

• the <item key="response_code"> element contains 210
• the <item key="response_text"> element contains “Domain taken”
• and the <item key="status"> contains “taken”.

I generally prefer to use the contents of the <item key="response_code"> element, as this code is less likely to be changed in future versions of the API.

Putting it All Together in Ruby

I've just presented you with enough information to write a quick little client application that checks a domain name for availability.

I'll use the Ruby programming language. A number of programmers I know are very interested in that particular programming language, partly because of the Ruby on Rails web application framework and partially because of the resurgence of interest in dynamic functional programming languages. It's also a language that isn't covered in the current documentation.

The application will be a simple command-line tool. To check a domain name for availability, the user should simply have to entr this at the command line:

ruby lookup-domain.rb domain_name

Let's get coding!

First, let's make sure that the necessary libraries, net/https,  digest/md5 and rexml/document are loaded:

require 'net/https'
require 'digest/md5'
require 'rexml/document'
include REXML

Now let's define the constant OPENSRS_SERVER. To connect to the Live server, use this code:

# Definition for Live server
OPENSRS_SERVER = 'rr-n1-tor.opensrs.net'

If you'd rather connect to the “Horizon” test server, you'll want to use this code instead:

# Definitions for "Horizon" test server
OPENSRS_SERVER = 'horizon.opensrs.net'

I recommend that you connect to the Live server for this particular application. You'll get real results, and there's no risk of you losing any money (some API commands, such as the one for registering a domain name, will debit your OpenSRS account).

Let's define a few constants…

OPENSRS_PORT = 55443

OPENSRS_USERNAME = 'your_username'
OPENSRS_PRIVATE_KEY = 'your_private_key'

DOMAIN_AVAILABLE = 210
DOMAIN_TAKEN = 211

We'll want to store the first command line argument, which is the domain name whose status we want to check:

domain = ARGV[0]

And now, the message:

requestXml = <<-END
<?xml version=”1.0″ encoding=”UTF-8″ standalone='yes'?>
<!DOCTYPE OPS_envelope SYSTEM 'ops.dtd'>
<OPS_envelope>
 <header>
   <version>0.9</version>
 </header>
 <body>
   <data_block>
     <dt_assoc>
       <item key=”protocol”>XCP</item>
       <item key=”action”>LOOKUP</item>
       <item key=”object”>DOMAIN</item>
       <item key=”attributes”>
         <dt_assoc>
           <item key=”domain”>#{domain}</item>
         </dt_assoc>
       </item>
     </dt_assoc>
   </data_block>
 </body>
</OPS_envelope>
END

And once we've defined the message, we can define a message digest:

message_digest = Digest::MD5.hexdigest(
                   Digest::MD5.hexdigest(requestXml + OPENSRS_PRIVATE_KEY) + OPENSRS_PRIVATE_KEY
                 )

While all that preamble out of the way, we can send the message:

http = Net::HTTP.new OPENSRS_SERVER, OPENSRS_PORT

begin
  http.use_ssl = true
  req = Net::HTTP::Post.new('/')
  req['Content-Type'] = 'text/xml'
  req['X-Username'] = OPENSRS_USERNAME
  req['X-Signature'] = message_digest
  req['Content-Length'] = requestXml.size.to_s

  response = http.request(req, requestXml)

ensure
  http.finish if http.started?

end

And now, it's time to parse the message and display the result:

response_doc = Document.new(response.body)
is_success = response_doc.root.elements[
               "body/data_block/dt_assoc/item[@key='is_success']“
             ].text.to_i
response_code = response_doc.root.elements[
                  "body/data_block/dt_assoc/item[@key='response_code']“
                ].text.to_i

if is_success == 1

  case response_code
    when DOMAIN_AVAILABLE
      puts “#{domain} is available.”
    when DOMAIN_TAKEN
      puts “Somebody already registered #{domain}.”
    else
      puts “This is one of those rare weird cases — 
            response code #{response_code}.”
  end 

else
  puts “Something weird happened at the server end — 
        response code #{response_code}. Try again.”
end

It's been a busy time here at Tucows over the past few weeks, but the good news is that we'll soon have lots of new stuff to show for it and I'll also be able to devote a little more time to blogging here at the Tucows blog. Here are some items I'm working on for next week:

• More information about our new and improved email service. Now that we've discussed some of the higher-level details (see this post and podcast), we'll talk about some of the technical underpinnings of our email service, plus the methodology we used to develop it.
• The simplest way to build OpenSRS client applications. There are actually two ways in which a client can communicate with the OpenSRS servers: the “standard” way and via HTTPS POST. The HTTPS POST way is much simpler, and with the assistance of nice diagrams like the one shown on the right, I'll show you how easy it is to write an OpenSRS client in your favourite programming language.
• The Domains Explained series of articles continues. I'll post the next article in which I expand on Elliot's article, Questions to Ask Before You Pick Your Domain Name Registrar.

There's some interesting stuff ahead, so watch this space!

Next month, Tucows will launch its new-and-improved hosted email service, which we built from the ground up to meet our customers' needs. I've been following this project from the very beginning, and over the next few weeks, I'll be posting all sorts of things — articles, podcasts, interviews and diagrams — on Tucows' email service, its features and the underlying technology.

In this first posting on email, I have a podcast interview with three key people here at Tucows about the new email service:

• Elliot Noss, Tucows' president and CEO
• Kim Phelan, Director of Product Management
• Rick Yazwinski, Director of Technical Operations and Planning

In the podcast, we talk about the importance of email, Tucows' focus on email and the technical and service advantages of our email service.

To list to the podcast, click the link below. The podcast is 18 minutes, 16 seconds long, just under 13MB in size and is an MP3 file that will play in any MP3 player, as well as iTunes and Windows Media Player.

Click here to play the podcast. (Right-click and select “Save as” to save it to your hard drive.)

We've had the podcast transcribed; the transcript appears below.

Podcast Transcript

[music]

Joey deVilla: Hello, and welcome to another Tucows Podcast. In this podcast, we'll be talking about Tucows Email and the new webmail feature. I'll be talking with CEO Elliot Noss, Director of Product Management Kim Phelan, and Director of Technical Operations and Planning Rick Yazwinski.

[music fades out; interview begins]

In the age of Web 2.0 and all sorts of new applications, why is this decades-old thing called “email” still important?

Elliot Noss: Well, I think that email, interestingly, has become, in orders of magnitude, more important than it used to be. One of the interesting things that we've observed over the last six months as email systems around the Internet have come under greater and greater pressure, both from load, but certainly, primarily from the massive amounts of spam that are now flowing through the system is that as there have been challenges around performance and deliverability across the Internet, you've seen businesses screaming in a way that, certainly, in my 12 years in this space have never seen before.

What has been clear to me is that the reliance that people, both individuals and businesses, now place on email in so many aspects of their lives has just taken it to a whole new level in terms of importance. So, just when you thought it couldn't get bigger, it did!

Joey:Why is Tucows, in particular, focusing on email?

Elliot: Well, this is something I've talked about previously, both on conference calls and on some of the earlier podcasts around some of the acquisitions that you and I did, Joey. The single largest providers of for-pay email, commercial email, of email that is central to people's Internet lives is delivered by service providers, and for service providers, there's really been a sea change over the last 12, 24, even as far back as 36 months.

For me, that centers around three things:

• One is, certainly, the massive increase in spam, where email is table stakes for service providers, and filtering spam was kind of a nice thing to have. Now, being able to do that at a massive scale, where 19 out of every 20 emails that pass through your system are garbage, has just become so much more difficult.
• The second is, now, the massive storage requirements. It's still the case, if you look around the Internet, that most service providers — most web hosting companies and ISPs — are still providing mailbox sizes of less than 100 MBs, or 100 MBs. That's a joke. There's no question that where Google, Yahoo, and Microsoft have taken us is to a world of — whether it's a GB, or two GBs, or five GBs, or certainly in our view — something bordering on unlimited storage has become an absolute requirement for email.
  
  By the way, that storage requirement is driven because people use email differently now. To go back to your first question about why is email still relevant, people use email as backup now; people use email as transport between themselves at the office and at home. People use email as archival storage in a fundamentally different way than they ever have. That creates this huge storage requirement for service providers, who typically could get away with some simple attached storage; now they're being driven into massive storage or uncompetitive email offerings.
• The third is around the fundamental changes we've seen in webmail over the last 12 to 24 months, where webmail has moved from a kind of crappy looking HTML that you used when you had to remotely, to, now, a place where the best webmail implementations are starting to rival desktop mail apps.

So, I think those three things have made it fundamentally different for service providers, and have fundamentally changed the economics and the calculus in terms of what service providers have to look at. As you know, we really like to find opportunities where we can help service providers, and supply them with things that allow them to be more competitive and more successful.

Joey: Earlier, you mentioned Google, Yahoo, and Microsoft, which brings up an interesting question, and that is: why would you go with a Tucows-based email service, when Google, Yahoo, and Microsoft are offering are offering it for free? Basically, how do you compete with free?

Elliot:So, there are two levels that you have to think about that at. One is the service provider level. I think it's a fundamentally different answer, but let's take that out to the end user, through the service provider. If you're a service provider, you need to think about why your customers are going to still want and take mail from you, and whether you care about that.

So, I start from if I'm a service provider, well, do I care if all of my customers are using Google, Yahoo, Microsoft, and, maybe, AOL for email. That's less likely in a service provider context. For me, the answer is clearly yes. I'm a fundamental believer that what service providers are in the business of doing is helping their customers use the Internet more easily and effectively. If we agree on that, and if we agree that email is the most important application in that usage, then to have that be supplied somewhere else — and when it's supplied somewhere else that means it's being supported somewhere else, or not supported at all — it's a fundamental disconnect, if I'm a service provider, between me and relationship I can build with my customer.

So, that's kind of the “OK, if I'm a service provider, why do I care?” Now, it's “Why should my customer care?” Why would my customer more want that to come from me — the hosting company or the ISP — than from Google, Yahoo, or Microsoft? There, I come down to roughly two or four important differences. First, those are, and will continue to be, generally, ad-supported models.

For me, personally, for the tiny increments in price that I need pay to get quality email from my service provider, for less than an expensive cup of coffee a month, for less than a cup of Starbucks coffee — one cup — put it in my monthly bundle, I can get email from my service provider with no advertising. That seems like an easy decision for me.

The second point is there's no question that a continuum that stretches from us through the service provider to the end user is going to provide, or should provide it we're all during our jobs, a significantly better user experience at a support and service level than Google, Yahoo, or Microsoft can provide — possibly, can possibly provide.

I say that because if you're a service provider, overwhelmingly it's the case that servicing and supporting that end user, helping them use the Internet, is what's in your DNA, and that's not what Google, Yahoo, or Microsoft are about. They all do great things, and do lots of them, but providing one to one support is not one of them, and it is for the folks that I'm talking about.

That's the second thing. I think that the third thing is one that we're going to start to see and hear of going forward, which is the fact that nobody has yet figured out how you migrate out of these services. One of the things, from my perspective, that people aren't making enough of out of that whole PhotoBucket/MySpace thing is that, boy, when you have free services, you probably don't own and control your data to nearly the extent that you should or will want to. That's, unfortunately, one of those things that you won't really feel the pain around, even though you care about it, until it's too late or until you have some sort of negative incident.

But, boy, if you're paying a service provider for email, and it's commercially provided and supported, your control of your data is going to be at a way higher level than it will be with a Google, Yahoo, or Microsoft, even though nobody's really figured out how to port of those places yet. So for me, those are the three big reasons.

Joey:Kim, it looks like you've got a fourth item that you have to add to Elliot's list. Go right head and tell me about it.

Kim Phelan:Well certainly, I realize that Microsoft and Google have announced the ability for people to use their own domain names with those tools. But, that's another aspect that I think about for the service provider relationship with their end customer: to be able to help along with that path. They've got names; they can then also bring that together with their email. Things like when we bought NetIdentity last year, that was exactly why we went there, that people have an online identity, and the loyalty to that online identity is huge. To have the service provider be able to weave that story and provide that service to them, I think, is great.

Joey:All right. Well Kim, you're the Product Manager for Email; tell us about the highlights of Tucows' Email Service.

Kim:All right. Obviously, with the background that Elliot provided, we really wanted to look at our email offering and build a new offering that really made sure that we were supporting the, obviously, desktop users that exist today, who are using those clients, but also really allow our service providers to compete against the Googles and the Yahoos of the world by a really great webmail experience.

So, we're really looking at how to make webmail not just something you have to use when you're traveling, but something want to use. Just like Gmail has changed how we look at webmail, we want to do the same thing but provide it in a way that's really centered around how the service provider wants to deliver. So, whether that's brandability, with Tucows being totally in the background, but just email that works and is really competitive and works inside their existing infrastructure.

Joey:Rick, as the tech guy, tell us a little bit about the underlying technology — the hamsters on wheels behind all this.

Rick Yazwinski:Our new email product is really a combination of the best of breed — hardware and software platforms that we could put together into the solution. From a hardware perspective, we have all the big names that you would expect to see: NetApp for storage, Sun with their 64-bit AMD Platforms, big IP load balancers to distribute the traffic across our farms.

From a software perspective, we've really looked at the solutions that we've run in the past, both the Critical Path hosted and the CommuniGate one previous, and seen what they did really well and where we had problems with those. From the hosted platform, we took some of the really leading-edge stuff that were doing, merged it with some of the Tucows legacy platform products that we had, then finally layered on a set of componentry from the open source realm that is being used for email delivery world-wide. With this combination, we have a solution that is really robust, very scalable, and we're very excited about it.

Joey:So Rick, all this great underlying hardware and software technology; what does it provide in the end?

Rick:I think the big three things that I would call out, specifically, in roughly the order that our customers would experience them, would be:

• First, the ease of integration. Our new platform is very easy to start communicating with, and to start creating users. We've scaled it and done a significant amount of testing around rolling out very large user bases — multi-million user bases into the mail solution. Where, historically, that might take days or weeks, it now takes hours. So, to get a customer going in the platform is now a very simple and quick operation.
• The second high-level item that I would touch on would be deliverability. We know that today, in the real world, people use email as they do conversations. They expect mail to be delivered; they expect it to be delivered in near real-time. Paging systems, doctors appointments, meetings at the office, interoffice communication; all those types of things are happening within email, and people just have the expectation that it happens. We found that with email it's very, very easy to disappoint. Five minutes of delay with an email translates into customer disappointment. What we're trying to build with this solution, and what we will build with this solution is excitement and delight.
  
  We've done this with that software/hardware layer that we were talking about, so the technology layer is very important. We also do a lot of research around optimizing mail flow, and getting that expectation met in the very, very large mail clusters that we're talking about.
• The last point that I would talk about is performance in the large, and this speaks to the power users that we're starting to see come on and using email, as Elliott was saying, as an archival means — as a way of tracking their history, as a way of documenting a company's past or their past in their department. At Tucows, in our operations department, we had guys with in-boxes with 10,000 messages in them.
  
  This exposed a challenge to us that we really didn't expect when we were looking at this problem space. It took a reasonable amount of work to work around; with some smart use of caching and some technologies that I'm not going go into here, we managed to overcome those in really interesting ways that give the end users a really clean, fast, and responsive experience.

Joey:Kim, beyond the nuts and bolts, the hardware/software combination that actually makes the email service go, what else is there that Tucows provides?

Kim:Well, Tucows provides — it's a hard to quantify benefit, but it really comes down to the human side of things. In the last six to 12 months, we've certainly learned a lot of lessons around anti-spam and how it's really changing. The volume is just exorbitant now.

Part of it is having good filters, and that should be a non-starter. But the second half of it is the human part, which is how do you deal with those different attacks. When you have all of these mail providers at war with each other, trying to the best service ever, there's always somebody blogging someone else.

Tucows actually has two different teams that deal with those types of issues:

• We have an abuse team, and they have great relationships with all of the mail providers and any of the spam list providers as well. It's up to them to actually work with those providers to make sure that any issues are eliminated.
• Then, the other side of it is our compliance team. We have some pretty extensive experience because of our domains background. Whether it's regulatory issues, legal issues, or even law enforcement issues, we take that same type of experience with our compliance group when it comes down to email, as well. So let's say one of your users has a phishing attack related to your email, we will certainly be reaching out to you as a service provider to help you with that problem and work through it, instead of you having to deal with it on your own.

So, it's that human side of things — good technology is great, but you also have our support, as well.

Elliot:It's our experience that the human side is what has the greatest impact on deliverability, and deliverability is single largest factor as it relates to support calls. I think that's such a “what's in it for me?”

 

[music fades in; interview ends]

Joey:This has been a podcast about Tucows Email Service and the new webmail feature with CEO Elliot Noss, Director of Product Management Kim Phelan, and Director of Technical Operations and Planning Rick Yazwinski. I'm Technical Evangelist Joey deVilla, your host.

For more information about Tucows Services, please visit our services website at services.tucows.com.

Thanks for listening.