Introduction: Neil Jenkins, FastMail

Hi,

I'm Neil Jenkins and I work for FastMail (https://www.fastmail.fm),
mainly building our webmail client. I'm happy to offer our perspective
as an email client author and service provider.

As a quick guide, we do the following with HTML email:
* Try to support the full fidelity of the browser, subject to the
  constraints below.
* Parse the whole structure on the server, with all tags, attributes
  etc. evaluated against a white-list to remove any potential security
  issues (no JavaScript allowed, no plugins, no frames).
* Any external content (images, linked CSS etc.) is allowed only via
  user preference, to prevent unwanted tracking.
* CSS properties like position:fixed that could draw over the main UI
  are not allowed.
* CSS selector precedence is not respected – precedence is solely
  determined by order. Due to the need to render the email in the same
  HTML page as the webmail UI without the two conflicting and without
  rendering the email in an iframe, we do the following:

  1. Have a hidden iframe in which we inject the CSS.
  2. Build a DOM tree from the HTML using innerHTML in the scope of the
     original page, but don't insert it into the document yet.
  3. Use the Stylesheets API to traverse the parsed CSS in the iframe,
     then use querySelectorAll to find the elements in the DOM tree that
     a rule applies to and apply the style directly to the elements. We
     iterate backwards through the rules and don't override a style
     already set, which maintains the basic precedence (direct attribute
     > CSS rule, later rules > earlier rules), but doesn't match the
     real CSS precedence. We also support most media queries.
 4. Strip the ids and class names from the elements to avoid any
    conflicts with the CSS for the UI.
 5. Inject it into the page for the browser to render.

I don't know how this compares to other webmail clients, but all are
faced with the same problem: cleaning potentially dangerous external
content which you need to inject into a page with full privileges. So,
perhaps some standardised "safe" subset of HTML/CSS could be agreed
upon, preferably as easy to verify as possible.

Cheers,

Neil.

Received on Tuesday, 4 February 2014 12:53:22 UTC