Kobold letters: HTML emails are a risk

Original Article ↗ Hacker News Discussion ↗

HTML-formatted email is shown to enable a novel phishing technique: attackers can hide text with CSS that only appears when a message is forwarded, making spoofed payment requests or altered content look as if they came from a trusted manager. Commenters debate how often such a narrowly tailored attack would succeed, but many note that even simple phishing still works and that any method which slightly increases success rates is concerning. The thread broadens into criticism of HTML in email in general, with suggestions ranging from stripping or inlining CSS and sandboxing rendering, to reverting to plain text or simpler markup to reduce irreproducible, easily manipulated content.

Perceived risk & practicality of the “kobold letters” attack

  • Some see the money-transfer example as contrived: a cautious employee would ask “do you really want this transfer?” and likely expose the scam.
  • Others argue many people don’t verify, or verify only superficially (“did you send this email?”), so even a narrow exploit window is viable.
  • Several note that attackers already succeed with much simpler phishing, so the incentive to adopt a complex CSS trick may be low.
  • Counterpoint: even a modest increase in success rate, especially for targeted or financial workflows (e.g., accounts payable, invoice routing changes), is dangerous.

Real-world phishing behavior and training simulations

  • Multiple anecdotes of employees buying gift cards or failing obvious test phish despite repeated training.
  • Complaints that phishing simulations often:
    • Count any click as failure (even safe investigation or reporting workflows).
    • Misattribute clicks from security scanners (e.g., link-checkers) to users.
    • Lead staff to learn “detect the training vendor,” not “detect phishing.”
  • Debate whether clicking a link should be considered a fail; replies stress real risk from browser/exploit chains and session theft.

Technical causes and proposed mitigations

  • Core issue: email clients modify HTML/CSS on forwarding; DOM structure changes make it possible to show hidden content only in forwards.
  • Suggestions:
    • Disallow or strip stylesheets; compile to inline styles only.
    • Warn on hidden/overlay elements; randomize wrapper structure.
    • Render emails in sandboxed iframes (with careful sandbox flags).
  • Objections: these can break responsive layouts, media queries, dark mode, and current marketing workflows.

HTML vs plain text and alternative formats

  • Strong sentiment that email should be plain text; HTML/CSS adds complexity and attack surface for marginal benefit.
  • Others argue users want rich text, color, size, basic layout, and mobile-friendly designs.
  • Mention of existing alternatives like text/enriched and markdown-like ideas; they exist but never reached broad adoption.

Email client design & standards gaps

  • Frustration that clients embed email HTML in the same DOM as the app, instead of isolating it.
  • Broader criticism that “HTML in email” has no clear, secure subset spec, leading to per-client hacks and recurring vulnerabilities.
  • Some see this as a standards failure; others blame early resistance to HTML email for blocking sane standardization.