Working with Email Clients

[husseinalhammad]

We clearly intend to work with Email Clients. What does entail? How can we help each other?

We came up with some ideas during meetings and on the main ideas thread (+ Slack). Perhaps we are at a stage to discuss these in more detail. I'll list these in separate replies to make discussion easier.

[husseinalhammad]

Reporting bugs to email clients

There's an existing community effort to document bugs. The primary audience for the hteumeuleu/email-bugs ended up being developers who build HTML emails. And even though the repository's readme includes links to report bugs to some email clients, the consensus is that these bug reports are generally ignored.

[husseinalhammad]

We are doing this for 1&1 email clients at trial basis right now. See #81

[M-J-Robbins]

Just been reading this article on how to contribute to thunderbird and how to report bugs

https://blog.thunderbird.net/2022/08/how-you-can-contribute-to-thunderbird-without-knowing-how-to-code/#:~:text=Let%E2%80%99s%20Go%20Bug%20Hunting

[husseinalhammad]

That's great! Under what component/category do rendering bugs go? Message Reader UI sounds like it is about the app's UI
https://bugzilla.mozilla.org/describecomponents.cgi?product=Thunderbird

[M-J-Robbins]

Yeah, I think "Message Reader UI" and "Disability Access" would cover most of the sorts of bugs we'd be reporting. There are already some bugs listed in there that seem to match the sorts of things we'd look for

[husseinalhammad]

A shared sanitiser

While we don't have plans to build a sanitiser ourselves, we could help email clients to work together on a shared sanitiser.

The goal is for email clients to handle things in a consistent and predictable way. This doesn't mean they'll support the same sets of features, but it means if a feature is/isn't supported, it would be handled in the same way.

[M-J-Robbins]

I stumbled across this list of open source web-based email clients might be helpful for us to look at how they build their sanitisers when we start working on this project.

• https://roundcube.net/
• https://cypht.org/index.html
• https://www.squirrelmail.org/
• https://www.rainloop.net/
• https://www.horde.org/
• https://www.sogo.nu/
• https://afterlogic.org/webmail-lite

[o-t-w]

The quickest way to get this done would be to get some funding and pay Igalia to build a shared open source email sanitizer seeing as they work with Google/Apple/Microsoft already. I assume it would be in the interests of ESPs to make this happen so maybe some large companies would be willing to throw some money at the problem?

[husseinalhammad]

@o-t-w Not a bad thought at all. However, contributing to an open-source browser engine is not the same as convincing a company to adopt your solution for closed-source email client.

Not saying we should not involve Igalia, but I don't think we should assume if it's built by Igalia, it would automatically be adopted by major email clients even if they have good working relationship with these companies.

[o-t-w]

I agree, its certainly harder to engage with closed source software although Igalia do have broad visibility among companies that also make email clients. See: https://x.com/RickByers/status/1839907648365334710 Perhaps starting with adoption in an open source client like Thunderbird would be the first step?
Looks like the initial version of the Sanitizer API was removed from Chrome. It's still being standardised and I think progress is being made.

[husseinalhammad]

Thanks for the nudge @o-t-w. I agree with you here. I'll come back to this thread later with some thoughts.

[husseinalhammad]

Documentation: what is/isn't safe, and why

This wasn't discussed in our latest call, but has been brought up before - including in the main ideas thread and most recently by Gnanavel Shanmugam on Email Geeks Slack:

Email providers sanitize or do not support certain markup mainly for security reasons. so wondering whether caniemail (or something similar) can show details on why certain markup tags/attributes cannot be supported by email providers when rendering an email on a platform. This will also help email providers to know about the risk in supporting a new markup.

There's certainly a lot to go through:

• HTML elements
• HTML tag attributes
• CSS properties
• CSS values
• SVG
• <script> (e.g. for JSON-LD)
• External resources (images, fonts, etc)

Does this piece of documentation also need to mention under what contexts it is/isn't safe to support some features. E.g.:

• Webmail client embedding the email message in an iframe
• Webmail client embedding the email message directly on the page
• Native mobile app (does OS matter?)
• Native desktop app (does OS matter?)

How does this documentation help us work towards our goals?

• Knowledge sharing between email clients?
• Act as a resource for email clients (not just the major ones)?
• Help other EMC projects (e.g. shared sanitiser) move forward?

[M-J-Robbins]

Is there a danger of documenting these risks publicly? Could this be helping people who are looking for malicious exploits?

I don't think that risk should block this project, but it should be considered throughout.

[husseinalhammad]

I thought about that, and I don't see it as risky. It is like documenting XSS and CSRF security issues and how to build certain functionalities without making your app vulnerable to such attacks. And just because there are a lot of websites out there that have XSS vulnerabilities, it should not stop anyone from discussing XSS publicly.

This is not just for the big players. Any party that maintains (or intends to build) an email client can refer to this documentation and improve the security of their email client. I think this actually can extend to apps that inject third-party HTML/CSS; not just email clients.

Email clients that get involved may bring up valid points against this though.

[husseinalhammad]

Documentation: rewriting HTML/CSS

The Compliant Standards document covers this at an abstract top-level way. I'm sure email clients can help us improve this document over time.

Do we additionally need a more specific, less abstract documentation for this? Does this fall under any of the other project ideas listed above already? Do we need specific documentation based on how the email message is embedded?

• Webmail client embedding the email message in an iframe
• Webmail client embedding the email message directly on the page
• Native mobile app (does OS matter?)
• Native desktop app (does OS matter?)

[M-J-Robbins]

Benefits to the email clients

Looking at the long term goals, what benefits are likely to come out of joining the EMC and building better consistency/interoperability between email clients.

• Better consistency for user to user emails. An email thread between email clients can quickly hit display and layout issues, leading to poor user experience.
• Prevent CSS fingerprinting. Currently, it’s easy to track which email client a recipient is using by focusing on the quirks of the markup. Is this a concern for the email clients?
• Communication channel to ESP’s and Email Developers. I’m sure there are a number of things senders do that frustrate the email clients. We can guide senders to do a better job from the email clients point of view.
• Shared resources. All email clients face the same challenges with email markup, these can be tackled together, giving early warning to new risks

[husseinalhammad]

Another piece of documentation! These benefits could be handy when pitching to email clients to join!

[M-J-Robbins]

Benefits to email clients document
https://docs.google.com/document/d/1GHEYYTKPAwQFa6sO1rQphrXo1ZOnasvozXM5F9fTPwA/edit#heading=h.7h75aexppzj5

[husseinalhammad]

@M-J-Robbins this document is not public right now so only EMC members who were added to the Google Drive folder have access to this

[M-J-Robbins]

Ah yes good point, I'll leave it here for now and anyone who want's access can request, but we'll have a public published version of it available at some time too.

[husseinalhammad]

Helping email clients document supported features

A shared sanitizer doesn't necessarily mean all email clients support the same set of HTML/CSS features. One of the goals of email clients using a shared sanitizer is that they would handle unsupported features in a consistent way. So the sanitizer can be configured to allow/disallow different features.

This means there will be a need for email clients to document the features they support regardless of whether they adopt using the shared sanitizer.

How can we help email clients document these? Can we provide some sort of template they can use? Perhaps it could be a JSON file that they maintain and make publicly accessible.

[M-J-Robbins]

I like that. I imagine the settings would be done in something like a JSON format in the sanitizer set up. Maybe one for an allow list and one for a block list. If we could use that same format for generating documentation, that would make things easier.

This has also got me thinking... I'm wondering if there is a way some of these settings could be passed into the template, perhaps in an attribute on a wrapping element.

Similar to the sandbox attribute for iframes we coudl maybe use data-email-sanitize-block="" data-email-sanitize-allow="". Although with iframes we can't use CSS to get that information if it were on the <html> <body> or a <div>, senders could potentially use attributes selectors to account for edge cases where certain things aren't supported.

[husseinalhammad]

The attributes selectors approach is probably more manageable than the current approaches (I know you're familiar with all the wild selectors on howtotarget.email 😅).

It almost feels like we need an at-rule like @supports, but instead of querying the browser's support of a feature, it would query the app's (in this case the email client's) support. That would make things a lot more manageable.

[M-J-Robbins]

@supports may be an option if it gets wider support. Samsung mail works a bit like that.

Using @supports (position:absolute) will get changed to @supports () and that will mean the code inside that query won't get rendered, so affectively it's doing the job it should, just in a slightly different way.

[husseinalhammad]

I think this is still a hacky approach and our goal is to move away from these. It would be great if email developers write the code as they mean it.

And if @supports is meant to check the browser's support (not the email client's), perhaps it should behave the same way inside email clients? Or should it be the sanitizer's responsibility to check this and keep/remove the at-rule block if the feature(s) are/aren't supported by the email client?

[M-J-Robbins]

How about something like prefixing the code to make it invalid. So the sanitizer would change it to @supports (-blocked-position:absolute) if position is on the block list. Or if it's only the value of absolute that isn't allowed, it could be @supports (position:-blocked-absolute).

That way, it's easier to follow what has been removed, which would help people understand why something might not be working as expected. It would also work well with not and or modifiers @supports not (-blocked-position:absolute)