Stop Microsoft users sending 'reactions' to email by adding a postfix header

Original Article ↗ Hacker News Discussion ↗

Microsoft’s new Outlook feature that lets users react to emails with emojis is drawing fire for how it leaks outside the Microsoft ecosystem. Commenters argue that, instead of staying a lightweight in-client signal, reactions are turned into separate emails that clutter inboxes, confuse non-Outlook users, and can even help spammers confirm active addresses. The thread broadens into a critique of proprietary “extensions” to open standards, the social value and ambiguity of reactions versus explicit replies, and whether such features belong in formal, asynchronous channels like email at all.

How Outlook Email Reactions Work

  • Outlook/Exchange lets users “react” to emails; for other Outlook users, this shows as inline emoji on the original message.
  • For many non‑Outlook recipients, each reaction arrives as a separate “X reacted to your message” email, often with an image that may be blocked.
  • One commenter tested and found no simple distinguishing header; reaction emails look like normal mail plus the usual x-ms-* headers.
  • Gmail has added a similar emoji reaction feature, so this is no longer unique to Microsoft.

Postfix Header Opt‑Out and Technical Concerns

  • The blog’s approach is to add a custom header (e.g., X-MS-Exchange-Organization-DisableReaction: true) in outbound mail so Microsoft servers suppress reactions.
  • Some note this “fix” breaks DKIM because the MTA modifies headers after signing.
  • Alternatives discussed:
    • Rejecting such mails at SMTP time (sends a server‑generated bounce).
    • Blackholing them after acceptance (nicer for the recipient, confusing for the sender).
    • Simple content-based filtering on reaction subjects/text.
  • Several argue Microsoft should have shipped this as opt‑in based on known‑capable clients, not opt‑out via magic headers.

UX, Attention, and Email Culture

  • Many participants dislike reactions in email specifically:
    • Extra low‑value messages clutter inboxes and notifications.
    • Ambiguity: a thumbs‑up may mean “acknowledged,” “agree,” or just “saw this.”
    • Email is treated as “serious” async communication where explicit, textual replies are preferred.
  • Others like reactions as lightweight acknowledgments, especially inside a single Outlook/Exchange environment, reducing “OK/Thanks” reply‑all spam.
  • Some prefer read receipts; others find them invasive or misleading and routinely disable them.

Reactions in Chat, SMS, and Other Systems

  • Reactions are generally viewed as useful in Slack/Teams/IM: fast acks, less typing, reduced message noise if clients aggregate them.
  • Complaints arise when these systems leak into incompatible channels:
    • iMessage reactions forwarded as SMS text (“X liked ‘…’”) are widely seen as spammy.
    • RCS and Android/iOS now try to parse and collapse such texts, with mixed success.
  • Several stress that norms differ by medium: what’s fine in real‑time chat can be confusing or hostile in email.

Microsoft, Standards, and Historical Parallels

  • Many see this as another case of “extend” in “embrace‑extend‑extinguish”: leveraging a standard (email) while degrading interoperability.
  • Parallels drawn to:
    • Microsoft Comic Chat mangling IRC with extra metadata.
    • Exchange “recall” messages that only worked inside Exchange.
    • Wi‑Fi Sense password sharing and SSID _optout conventions.
  • There is mention of an existing RFC for email reactions, but uptake appears minimal; Outlook’s implementation is proprietary.