Why use mailing lists?

Original Article ↗ Hacker News Discussion ↗

Perceived strengths of mailing lists

  • Fit the desired properties: open standard, non‑proprietary, broadly federated, archivable, portable, and not tied to one company.
  • People like using any mail client they want, with powerful local filtering, threading, and offline access; once messages are downloaded, they’re theirs “forever”.
  • Asynchronous flow encourages more considered, long‑form technical discussion than chat; good for engineering, legal, HOA, professional groups, and newsletters.
  • Decentralized/federated nature of email is seen as a major counterweight to today’s platform centralization and vendor lock‑in.

Critiques and usability problems

  • Many find mailing list UX poor: hard to join casually, hard to browse/search history, and confusing threading—especially for newcomers without a tuned mail client.
  • High-volume lists overwhelm users who don’t know or don’t want to configure filters; bad CC/reply etiquette worsens this.
  • For anonymity and privacy, forums are seen as easier (nicknames) than managing extra email addresses.
  • Some argue the benefits (no special software, minimal security/privacy risk, “abuse-free”) are overstated or false.

Self‑hosting and infrastructure challenges

  • Setting up list software: mixed reports. Mailman 3 and its multi‑service architecture are called both “manageable in a day” and “horrible”; some prefer Mailman 2 on Python 3 or Sympa.
  • Running email servers: debate over difficulty. Critics describe a maze of SPF/DKIM/DMARC, TLS, reverse DNS, blocklists, IP reputation, and deliverability issues (especially to big providers). Others say it’s doable with some initial effort and monitoring.
  • Several mention turnkey/self‑host solutions (Mail‑in‑a‑Box, Mox, Proxmox mail, Postfix+Dovecot) and third‑party SMTP relays as mitigations.

Alternatives proposed

  • NNTP/Usenet and NNTP‑backed forums; Gmane‑style gateways; public‑inbox/lore.kernel.org.
  • Web forums and Discourse (with email posting, some ActivityPub support), though critics dislike gamification and “web-first” interaction.
  • Chat systems (IRC, Matrix, Revolt, Discord, Slack, WhatsApp) for informal/ephemeral discussion; many worry these are proprietary, non‑indexed, and cause knowledge loss.
  • ActivityPub/ATProto as protocol-level successors; RSS and newsletters for read‑only flows.

Decentralization, privacy, and spam

  • Strong concern about migration of technical communities to closed platforms (Discord, Slack, Facebook groups), viewed as “knowledge sinks” and ransomware‑like lock‑in.
  • Others argue closed platforms can centralize security and allow revoking access, whereas mailing lists expose content to every subscriber device and can leak emails/IPs.
  • Everyone agrees spam and deliverability remain significant issues, whether via DIY SMTP or commercial senders.