Re: Ideas for an Email Specification

Hi Rémi,

This is a brilliant start. Perhaps we should move this conversation from the mailing list to another channel to start sharing resources and tracking progress. GitHub for code examples? Slack for conversations?

I actually prefer to model the CSS supports as a blacklist instead of a whitelist. If we start with the premise that all CSS features, properties, selectors, and values should be supported, then it would be up to the vendors to reductively blacklist these and define the reasoning. As this list would ideally be shorter, it may be easier to version and iterate as support changed.

Cheers,

Charles Hall
UX Architect, Technology

t / 248.203.8723  m / 248.225.8179
e / charles.hall@mrm-mccann.com
skype / charles.h.all
280 N Old Woodward Suite 300, Birmingham MI 48009
w / www.mrm-mccann.com

[cid:1D607139-B22F-47A4-92C2-2C7A54C23A13]
Creativity. Technology. Performance.

From: "Rémi (HTeuMeuLeu)" <remi@hteumeuleu.fr<mailto:remi@hteumeuleu.fr>>
Date: Friday, July 8, 2016 at 8:16 AM
To: "public-htmail@w3.org<mailto:public-htmail@w3.org>" <public-htmail@w3.org<mailto:public-htmail@w3.org>>
Subject: Ideas for an Email Specification
Resent-From: <public-htmail@w3.org<mailto:public-htmail@w3.org>>
Resent-Date: Friday, July 8, 2016 at 8:17 AM

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 ?

Cheers,

-- Rémi

This message contains information which may be confidential and privileged. Unless you are the intended recipient (or authorized to receive this message for the intended recipient), you may not use, copy, disseminate or disclose to anyone the message or any information contained in the message.  If you have received the message in error, please advise the sender by reply e-mail, and delete the message.  Thank you very much.

Received on Friday, 8 July 2016 15:22:24 UTC