Read HTML email replies safely in a shared inbox
Show an HTML email exactly as it was written, and let none of its code run. The usual way to do that in a web app is a sandboxed frame: the message is drawn in its own isolated box that is not allowed to run scripts. Email Digit renders HTML replies that way, sized to the full height of the message so you read it as sent, not through a cramped scroll box.
Why HTML replies are awkward
A customer replies to your newsletter from a mail app that writes heavy HTML: tables, inline styles, a signature block with a logo. An app that shows replies has three choices, and two of them are bad:
| Approach | Problem |
|---|---|
| Flatten it to plain text | Loses tables, emphasis and layout, so you misread what they sent |
| Insert the HTML into the page | The email’s styles and code mix with the app’s own |
| Render it in a sandboxed frame | Looks as sent, and kept apart from the app |
The middle option is the dangerous one. A reply is content written by someone outside your company. Dropped into the page, its markup can restyle the screen around it, draw something that looks like part of the app, or, if anything slips past a filter, run code with the same access as you. The dashboard it lands in holds your contacts, your campaigns and your team’s work. Those should not share a room with a stranger’s HTML.
How Email Digit shows a reply
- HTML replies render in a sandboxed frame. The frame is not allowed to run scripts, so the message’s markup is displayed and its code never runs inside the app. Forms inside the email cannot be submitted from it.
- Full height, no inner scrollbar. The frame is sized to the message, and resized when the reading pane changes width, so a long email reads top to bottom like it would in a mail app.
- Links open in a new tab. Following a link in a reply never replaces the inbox.
- Quoted history is tucked away. The earlier messages that mail apps append below a reply are hidden behind a toggle, so you see what is new first. If hiding them would leave nothing readable, nothing is hidden.
- Plain text replies render as paragraphs with working links, with quoted history and signature blocks behind the same kind of toggle.
The replies you send use the same card, so a thread reads top to bottom like a mail client rather than a chat.
Why this matters more in a shared inbox
Mail apps have treated incoming HTML with suspicion for years, which is why most of them refuse to run scripts in a message at all. A web dashboard is a different setting: it is a full application, signed in, with buttons that send campaigns and change contacts. A message that can run code there is not limited to what a mail app would allow; it can act as you. That is why the isolation has to be explicit rather than assumed.
In a personal mail app, one person reads their own mail. In a shared inbox, several people open the same replies, often the day they arrive, and rarely stop to think about who wrote the HTML. Each of them is signed in to an account that can send campaigns or manage contacts. Safety in a shared inbox cannot depend on everyone being careful every time, so it has to be built into how messages are shown.
What the sandbox does not do
The frame protects the app. It does not make every message trustworthy:
- Images load. Pictures in the email are fetched as they would be in most mail apps, so a sender who put a tracking pixel in their reply can learn that it was viewed.
- Links are real links. A link that says one thing and points somewhere else still does. Hover before you click, and be wary of anything asking you to sign in.
- The words can still mislead. A reply claiming to be from your bank, your payment provider or Email Digit is text someone wrote. Check the sender address.
A short checklist for any team inbox
- Make sure replies are shown in an isolated frame or as plain text, never inserted into the page.
- Open links from replies in a new tab, and treat sign-in pages reached that way with suspicion.
- Give people who only answer replies a role that cannot change domains or API keys.
- Agree what the team does with a suspicious reply: who looks at it, and that nobody signs in anywhere from a link inside it.
The rule underneath all of it: show the email exactly, and trust its code not at all. Roles are covered in Who deleted those contacts?, and how replies are sorted and drafted is on the reply intelligence page.