Block remote images and tracking resources in rendered email

[jzhao234]

Problem

Explorer sanitizes archived HTML email before rendering it, but the sanitizer currently permits <img> elements with http and https sources.

Opening an archived message can therefore contact a sender-controlled server through a tracking pixel or other remote image. This can disclose the viewer's IP address, browser metadata, and the exact time the archived message was viewed.

Desired behavior

Block remote resources in rendered email content by default while preserving locally served inline/CID images.

At minimum:

• Remove or neutralize http:// and https:// image sources in sanitized email HTML.
• Continue rewriting valid CID/inline images to Explorer's authenticated /attachment route.
• Add a Content Security Policy that prevents rendered email content from loading remote images or other remote subresources as defense in depth.
• Preserve ordinary external links as user-initiated navigation, but ensure new-window links use safe rel attributes.

If a future product requirement allows users to load remote images, it should be an explicit per-message action with a clear privacy warning, not the default.

Acceptance criteria

• Rendering an email containing <img src="https://tracker.example/pixel"> produces no browser request to that origin.
• http and protocol-relative remote image sources are also blocked.
• CID images rewritten to the authenticated local attachment endpoint continue to render.
• Script, iframe, object, embed, stylesheet, and other active/remote content remains blocked.
• Responses containing rendered email HTML include a restrictive, tested CSP.
• Sanitizer tests cover tracking pixels, malformed URLs, protocol-relative URLs, CID images, and allowed local images.

Security/privacy impact

Archived email must be treated as attacker-controlled content. Sanitizing scripts is not sufficient if passive remote resources can still beacon information about the authenticated viewer.