Mining my mailbox for top email service providers
obem.be
obem.be
The author clearly isn't subscribing to things like Best Buy's weekly deal email, or Target cart reminders.
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...
Let me know if we can help.
The grandparent was worried about the extension stealing his email's contents.
I think the app store should warn that a page can send data to any website if it has permission to modify any page.
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.
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.
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)
* Salesforce * IBM * Contact Contact * Campaign Monitor * HubSpot * ActiveCampaign
etc etc
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.
Who on earth, that knows how to unsubscribe, would ever subscribe to spam?
I'm subscribed to some marketing emails, but I delete them after reading them. I save transactional emails.
Maybe the other big operators are more content-based?
What you say certainly rings true about Gmail - email subjects/bodies that set off warning bells in Outlook seemingly pass through Gmail without a hitch if your account has a good sender reputation - and vice-versa. However, we've also noticed that even if you have a good sender reputation, Gmail can and will (automatically) spam your content if the wording is too spammy/phishy.
Yahoo seems to be midway between Outlook and Gmail, at least from what I've observed.
Anyway, do give the tool a spin and try out various types of emails. I'm sure you'll find the results interesting!
[EDIT] Oh, BTW - you can set the tool to use your own service as well! Obviously, this will be more accurate than using the default (which is an SES account we use).
Are those percentages really a good measure of deliverability? I mean, a significant portion of “one million dollars for you” scams in my Gmail spam folder are from @gmail.com addresses; that doesn’t say anything about gmail.com to gmail.com deliverability.
I was thinking about spam as I read the post too, since this is a problem I get to deal with almost daily. Marketo has a terrible signal-to-noise ratio and it can often end up blackholed on my network with nary a user noticing. Sendgrid is my next least-favorite email-as-a-service, and in fact I happened to have this article open in one tab and in another tab I had this morning's automated reports from some of my spam software showing that a pile of inbound messages from Sendgrid had tried to land at a list of nonexistent mailboxes -- someone was rolling through "andy@", "barbara@", "vijay@", "kenneth@", etc.
I have had very little trouble with Mailgun in this regard, so far, but that may only be because the spammers haven't fully adopted them yet.
As a sysadmin on the receiving side, I really loathe these services, they make my job significantly harder and more time consuming than it used to be.
Unless I misunderstood, the person you replied to literally says he has emails from @gmail.com throwing in his Gmail spam filter. So not sure why you mention Gmail is special here (regardless if it's true or not).
If you mess-up really bad you will have bad deliverability across the board.
The mistakes can be numerous:
* bad setup like broken DKIM
* bad sending parameters like opening too many connections by IP to a given provider
* bad content format like too many large images
* bad actual content
* bad recipient list management with lists containing lots of typos, none existent mailboxes, spam traps, etc
* miss-managing unsubscribes
* bad bounce handling
If this happens, you can have some if not all of your IPs blacklisted, maybe even your domain. In worst cases, a whole IPv4 range is blacklisted.
Then a second aspect to take into account is the open rate and the click through rate (people actually clicking a link in a marketing email), this one can vary depending on the company activities, and also the quality of their marketing content, but is generally in the range of a few percents at most. And then, you also have to take into account the actual impact in term of sells which will be even lower.
Deliverability is import, it's not rocket science, but it's a lot of small items various people at various stages (tech, creatives, marketers, etc) must be cautious about which makes it actually quite hard.
I understand that people use what they're familiar with and there seems to be a vibrant ecosystem for JS outside of the browser but it'll never not be weird seeing it take over what would once have been written in Perl or Python, especially since for a long time all I heard about Javascript was "well yeah it sucks but it's not like I have a choice if I want to script in the browser".
Software is eating the world, and the web is eating software.
At first, I thought it was crazy. It kinda makes sense though, JS seems to be growing extremely fast.
Readable languages are the kinds where not only do you understand what they're trying to do at a quick glance, but also what they actually do.
Just because more people are doing it, doesn't mean it's improving.
I'll believe things are going in a good direction when `{}.foo` throws an exception in all major JS implementations. But I'm not optimistic about that ever happening.
My only hope for JavaScript right now is that it might die because WebAssembly lets a reasonable language achieve dominance.
It does. That's a SyntaxError.
Try one of the following:
> ({}).foo
undefined
> var a = {};
undefined
> a.foo
undefined
The fact that JavaScript throws an exception on `{ foo: 'bar' }.foo` and not `({}).foo` isn't exactly a defense of the language.
> Now imagine hundreds of lines of code and a bunch of asynchronous callbacks occur between the last two lines, and imagine what that does for your debugging experience
That's what using typed signatures for your objects is for. It's not even substantially different from having, say, Java with an object with properties that can be nullable or Optional.empty().
This is an excellent and succinct explanation of why JavaScript is a badly-designed language, and why I use better designed languages when possible.
If the basic properties "work" when it makes no sense for them to work, your language is broken.
> That's what using typed signatures for your objects is for.
Explain more?
With Typescript or even just JSdoc and a good IDE, you can do:
const a: {propertyA?: true; propertyB?: 'cats';} = {};
// or
/**
* @type {object}
* @property {true=} propertyA
* @property {'cats'=} propertyB
*/
const a = {};
With Typescript, you can turn on full strictness and make these build-rejecting compile-time errors, too.
There gotta be a better way to design syntax for an async language.. right?
The Pragmatic Programmer says to throw away prototypes, but in practice it always seems easier to click the merge button than to rewrite working code.
You aren't seeing the non-existence all the well engineered stuff you never had time to build "properly".
If only 1 in 10 throwaway scripts survives, that can easily cost more in the long run than writing all 10 scripts in a sustainable way.
The open secret is that you almost always have time to do it properly. Doing it properly doesn't take that much more time, and most deadlines are self-imposed and artificial.
EDIT: Time isn't actually the most important cost. Not my code, but a coworker's throwaway script where he thought, "We'll just log this to a file for now" filled up a production DB server with log entries and took down a high-traffic e-commerce site for 6 hours. That easily cost more money than an entire career's worth of "doing it properly". There were obviously multiple mistakes that allowed that to happen, but removing the "we'll do this properly later" mistake would have prevented it.
> Doing it properly doesn't take that much more time
If you don't have a cutting board for a small thing, surely you wouldn't put your cooking on hold to drive out to the kitchen supply shop to buy a cutting board. You'd just use a stack of cardboard or something. (And make a note to buy a proper cutting board later, of course.)
Technical debt is inevitable, and it will never be adequately documented. That's not really the situation we're talking about here.
This is more about stuff that was written with the mindset of "this will go into prod" versus "this will never go into prod". If your code is never going into prod, it's often acceptable to have huge, critical bugs--that's a very different thing from technical debt.
> If you don't have a cutting board for a small thing, surely you wouldn't put your cooking on hold to drive out to the kitchen supply shop to buy a cutting board. You'd just use a stack of cardboard or something. (And make a note to buy a proper cutting board later, of course.)
Well, sure, but this is a great example of why analogies aren't a good way to make arguments.
You're talking about using the right tools, not doing things properly. Sure, if I don't have the right tools, I'd do the best I can with the tools I have. But you'd better bet that a professional chef shouldn't just skip chopping the carrots because "it's just a throwaway dish, no need to do this properly" when there's a chance that it's going to be served to a food critic.
There are differences in style and views on things from the way they were long ago that float around. These impact a lot of opinions.
Do you have any links to good examples/comparisons?
http://modernperlbooks.com/books/modern_perl_2016/index.html
I've mentioned it before, but reading this book and applying its concepts (along with judicial use Damian Conway's Perl Best Practices) changed my view of Perl from "well, I guess I'll use it since it's here," to "I really enjoy using Perl".
Mark Jason Dominus's Higher-Order Perl was another enjoyable read, for its advice on using Perl as a more functional programming language.
This is from a few years ago, but I bet it’ll still do the trick:
https://austingwalters.com/analyzing-email-data/
Everything is in python:
https://github.com/lettergram/Email_Analysis
Regardless, I encourage everyone to do an analysis of their emails. Cut out the junk, set reminders on when to check, etc. it’s both enlightening and potentially horrifying to discover trends.
Return-Path: <bounces+XXXX@XXXX.intercom-mail.com> Received: from mta-216-35.sparkpostmail.com (mta-216-35.sparkpostmail.com. [147.253.216.35]) by mx.google.com with ESMTPS id t13si7000210pgg.534.2020.02.03.08.37.30 for <XXXXXX> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Feb 2020 08:37:30 -0800 (PST)
For example MailChimp Targets small B2C companies while Hubspot targets small B2B business.
I’m guessing the op isn’t a small B2B business hence the lack of hubspot in the list.
Is this intentional? I assumed the opposite, given that:
> Mandrillapp.com is the transactional email service for Mailchimp. It used to be a standalone service until it became deeply integrated into Mailchimp.
;(async function () {
try {
// All your code
} catch (e) {
console.log(e)
}
})()
;(async function () {
// All your code
})().catch(console.error)
Starting a line with ; is just plain weird and the last bit })() seems like German, where all the stuff that you technically not need to understand the sentence is at the end.
Maybe someone can explain with JavaScript developers love anonymous functions so much. Why not just name your function and make the whole thing a bit more readable.
Love the language, hate the popularity of anonymous functions and non-descriptive variable names.
My production code as a sample. http://designbymobi.us/wp-content/uploads/2020/02/rabbitmq-c...
function someName(p1, p2) {}
and then when you need it for something, like a handler, just say:
handler: someName
Obviously wrong. My mistake.
catch(err => console.error(err))https://twitter.com/dustywes/status/1228733404826333185?s=21
I’m planning on doing a more thorough write-up on my solution (it’s convoluted), but my tl;dr is that email seems woefully broken at the moment. Hope my experience can be helpful for others dealing with the same issue.
Sendgrid: 30.2%
SES: 16.8%
Mailchimp: 16.8%
"Amazon SES only supports open tracking over HTTP domains."
https://docs.aws.amazon.com/ses/latest/DeveloperGuide/config...
Yes, big webmail providers fetch the tracking pixels for you and serve them to your browser over HTTPS, but not every mail provider does that, sometimes for good reason, leading to problems like this:
https://protonmail.com/support/knowledge-base/connection-not...
The emails in your mailbox aren't yours to do with as you please - they're all still owned by their original sender, who has given you an implicit license to read them, and store them for later re-reading.
You don't really have rights to datamine, aggregate, train AI on, post stats about, etc. the data in those emails. Its a violation of the rights of the original sender to do it without permission.