Pass requests for remote resources through proxy service

[infogulch]

To improve privacy some email services run requests for remote resources (i.e. email images, styles etc) through a caching proxy, sometimes even pre-caching resources. This prevents the client IP and open date from leaking to the sender.

Google's Gmail runs remote resource requests through their proxy in the web client, but doesn't do anything for people that use traditional clients as through IMAP. Briefly in 2013 it also pre-cached resources, but they stopped after getting blowback from marketers.

Today Protonmail does both. See: Enhanced Tracking Protection, Loading images in Proton Mail.

I think this would be a great feature to have in open source, so I started a discussion about it in the Stalwart Mail repo. The conclusion there so far is that this would need to primarily be a client-side feature.

Is this a feature that tmail might consider?

[chibenwa]

Hello,

Thanks for reaching us on the topic, which definitly is an interesting one.

IMO it is both a server ( as resources needs to be cached by the server upon receival OR proxy) topic, frontend topic (needs to ask the server for remote resources ) and a service policy (extra calls / bandwith vs privacy. So IMO we would need something that would look like a spec to implement.

Do you have some kind of drafts for this already?

[infogulch]

I agree with your assessment of the scope. To restate it, the backend will need to sustain CDN-like compute workloads for all clients, the frontend will need to be capable of proxying resource requests through the server ¹, and they will need some way to communicate the proxy configuration and turn it on and off. Policy beyond turning the proxy on and off reduces to a privacy vs cache retention question, which I think we can leave to the administrators running the server to balance.

Yes a spec will be needed at some point. It would probably also be good to implement an mvp demo to show that it basically works. Not sure what path would be best.

Footnotes

1. e.g. browser clients may use the webRequest api ↩

[infogulch]

Setting up an http server to handle some X-Forwarded-* headers and cache things will be very straightforward.

The longest path dependency imo is to implement resource proxying as an experimental client feature with manual configuration. From there we can test and iterate on it and the server config until it mostly works. Call it a "Feasibility Study" even. Once we have a vertical slice that "works" we reevaluate (and consider other complications like cross platform implementations and email encryption).

It looks like a library you use html-editor-enhanced ¹ uses an android webview ². Is it reasonable to assume that tmail uses the platform webview to render emails? Notably, Android has ProxyController ³ for apps to manage per-webview proxies.

Footnotes

1. https://github.com/linagora/html-editor-enhanced ↩

2. https://github.com/linagora/html-editor-enhanced/blob/90bf8a872bd9039511c04c81621f5bbab67325a4/lib/utils/shims/flutter_inappwebview_fake.dart#L1 ↩

3. https://developer.android.com/reference/androidx/webkit/ProxyController ↩

[chibenwa]

Is it reasonable to assume that tmail uses the platform webview to render emails?

Yes.

Ok so we are looking for a PROXY configuration.
The proxy itself could be something like squid, I guess?
Advertizing the proxy and configuring tmail seems doable...

Another point remain: as a service operator I whishes to proxy only requests originating from my Twake mail fleet and not run an open-http-proxy on the internet. How could we secure the proxy usage and limit it to my only tmail users?

[infogulch]

something like squid

I'm not familiar with squid but it would probably work. I might prefer to trial this with Caddy Server at first since it is very flexible: it has caching and authentication features built-in and is very easy to configure. Once a pattern is working and nailed down, we can look at expanding to other servers.

How could we secure the proxy

We definitely want the proxy to authenticate requests. Can we piggyback on jmap authentication?

[chibenwa]

Also we would need a mechanism to pre-load resources in the proxy...

THis is the case for a real proxy behaviour, likely uneeded if mail server pre-loads data

[infogulch]

I think the client configuration doesn't need to change if the server pre-loads resources. We'd just need to configure the server to retain images forever... which leads to some troubling considerations:

If we're preloading images etc then we need to retain them until the original email is deleted. So the mail server will need to keep a record of which emails use which resources so they can be cleaned up after no emails reference it anymore (or accept infinite growth? probably not). Also, considering very long-term retention, we might run into situations where the sender changes an image (say, 5 years after sending the first email) so if new emails reuse the cache then that can be problematic. We'd probably need the cache to be able to cache multiple versions of a given url and serve the appropriate version to emails of a given age.

This seems to be a much bigger problem. Maybe we should pretend we didn't see this and come back to it later. 😅

[infogulch]

Proton Mail does it differently:

If Proton can intercept remote images inside my email, can Proton read my emails?
To protect you, we now load remote images in your emails using our servers as we receive them rather than when you open them.

This applies to emails you receive that are not end-to-end encrypted, such as most newsletters and promotional emails. These emails have already been checked for spam, phishing, and malware before arriving in your inbox, so we simply added tracking protection to existing automated filters.

Emails are then stored in your inbox with zero-access encryption, and we can no longer access them.

[chibenwa]

[infogulch]

Was it something I said? 😅