The Attachment That Opens a Tab: Auditing HTML Smuggling at the Filter Edge

Most email filters still think in file types. A PDF is a document. A DOCX is a document. An HTML file? That’s where the logic gets wobbly. To the mail gateway it looks like an attachment; to the browser it’s a local website with a “Open me” sign taped to the front. That mismatch is the whole point of HTML smuggling, and it’s why a parcel or tax lure can land in a UK inbox looking like a harmless receipt while quietly opening a tab that wants your credentials.

Why HTML attachments get a free pass

An .html attachment is not just markup. It can load remote scripts, redirect to a fake login page, render a QR code for a mobile hand-off, or pull in a form that posts somewhere unpleasant. Some filters scan the file and see no executable — because it isn’t one. Some sandboxes render it without JavaScript, so the page looks blank. Some organisations allow HTML because a supplier once sent an e-receipt that way and nobody wanted to break it.

That’s the filter-edge problem in a sentence: the attachment is a website, but the policy was written for documents.

At Spamdex, we’ve seen the same pattern across UK tech teams. The spam filter blocks .exe and .js, maybe quarantines .zip, then lets .html, .mhtml, .svg and .xhtml sail through because they’re “just web files.” Except they’re not just anything. They’re a delivery mechanism for a page the user never asked to visit.

Start with what you actually allow

Before you change a single rule, inventory your attachment policy. Not the policy document from 2022 — the live ruleset. Ask:

• Which extensions are allowed, blocked or quarantined?
• Are HTML variants treated the same as .htm? What about .mhtml, .xhtml, .svg and .hta?
• Do you inspect inside archives, or only the archive itself?
• Are password-protected archives quarantined, or scanned and released?
• Does your sandbox execute JavaScript and follow remote resources?

A useful audit isn’t about blocking everything with a dot in the name. It’s about knowing where the gaps are. A lot of teams discover that HTML attachments are allowed for one legacy supplier, then quietly extended to everyone. That’s how a single exception becomes a nationwide front door.

Test the parcel and tax shapes, not live campaigns

You don’t need to name a current campaign to test the policy. Build safe synthetic samples using the shapes UK users see every week: a parcel redelivery fee, an HMRC refund, a council tax rebate, a TV Licence renewal. Keep them inert — no live payloads, no real brands — and run them through the full path.

Check three things:

1. Filter verdict. Does the HTML attachment get blocked, quarantined, stripped or delivered? Does the verdict change if the file is inside a ZIP? What about a nested archive?
2. User warning. If it lands, does the banner actually explain the risk? “This message came from outside” is not enough when the attachment is a local web page.
3. Sandbox behaviour. Does detonation open the page with scripts enabled? Does it follow the remote fetch? Does it decode the QR code, or just screenshot a blurry square?

That last point matters more than it used to. A QR code in an HTML attachment is a hand-off to the user’s phone, where your desktop filtering has no vote. If the page says “scan to pay the redelivery fee,” the scam has already left the mail gateway.

Archives need a policy, not a shrug

HTML smuggling often travels inside archives because the outer file looks boring. A ZIP containing an HTML file may pass a scanner that only checks the archive’s MIME type. Password-protected archives are worse: many filters can’t inspect them, so they either quarantine blindly or release them with a shrug.

A practical 2026 approach is to treat encrypted archives as untrusted by default unless there’s a business case and a process. For nested archives, set a depth limit and a file-count limit. For ISO, IMG and VHD files, decide whether they belong in email at all. If you have content disarm and reconstruction, use it — but test what it does to legitimate HTML, because some suppliers still send statements that way.

Make reporting match the risk

Users are not going to read a file extension table. They will, however, understand “if an attachment opens a web page, stop and report it.” Put that sentence in your phishing training and your intranet. Add a one-click report button that works on mobile, because the QR hand-off often finishes on a phone.

When someone reports an HTML attachment, don’t just delete it. Capture the sender, the filename, the archive structure and the remote URLs. Feed that back into the policy. If you’re in the UK, the NCSC’s Suspicious Email Reporting Service is still a sensible route for genuinely suspicious mail, but your internal report data is what fixes your filter.

A monthly rhythm beats a big clean-up

Attachment policy drifts. A supplier asks for an exception. A new file type becomes popular. A filter update changes a verdict. So put HTML attachments on a monthly review: sample what was quarantined, check what was allowed, run one synthetic parcel lure and one tax lure, and log the false positives. Keep the exceptions list short and dated.

The attachment is a website. Once your policy says that out loud, the audit gets a lot less mysterious — and a lot more useful.