A user on Reddit’s r/selfhosted forum described a simple solution to an irritating problem: giving their printer its own email address. Family members stopped asking them to print things. The setup took minutes. The post gathered thousands of upvotes. What it describes is not novel, but its popularity signals something worth examining: the moment when infrastructure collapses back to the household, and when a boundary reasserts itself not through argument but through architecture.
What Actually Happened
The setup in question routes incoming email through a local mail server to CUPS, the Common Unix Printing System standard on Linux, FreeBSD, and macOS. A script monitors an inbox, extracts attachments, and pipes them to the printer queue via a command-line interface accessible at a web-based address. The printer becomes addressable. Family members email documents. The printer outputs them. No intermediary request to the person who manages the hardware.
This is not new. CUPS-email backends and print-to-PDF-via-email scripts have existed for years, configured through PostScript printer definitions and backend scripts invoked with commands like lpr. Commercial implementations predated hobbyist ones. HP ePrint, which assigns printers email addresses for remote printing, was recommended by HP as a Google Cloud Print alternative when Google officially deprecated Cloud Print in January 2021, after announcing the end-of-life in 2019.
What changed is not the technology. What changed is the collapse of the expectation that a third party would provide it reliably and indefinitely.
The Cloud Print Interregnum
Google Cloud Print never left beta, and Google ended it because the internal tool became too popular to manage after being released publicly. The service launched around 2010, coinciding with Chromebooks and Chrome OS, as a browser-based printing solution for devices without local driver stacks. It worked. Users built workflows around it. Then Google pulled support.
The replacement ecosystem is commercial and fragmented. Accepted paths in 2025 include Microsoft Universal Print for Microsoft 365 environments or PaperCut Mobility Print with cloud mode for remote users. PrintNode and similar services integrate printing into web applications, fetching documents from the cloud and routing them to printers via API calls. All require subscription relationships or vendor lock-in.
HP ePrint remains functional but limited. One user noted it was outdated and lacked the ability to select pages or specify color versus black-and-white. The feature set degrades because the vendor has no competitive pressure to maintain it. The user has no leverage. The printer, despite being local hardware, depends on a remote service that may change terms, retire APIs, or simply stop working.
Print as Perimeter
The Reddit post describes a social solution, not merely a technical one. The boundary it establishes is not about capability but about labor. Family members could previously ask the printer’s owner to print something. Now they send email. The difference is the elimination of interruption and the shift of responsibility. The person who set up the printer no longer performs the print job; the infrastructure does.
This mirrors the original promise of cloud printing, but inverts the dependency. Cloud printing eliminated the need for local expertise by outsourcing the server to Google or HP. Self-hosted email-to-print eliminates the need for ongoing personal involvement by embedding the server in the home. Both reduce interruptions. One requires trusting a third party. The other requires maintaining a daemon.
The vulnerabilities differ. Scan-to-email and cloud print jobs often store temporary files on device memory, and without encryption, sensitive documents can be intercepted or misrouted. When print jobs transmit over the internet to cloud servers, sensitive information like financial statements or medical records could be intercepted or accessed by unauthorized parties. Conventional email print services automatically forward jobs to printers without considering confidentiality, meaning documents may print when the recipient is not present.
A self-hosted setup behind a firewall avoids some of these risks but introduces others. Printers on unsegmented networks or default IP ranges can be scanned by attackers who discover open ports and use the devices as pivot points to access servers or cloud resources. The responsibility for patching firmware, monitoring logs, and restricting access falls to the operator, not a vendor SOC team. The question is not which approach is secure in absolute terms, but which threat model the user can address and which they cannot.
Email as Addressing Layer
Email is older than the web. SMTP dates to 1982. It is federated, asynchronous, and requires no installation of client software beyond what is already present. Giving a printer an email address makes it addressable in the same way a person is addressable: by a string that resolves through DNS to a mail server that accepts the message.
This is architecturally simpler than IPP, Bonjour, or driver-based print queues, all of which require client-side configuration or discovery protocols. Bonjour, also known as mDNS/DNS-SD, allows computers to find services on local networks, and IPP is the transport protocol. These work well on LANs. They do not work well across the internet without VPNs or port forwarding. Email does, because mail servers are designed to be internet-facing and delivery is the MTA’s problem, not the sender’s.
The simplicity has costs. Email is not authenticated by default. SPF, DKIM, and DMARC mitigate spoofing but do not prevent it entirely. A printer that accepts email from any sender will print anything sent to it by anyone who knows the address. Backend configurations can filter based on sender address and append default domains to addresses that lack an ‘@’ symbol, relying on the mail server to handle validation. This shifts the access-control problem to the MTA, which is where spam filtering and authentication already occur.
The result is that the printer becomes subject to the same threat model as any inbox: spam, phishing, and unauthorized access. The difference is that a printer cannot report phishing or delete suspicious messages. It will attempt to print whatever it receives, or halt the queue on error. Operational security depends on the same disciplines required for email security: restrictive firewall rules, authentication at the MTA, and monitoring of logs.
Infrastructure That Lasts
CUPS was originally developed by Easy Software Products, acquired by Apple in 2007, and forked by the Linux community when Apple’s version diverged. CUPS is a standards-based, open-source printing system developed by Apple for macOS and UNIX-like systems, using IPP and providing command-line, web, and C API interfaces. CUPS is licensed under Apache License Version 2.0. It has been stable for over two decades. It will be maintained as long as UNIX systems require printing.
Google Cloud Print lasted eleven years. HP ePrint’s feature set has stagnated. Microsoft Universal Print requires a subscription. The commercial alternatives are provisional. CUPS is infrastructure.
Email infrastructure built on SMTP and IMAP operates according to similar durability principles. These are stable, federated protocols implemented across multiple platforms and maintained independently of any single vendor. Open-source implementations like PQCServer – which provides post-quantum cryptographic algorithms under AGPL-3.0 – illustrate how infrastructure can remain available regardless of commercial decisions. The architecture assumes that third-party services will change, retire, or become adversarial. The response is to choose dependencies that cannot be unilaterally revoked.
A printer with an email address is a small instance of this principle. The user depends on SMTP, DNS, and CUPS. All three are open standards implemented by multiple parties. None require ongoing payment or vendor approval. The printer remains functional as long as the hardware works and the operator maintains the software. This is not resilience through redundancy. It is resilience through simplicity and fungibility of components.
What the Popularity Signals
The Reddit post resonated because it solved a problem many people have but few articulate: the expectation that household technical labor should be available on demand. The social norm is that the person who understands the printer becomes responsible for operating it on behalf of others. The self-hosted email gateway externalizes that labor into a daemon running on a Raspberry Pi or home server.
The broader signal is the return to local infrastructure after the cloud interregnum. Users who adopted Google Cloud Print because it was convenient are now forced to choose between commercial subscription services and self-hosted alternatives. The former may disappear again. The latter requires skills that were unnecessary a decade ago, when the expectation was that printers would be supported by drivers bundled with operating systems and discovery would be automatic.
Neither expectation held. Printers remain difficult. The difference is that users now have a reference point for what happens when a vendor-managed convenience disappears. The response is not universal migration to self-hosting, but a subset of users rebuilding the capabilities they lost using tools that predate the cloud. CUPS, SMTP, and shell scripts are not modern. They are durable. The fact that a post describing their use to solve a domestic annoyance attracts thousands of upvotes suggests that durability is once again valued, or at least noticed in its absence.