Kobold letters: HTML emails are a risk

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.