Email Is Still 1982, and Nobody Wants to Talk About It

Here is a sentence that should terrify you more than it does: the protocol responsible for basically all business communication on Earth was designed before anyone thought to ask whether the people sending messages might be lying about who they are.

That’s SMTP. Simple Mail Transfer Protocol. It’s the plumbing behind every “per my last email” and every wire-transfer scam that ever worked. And in 2026, we are still discussing it as though it were a new problem, which is sort of like discussing whether cars should maybe have seatbelts. The technology has been around since disco was a going concern, and the core issue has never changed: SMTP was built on the assumption that everybody using it would be reasonably polite about it. This is the same logic that makes small towns leave their front doors unlocked, and it works fine right up until it catastrophically doesn’t.

The Basic Bit, Explained Like You’re at a Dinner Party

Somebody sends an email. Their mail client talks to a server. That server hands the message off — sometimes through two or three other servers, like a game of telephone played by machines — until it lands in a mailbox somewhere. The whole exchange happens via a short list of plain-text commands: introduce yourself, say who it’s from, say who it’s for, send the content, hang up. It is, structurally, a conversation with the manners of 1982 and the security awareness of a Post-it note left on a monitor.

The problem is that none of those commands are load-bearing in terms of trust. Nothing stops a sender from issuing extra ones. Nothing inherently stops a message from being routed somewhere it was never supposed to go. And nothing about the base protocol confirms that “From: yourboss@company.com” was actually written by your boss.

Injection, or: What Happens When You Let the Bits Rearrange Themselves

The most persistent vulnerability class here is injection — sneaking extra line breaks (carriage return, line feed, the invisible little characters that tell a system “new instruction incoming”) into fields that were only supposed to hold a name or an email address. Do that successfully, and you can quietly tack on additional recipients, rewrite the subject line, forge the sender, or just detonate the server with garbage commands until it falls over.

This is not an abstract, theoretical concern reserved for security conference keynote slides. It has hit real, mainstream software — mail-sending libraries in .NET, WordPress SMTP plugins, open-source mail transfer agents that half the internet quietly depends on without ever thinking about it. Somewhere, right now, a form field that should only accept an email address is instead accepting a haiku’s worth of hidden instructions, and somebody’s inbox is about to receive a recipient nobody intended.

Not to scare you, but these types of injection attacks have plagued a variety of platforms for years (primarily database-driven systems because they are the most prone to taking in unchecked or unvalidated data types):

• MOVEit Transfer Breach (2023): Hackers exploited a zero-day SQL injection vulnerability in the popular managed file transfer software, MOVEit Transfer. This allowed attackers to execute SQL statements to steal vast amounts of data from over 2,000 organizations and impact an estimated 60+ million individuals worldwide.
• ResumeLooters Campaign (2023): A hacking group launched widespread SQL injection (SQLi) and Cross-Site Scripting (XSS) attacks targeting recruitment and retail websites. They successfully breached at least 65 websites globally, stealing over 2 million user records.
• Accellion FTA Data Breach (2021): Attackers utilized SQL injection flaws to deploy web shells on servers running Accellion’s legacy File Transfer Appliance (FTA). This unauthorized remote access allowed them to steal data from dozens of universities, government entities, and private corporations.

Open Relays: The Email Equivalent of Leaving Your Car Running

An “open relay” is a mail server configured — usually by accident, usually years ago, usually by someone who has since left the company — to forward messages between two parties who have nothing to do with the organization running it. Spammers love these the way raccoons love an unlocked dumpster. They don’t need their own infrastructure; they just borrow yours, send a few million phishing emails through your reputation and your IP address, and leave you to explain to your ISP why you’re suddenly blacklisted.

Plaintext: Because Encryption Is Apparently Optional, Somehow, Still

SMTP, left to its own devices, sends messages in plain text. Anyone positioned correctly on the network — which is a lower bar than people assume — can simply read it. There are encryption layers bolted on after the fact (STARTTLS, or the older SMTPS), but “bolted on after the fact” is the operative phrase. If encryption is optional rather than mandatory, an attacker can just ask the server to skip it, and plenty of servers will politely agree, because that is what SMTP servers have always been bred to do: cooperate.

The 2026 Update: Basic Auth Finally Dies

The one genuinely new development worth flagging is that Microsoft and Google have now fully retired Basic SMTP Authentication — the old username-and-password-only method — in favor of OAuth 2.0. If your outbound mail system is still authenticating the old way, it is either already broken or about to be, and no amount of nostalgia for simpler configuration files will fix that. Alongside this, a handful of 2026 CVEs are worth knowing by name if you touch mail infrastructure: a .NET mail library injection flaw, a header-injection issue in a popular local testing tool, a stored cross-site-scripting bug in a WordPress SMTP plugin, and an information-disclosure hole in another plugin that exposed configuration details and API keys to anyone who asked.

Notice the pattern. It’s almost never the core protocol logic that fails spectacularly in the year 2026 — it’s the plugin, the wrapper, the admin dashboard nobody has looked at since it was installed. The house has a great foundation and a screen door for a back entrance.

What Actually Helps

Strip away the jargon and the fix list is almost boringly sensible:

• Validate and sanitize everything — assume every field a user can touch might contain a hidden instruction, because eventually one will.
• Require authentication and encryption, not as a courtesy but as a non-negotiable gate. Mandatory TLS, not “TLS if convenient.”
• Segment your mail servers away from the open internet and from each other; a DMZ is not a decorative architecture choice.
• Patch relentlessly. Old mail software is the digital equivalent of a car with bald tires — it might get you there ninety-nine times.
• Log everything, and actually look at the logs. Most of these attacks leave fingerprints; the fingerprints just sit unread in a file nobody opens until after the fact.
• Train the humans. Every technical control in the world doesn’t matter if someone wires money because an email politely asked them to.

The Part Where I Tell You There’s No Ending

Here’s the uncomfortable truth about protocols like SMTP: they don’t get replaced, they get patched, forever, in perpetuity, the way an old house gets additions instead of a teardown. Nobody is going to unplug email. It is too embedded, too load-bearing, too structurally identical to how the entire world already communicates. So the future of SMTP security isn’t some clean architectural revolution — it’s the same incremental hardening we’ve been doing for twenty-five years: better authentication standards, mandatory encryption, smarter anomaly detection, and the eternal hope that the next plugin developer reads the OWASP list before shipping.

Which, if you think about it, is a pretty normal way for humans to handle any inherited flaw. We don’t fix the foundation. We just get better at noticing when the walls start cracking.