Re: Ideas for an Email Specification

Very awesome!

I Think we have to talk about a subversion HTML 5 Email, CSS Email and
Embed Objects.

What do you think about to split the group to focus to the main pain points?






Joshua Cranmer <Pidgeot18@verizon.net> schrieb am Sa., 9. Juli 2016 um
02:01 Uhr:

> 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
>
>
>