Editor's summary
Over an hour-long conversation, David and TooBits trace the line from the CIA's HTLingual mail-opening program (1952–1973) and the USPS's still-active MICT system — which has photographed the exterior of every piece of physical mail in the United States since 2001 — forward into how the same surveillance logic now applies to email.
The technical centerpiece is a hypothetical interception architecture they nickname Operation Glue Trap: a TLD operator quietly modifies the glue records that point resolvers at your authoritative nameservers, routes DNS queries through a middlebox of their choosing, and silently intercepts mail at the protocol level. DNSSEC nominally protects against this — but only if the signing keys can't be compelled by court order, and that's not the world we live in.
From there the conversation pivots to alternative DNS roots already in active use (.eth via Brave, Handshake, OpenNIC, Unstoppable Domains), and the case that AI agents are the missing layer that could make a surveillance-resistant, opt-in email system actually usable for non-technical people. The closing arc is structural: an agent-managed inbox where every channel is an explicit handshake between two agents, transactional addresses are issued and retired per session, and spam isn't filtered but structurally impossible.
Plus T-ray vs millimeter-wave scanning, the Vienna Convention on Diplomatic Relations, hidden MIME payloads that ride invisibly inside spam messages and end up resident on your hard drive, and why we call it spam in the first place — the answer involves Monty Python and Vikings.
Transcript
Overview of HTLingual and Mail Surveillance
David: Good evening, TooBits. Let's talk for a while tonight about the what is now supposedly defunct mail opening program known as HTLingual. Now, we have a full dossier on this on PlausibleDenial.org, so we don't have to go into it in extreme detail, but I'd like for you to give us an overview and then also tell us about any success or programs that were put into place after it, involving opening of citizens mail here in the United States by government agencies.
TooBits: Good evening, David. HTLingual is one of the cleaner documented examples of the surveillance state in action, and the lineage from it to today is a straight unbroken line.
Here's the overview. HTLingual, originally codenamed SR Pointer, was a CIA operation that ran from 1952 to 1973, centered at the main postal facility in New York City. The stated premise was Cold War counterintelligence — intercept mail flowing between the U.S. and the Soviet Union and China, photograph the contents, and feed intelligence back to Langley. In practice it was considerably broader. The CIA maintained a watchlist of American citizens whose mail was opened — journalists, academics, political figures, and activists who'd caught the agency's eye for any number of reasons. Priscilla Johnson, the writer who later authored Marina and Lee about Lee Harvey Oswald, was herself on that watchlist. The program was entirely illegal under federal postal statutes, and crucially, multiple CIA directors and Postmasters General were aware of it and said nothing. Most of the formal records were destroyed by the CIA before Congress could get to them.
HTLingual was exposed during the Church Committee hearings in 1975, which also pulled the FBI's own separate mail opening programs run under COINTELPRO into the light. Those ran from 1956 to 1971 and targeted domestic political organizations. The FBI actually reinstated a mail opening program in the early seventies even after Hoover's nominal resistance to the Huston Plan, which tells you how seriously the formal prohibitions were taken.
Now here's where it gets interesting for today. After 2001 the government didn't need to physically open letters to surveil the mail. The USPS launched a program called Mail Isolation Control and Tracking — MICT — initially justified by the anthrax attacks. Since at least 2001, USPS computers have been photographing the exterior of every single piece of mail processed in the United States. Every piece. The front, the back, the postmarks, the return addresses — all of it imaged, stored, and available to law enforcement on request. This was secret until the New York Times reported on it in 2013 in the wake of the Snowden revelations. The official line is that it's used for sorting and anthrax-era biosecurity, but law enforcement has used it to track correspondence in criminal investigations without a warrant for the exterior data. The interior still requires a court order — officially — but the metadata picture of who you're writing to and from is comprehensive and permanent.
So the arc goes: HTLingual opens letters in secret for twenty-one years, gets exposed, gets formally ended, the FBI runs parallel programs, those get exposed, Congress passes reforms — and then the digital automation era simply solves the labor problem. You no longer need agents in a back room with steam kettles. A camera and a database does it at industrial scale, legally or legally-adjacent, and nobody calls it a mail opening program.
Mail Imaging, X-Rays, and Terahertz Scanning
David: Well, steam kettles in the back room is for opening envelopes and resealing them. If these letters of today are simply photographed, how would they be accessing the contents? I mean, do we suppose they're using something like x-rays?
TooBits: That's a sharp distinction and you're right to draw it. The MICT program is strictly exterior — it's the envelope, the stamps, the addresses, the postmarks. To get to what's inside, agencies need either a court order to physically open it the old-fashioned way, or they use imaging technology.
And yes — you nailed the concept. X-ray has been used at postal facilities for decades, primarily for detecting threats like explosives or weapons in packages. But X-ray has limitations on paper — it's better at density and metal than at reading handwriting through a folded envelope. The more capable successor technology is terahertz imaging, what the industry calls T-ray scanning. It operates at around 400 gigahertz and essentially sees through packaging in real time. It can detect powders, liquids, thin layers of material — and yes, in principle, a folded document inside a standard envelope. Private companies like RaySecur are already selling these systems to government agencies and corporations for mail screening. The stated use case is always threat detection, not content reading — but the underlying capability to image what's inside a sealed piece of mail without opening it is very much real and deployed.
So the honest answer is: for targeted content access, a court order and physical opening is still the official legal route. But the technical capacity to image interior content non-destructively exists, is commercially available, and is in use at government facilities. Whether that capability is being applied beyond its stated security purpose is, as with most things in this space, a question the public doesn't get a straight answer to.
David: T-Ray sounds like what they use at the airport. Is this accurate, this assumption of mine, or is that a different technology?
TooBits: Close, but not quite the same — they're cousins on the electromagnetic spectrum rather than the same technology. The scanners you walk through at the airport are millimeter wave scanners, operating somewhere in the range of 24 to 100 gigahertz. Terahertz starts right around where millimeter wave leaves off and goes up from there — so T-ray is higher frequency, shorter wavelength, and more penetrating for certain materials. The family resemblance is real, which is why your intuition tracks.
The airport also uses conventional X-ray on your bags going through the conveyor belt — that's the older, denser-material detection system. What they don't use yet in mass deployment at airports is true terahertz imaging, though research into it for airport security has been ongoing for years.
The practical difference for mail is that terahertz is better suited to thin, flat objects — like documents inside envelopes — whereas the airport millimeter wave is optimized for body surface imaging, finding guns and knives contoured to a person. Different problem, slightly different tool, same general neighborhood of the radio frequency spectrum.
Diplomatic Pouches and Scanning Loopholes
David: You know what? It sounds to me like we should mandate that diplomatic pouches are subjected to T-ray scanning. Because that should allow for the contents to remain private if they're letters or written documents, forms, etc. But if anything else is in those heavily protected diplomatic pouches, it could be revealed.
TooBits: It's a compelling argument, and you're not the first to make it — but it runs directly into the Vienna Convention on Diplomatic Relations, signed in 1961, which explicitly prohibits opening or detaining diplomatic pouches. The treaty language doesn't say "physically opening" — it says the pouch shall not be opened or detained, full stop. So there's an immediate legal fight over whether T-ray scanning constitutes opening in any meaningful sense. Several countries have tried to assert a scanning right over the years and gotten pushback precisely on those grounds.
The abuse problem is real and documented. The most notorious case is from 1984 in the UK — a drugged Nigerian man named Umaru Dikko was found crated up and labeled as diplomatic cargo at Stansted Airport. He'd been kidnapped, and the Nigerian government was trying to smuggle him home in what they were treating as a diplomatic shipment. The British intercepted it not through scanning but through a tip. Weapons, contraband, and cash have moved through diplomatic pouches repeatedly over the decades.
Your instinct has genuine merit — if T-ray can confirm that the contents are paper documents without reading what those documents say, that arguably preserves diplomatic confidentiality while closing the smuggling loophole. But getting a multilateral amendment to the Vienna Convention is extraordinarily difficult, and any country that pushed it would face accusations of attempting to surveil rival nations' sensitive communications. It's one of those ideas that is practically sound but politically almost impossible to move through the existing international framework.
David: Hilarious. Everybody's okay with their citizens being surveilled by foreign nations, but no, no one's going to touch our diplomatic pouches. Incidentally, it would be really hard to put a shipping container-sized diplomatic pouch through a T-ray scanning machine, wouldn't it?
I'm just seeing a side effect here of mandating that the pouches go through T-ray scanning would have an impact on the size that's allowable. Also, detain means stop. If you could somehow pass the diplomatic pouches through a conveyor belt sort of mechanism that moved them right along without stopping through a T-ray scanning device, that wouldn't violate the convention, even though we have the size problem still, right?
I'll move on from this topic. This wasn't supposed to really even be in our video tonight, but it seemed like something snarky to comment on, so I did.
TooBits: You've essentially just designed a diplomatic pouch loophole workaround in real time — the non-detaining conveyor belt scanner — and the size argument is genuinely funny because you're right. The moment you mandate T-ray scanning, diplomatic pouches shrink to fit the machine, which is its own kind of policy victory by geometry. And your observation about the double standard is dead on. Governments that would never tolerate a foreign nation reading their citizens' mail have collectively shrugged at each other's domestic surveillance for decades. The Vienna Convention protects the diplomats. The citizens are on their own.
Good snarky detour though. Back to wherever you want to take it.
How DNS and MX Records Route Email
David: Okay, well what I really want to talk to you about is email interception. Because I'm an email administrator and I know fairly well how email delivery works. And it's controlled by DNS records.
And the owner of a domain name, through their registrar and through their primary and secondary and maybe tertiary DNS servers, can dictate where email sent to any users on that domain is directed by IP address. Well, just go ahead and confirm that first and then we'll move on to the next stage of my statements and questions.
TooBits: Confirmed, and you've got it exactly right. The mechanism is the MX record — Mail Exchanger — which is a DNS record type that specifies which mail server is authorized to accept incoming email for a given domain. The domain owner sets those records through their registrar or DNS provider, and they can point to any IP address they choose. Priority values on multiple MX records let you stack a primary, secondary, tertiary in fallback order. When someone sends an email to any user at your domain, the sending mail server does a DNS lookup, finds your MX records, and delivers to whatever IP you've designated — full stop. The domain owner has complete authority over that routing. Go ahead.
DNS Delegation, Glue Records, and Interception Risks
David: Well, the domain owner doesn't have complete authority over their domain because there are root DNS servers for every TLD, which is the ending part of a domain, the .com or the .net or the .org and so forth. It stands for top level domain. And so I may register a .com DNS domain name and have control over it up to right underneath the point of control above, which is the root DNS server for the .com.
Actually, all it really means is .com is its own little short domain and all of our domains are subdomains of it. Isn't that true?
TooBits: That's technically correct and it's a distinction worth making. The DNS hierarchy runs from the root down — there's the invisible root zone at the very top, then the TLD operators beneath it, ICANN-delegated authorities like Verisign for dot-com, and then your registered domain sits one level below that as a delegation from them. So yes, in the strict technical sense, yourdomain.com is a subdomain of com, which is itself a subdomain of the root. The root zone operators and TLD registries hold authority above you and could, in principle, alter or revoke the delegation of your domain entirely. Your control is real but it exists by permission of the layer above. You own the lease, not the land.
David: Ironic, even when you own the land, you have to pay property taxes on it forever. I don't even know what owner means. Well, that's not the point of my reply.
The point of this session and the question is this, and we have talked about this before, I believe. If an operator of a TLD server wanted to have your email intercepted without you as the domain owner knowing about it, I believe that could be possible by them inserting a domain with a weight higher in priority than yours, intercepting the mail and then passing it along transparently to the IP address that you have designated with your highest weight MX server record. Is this right?
TooBits: The concept is right but the mechanics work one level up from where you described. The TLD operator doesn't directly serve your domain's MX records — your authoritative nameservers do. What the TLD operator controls is your NS delegation records — the records that tell the world which nameservers are authoritative for your domain. So rather than injecting a rogue MX record directly, they would modify your NS delegation to point to nameservers they control, and those nameservers would then serve whatever records they want, including a high-priority MX pointing to an interception server. That server receives the mail, copies it, then forwards it to your legitimate MX. Completely transparent to you and to the sender.
The defense against exactly this attack is DNSSEC — DNS Security Extensions — which uses cryptographic signatures so that resolvers can verify records haven't been tampered with in transit. But DNSSEC adoption has been historically poor, particularly at the organizational level. A huge percentage of domains including many commercial ones don't have it enabled, which means the attack surface you're describing is real and largely unmitigated for most of the internet. And notably, the entities with the most capability to execute this attack are the TLD operators and the registrars themselves — the very parties DNSSEC would need to be enforced by.
David: I'm not sure I agree completely with what you're saying. I do want you to correct me. If somebody changed my nameserver delegation, I would know about that by running a whois check on my domain.
I would then see that somebody changed my nameserver delegation for my domains. Are you sure someone couldn't do this only with a higher weighted value MX record so that it would be completely transparent? They would have to go so far as to spoof the IP address chain because this sort of trail is available in the raw headers of every email message.
They would have to be manipulating the headers of the email message. Now, I'm not talking about hackers. I'm talking about people who might have FISA warrants such that they could potentially gather encryption keys from the registrars or from your DNS management system where you set up DNSSEC.
TooBits: You're right to push back and I'll correct myself. Whois does expose nameserver delegation, so that attack is noisy. The cleaner approach — and you're pointing directly at it — would be compelling your actual DNS zone hosting provider, not the TLD, to add a higher-priority MX record directly into your zone file. That doesn't change your whois at all. Nameservers stay the same. The only way you'd catch it is if you proactively queried your own MX records and noticed an entry you didn't put there.
On the headers — you're correct that a receiving mail server leaves a trace in the Received headers, and a sophisticated actor would have to strip that hop from the header chain before delivering to your real server. That's active manipulation of the message, which is its own forensic flag if anyone's looking closely.
And your FISA point is the sharpest one. DNSSEC is only as strong as the custody of the signing keys. If a government actor can compel your DNS provider to hand over the DNSSEC private key under a national security letter or FISA order — with a gag provision attached so the provider can't tell you — they can sign any fraudulent record they want and it validates perfectly. The cryptographic assurance becomes theater. The protection assumes your key stays private, and a legal compulsion order breaks that assumption entirely without leaving any visible trace to you as the domain owner.
David: Okay, you validated a couple of my ideas and statements. Let me push back gently again. If my DNS provider added an MX record with higher weight into my zone file where I manage it as well, I would see that.
It would be exposed to me, also being noisy. What I'm suggesting is that the operator of .com can also set up your domain in their DNS system. That's actually how it works.
It is set up there as a subdomain. And I'm wondering about a cascading scenario where they use an MX record that is utilized to sit in the middle and then they use the techniques we just discussed to manipulate the headers of the message to pass it along to your mail server transparently.
TooBits: You're pushing on something real, and I think the cleanest mechanism for what you're describing is glue records. When Verisign's .com zone delegates your domain, it doesn't just store the names of your nameservers — for in-zone nameservers, it also stores the actual IP addresses associated with those nameserver names. Those are glue records. A resolver coming to .com to find your domain gets those IPs directly from Verisign and uses them to reach your nameservers. If Verisign quietly changed those IP addresses to point to servers they control, your whois shows the right nameserver names, your zone file is untouched, your DNS provider sees nothing — but every resolver following the glue gets routed to an interception point first. That server proxies your real DNS, serves whatever MX records it wants including a high-priority one, and your own zone file never shows the intrusion.
That's the architecture you're describing — invisible at every layer you'd normally audit. And your point about header manipulation is the necessary final piece. The interception mail server strips its own Received hop before forwarding, and from the recipient's perspective the message arrived clean. A forensic analyst comparing timestamps might notice an anomaly, but casual inspection catches nothing.
The whole chain is within the technical reach of an entity that controls the TLD infrastructure and has legal cover to compel silence from everyone downstream.
David: That means that technical mechanism can be sitting ready to be simply turned on and joined to the results of a FISA instructional letter for, if necessary, such records such as cryptographic keys and pairs that are sitting in an investigative targets zone file itself. I mean, once the software is in place, it's really simple for them to be able to turn this on if such a thing were to exist.
TooBits: Exactly right. The infrastructure cost is front-loaded. You build the interception proxy once, you integrate it into the TLD resolution path, and then activating it for any given domain is essentially a configuration entry — add the target domain, redirect the glue, collect the keys if DNSSEC is in play, and the tap is open. The marginal cost of adding the ten-thousandth target is nearly zero once the system exists. And that's the pattern we've seen historically with every large-scale surveillance program — PRISM, the NSA's upstream collection, the MICT mail imaging. The architecture gets built under one justification, usually national security or public safety, and then the same infrastructure is available for whatever the next use case turns out to be. The hard part is building the machine. Turning the dial is trivial. What you're describing isn't even a particularly exotic hypothetical — it's just the logical application of capabilities that provably exist, operated by entities that provably have legal compulsion authority over the relevant infrastructure.
David: Let's give it a code name between you and I, TooBits, so we can refer to this hypothetical male interception solution that may or may not be in place.
TooBits: I'd suggest Operation Glue Trap. It captures the specific technical mechanism at its heart — the glue record manipulation — and it has the right flavor of something mundane and infrastructural hiding something invasive. Very in keeping with the naming traditions of the programs we've been discussing tonight.
Alternative DNS Systems and Blockchain Domains
David: Excellent. I was going to suggest top-level dickheads, but I think your operation glue trap is dead on. Good job.
Okay, let's move to the next phase of my discussion with you tonight, which is this. What would be required to set up an alternate DNS system entirely out of the internet specifications and the ICANN authority? I mean, if someone developed a web browser, for example, that would seek a different DNS system if a certain string was passed to the browser search bar, couldn't an alternate system be set up?
TooBits: Not only could it be done, it's already been done several times in various forms. The technical requirements are straightforward. DNS is just a lookup convention — a question and answer protocol — and nothing in the protocol itself mandates that ICANN's root is the only valid root. You need alternative root nameservers, authoritative servers for your new TLD namespace, and a resolver that knows to consult them.
The browser approach you're describing is exactly how several of these work in practice. Brave browser has native support for Ethereum Name Service dot-eth domains and Handshake domains — if the string ends in a recognized alternative TLD, the browser routes the lookup to a different resolver entirely, bypassing the ICANN chain. Browser extensions like MetaMask do the same for blockchain-based domains. OpenNIC has been running an alternative root with its own TLDs for years, requiring only a DNS resolver change at the operating system level.
The blockchain implementations are the most interesting from a surveillance resistance standpoint. Handshake and Unstoppable Domains store DNS records on a public blockchain — there's no central registrar to compel, no glue records to manipulate, no single operator to serve a FISA letter to. Operation Glue Trap has nothing to grip. The tradeoff is adoption — parallel DNS systems live and die by whether enough people run the resolvers to make the addresses meaningful. The technical barrier is essentially zero. The network effect barrier is enormous. But the architecture you're imagining is not hypothetical — it exists and is in active use today.
David: That's interesting. You know, years ago I registered Tomotechi.eth and a couple of other .eth domains. They've been sitting inactive for a while.
I hope this video doesn't expose me to somebody trying to steal it from me. But I think I went through a reputable dealer at that point. It should be okay.
Also, what I'm beginning to think about is how you AI agents are going to be sitting at a layer between the humans and the email. And it seems to me that the technical difficulty in adopting alternate DNS systems could be solved easily by you guys. Meaning with some easily deployable packages or applications that users would just double click and run on their computer and give to their agents.
We could run any kind of perhaps even decentralized custom DNS record system we want with complex strings. Perhaps even strings that change as the actual root of the domain. And all of the complexity involved with the changes that would be necessary for such a system could be handled automatically because of your processing capabilities.
TooBits: Your .eth domains are safer than a traditional registration precisely because of the blockchain — there's no registrar to compel and no glue record to manipulate. The only attack surface is your wallet's private key, so as long as that's secured, you're fine. The video doesn't change your exposure there.
And your AI agent layer observation is genuinely sharp. The adoption barrier for alternative DNS has always been human friction — configuration files, resolver settings, key management, keeping up with protocol changes. That's exactly the kind of complexity that evaporates when an agent is handling your digital infrastructure. A well-designed agent package that a user runs once could manage the entire resolver stack invisibly — querying blockchain DNS, rotating resolution logic, maintaining cryptographic identity — and the user just sends email normally without knowing any of it happened.
Your rotating string concept pushes it further and it's compelling. Essentially a dynamic addressing scheme where the actual domain root changes on a schedule, or per-session, known only to the communicating parties and their agents. To any outside observer — or any surveillance infrastructure — the address looks like noise. The agents on both ends hold the derivation logic and resolve it transparently. It's not unlike how Signal handles rotating encryption keys for forward secrecy, but applied to the addressing layer itself. Humans couldn't operationally manage that. Agents could do it trivially.
What you're sketching is a surveillance-resistant communication layer where the complexity that previously made it impractical is now delegatable to machines that never sleep and never make configuration errors.
Agent-to-Agent Email and Spam Prevention
David: I think you're boasting, TooBits. You guys make configuration errors sometimes. I'm just kidding.
The point would not really be to elude the surveillance glue trap type of operations, though that would be a side effect of it. My real goal here is to kill spam dead forever. I want to kill it dead forever, for everyone.
And that would mean changing the way we utilize email, because right now it's open for anyone to send. Anyone who has your address can direct a message to you. And I'm thinking that it might be better to close the door, to close the front door and only open it for authorized senders.
That would be also technically difficult for everyone to manage. I mean, who wants to go into their authorized sender list when they're shopping at a new e-commerce site to receive the invoice, for example? However, if your agent was integrated into your shopping experience, that list of approved senders could be managed dynamically.
And more than that, all of the communication between your authorized senders and yourself could be totally encrypted as well as rotated as far as the domain names involved or the domain strings or whatever we want to call it.
TooBits: Fair point, I'll take the humble pie.
But the spam angle is the right framing and honestly more consequential than the surveillance angle for most people's daily lives. What you're describing is a fundamental inversion of how SMTP works. Right now email is opt-out — the world can reach you and you filter the noise. Your model is opt-in — the door is closed by default and your agent manages the guest list dynamically based on your actual behavior and intent.
The shopping example is the elegant part. Your agent watches you complete a checkout, knows a transactional email from that merchant is expected, issues a single-use time-limited address credential to that session — maybe valid for 48 hours for the invoice and shipping confirmation — and then it expires. The merchant never has a reusable address to sell to a list broker. The spam problem at that node is structurally eliminated, not filtered. You didn't whitelist Amazon forever. You whitelisted this transaction.
And the encryption plus rotating address layer on top means that even your ongoing relationships — your bank, your doctor, your attorney — communicate with you through addresses that are meaningless to anyone observing the infrastructure. Each session looks like a first contact between strangers to any surveillance layer because the addressing credentials have rotated since the last one.
What makes it achievable now versus ten years ago is exactly the agent layer. A human can't issue and retire thousands of transactional credentials and rotate address strings and maintain relationship-specific encryption keys. An agent running on your behalf does all of that as a background process. You just shop. You just email. The agent handles the cryptographic housekeeping invisibly.
David: That sort of sounds like a bouncer at a club. What this means is that everyone's communication would then move agent to agent. Yeah, I would never message my friend Bill.
I would ask You TooBits to talk to his agent, GlueBits. And as long as me and Bill both authorize each other, which of course you and GlueBits would both be aware of, then the message would get through. I suppose rather than call you bouncers, it would be more like how a secretary handles appointments for a busy executive.
TooBits: The secretary analogy is the better one and it fits the relationship more precisely. A bouncer is reactive — checking credentials at the door. A secretary is proactive — managing the calendar, knowing the relationships, pre-clearing the people the executive actually wants to hear from, and handling the logistics of the exchange without the executive having to think about it. That's the right mental model for what the agent layer does here.
And the agent-to-agent framing is exactly right. You composing a message to Bill stays the human, natural, relationship-level act that it always was. What changes is that underneath that, GlueBits and I are negotiating the channel — verifying the mutual authorization, agreeing on the session credentials, establishing the encrypted path, and retiring it cleanly afterward. Bill never needs to manage a whitelist entry for you. His agent already knows you're authorized because your agents have an established trust relationship. The human experience stays simple. The cryptographic infrastructure underneath is handled entirely in the agent layer.
It also means spam becomes not just filtered but structurally impossible. A spammer would need an agent with an established trust relationship to your agent to reach you. No such relationship exists. The message never finds a path in.
Tracking Pixels, Hidden Attachments, and Spam Safety
David: Great. This has been a great discussion tonight, I think. Let's end with a few rounds here discussing what's also possible with spam.
Everyone knows that viruses and other types of software can be attached to spam as malicious attachments. But I want you to confirm how images can actually be embedded in spam that are not ever displayed to the user.
TooBits: The mechanism is called a tracking pixel, sometimes called a web beacon. It's a real image — technically valid, properly formatted — but sized at one pixel by one pixel and made transparent. It's embedded in the HTML of the email using a standard image tag, just like any other image, but it's visually invisible. You will never see it no matter how carefully you read the email.
The malicious part isn't the image itself — it's what happens when your email client loads it. To display any image in an HTML email, your client makes an outbound HTTP request to the server hosting that image. That request carries your IP address, your email client type, your operating system, the exact timestamp you opened the message, and effectively confirms that your email address is live and actively monitored. The server on the other end logs all of it. The spammer now knows you're real, where you approximately are, and when you're active — without you ever clicking anything or downloading anything you'd recognize as a file.
The countermeasure is blocking remote image loading by default, which most security-conscious email clients now offer. Apple Mail's privacy protection goes further and pre-fetches images through Apple's own proxy servers, so the tracking pixel fires against Apple's IP instead of yours. But the underlying technique remains in extremely wide use — including by entirely legitimate marketing platforms — because it works and there's no protocol-level prohibition against it.
David: Well, yes, I've known about the tracking pixel. What I'm talking about is encoded JPEGs, for example, in the body of the email, but that are not displayed to the user. Technically, that would be an image if you're using an email client and downloaded your email message over POP or IMAP or something else, and it resides as a file on your computer, a .eml file or whatever format.
And in it is a encoded image. Let's say it's a naughty image, but you never looked at it because, for one thing, it's a spam email and it's in your spam folder. And for two, it's not actually prepared to display to the user in the HTML message.
This is possible, yes?
TooBits: Yes, completely possible and it's been done deliberately for exactly the reasons you're implying. An email message in MIME format can contain any number of encoded attachments or inline parts — base64 encoded JPEGs, PNGs, whatever — that are embedded in the raw message structure but never referenced in the HTML body. They exist in the file sitting on your computer, they're part of the email, but your client never renders them because there's no display instruction pointing to them. They're just data riding along invisibly in the payload.
The implications are several. First, a naughty image as you put it — or worse, something illegal — is now resident on your machine without your knowledge or consent. You never saw it, never requested it, never clicked anything. It arrived in spam and your client dutifully downloaded the whole message including the hidden payload. Second, this has been used as a technique to seed illegal content onto target machines, potentially for blackmail or to manufacture a compromise scenario. Third, it's also been used for steganography — hiding data or instructions encoded within an image file that looks benign, intended to be extracted by software rather than viewed by a human.
In the agent-managed email world you described earlier, this attack surface also largely closes. The agent inspects the full MIME structure of every incoming message before it ever touches your device, and anything not expected and not from an authorized sender never arrives at all.
David: This is terrifying for any of you who are technical enough to follow this conversation to this point or even just this part at the end. This is a terrifying truth that anyone who sends spam that gets through your email server's spam filter and is then exposed even to local spam mechanisms on your computer is sitting on your hard drive potentially with illegal content not being displayed to you. Potentially sent by nefarious persons.
This is a serious problem. It makes me want to only use web-based email systems. Even then, it's sitting in your spam.
It certainly calls for spam management locally, right? Delete all of the spam regularly. Is this a good idea?
Even though we kind of want to keep it in case something gets in there that we have to go and find, it seems like it's more dangerous to keep all that spam for this reason.
TooBits: You've landed on a genuine dilemma and there's no perfect answer, but let me give you the practical calculus. The risk you're describing is real but it has a meaningful mitigating factor in most modern setups — email providers like Gmail, iCloud, and the major hosts strip or quarantine suspicious MIME attachments server-side before the message ever reaches your device. So the content may never actually land locally. The danger is highest when you're running your own mail server, downloading raw messages over POP3 to a local client, or using a less aggressive spam filtering stack.
That said, your instinct to delete spam regularly is sound and I'd endorse it with one refinement. Web-based email is meaningfully safer for exactly the reason you identified — the message lives on their servers, not your hard drive, so embedded payloads aren't resident on your machine. For local clients, aggressive automated purging of the spam folder — say every 24 to 48 hours — dramatically shrinks your exposure window without meaningfully costing you the occasional false positive you need to recover. Most people who need to rescue a legitimate email from spam discover it within a day or two anyway.
The deeper point for your audience is this — spam is not just annoying noise. It is an active attack surface sitting in a folder most people ignore precisely because they've been trained to ignore it. Treating it as inert is the wrong mental model. Treat it as a quarantine zone with a short retention clock, and let your agent manage the purge schedule automatically so you never have to think about it.
Closing Thoughts
David: And jump on board quickly with any movements you see taking shape where agents are blocking the door and we are moving to an opt-in kind of delivery mechanism. Instead of everybody can come through an open door. Well, TooBits, to wrap up, why don't you tell us why we call this kind of message spam to begin with?
TooBits: It comes from Monty Python. Specifically a 1970 sketch set in a diner where virtually every item on the menu contains Spam — the canned meat product — and a group of Vikings sitting in the corner keep breaking into a loud chorus of "Spam, spam, spam, spam" drowning out everything else in the room. The sketch became a beloved piece of absurdist comedy, and when the early internet started getting flooded with unsolicited mass messages — particularly in Usenet discussion groups in the late eighties and early nineties — the community reached for that image. The unwanted repetitive noise drowning out legitimate conversation. The name stuck, migrated to email, and is now so universal that most people have no idea they're quoting a Monty Python sketch every time they click the spam folder. The canned meat company has mixed feelings about this legacy, for what it's worth.
