Can you share some CSS vulnerabilities that would work in email but not in a browser? I can certainly think of CSS vulnerabilities that would not work in email because email can't execute javascript, but can't come up with the reverse off the top of my head. Genuinely curious here.

* Any way that reference external resource like css url() can be used as beacon. It should be blockable by client like image, but thinking how it affect is difficult if all tags are allowed.

* iframe content inside message is editable after message sent.

* Java Applet/ActiveX is almost dead, but still available. Should it be allowed on email? (for web mail on IE11/Trident)

* Sanitizing JavaScript from HTML by blacklisting isn't simple operation. Possibly attack vector. (for web mail)

> * Any way that reference external resource like css url() can be used as beacon. It should be blockable by client like image, but thinking how it affect is difficult if all tags are allowed.

You can already use url() to load background images - seems like this is a solved vector.

> * iframe content inside message is editable after message sent.

Does this really increase the attack surface area, since you can't execute javascript from the iframe?

* Java Applet/ActiveX is almost dead, but still available. Should it be allowed on email? (for web mail on IE11/Trident)

No, because that's not in the HTML/CSS spec and modern browsers don't support it.

* Sanitizing JavaScript from HTML by blacklisting isn't simple operation. Possibly attack vector. (for web mail)

Seems like a solved problem considering there's currently no way to execute arbitrary javascript in webmail.

> You can already use url() to load background images - seems like this is a solved vector.

Background image with url() is very easy to be whitelisted because it's very similar to <img> tag.

> Does this really increase the attack surface area, since you can't execute javascript from the iframe?

Sorry, this concern isn't about security for browsers, but for text editable email without indication. Maybe you can argue that it's not a problem because external image is already replaceable, but IMO it's more problematic.

> No, because that's not in the HTML/CSS spec and modern browsers don't support it.

Blacklist approach means that any tags just work unless explicitly specified on blacklist. "Not in spec" won't help.

> Seems like a solved problem considering there's currently no way to execute arbitrary javascript in webmail.

That's thanks to whitelist approach.

I don't think there's any HTML or CSS that is problematic in an email. The problem is Javascript.

The surface of HTML+CSS is pretty big by now. Perhaps you could use CSS to restyle the "From" address: hide the original content and use an :after property to put "$bank_name" there. Perhaps you can generate a unique @font url for each user to track opening of messages. Just two things of the top of my head that maybe won't work, but it would probably be a cat and mouse game for a while when security researchers start poking at it.