Fred Lackey.

Work / SpamJammer

Case study · SpamJammer, acquired by a major antivirus company

From renting email lists to stopping spam

How I shut down my own email-list business when it stopped sitting right with me, built a service that made every unknown sender prove they were real, and turned it into self-organizing rack appliances that a major antivirus company acquired.

Short link: fredlackey.com/spamjammer
held until confirmed SpamJammer SpamJammer SpamJammer Prove you’re real. Then you’re delivered.

Executive brief

The problem

Unsolicited bulk email was flooding inboxes, and I knew the business from the inside: my own company, 321 Email, built targeted lists from newsgroup addresses and mailed them in bulk. It made money from the first day and felt dirtier every week. I shut it down.

What I built

SpamJammer, a service that held mail from unknown senders and released it only after the sender clicked a unique confirmation link. It began as a tool for my own inbox, became a hosted service, and was rebuilt in ANSI C and C++ to ship as rack appliances.

The outcome

SpamJammer grew from a hosted service into an enterprise appliance that scaled by adding units. A major antivirus company acquired it and made it the core engine of its anti-spam offerings.

Shut downmy own email-list business, on principle
Millionsof messages through a custom mail transfer agent
Plug & playappliances that found each other and divided the work
Acquiredby a major antivirus company, as its anti-spam engine

The situation

SpamJammer had two beginnings: a business I walked away from, and an inbox I could no longer use.

Back then, people talked in newsgroups: public discussion forums run by universities and other organizations, read in programs like Netscape Communicator. Every post showed its author’s email address, and every newsgroup had a topic. I realized I knew what each group was about and how to reach the people in it, so I wrote software to collect those addresses and built a business on them, 321 Email, which created targeted email lists. There were no laws against bulk email yet, and hardly anyone called it spam. Within the first four hours, $1,000 in credit-card orders had come in. That was addictive.

The engineering was the fun part. In a room at home I ran about twenty cloned computers, each set up to boot two ways under Windows 95. In one configuration a machine used my ISDN lines to pull its next job from the database; then it rebooted into the other, changed its own dial plan, and called out over an ordinary phone line through a fresh internet provider. When a job finished, it rebooted and fetched the next one. I could feed it new account details from a web form and run the whole thing remotely. It was crude, and it was a kid’s project, but it was a semi-autonomous system I could steer from anywhere. Getting past each barrier was the challenge that kept me at it.

Internet providers didn’t share my enthusiasm. They shut my accounts down, I opened new ones, and I kept building systems to get around being shut down. I was a dumb kid. None of it was illegal, and it was fascinating how quickly the money came. But that constant need to evade felt deceitful, and in the end it felt dirty. I didn’t want that feeling anymore, so I shut 321 Email down and put my effort into fighting unsolicited email instead of sending it. That decision pointed me at the problem SpamJammer would solve.

The other beginning was my own inbox. I used Bigfoot.com, a service that gave you one email address for life and forwarded your mail wherever it needed to go. People were switching internet providers constantly, and rather than hand friends and family a new address every time, you gave them your Bigfoot address. An address that never changes also collects years of junk mail. Nothing at the time checked whether a sender was a real person, so I built a tool that did: the first version was a Visual Basic 6 program that handled the confirmations for me. Once I showed it to a few people, it took on a life of its own.

Why it was hard

Stopping spam sounds like a filtering problem. In practice, it touched almost every part of how email moves.

  • Email is asynchronous. A held message has to wait while its sender is contacted, and the system has to match a confirmation that arrives later to the message it belongs to, while still receiving, scanning, retrying, and delivering everything else.
  • The first tools gave little help. The original service ran on classic Active Server Pages, with all of its processing on the server. Parameterized queries existed only in a limited form and weren’t foolproof, and there were no ORMs or data layers to lean on. So I built my own layer that examined, stripped and cleansed every incoming string to protect against SQL injection.
  • Larger companies wouldn’t touch Microsoft. The companies with the most to gain ran their mail on Linux and Unix systems and wanted nothing built on Microsoft tools, .NET or Java.
  • One person can’t run everyone’s mail. As a hosted service, every customer depended on me personally keeping it running.
  • Corporate mail had to keep flowing. Anything placed in front of a company’s mail servers had to fit alongside them, be simple to adopt, and keep working as volume grew.

The approach and the decisions behind it

The idea at the center of SpamJammer was simple: before judging a message, ask its sender to prove they were a real person. Everything else followed from making that work at scale.

Verify the sender, not just the message.
SpamJammer used URL confirmation to check that mail came from a real, legitimate sender before it was delivered. What it confirmed was the pair: this sender writing to this recipient. I had never seen URL confirmation used this way before, and with the appliances it was the novel part of SpamJammer.
Hold mail instead of delivering it.
Incoming mail from an unknown sender was queued rather than delivered immediately, so nothing reached the recipient until its sender had confirmed.
Make every confirmation unique.
Each confirmation carried its own globally unique identifier, a GUID, so every link pointed to exactly one confirmation.
Rewrite for the enterprise’s platforms.
SpamJammer had already been ported more than once. To win over the bigger customers, I ported it again, to a mix of ANSI C and C++ on Linux, which let it sit comfortably beside corporate email servers.
Own the mail transfer agent.
Rather than bolt confirmation onto someone else’s mail server, I built the system around a custom, high-performance mail transfer agent that handled receiving, queuing, scanning, retrying, and delivery, and kept track of the state of every message.
Ship it as an appliance.
The idea came from GNAT Box, an all-in-one firewall you simply bought and plugged in. It was the first appliance of any kind I had seen; everyone else built their firewalls on a Unix box. SpamJammer became a server with its software already configured and the machine locked down, so a company racked it instead of administering it and ran everything from a web interface.
Let the appliances organize themselves.
A new unit broadcast to find the units already running, exchanged its role and a pairing key with them, and joined the environment. Its screen showed a countdown explaining how it was about to join; if nobody stepped in within 60 seconds, it accepted those settings. Zero configuration was the whole goal: growing capacity meant powering on a box, not reconfiguring a system.

How it works

Before the appliances, SpamJammer ran as a hosted service at SpamJammer.com. From the sender’s point of view, the first message to a SpamJammer user came back with a request: click this link to confirm you sent it.

How SpamJammer confirmed a sender A sender's message arrives at the SpamJammer relay, which holds it in a queue instead of delivering it. The relay sends the sender a confirmation link carrying a unique identifier. When the sender clicks the link, the relay releases the held message to the recipient's inbox. A message whose sender never confirms is never delivered. Sender unknown to the recipient SpamJammer relay Held in queue not yet delivered Unique identifier for each confirmation Recipient inbox 1 · message arrives 2 · link sent back 3 · sender clicks 4 · released A sender who never confirms is never delivered.
Figure 1. Sender confirmation: the message waits, the sender proves they are real, and only then does the mail go through. Swipe the diagram sideways to see all of it.
  1. Mail arrives at the relay. A message from a sender the recipient hasn’t confirmed reaches SpamJammer instead of going straight to the inbox.
  2. The message is held. SpamJammer places it in a queue rather than delivering it.
  3. The sender is asked to confirm. SpamJammer sends the sender a confirmation link built on a unique identifier.
  4. Confirmed mail is delivered. When the sender clicks the link, the held message completes its delivery. Only confirmed senders get through.
  5. The pair is remembered. Once a person has confirmed a sender and recipient combination, later mail between them goes straight through. Users could still block a domain, an address, a subject or words in the body; confirmation was the first line of defense, removing the vast majority of unwanted mail.

From a service to an appliance

The hosted service proved the idea, but I was the one running all of it, and that was becoming painful. The bigger opportunity was in the enterprise, and enterprises needed something they could put in a rack and trust. I found a Midwest manufacturer that would brand rack-mounted servers, and we produced customized 1U and 2U units, each with a distinctive yellow bezel carrying the SpamJammer logo and its software already in place.

At the heart of every unit was the custom mail transfer agent, built to receive, queue, scan, retry, and deliver millions of messages while correlating each confirmation with the mail it released.

How SpamJammer appliances shared the work Inbound mail reaches an edge device, which handles initial filtering and storage. It passes mail to a processing server, which performs spam filtering and scanning. A mail server then provides web client access and user management. When a new appliance is added to the rack, it detects the existing units, performs a handshake, and negotiates which role it will take. Inbound mail Edge device initial filtering and storage Processing server spam filtering and scanning Mail server web client access and user management New appliance added to the rack Detects its peers, performs a handshake, and negotiates its role.
Figure 2. The appliance roles. A new unit worked out its place with the units already running. Swipe the diagram sideways to see all of it.

The appliances were modular. An edge device took mail in and handled initial filtering and storage, a processing server did the spam filtering and scanning, and a mail server gave users web access and gave administrators user management. When a company added another SpamJammer box, it detected the units already running, performed a handshake, and negotiated its role in the environment on its own. The result was a system that was scalable and fault-tolerant, run from a control panel designed for people who were not email specialists.

Outcomes

  • A personal tool became an enterprise product. SpamJammer grew from a program for my own inbox, to a hosted service at SpamJammer.com, to plug-and-play rack appliances for corporate mail.
  • It scaled by adding hardware. New appliances joined the cluster and took on a role without manual reconfiguration.
  • Non-technical administrators could run it, through a control panel built for people who did not manage mail servers for a living.
  • It was acquired without a pitch. The offer came informally, over lunch, from someone with the authority to make it who already knew about SpamJammer. A major antivirus company bought it, and it became the core engine for its anti-spam offerings.

My role

I founded SpamJammer and was its only developer. I wrote the first version as a Visual Basic 6 tool, turned it into a web service in Active Server Pages, then rewrote it in ANSI C and C++ around the custom mail transfer agent and moved it to Linux for the enterprise market. I worked with the manufacturer to turn the software into locked-down rack appliances, and took the product from my own inbox to the enterprise systems that a major antivirus company acquired. I built it on the side, outside my day job, and I wasn’t chasing a sale; it was right place, right time.

I once shut down my own email-list business because it didn’t sit right with me. Then I built a product to fight spam.
On doing the right thing

Next step

Why it still matters

Two lessons from SpamJammer have stayed with me. The people best placed to fix a problem often understand it from the inside. And the products that win are the ones that are easiest to adopt: a mail team could rack a SpamJammer appliance, add another when it needed more capacity, and let the units sort out the rest.

If your organization has a product that works but is hard to adopt or hard to grow, I am glad to compare notes on where it stands and what I would do next.

Start a conversation