The First Spam Email Was Sent in 1978

The first spam email was sent on May 3, 1978, over the ARPANET — roughly fifteen years before anyone used the word "spam" to describe it.

Gary Thuerk, a marketing manager at Digital Equipment Corporation, sent an unsolicited message to about 393 ARPANET users on the US West Coast. It was an invitation to demonstrations of DEC's new DECSYSTEM-20 machines. At the time the network had only a few thousand users in total, so a single message to 393 of them reached a meaningful share of everybody online.

Complaints arrived the same day. Network administrators at DARPA, which funded ARPANET, made it clear that the network was for government and research use and that mass advertising was not welcome. Thuerk got the sales leads he was after and a reprimand along with them.

The word came much later

The message was not called spam. That name came out of a Monty Python sketch in which a café menu consists almost entirely of Spam, and a chorus of Vikings drowns out conversation by singing about it. In the 1980s, users of Usenet groups and text-based multiplayer worlds (MUDs) borrowed the term for anything that flooded a shared channel and made it unusable. By the mid-1990s it had attached itself permanently to unsolicited bulk email.

The sketch is a better metaphor than it first looks. The problem is not that the Spam is offensive. The problem is that it is loud enough to make everything else inaudible.

The network worked perfectly

This is the part worth sitting with. Nothing broke in 1978. The mail system did precisely what it was designed to do: accept a message and deliver it to every address on the list, quickly and reliably. ARPANET had no bug that day.

What it had was an absent constraint. Sending cost the sender essentially nothing, and the cost of receiving landed on 393 other people. Any shared channel with that asymmetry will eventually fill up, because there is nothing in the system pushing back on the sender. The internet spent the next forty years retrofitting that pushback — filters, reputation scoring, rate limits, authentication — onto a protocol that never assumed it would be needed.

The same problem, now with sensors

Anyone building connected hardware runs into this exact asymmetry, usually within a week of the first pilot deployment.

A device that publishes every reading at full rate feels like thoroughness. In practice it produces three costs that all land somewhere other than the device: bandwidth and cellular data that scale with fleet size, storage and query time on whoever is running the backend, and — most expensively — the attention of the people who are supposed to act on the data. A dashboard that updates constantly is a dashboard nobody watches. An alert that fires on every minor excursion is an alert the operations team learns to swipe away without reading.

That last failure is the one that quietly kills projects. Once a team has been trained by false positives to ignore notifications, the real event goes unnoticed too, and the system is worse than having no monitoring at all — because everyone believes they are covered.

Designing the constraint in

The fix is not to send less data arbitrarily. It is to decide, on the device, what is worth saying:

Filter and aggregate at the edge. A temperature sensor sampling every second does not need to transmit every second. Send a rolling average, plus anything that crosses a threshold. The raw resolution stays local, where it is cheap.

Report by exception, not by schedule. Publish when state changes meaningfully, with a slow heartbeat so the backend can distinguish "nothing to report" from "device is dead."

Buffer through outages. On patchy warehouse Wi-Fi or field cellular in the Philippines, a device that drops readings during a dropout is a device with holes in its history. Write to flash and reconcile on reconnect.

Set thresholds with the people who will be paged. An alert threshold is not a technical parameter. It is a promise about what deserves someone's attention at 2 a.m., and it should be negotiated with the person who will be woken up.

Give every alert an action. If nobody can name what they would do when a notification fires, that notification should be a log entry, not a page.

MQTT, the protocol behind most modern IoT deployments, was shaped by exactly these pressures — it was built in 1999 to monitor oil pipelines over expensive satellite links, where every byte had a price. That scarcity produced a design with a two-byte header, quality-of-service levels, and clean reconnect semantics. Constraints made it good.

The lesson from 1978

Thuerk's message is remembered as a marketing misstep, but the interesting failure is architectural. A network that makes sending free will fill with things nobody asked for, and no amount of good intentions among the senders will prevent it. The constraint has to be in the system.

When we design telemetry for a connected product, that is the question we start with — not "what could this device measure?" but "what will somebody actually do with this, and what does it cost them to receive it?" Devices that only speak when they have something worth saying are the ones people keep listening to.

If you are scoping an IoT deployment and want the alerting to still be trusted a year in, talk to us about your project or take a look at what we build.