Self-hosting email like it's 1984

Original Article ↗ Hacker News Discussion ↗

Getting started & software options

  • Several commenters recommend turnkey stacks to reduce complexity:
    • Mail‑in‑a‑Box, Mailcow, and integrated servers like Stalwart are highlighted as “few‑hours” setups with sane defaults (DKIM/SPF/DMARC, TLS, web UI).
    • Others prefer traditional Postfix + Dovecot (sometimes via long‑standing guides like PurpleHat and workaround.org), valuing modularity, maturity, and long‑term support.
  • Stalwart gets repeated praise: single binary, minimal dependencies, JMAP support, good defaults and UI; some use it with SES or other relays.
  • Some still like Exim/OpenSMTPD, but Exim’s Debian packaging is described as painful.

Deliverability, IP reputation & big providers

  • Core pain point: outbound mail reaching Gmail/Outlook/Yahoo.
    • Residential IPs are often blocked; people either use VPSes, IP tunnels, or external relays (SES, SendGrid, etc.).
    • Even with perfect SPF/DKIM/DMARC and 100/100 mail‑tester scores, some report persistent blocking or spam‑foldering, especially from Microsoft; others claim near‑perfect deliverability.
  • There’s disagreement whether “do SPF/DKIM/DMARC right and you’re fine” is realistic; several describe opaque “extra heuristics” (IP reputation, age of IP, ASN, prior spam on the block, DKIM alignment strictness) that periodically break setups.
  • Some note that big hosted platforms also misclassify legitimate mail (e.g., Shopify, even Microsoft’s own marketing).

Spam handling, greylisting & filters

  • Greylisting is widely used and effective, but causes issues with 2FA and signup emails; some services never retry. Workarounds: whitelisting MFA domains or postwhite‑style whitelists.
  • Filtering stacks mentioned: rspamd, SpamAssassin + DNSBLs, reverse‑DNS checks, geo‑IP blocking, content classifiers, and even experimental LLM‑based classifiers.
  • Debate over aggressively rejecting missing PTR/reverse‑DNS: great spam reduction vs. potential false rejects from poorly configured sites.

Uptime, reliability & disaster recovery

  • Some argue email isn’t truly “critical” thanks to SMTP retries and backup MX, and that it’s easy to achieve months‑long uptime.
  • Others quit self‑hosting after:
    • Needing near‑100% uptime because some senders (e.g., GitHub historically) disable addresses after a single bounce.
    • Lacking robust backup/restore and DR, or fearing ransomware and operator error.
  • A common “hybrid” pattern: self‑host incoming mail and use a commercial relay for outgoing.

Home vs VPS & privacy

  • Hosting at home is seen as “pure” self‑hosting but runs into port‑25 blocks, dynamic IPs, and blacklist issues; warming a clean static IP is described as slow and fragile.
  • Many instead use a cheap VPS (often Hetzner, DO, etc.); some argue that if a company can access your VPS anyway, you might as well buy managed email. Others counter that VPS providers typically don’t mine mail contents, unlike consumer webmail.

Motivations, trade‑offs & community ideas

  • Long‑time self‑hosters emphasize:
    • Pride, technical learning, independence from “email oligopolies,” and the ability to deeply inspect logs and automate.
    • Viewing self‑hosting as a hobby rather than a pure cost saver.
  • Critics highlight:
    • Time sink, moving‑target configs, constant whack‑a‑mole with blacklists, and reliance on goodwill of large providers that have little incentive to trust small servers.
  • Alternative visions:
    • Separate “receiving only” self‑hosting from “sending” via relays.
    • A gated “community email realm” excluding big providers, with reputation and pay‑per‑abuse models.

Migration strategies & configuration details

  • For “testing the waters” while staying on Google Workspace:
    • Suggestions include forwarding from Google to the self‑hosted server, replying from the new server, using split‑domain configs, or putting Google as a backup MX.
    • Outbound can safely be multi‑homed if SPF is configured to allow multiple senders.
  • Technical tips scattered through the thread:
    • Use Maildir over mbox; monitor DMARC reports; register with DNS whitelists; use fail2ban; keep configs simple; and treat greylisting and DNSBLs as primary spam defenses.

“Like it’s 1984” title & nostalgia

  • Several note that the described stack (Postfix, DKIM, TLS, DMARC) is thoroughly modern; 1984 would have meant UUCP, bang paths, open relays, simple SMTP, and no MX records.
  • Some share nostalgic anecdotes about early Unix labs, dial‑up BBSs, and mail taking days to traverse multi‑hop UUCP paths, contrasting sharply with today’s complex, security‑heavy setups.