Re: Ideas for an Email Specification

On 7/8/2016 7:16 AM, Rémi (HTeuMeuLeu) wrote:
> Hello everyone,
>
> I believe that creating an Email Specification with guidelines for 
> email client vendors could vastly help getting things standardized. 
> Given the recent rebirth of this mailing list, I'd like to share a few 
> random ideas I had in the past year of things that should be 
> standardized across email clients.
>
> # HTML
> * How to embed an HTML email within a webmail or application. Some 
> webmails like Gmail, Yahoo or Outlook.com embed the HTML directly 
> within the webmail. Others like AOL use an iframe.
> * Supported attributes. Given the immensity of JavaScript attributes 
> that can be written directly inline (like "onload", "onmouseover", 
> etc.), I believe the safest way to embed an HTML email within a 
> webmail is to have a white list of supported attributes. I believe 
> attributes like "id" and "class" should be supported. But for some 
> reason, a webmail like Gmail removes this (even though it keeps styles 
> targeting classes or ids).
> * Attributes prefixing. Supported attributes like class or ids should 
> be prefixed in order to prevent an email to reuse styles from a 
> webmail. This is done by webmails like Yahoo.
> * Supported elements. Listing elements that should or shouldn't be 
> supported by webmails and email clients. For example, should a webmail 
> support video or audio tags ? What are the security implications ?
> * Image blocking. Some webmails (like Outlook.com) block images by 
> replacing the image path in the src attribute with a dummy pixel 
> image. Others (like Gmail, Yahoo or AOL) remove the src attribute. 
> Both solutions have different results across browsers depending on 
> other attributes present on the images.
>
> # CSS
> * Supported properties. Things like "position:fixed" should be removed 
> for security reasons (a malicious email could easily position an 
> element above the webmail's UI). What properties and values should be 
> allow ?
> * Filtering guidelines. If a style has to be filtered, how should this 
> happen ? Some webmails remove only the property concerned. Others the 
> complete CSS rule. And others the complete style tag.
> * Styles prefixing. This follows the HTML guideline for attributes 
> prefixing. But there's allow cases were prefixing needs to happen in 
> CSS. For example, a webmail should prefix animations @keyframes 
> declarations names (in order to avoid a malicious email to use same 
> names as in the webmail's UI).
>
> Do you see more points that needs to be addressed ? My biggest 
> question is how can we talk about this in a productive way. For 
> example, listing all the CSS properties that should be supported in a 
> webmail can be a huge task. Should we like open a Github issues 
> somewhere and open a discussion for every single CSS property ?

There also should be discussion on how the HTML interacts with the email 
and MIME formats. Examples of such concerns include:
* HTML doctype assumptions
* HTML charsets
* The use of cid: (if you have to rewrite URLs, then you have to know 
specifically which contexts can include cid: links that may need to be 
rewritten).
* Security concerns with respect to remote resource loads. Things like 
fonts or videos default to prohibiting cross-origin loads, which makes 
their use in email more problematic. And, of course, some users would 
prefer not to load remote images
* Some standardization for standard email features, most notably 
indicating replied-to content, and arguably signatures.

 From the HTML/CSS world, one thing that would make developing webmail 
clients easier is the introduction of an <iframe> that takes its height 
from content (the venerable 
<https://bugzilla.mozilla.org/show_bug.cgi?id=80713>). This would allow 
clients to use <iframe> to achieve a lot of sandboxing with much less 
risk to its UI if it fails to rewrite stuff.

-- 
Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth

Received on Saturday, 9 July 2016 00:01:32 UTC