Use Plaintext Email (2019)

Thunderbird and client recommendations

  • Debate over why Thunderbird is omitted from the “recommended” client list: author’s stated criterion is “works correctly out-of-the-box for plain text,” and Thunderbird needs configuration.
  • Some argue it’s still the only obvious cross‑platform GUI choice in 2025 and excluding it is gatekeeping; others say its size/complexity (“350 MiB monster”, “desktop bloat”) makes it a reasonable omission for a minimalist/plain‑text guide.
  • Alternatives like Claws and Sylpheed are mentioned but seen as harder to get on modern macOS (often needing Homebrew).

Inline replies, top‑posting, and client behavior

  • Several participants like inline replies with trimmed quotes, but feel this practice is effectively dead in mainstream use: Outlook/Gmail UIs hide quoted text behind “show more,” making inline replies invisible or confusing.
  • Some still do inline replies selectively (mailing lists vs family), or prefix with hints like “reply below.”
  • Others have reverted to top‑posting because “modern clever clients” break the traditional quoting workflow.
  • Quote formatting in plain text (72–78 char wrapping, nested “>”) is seen as tedious or broken in many GUI clients; terminal clients plus good editors (Vim) or format=flowed are mentioned as fixes.

Privacy, tracking, and MDNs

  • Strong support for disabling automatic image loading to block tracking pixels; some share testing using email privacy tester sites.
  • Discussion of Apple and Gmail proxying images: they still “look” like loads to senders but break open‑rate tracking by prefetching everything.
  • Multiple comments advocate disabling MDNs/read receipts and sometimes filtering them at the MTA level; counterpoint: DSNs (delivery notifications) can be useful and some organizations cherry‑pick what to drop.

Plaintext vs HTML: ideals vs reality

  • Plain‑text proponents cite simplicity, security, and control; some run terminal clients (alpine, mutt, mailx) and report most mail still includes a usable text/plain part.
  • Others call the anti‑HTML stance cranky and outdated: rich text, inline links, headings, and limited images genuinely improve readability and structure.
  • Accessibility and security arguments from the article are challenged: HTML has accessibility features; phishing/tracking concerns are more about how HTML is used than the format itself.
  • Some say spam filters may distrust weird HTML; others claim pure plaintext can look more suspicious now.

Line length, wrapping, and devices

  • Disagreement over 72–78‑column hard wrapping: some like it for large screens; others say it looks terrible on phones and that only format=flowed makes plain text tolerable across devices.

Social and adoption dynamics

  • Many feel the “use only plain text” battle is lost: Outlook and Gmail defaults dominate, and very few users opt for plain text when given the choice.
  • Several argue you should match the recipient’s ecosystem (mostly HTML/Outlook), not enforce personal purity.
  • Others refuse to “bow to Outlook/Gmail,” insisting on sending plain text even if it “looks odd” to most recipients.
  • There’s tension between “refusing to modernize” vs “not wanting proprietary, bloated, or privacy‑hostile tools.”