Mailgun Becomes an Independent Company
blog.mailgun.com
blog.mailgun.com
All the while, you have a leadership that continues to say "Everything is OK! This is good news overall for the company! Let's continue to work hard in solidarity with each other! We're one big happy family!" Its important for people (in general) to see past that kind of management bullshit, look at the numbers (profitability, customers etc.) and make a very informed decision about their future, lest they get caught unaware by "restructuring".
Disclosure: Obviously, a former Racker. Loved the peers I worked with and the company culture. Management was (is?) a total shit-show. I was lucky enough to see the future and take a better job before the company went private.
I wholeheartedly agree!
Kinda a kick in the teeth when you pay through the nose for an archaic machine because "we sell support".
Want to use CloudLinux because it makes multiple PHP versions easier for the less technical? Won't support your server at all.
So it's only fanatical support for a subset of what most vendors usually support.
Don't get me wrong, support is better than what you get with say eUKhost but a lot of stuff is faster to just do myself than pick up the phone and listen to some bad techno until I get through to Linux support.
Fanatical Support my arse.
What you need is a consultant or a service that specializes in your particual use case.
Same case with CloudLinux but understand there. To be honest, it's a bit much for what I needed and confusing as hell to work with myself.
The support used to be awesome but I just feel in the last year or so it hasn't been that great.
Since when is server management non-technical :-) ? Anyway, I recommend cloudron.io these days especially if you use the server to host web apps.
The only other issue that I do have with them is that the "history" for messages has a really stupid encoding. Basically, when a message does fail, or get marked as spam, we have a web hook set up. This works great. However, when looking at the message source, it has a dumb encoding on carriage returns, and colons. It's not the biggest issue, but still annoying.
We ended up making a little appliance to resend failed emails for our sales guys. Basically, this had to have the code "Replace("=\r\n", "").Replace("=0D=0A", "").Replace("=3D3D", "").Replace("=3D", "=");" instead of just being a straight copy paste. Ideally we could have a "resend" button. In the console.
quopri.decodestring(message_source)Edit: a quick cursory google shows http://www.dpit.co.uk/decoding-quoted-printable-email-in-c/ as a good enough solution for C#. I feel kind of stupid now, but had honestly never heard of QP encoding before.
In my experience, it's the only way to keep content of an unknown character set and highly diverse content from getting corrupted when going through processing stages (for email). A lot of the tools to manipulate an email message can (also) be destructive.
Email is weird.
I can see why they'd use it for this service, if the original email was also a part of the notification they're sending.
also first time i was sending sms messages and not using ascii trying to determinate the message length was fun. and by fun i mean gsm 7bit annoying.
Debugging something in an email message encoding in quoted-printable simply by viewing its source is doable sometimes. If it's in base64, not so much. I believe the size of your message would also be less using quoted-printable, rather than base64
https://documentation.mailgun.com/api-sending.html#retrievin...
Somehow I'd missed the news of the acquisition, so it was all a bit mysterious. Maybe I should check the product out again... :)
I haven't looked at their outbound service in a while because I've been so impressed with Sendgrid's dual DKIM CNAME setup so that they can handle automatically rotating your DKIM keys without bothering you...that it's really hard to even think about trying somebody else.
Once that key is known, it can be impersonated. Regular rotation is a practical mitigation strategy and I like that Sendgrid took it on ahead of the game.
Since they are sending, they can create a new key on the second domain, tell new emails to use it without impacting anything in transit by leaving the old one active until it is changed for rotation.
With SSL the key exchange happens because you are trying to connect to a specific IP address with an encrypted connection. The cert is issued for the domain you say you're trying to access, vouched for down the certificate chain by certificate authorities that your client can check and warn you about. You get to the IP by connecting to a DNS server to get the address. So even if somebody had the key, they've got to get you to visit their IP with it and the second it's discovered that they key has been stolen the CA can revoke it.
With DKIM you have a key without that entire chain of authentication and all it does it give a receiving email server a place to look to see if the message has been changed in transit, with the key. Anybody with that key can send messages claiming to be from your domain and instead of you having to seek them out, they get to send directly to you so the risk is much higher and the only equivalent of having a CA to void the key is key rotation.
That's why DKIM and SPF (with DMARC) work well together because SPF will at least let you specify authorized origin servers...with the downside being that it breaks forwarders when strictly enforced so a lot of people don't like it and opt to rely on DKIM only.
If the length of the key effects the time it would take to crack it, rotating the keys gives them a usage window so you'd have to be able to crack / obtain it within that window of time for it to be useful.
For many sites this probably doesn't seem like a big deal. For sites that deal with heavy phishing attempts though, these precautions are really important.
> Once that key is known ...
You say that like it happens every day. Use long enough keys and you don't have to worry about it.
The general consensus is that (some) 1024-bit keys can be brute-forced -- though the number of attackers capable of this is extremely limited. If your threat model includes the NSA (or anyone, for that matter) cracking your key, the solution is to increase the length of your key.
I agree that rotating your keys is a good idea but it's not like it's something you have to do every day.
Postmark has a nice DMARC processing system.
Unfortunately, the emails are sent from the original address, so if that is user@yahoo.com, and since yahoo.com has p=reject in it's DMARC record, that email will suffer all of the issues of failing a DMARC test, so depending on the receiving mail server's configuration, the email may not even reach the spam folder (all Yahoo! and Microsoft domains behave this way, as well as many others).
That is, if an e-mail coming into my server purports to be from example.com, checking for the existence of a valid MX for example.com is a common "anti-spam" measure. If example.com can not or will not accept mail, rejecting (or marking as spam) the incoming message is considered acceptable.
If example.com sends out mail but can't or won't receive incoming mail, then some mail servers may reject those outbound messages.
Hope they add support for tracking against SSL/HSTS sites.
...except Bob over there, but he's kind of a grumpy old man anyways, so you can just ignore him.
Pro tip: Just write "The team is very excited" or something like that, its saves that tiny bit of awkwardness.
After all the hate mail they recieved they opened up a free Mandrill plan if you are a paying Mailchimp customer. Who knows how long that will last though.
Basically I just recommend Mailgun or AWS SES now.
I hope the spin off lets them focus on improving the service and the surrounding experience - I definitely would rather they succeed than go belly up. As it stands if someone pops up with similar offerings, I'd definitely check them out. But mailgun isn't impossibly far off from creating an exceptional product. The question is: with this change, will they?
Their support basically refused to take my money and switched us to a different sending server that day and our emails were no longer hitting the junk folder within possibly less than two hours of first contact with their support.
As a developer it's incredibly easy to integrate with, the dashboards are very helpful for debugging, and the one time in at least a few years I've reached out to their support they were informative and expedient.
I've found their competitors to be harder to integrate with and focused more on mass mailing for marketing, wanting to funnel everything through their UI.
I hope Mailgun can keep up all the good work they're doing, it's a breath of fresh air to know sending emails from our web applications will take all of five minutes to integrate.
I literally went through the same problem, and they did the same thing for me, they didn't accept money for a dedicated IP
It seems that spammers are using their free tier to send spam emails, and because of that, some of their non-dedicated IP range are listed as spam by Office365/google
We did eventually get on a solid IP and after I spent several days calling every little local ISP that was flagging our emails based on razor2 our last deleiverbility issues went away.
One thing I'd love to see is a direct integration of mail events with Slack. Currently we pass the events through ourselves via a webhook.
This gave me a mini-heartattack...I guess I don't think about VCs and investments as much as the average reader of these things.
I've avoided MailGun & SendGrid entirely for various reasons.
worse still, i sent them a request to un-suspend my account at 5:20pm on a weekday, had their indian support ho-hum about it over the next 13 hours until I finally submitted a new ticket around 7am in the morning and their USA support picked it up, fixing my issue in about 30 min. (total downtime near 14 hours).
i will keep using them because I doubt the disaster scenarios for other providers is going to be much better, but I'm also going to setup a second mail provider as a failover for the next time I have issues with them.
Yet with Mailgun everything always works, the API is super simple and so is integration. And their free tier lets you handle 10,000 msg per month!!
Maybe they can use some marketing, because the product is great!
Good luck to Mailgun! DFTBA
- preparation for a sale
- raising capital for the spin out, but not the parent company
- the spin out is not part of the parent's core focus, and is something of a distraction
- the parent is transitioning to more of a holding company, and looking to make further acquisitions that have nothing to do with the spinout
- the spin out is an idea developed by a parent company team, and that team wants to leave the company to develop the idea, so they work out a deal where the company and the team both get a stake
Mailgun meets that criteria, it has all of the components of being a full 'company' or can get the ones it was missing, and it has a customer base, product, and revenue (and its profitable according to the post).
So someone bought Mailgun and that owner is treating it like a separate company. Sometimes its the original founders that buy it back, sometimes it is another firm that thinks they can do a bit of work and then sell it or take it public.
Other things that are typically sold off are real estate holdings, patents and other IP, trademarks, and sometime infrastructure contracts. So if for example Rackspace had a long term contract to host company X, they might sell that contract to another Colocation company like Equinex or Coresite.
The idea is that you can sell off all the bits for more money than you paid originally and make a profit. It is not unlike buying a wrecked car and selling it off for parts.
My 2 cents on why for Mailgun? It is a developer focused service and while Mailgun may have customer overlap with Rackspace's overall base it is a different decision maker / buyer inside the company than the person who's choosing where to host the IT system or website, etc. So while you may have customer overlap you don't have sales and marketing buyer overlap.
Mailgun has one of the best inbound/outbound API combinations available, great for companies with a strong developer team.
- From a happy customer.
Mailgun OTOH is a cheaper and more streamlined product. It's for sending and receiving email, possibly in quantity, by developers and developers only. No mailing lists, no campaign metrics, no templates or template editors, just sending and receiving email from code.
I only encountered it personally a handful of times when using SES for delivery, and it was usually resolvable because the target customer base was easy to reach and worked with their IT departments to solve the problem.
Also, if you send over 10k too soon, you may be throttled or shut down. Lastly, they also throttle you if your bounce rate is higher than 2%. To get around that, you must make sure your list is super clean or send emails slowly to make sure your bounce rate is not over 2% in any given month. Not ideal for newsletters or large customer lists imo.
Again, some of this may have changed since I used them 2+ years ago.