A few years back, one of our (Twilio SendGrid's) developer evangelists created an open source Chrome extension to show the icon of the ESP who sent a message in Gmail.
We (Streak) made the InboxSDK. Great for projects like this because we autoupdate so you can write the extension against our high level api and not have to worry about gmail changes going forward.
OMG, this sounds like a massive security risk. That nice developer could easily siphon off all the email to his backend server with this little extension. I install almost no extensions because they are too risky.
All Chrome extensions require trust. That should factor into your decision to install any of them.
This is no more risky than any other extension whose permissions include `https://mail.google.com/`. Anecdotally, that probably includes most extensions seeing as how most of the ones I come across request `<all_urls>` whether or not they need it (not that that's okay).
In any case it's open source, so you can download it, audit the code, and install it locally to prevent auto-updating.
Or use an email client that runs outside your browser, and reduce your threat surface considerably - yes, you still have to worry about other things you do in the browser, but compromising your email compromises all those too via password resets, which isn't the case for anything else if your password discipline is good.
Yes, Gmail makes it harder than it should be to use the email client of your choice. But that's not a problem with email clients. That's a problem with Gmail. It's far from the only one.
Chrome sandboxes fetch requests from extensions and tells the user what permissions the app is requesting, so it’s not actually that bad (barring bugs in the sandbox)
> The author clearly isn't subscribing to things like Best Buy's weekly deal email, or Target cart reminders.
I don't think that will be interesting for the author given where he's based. (I first assumed Belgium due to the domain's TLD, but it's actually Nigeria)
It can be quite hard to detect. A lot of this services will not have an easily recognizable marker.
It can be for various reasons:
* They can use these services themselves
* They can support full customization of domains, including for the "message-id" and the "received" headers.
I'm working as SRE in a fairly large marketing provider (not sure in term of %, but we provide services for quite a few large brands sending several millions emails per day), and we do this full customization by default. There are other way to recognize us (other headers in the email or the pattern for the tracked url for example), but the one described in the article will not work.
It would also be interesting to be able to detect which MTA is used by these service providers. Is it an in-house one or an off the shelf one? The two off the shelf ones I know for mass sending are Momentum and PowerMTA which are both owned by Sparkpost but they might be others.
The last big Gmail UI update broke it, but most of the ESP identification strategies probably still work: https://github.com/nquinlan/Email-Intelligence/blob/master/c...