Thus begins the piecemeal partitioning of Rackspace. It was pretty obvious that would be the ultimate result after being taken private by Apollo. To be sure, there was much inertia within the company to let go of services that weren't profitable/weren't the future of the company anymore even before the acquisition.
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.
For non-technical users, you must use Plesk. Want to use WHM because cpanel is more familiar? Won't support the server at all.
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.
Rackspace makes that clear from the beginning. Do you want someone who can support the most common usecases very well, Apache, Nginx, MySQL, Ubuntu, CentOS. Or do you want mediocre support that can support YOUR use case.
What you need is a consultant or a service that specializes in your particual use case.
As a former support racker I can tell you that while those might have fall outside our offical spheres of support you would have had no issues getting support for cPanel or WHM. CloudLinux support is a different story.
I agree, Mailgun is fantastic. However, their lack for 2 factor authentication is seriously worrying.
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.
2fa is on its way. Encoding is a real pain. We went ahead and put more details about quoted printable encoding and updated our docs with some examples on how to handle this properly.
honestly? because i didn't know the encoding was called quoted printable, lol. I wish I had have known that at the time as it would have saved me a lot of hassle. I'm going to go back now and use a library, as my guessing-at-the-html is probably wrong.
I feel your pain. This is something that I learned on-the-fly as well. I encourage you to read up on the MIME specs to flesh out your understanding of “common things that show up inside emails”. https://en.wikipedia.org/wiki/MIME is a good starting point, because there are umpteen relevant RFCs.
quoted-printable is used to encode email messages quite a (7)bit :) Take a look of the source of most any HTML-formatted email.
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.
I wouldn't suggest base64 encoding for messages that are mostly text (plaintext, html messages), but it's just dandy for attachments.
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
I'm a Mailgun customer and CEO of Jungle Disk (that I bought from Rackspace a year ago). As a Mailgun customer I'm really excited about this. For comparison at Jungle Disk we've already doubled the R&D investment in our first year and will continue to grow it over time. I believe the Mailgun team will be able to really accelerate what they're able to do too. Secondly, I'm happy to have more neighbors moving to our area of town!
Oh, so that explains what happened to Jungledisk! I was an early customer, loved it, then got fed up and left when the product stagnated, bugs were left unfixed, and support became terrible.
Somehow I'd missed the news of the acquisition, so it was all a bit mysterious. Maybe I should check the product out again... :)
Mailgun's a solid service. They've got the best inbound handling of all of the services out there in terms of letting you apply rules before the messages hit your servers.
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.
I haven't looked in a while. At one point over the last year or so I sat down and tried them all. For the most part they all seemed pretty much the same. Mailgun's big distinguishing factor was the ability to pattern match on different factors of the incoming emails to apply different handling rules. I believe they also had a setting that would let you download attachments separately when I looked, which gets to be big with volume inbound processing.
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.
Yes, if someone steals your private key, you're screwed. Keeping the private key private is, well, a fundamental component of how PKI works.
> 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.
That makes it harder to figure out the private key, but once the private key is known you're still open to impersonation. Longer key + rotation mitigates both.
Isn't the likelihood of brute forcing the private key the same as it would be for an SSL certificate? At 2048 bits, brute forcing the private key is effectively impossible. Which leaves the avenues of attack the same for any private key: information breach through various other means.
I'm just spit balling here so hopefully someone will correct me if I'm wrong but...
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.
why do you need CA when you control the domain. if somebody can take over your domain you or the reciever has a bigger problem. im not sure what do you get with key rotation that you would not get with using proper length keys.
If somebody gets the original key by any means, they can impersonate your domain in emails because the corresponding public key is sitting in your DNS to validate the message unless you change it. The length of the key only reduces the chance of finding it by brute force. If anybody gets a hold of the key by any other means (compromised mail server or other vulnerability) they can still impersonate you no matter how long the key was...because they'll have it.
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.
im still not convinced. if somebody breaks 2048bit we all have bigger problems. and if somebody compromises your mail server i assume you would like to know and not only let the keys rotate via cron and call it a day.
Maybe this means Mailgun lists feature will be friendly to DMARC? It was such a great solution for domains not really requiring a mail server for inbound mail, that is, until everyone started caring about p=reject (well, except for Gmail - I'm still not sure how much my mail has to not conform to standards before they refuse to deliver to even a spam folder).
Verifying that a valid mail exchanger (MX) exists for a domain when receiving mail from that domain is a fairly common thing to do.
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.
You read past the part where I described receiving mails. It sounds like you have never used the service, so have no idea what I'm talking about, so have no idea what you're talking about.
When using the lists feature, an alias address can be created user@example.com. Then, you can add email addresses to the list.
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).
We are working on SSL support now. While this has drawbacks, you can terminate on a service like Cloudflare and we can enable HTTPS link writing for your sending domain. Otherwise, hangtight for a more integrated solution.
> If you are a current customer, you remain in good hands. Nearly every Mailgun employee and all of leadership is continuing with the new organization and excited about the mission ahead of us.
...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.
I mainly read that as a statement about the team composition (I'm sure they wanted to say that "everyone" was continuing, but "nearly all" is the best they could do) rather than about who was excited about the mission.
Mandrill became part of the Mailchimp subscription. Only for paid accounts. Basically making costs for low-traffic projects way higher than they used to be if you didn't use Mailchimp with Mandrill. (Mailchimp subscriptions start at 10 $ a month)
I got burned by Mandrill as well, even though I pay Mailchimp $59 a month.
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've used mailgun for several high-volume clients and overall it works - but the feeling I got when working with their API, their docs, their UI and their support is a product in maintenance mode. There is a lack of polish, a lack of effort, and a lack of overall robustness. But, it works.
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?
I'm a big fan of Mailgun, but haven't actually sent enough mails in a month yet for them to actually charge me. I wonder what % of their users are the same?
We were having some deliveribilty issues with Office365 just putting everything in the Junk Mail no matter what we were trying. I found a write up on the issue from someone else who had the same issue and the solution (for them) was basically, pay Mailgun for a dedicated IP. It was going to be a tough pill to swallow because we send, MAYBE, 200 emails a month (they're basically for password resets and such, not mailing list blasts).
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.
>We were having some deliveribilty issues with Office365 just putting everything in the Junk Mail no matter what we were trying. I found a write up on the issue from someone else who had the same issue and the solution (for them) was basically, pay Mailgun for a dedicated IP. It was going to be a tough pill to swallow because we send, MAYBE, 200 emails a month (they're basically for password resets and such, not mailing list blasts).
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.
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
This is (and probably always will be) a work in progress for us. Our systems promote you into higher quality IP ranges as you send better e-mail. The downside is that this is a reactive process. We have some experiments that we're starting to run to help improve onboarding and IP assignment for legitimate users. In the meantime, support is always happy to review your account and expedite this process for you.
We spent a month dealing with intermittent deliverables issues and had to cycle through a number of IP addresses. Deleiverbility issues due to IP reputation or receiver rate limits are fairly easy to identify and it would be great to see some more proactive assessment of problems from mailgun.
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.
I'm in the same boat, bootstrapping my app. Mailgun's willingness to help me get off the ground for free engenders a sense of loyalty. I won't be looking to switch later. Even if they are more expensive than SES, their API and webhooks are great value adds.
Yep. Absolutely love Mailgun, provides an incredible service but I haven't hit the limit where I've been charged yet and hope this continues. I use them for firing off mail from contact forms and the visibility/trust is great.
I see a lot of comments about alternatives and such. https://postmarkapp.com/ is really nice. I've used them for years in all of my personal projects and it has always Just Worked™.
I've avoided MailGun & SendGrid entirely for various reasons.
i use sendgrid, and like the product, but the customer support is pretty terrible. i accidentially sent myself about 20k devlog emails, and they suspended my account. not just "i'm sorry you are over quota" but actually suspended, meaning I couldn't just upgrade my plan to fix things.
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.
I'm glad they learned the importance of support from RS and internalized it. I have noticed an increase in quality of support over the past couple months.
I really, really like Mailgun! and can't understand why they don't get more "press" or mentions on the forums, etc. It seems only their competitors are ever talked about.
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!
I like there system for deliverability too. They make you setup up the sending domain and verify it which really helps. Check out this tool if you are interested in deliverability: https://www.mail-tester.com/
Not a spin out expert, but a few reasons I can think of right now:
- 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
Every deal is different so this is all speculation. A common theme with a private equity buyout of company like Rackspace is to break it up into pieces that can be sold as a unit.
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.
CEO of Jungle Disk here, we spun out in Jan of 2016 from Rackspace. Reason they sold Jungle Disk is they're focusing on data center based apps sold to mid-market and enterprise buyers. Jungle Disk was a SMB data backup and online storage service for laptops, desktops, and servers (either on premise or cloud). Not a fit in the core sales and marketing machine inside Rackspace.
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.
This is great news and puts my Mailgun-related fears about the Rackspace acquisition to rest. I look forward to actually paying for Mailgun's service soon.
I don't know about AWS SES, but I know that compared to Mailgun, SendGrid is a more complex and larger product that has features for marketing campaigns, and it's not API-only - it also has a web UI. It's like a cross of Mailgun and Mailchimp.
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.
MailGun has better delivery than SES and easier to get setup than SendGrid. I use both MailGun and SendGrid but stopped using SES awhile ago due to delivery issues.
I haven't used SES in over 2 years now so things may have changed but lots of ISP's blocked the emails. Even basic transaction type emails.
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.
Not OP but I've heard (anecdotally here and there) that many sites reject email from Amazon IP blocks because of historical spam problems.
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.
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.