Re: Ideas for an Email Specification

This is what I think that looks like. Please feel free to correct any glaring inaccuracies or omissions.

Whitelist

  1.  By default, no HTML element or CSS property is supported.
  2.  Email community – through a vetted documented process – requests a feature support.
  3.  Document must contain a use case.
  4.  EACH email client vendor reviews request document and use case to make determination for approval.
  5.  SOME email client vendors add feature to product development cycle.
  6.  Eventually, support appears in a single email client.
  7.  Much later (likely years), support appears in remaining email clients that approved.

The result is that there is still widely varied support at widely varied times based on use cases that had to be foreseen years earlier. This seems like the current state of email client vendors.

Blacklist

  1.  By default, all HTML elements and CSS properties are supported.
  2.  As new HTML elements and CSS properties become available, EACH email client vendor reviews specifications for any potential risk an misuse.
  3.  IF a legitimate risk is discovered, an email client vendor publishes a documented specification of risk and reason to NOT support.
  4.  EACH email client vendor adopts this as standard.
  5.  Feature is not supported anywhere.
  6.  IF no risk is discovered, EACH email client vendor adds feature to product development cycle.
  7.  Eventually, support appears in a single email client.
  8.  Much later (likely years), support appears in EACH email client.

The result is that there is universal support for all HTML elements and CSS properties that pose no legitimate documented risk. The only thing that varies is the timeline of feature availability. This is more consistent with the current state of browser vendors – many of which are the same organizations as the email counterparts.

If this is accurate, I prefer the blacklist model. It seems to put more burden on the email client vendor to prove why a feature should not be supported.

Thoughts?


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:2FE6B972-796F-48C8-8DA5-46D8666F60A7]
Creativity. Technology. Performance.

On 7/10/16, 8:20 PM, "Chaals McCathie Nevile" <chaals@yandex-team.ru<mailto:chaals@yandex-team.ru>> wrote:

On Fri, 08 Jul 2016 19:08:49 +0200, Rémi (HTeuMeuLeu) <remi@hteumeuleu.fr<mailto:remi@hteumeuleu.fr>>
wrote:

Thank you all for your warm answers.

I have a preference to lead discussions (I'm not sure Slack is suited for
this, and I don't like Slack proprietary nature). There is already a
Github group linked on this CG (https://github.com/W3CGHtmail), but I'm
not sure how to joing…

If you tell me your github user id I can sign you up.

There's also the Wiki (
https://www.w3.org/community/htmail/wiki/Main_Page).
What would be the best way to discuss in detail everything ?

Regarding CSS support, I believe a blacklist is a bad idea given the
living and always evolving nature of CSS. Let's say that tomorrow Chrome
introduces a `display:-blink-fullscreen` property that can display any
element full screen. This would be bad for webmails security and should
be blacklisted. But there's a good chance webmails would take a long time
to add this to their blacklist. So a white list approach seems better to
me (from a security standpoint).

I think there is value to three things. The first is identifying what
actually does work in what clients. There is some subset of HTML and CSS
that pretty much works everywhere, some set of things that work in some
places, and some that work in none.

I think it's worth looking carefully at the things that work sometimes,
and checking whether there is a good reason *not* to implement them, such
as security.

Equally, it would be worth looking at the things that aren't implemented,
find out whether there is a good reason not to do so, and if there is a
good use case for having them. In some sense there is always a use case,
but for example "you can't write arabic without it" or "you can't make
something accessible without this" seems a stringer reason to me than "I
would like to use flexbox to make email appear in star shapes…".

My idea for discussing CSS support was to take a list like this one (
https://drafts.csswg.org/indexes/) and discuss every single properties,
values, functions, at-rules and selectors and see if they make sense for
emails (from a security standpoint once again). I don't want to cater
for a minimal subset of CSS like the old Email Standards Project did (
https://www.email-standards.org/). I want as much CSS support as
possible. (And I want to use flexbox and CSS grids in emails, god damn
it.)

I hope you don't get flexbox in emails ;)

Seriously, I agree that just finding a minimal set isn't much of a goal,
but as Rouzbeh points out it may well be a useful task to do anyway, as a
waypoint.

cheers

Chaals

2016-07-08 18:06 GMT+02:00 Rouzbeh Sarrafieh
<rouzbeh.sarrafieh@gmail.com<mailto:rouzbeh.sarrafieh@gmail.com>>:

Agreed on the github/slack(gitter possibly to keep it open source or
even
the current IRC irc://irc.w3.org:6665/#htmail) . I think the blacklist
idea is a good one as well as I've always referred to the campaign
monitor
list https://www.campaignmonitor.com/css/ to what I can't use vs can.
This was already an idea back when the group was slightly more active
https://www.w3.org/community/htmail/2015/04/30/taking-the-reductive-approach/

Perhaps start anew setting a baseline spec to at least establish support
for small to large screen layout/typography consistency across clients,
possibly start small to build a logical minimum support of these things
before moving on to trying to bring in the vast array of CSS props in? I
feel this would be a less harrowing task for email providers and
clients to
integrate. Thoughts?

Best,

Rouzbeh Sarrafieh

Rouzbeh Sarrafieh  //  Portfolio <http://www.rouzbeh.net>  //  LinkedIn
<http://www.linkedin.com/in/rouzbehsarrafieh>   //  @rouzbeh84
<https://twitter.com/rouzbeh84>

On Fri, Jul 8, 2016 at 8:39 AM, Spellacy, Michael <
Michael.Spellacy@tmp.com<mailto:Michael.Spellacy@tmp.com>> wrote:

+ 1 Github and Slack. We might even attract more attention/help on
GitHub. :-)

Yes, agreed. Swell start.

Regards,
Spell

On Jul 8, 2016, at 11:22 AM, Hall, Charles (DET-MRM) <
Charles.Hall@mrm-mccann.com<mailto:Charles.Hall@mrm-mccann.com>> wrote:

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<mailto:charles.hall@mrm-mccann.com>
skype / charles.h.all
280 N Old Woodward Suite 300, Birmingham MI 48009
w / www.mrm-mccann.com

<5D510C5C-1CCD-479C-A466-98D1FC580B9B[13].png>
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 <http://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
<http://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.





--
Charles McCathie Nevile - web standards - CTO Office, Yandex
  chaals@yandex-team.ru<mailto:chaals@yandex-team.ru> - - - Find more at http://yandex.com


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.