I often think the best way to defeat email open tracking would be for a mainstream email client to prefetch every image when a non-spam email is received and cache it for 72 hours or so.
Every email gets flagged as “opened,” so the flag is meaningless, and recipients can see the images without triggering a tracker.
I made an attempt to enumerate them[1], and whilst I catch this issue with feImage over a decade ago by simply observing that xlink:href attributes can appear anywhere, Roundcube also misses srcset="" and probably other ways, so if the server "prefetched every image" it knew about using the Roundcube algorithm the one in srcset would still act as a beacon.
I feel like the bigger issue is the W3 (nee Google). The new HTML Sanitizer[2] interface does nothing, but some VP is somewhere patting themselves on the back for this. We don't need an object-oriented way to edit HTML, we need the database of changes we want to make.
What I would like to see is the ability to put a <pre-cache href="url"><![CDATA[...]]></pre-cache> that would allow the document to replace requests for url with the embedded data, support what we can, then just turn off networking for things we can't. If networking is enabled, just ignore the pre-cache tags. No mixing means no XSS. Networking disabled means "failures" in the sanitizer is that the page just doesn't "look" right, instead of a leak.
Until then, the HTML4-era solution was a whitelist (instead of trying to blacklist/block things) is best. That's also easier in a lot of ways, but harder to maintain since gmail, outlook, etc are a moving target in _their_ whitelists...
I worked for a short time for an American company. They had periodic phishing test from Mitnick. The links in those emails was not to be clicked as it would trigger a mandatory training. The emails also had a header saying they were a phishing test, so I deleted all those emails in a filter.
The company also ran a mail filter called Baracuda or something similar that followed links in emails to see if they were malicious.
I was quite annoyed when I was called to do the mandatory training as "I" had clicked a link (on an email I hadn't seen) and more so when told I had no other recourse than to sit through it.
Did everyone get flagged then thanks to Barracuda? You’d think they’d realize there’s a problem if there’s a 100% fail rate.
Edit: also, to be fair, you basically told them you had opted out of the test, so it’s not completely ridiculous for them to ask you to do the training instead.
Those knowb4me or whatever supposed security lessons are terrible. In our case the emails included links to external domains (to knowb4) that you were actually required to click, as in really not as a test to see who did it. And you presume to teach me Fing security...
Gmails prefetch is terrible for privacy because it honors http cache headers, which means tracking companies simply use a "no-cache, must-revalidate" header to defeat it.
That is still signal that the email address is valid. I'd prefer something like the server immediately sending a SMTP 550 5.1.1 (unknown recipient error), for anything that's immediately recognized as spam (or marked as spam in the past by the user). That gives no signal at all and might even persuade some scammers to remove your email address from their list.
That's not enough. As the article explains, SVGs can reference external resources. So you also need to prefetch those external resources, recursively, if you want to be thorough.
From reading a little bit of the code it sounds like Roundcube's sanitizer is much closer to a blacklist than a whitelist. Any attempt to sanitize HTML with a blacklist is doomed to failure. Even if you read the current HTML spec (including referenced specs like SVG) and do a perfect job there are additions over time that you will be vulnerable to.
Probably any unknown element attribute pair should be stripped by default. And that's still not considering different "namespaces" such as SVG and MathML that you need to be careful with.
Not disputing the article, nor insinuating that there's some ulterior motive, but it's curious that this blog has only one post; and the About page suggests a lengthier history (with references to what would have been previous posts).
Author here! Are you referring to the "What’s inside this vendor’s VMware images?" on the about page? That is merely an illustration of what goes on inside my head. This is the first article on my blog.
Yes, those were the suggestions which made me think there was a disparity between the About and the posts (or lack thereof).
Best of luck to you on your blog. I would suggest you also add a "welcome to my blog" post where you give a little background about why you're writing the blog and what kinds of content readers can hope to see in the future. There's no denying that you have little content, so you might as well make it clear to readers _why_ that is. Plus, it sets them up to be interested to see what's coming next.
SVGs are just the tip of the iceberg of how hard it is to sanitize email content. There aren't any purpose-built good libraries for email sanitization either. Something that would handle SVG, CSS, HTML, everything.
Slightly related, but fraudsters love using .svg attachments, typically the mails purport to be for an invoice which you need to log into your Microsoft account to be able to “securely” view.
I’m not sure if Exchange Online doesn’t scan them or something, but I landed up making a rule which blocks all emails with either .svg or .htm(l) attachments and to notify me when blocked.
Happens a couple of times per month for the our small company, no false positives yet.
I wouldn't vouch 100% for my PHP understanding but it looks like SnappyMail removes `<svg>` elements entirely (`BuildHtml` in `snappymail/v/2.38.2/app/libraries/MailSo/Base/HtmlUtils.php`)
You give the developer time to develop a patch. Once the patch is out, attackers can already deduce the vulnerability by looking at what changed and at that point you either want to immediately install the patch or you want to know what the vulnerability actually is so you can do something to mitigate it if there is some reason you can't immediately install the patch.
I am trying to read as less _online_ as possible nowadays. I essentially have dovecot in my crontab, and read it off roundcube. It's been working great, RoundCube is dead simple to setup and use, the UI and search are very fast.
They still exist. Surprisingly, most folks aren't interested in letting every newsletter and promotion know that they were seen. So a surveillance arms race ensues instead.
I often think the best way to defeat email open tracking would be for a mainstream email client to prefetch every image when a non-spam email is received and cache it for 72 hours or so.
Every email gets flagged as “opened,” so the flag is meaningless, and recipients can see the images without triggering a tracker.
I think the problem is what is an image?
I made an attempt to enumerate them[1], and whilst I catch this issue with feImage over a decade ago by simply observing that xlink:href attributes can appear anywhere, Roundcube also misses srcset="" and probably other ways, so if the server "prefetched every image" it knew about using the Roundcube algorithm the one in srcset would still act as a beacon.
I feel like the bigger issue is the W3 (nee Google). The new HTML Sanitizer[2] interface does nothing, but some VP is somewhere patting themselves on the back for this. We don't need an object-oriented way to edit HTML, we need the database of changes we want to make.
What I would like to see is the ability to put a <pre-cache href="url"><![CDATA[...]]></pre-cache> that would allow the document to replace requests for url with the embedded data, support what we can, then just turn off networking for things we can't. If networking is enabled, just ignore the pre-cache tags. No mixing means no XSS. Networking disabled means "failures" in the sanitizer is that the page just doesn't "look" right, instead of a leak.
Until then, the HTML4-era solution was a whitelist (instead of trying to blacklist/block things) is best. That's also easier in a lot of ways, but harder to maintain since gmail, outlook, etc are a moving target in _their_ whitelists...
[1]: https://github.com/geocar/firewall.js
[2]: https://developer.mozilla.org/en-US/docs/Web/API/HTML_Saniti...
I worked for a short time for an American company. They had periodic phishing test from Mitnick. The links in those emails was not to be clicked as it would trigger a mandatory training. The emails also had a header saying they were a phishing test, so I deleted all those emails in a filter.
The company also ran a mail filter called Baracuda or something similar that followed links in emails to see if they were malicious.
I was quite annoyed when I was called to do the mandatory training as "I" had clicked a link (on an email I hadn't seen) and more so when told I had no other recourse than to sit through it.
I resigned shortly afterwards.
Did everyone get flagged then thanks to Barracuda? You’d think they’d realize there’s a problem if there’s a 100% fail rate.
Edit: also, to be fair, you basically told them you had opted out of the test, so it’s not completely ridiculous for them to ask you to do the training instead.
There’d be a bigger problem for the security training folks if there was a 100% pass rate.
Those knowb4me or whatever supposed security lessons are terrible. In our case the emails included links to external domains (to knowb4) that you were actually required to click, as in really not as a test to see who did it. And you presume to teach me Fing security...
Some of the big providers already do this, notably Apple and Gmail:
https://www.litmus.com/blog/gmail-prefetching-images
Gmails prefetch is terrible for privacy because it honors http cache headers, which means tracking companies simply use a "no-cache, must-revalidate" header to defeat it.
That sounds like a feature, not a bug, given where Google’s revenue comes from.
I knew the people who were setting this up for Yahoo like 10 years ago. Lots of major providers do it now.
I think this is what icloud does. Seems like an easy way to make tracking useless if every client did it.
That still provides “human” vs “bot” feedback to the sender.
An automated system processing emails isn’t going to be fetching images or rendering attached SVGs.
I think I might be misunderstanding. Why wouldn’t it? It’s not like the human is manually decoding the SVG or getting the PNG.
I mean I don't think that's exactly true in the age of LLMs.
That is still signal that the email address is valid. I'd prefer something like the server immediately sending a SMTP 550 5.1.1 (unknown recipient error), for anything that's immediately recognized as spam (or marked as spam in the past by the user). That gives no signal at all and might even persuade some scammers to remove your email address from their list.
If you don’t follow spam links, then it lets the spammer probe your spam filter, and try stuff until you follow links.
A better approach is to follow all links always (even to non-existent recipients) if you must play this game.
That reminds me: I should make sure all my mail clients are still set to plain text rendering.
That's not enough. As the article explains, SVGs can reference external resources. So you also need to prefetch those external resources, recursively, if you want to be thorough.
From reading a little bit of the code it sounds like Roundcube's sanitizer is much closer to a blacklist than a whitelist. Any attempt to sanitize HTML with a blacklist is doomed to failure. Even if you read the current HTML spec (including referenced specs like SVG) and do a perfect job there are additions over time that you will be vulnerable to.
Probably any unknown element attribute pair should be stripped by default. And that's still not considering different "namespaces" such as SVG and MathML that you need to be careful with.
Not disputing the article, nor insinuating that there's some ulterior motive, but it's curious that this blog has only one post; and the About page suggests a lengthier history (with references to what would have been previous posts).
Author here! Are you referring to the "What’s inside this vendor’s VMware images?" on the about page? That is merely an illustration of what goes on inside my head. This is the first article on my blog.
Yes, those were the suggestions which made me think there was a disparity between the About and the posts (or lack thereof).
Best of luck to you on your blog. I would suggest you also add a "welcome to my blog" post where you give a little background about why you're writing the blog and what kinds of content readers can hope to see in the future. There's no denying that you have little content, so you might as well make it clear to readers _why_ that is. Plus, it sets them up to be interested to see what's coming next.
Good suggestion! Thanks. I'll go write up a welcome post soon :)
SVGs are just the tip of the iceberg of how hard it is to sanitize email content. There aren't any purpose-built good libraries for email sanitization either. Something that would handle SVG, CSS, HTML, everything.
Slightly related, but fraudsters love using .svg attachments, typically the mails purport to be for an invoice which you need to log into your Microsoft account to be able to “securely” view.
I’m not sure if Exchange Online doesn’t scan them or something, but I landed up making a rule which blocks all emails with either .svg or .htm(l) attachments and to notify me when blocked.
Happens a couple of times per month for the our small company, no false positives yet.
Too bad CORS doesn't fix this. It would be awesome to be able to sandbox a page completely.
You can use CSP for this:
Hmm, I wonder, if roundcube was the exception (w.r.t feImage), or if soon other webmail clients will need to be patched
Author here! I have looked at Thunderbird. I'll go and look at some others as well, should have probably done that earlier.
I wouldn't vouch 100% for my PHP understanding but it looks like SnappyMail removes `<svg>` elements entirely (`BuildHtml` in `snappymail/v/2.38.2/app/libraries/MailSo/Base/HtmlUtils.php`)
You disclosed this the day roundcube was patched. Isn’t it usual to give us time to deploy updates before disclosing details?!
You give the developer time to develop a patch. Once the patch is out, attackers can already deduce the vulnerability by looking at what changed and at that point you either want to immediately install the patch or you want to know what the vulnerability actually is so you can do something to mitigate it if there is some reason you can't immediately install the patch.
The patch disclosed details pretty clearly already.
https://github.com/roundcube/roundcubemail/commit/26d7677
Nice catch!
I am trying to read as less _online_ as possible nowadays. I essentially have dovecot in my crontab, and read it off roundcube. It's been working great, RoundCube is dead simple to setup and use, the UI and search are very fast.
whatever happened to read receipts? I wouldn't mind allowing a sender who wants to know if I've opened their email, access to a read receipt about it.
They still exist. Surprisingly, most folks aren't interested in letting every newsletter and promotion know that they were seen. So a surveillance arms race ensues instead.