Discourage use of Mailgun as a mail provider

> 1. It's a bit different if it's a 'customer success' type person from a product that you're already using- that's different from totally cold outreach

It's really not, but I agree completely with your second point. I've managed interactions with vendors for only ~5 years and this is for a small startup, with not a lot of them, and still over 5 years they switch up your account managers left and right (people keep moving companies) and you never know what you're going to get. And each of them thinks your whole job is to just wait for their random emails to have calls without agendas scheduled where they'll go over whatever playbook they were given to see if you'll commit some more spend this quarter before their earnings.

I tend to reply after only several days and try to not get baited into looking an asshole like this Evan person did - but sometimes it's hard. I can imagine this person gets way more email than I do and my advice would be to just not reply if what you're going to write is to "teach them a lesson". There's no point in telling someone they lied to you in a sales email, get over yourself.

From the comments it seems like there's a bit of an information gap in terms of how email service providers (ESPs) like Mailgun operate, what data they must have routine access to, and how the space evolved to make money (this last part of my info is dated as I left the space about a decade ago).

First, ESPs send email on a client's behalf. One of the primary benefits of using an ESP is co-opting their email reputation and their contacts with real time blacklist (RBL) operators, postmaster organizations at major email providers and third party email reputation groups. A good reputation keeps a sender's email out of the junk folder (or worse refused/dropped on the floor) and is really all most folks care about (especially at an API driven company like Mailgun).

In order to do all of the above, an ESP needs access to the details of the email that's being sent, including recipient email addresses and the contents of the message being sent. This is because both of those things can potentially be dangerous and the ESP is the ultimate responsible party in the eyes of the receiving email provider (i.e. Google holds Mailgun as the responsible party for what Phabricator sends).

Now, as to this sales call, sometime ago (circa ~2004 I guess) it became apparent that ESPs could work with their problematic clients to improve their sending habits, thereby improving their reputation and collect more money from the client in the process (via either direct consulting fees or increased sending volume). This kind of win-win made a lot of sense, but as the price-per-email sent was dropping ESPs were looking for ways to reliably generate more revenue and, well, "deliverability consulting" became a thing. My guess is that this is what this email exchange was about, and like any consulting effort, it's only as good as the last interaction and here I agree with Evan that "Joe" fumbled the ball fairly badly.

Personally, I would have just reached out to Mailgun support and asked what's up with the incorrect billing and Joe's problematic responses, but that doesn't appear to have been Evan's first choice.

Source for the industry insider info is that I used to run the technical side of a small ESP from about 2003 to 2009, was an active participant in MAAWG and generally had to work with my peers across orgs to navigate deliverability problems regularly.

what is the male equivalent of Karen?

I run a business and I absolutely would fire a customer for being needlessly rude to an employee. If they're angry at the employee they can direct their 'feedback' to me. But yeah this 'the customer is always right' chunk of American culture needs to die- abusing employees is not 'feedback', nor is it acceptable

> If I'm billed for a dedicated email for years and it hasn't been provisioned for me, isn't that a major problem with the service?

If that's true, yes. But it sounds plausible that the salesman was in error (also a problem, but less severe IMO):

> (Mail headers show the dedicated IP is functioning correctly, see "headers.png", where the outbound route matches the dedicated IP in the web interface.)