SquareAnswer’s bid to control email

A startup called SquareAnswer has the magic bullet that will kill spam and make your inbox only receive mail from "real people."

...or perhaps not. Certainly, some of the ideas have been tried before, although not all of them combined. This post outlines their approach.

Simply put, SquareAnswer wants to have all email senders store a password (or "key") in a centralized database, without which they cannot send email. The key will "prove" that the sender is who they say they are. Senders supply the key in a special message header or appended to the subject line.

The theory is that this will prevent spam, as spammers can only survive by being anonymous. There are some wrinkles, though:

  1. If you want to send a message to a SquareAnswer-protected user and you've not signed up, your message will get caught in challenge/response
    . As we argued last week, this is bad for most users, and very bad for legitimate bulk emailers (e.g. newsletters or direct marketers).
  2. SquareAnswer argues that they have categorization rules that try to not send challenges to legitimate bulk emailers. That's a very difficult job: guessing whether a sender is a spammer or a legitimate bulk sender. We're sceptical that they can successfully do this.
  3. It relies on one single, enormous, centralized database (with billions of entries, if this were successful). This sort of
    architecture doesn't work on the Internet. SquareAnswer is trying to address the previous issue by
    partnering with infrastructure providers, to replicate the entire database in several locations.
  4. We think it would be better to distribute the database, with partial caches, in the same way that the DNS works. Heck, why not just store the information in the DNS anyway, using one-way encryption so that ?
  5. Spammers will attack it. As well as denial of service attacks, what's to stop a virus stealing keys? The problem is that the keys are public; visible to all in the headers of the messages.
  6. Far better if there was a private key, which could be combined with a random number and hashed to create a public key. This would be unique for each message. Of course, that's now additional work for the centralized infrastructure, and you couldn't now use the DNS for that.
  7. Successful implementation requires senders to install a plugin to their email client. Supporting all the different clients out there is a large task. It'll be hard for them to support web-based platforms like Hotmail, Yahoo!Mail, and Gmail.
  8. SquareAnswer also wants to run a another bonding program for
    legitimate bulk senders. That's an awful lot of bonds that senders are
    going to have to put up for maximum deliverability. The process of
    deciding if a bonded sender is spamming can be very subjective. TRUSTe
    and Habeas found this out very quickly. We wonder if the company has
    under-estimated that aspect.

SquareAnswer is charging ISPs $360 per million received messages for the right to check the keys of incoming messages. That works out at about 50¢ per average user per month. So SquareAnswer is effectively financing the ISP's purchase; the pricing model is aligned well with the typical ISP's business model. But are they adequately funded to sustain operations without up-front revenue?

All in all, an "interesting" development. We have reservations, but the company has answers to some of them. However, it's a small, self-funded startup; we hope it's not bitten off more than it can chew.

One Comment

  1. Posted April 19, 2005 at 11:24 AM | Permalink

    1) SquareAnswer’s Challenge Response is much different than any other to date – it was developed with newsletters and direct marketers in mind. Senders can avoid it altogether by going to http://www.imarealperson.com or http://www.imabulkmailer.com. Protected recipients can also categorize incoming bulk mail as opt-in or bulk which then starts a human-based procedure for adding these senders to the clearinghouse.

    2) Creating rules to tell the difference between real people and bulk senders such as auto-responses, lists, and newsletters is pretty easy; the bulk senders don’t get challenged. We only challenge real people and spammers trying to look like real people.

    3) Actually, the size of the database isn’t a problem (The billion or so email addresses that exist today would require less than 200Gb of storage). The challenge is in the number of transactions – there are several vendors that have proposed distributed solutions to this problem and are eager to participate in solving the world’s spam problem.

    4) Fundamentally this can’t work for the same reason SPF won’t stop spam. The spammers simply set up their own DNS servers and enter whatever records are necessary – even if it is only for a few hours before the blacklists and filters determine it is a spammer – domains are cheap.

    5) Since the processing occurs at the ISP, a DOS attack would effectively have to attack all ISPs. Plugins for Outlook and Outlook express are complete and others are currently being developed that will make it difficult for viruses to steal public keys. Since the distributed clearinghouse is centrally maintained, it will have the ability to react appropriately to stolen keys.

    6) This approach would likely have a much slower adoption since it would be more difficult for the average sender to use and understand.

    7) The beauty of our system as it stands is that plugins are NOT required. The Plugins simply automate the process for those who whish to save the 10 key strokes on each message they send. Although supporting all the different clients may seem daunting, Outlook and Outlook Express have 70% of the market and Version 1 of those plugins are complete.

    8) Although our concept is similar to other bonding systems in that the sender pays a fee – that is where the similarities end. Our system does not discriminate between senders, we simply enforce the rules at the gateway – the bulk sender makes an economic decision for each campaign. We also will provide tools for the bulk sender to trim their lists thereby minimizing the cost of returns/complaints.

Post a comment

You must be logged in to post a comment. To comment, first join our community.