I met Ev and Taylor a couple months ago. They're a brilliant team, in a not-so-glamorous market (there's not a lot of buzz around sending mail). These guys are committed to building a reliable/developer friendly email service though. They totally deserve this.
Congrats to Ev + team, from day 1 when they launched he's continued to answer my emails directly and openly, it's refreshing.
I really hope my beloved mailgun remains competitive and independently available and doesn't get assimilated like slicehost -- mailgun is a not-so-well kept secret that needs to stay as is.
This is probably a good time to ask about how people handle transactional email generally.
I had a play with Mailgun a while back (and others, Mailgun felt nicest to me) but there was a feature that seemed to be missing from them all.
How do you handle rules between outgoing emails?
For example, say there's an email that gets sent out on a user action, but you only want to send it out once a day. It feels to me like I should be able to set rules within Mailgun to say, only send out this email every x minutes, or, don't allow it to go out if another type of email has gone out before etc.
Is there a way of dealing with that? At the moment we have to put all those rules into our app, and it seems like something the app shouldn't have to deal with.
This strikes me as somewhat of an edge case - to add a full rules engine for what is essentially a very app-specific set of behaviours.
One main reason the application is the best place to manage these rules is that it's rarely just the email content that dictates the engagement pipeline. Whether a user has interacted with a component, or logged in, etc, are all app-side variables which may affect whether or not you wish to send a given email.
That said, one method some of our customers use at PostageApp to simplify some of the logic is to pass a UID to the API based on the unique parameter sets - e.g. recipient + template + hour - and rely on the engine to discard the duplicate API calls.
Agreed. This kind of domain logic doesn't really belong in a generalized mail API. It should be easy enough to build in to your app by recording the last email date/time
I think in the basic example I gave, that's fine, but it quickly becomes unwieldy.
Take for example the A/B testing of pricing. I'd like to offer some customers an infinite free trial while others only get a month free after which time they have to upgrade. The email flow for each of these types of customers would be quite different over the first couple of months. Different actions would trigger different emails at different times. That logic is not really something you want deep in your app (as I say, that's more marketing logic than app logic).
Looking through the other links provided in the sibling posts I'm starting to think the right way of doing this is using an event tracking system (Mixpanel type idea, but maybe storing that information internally). Then you have a rules engine outside of the app to send out the emails. It then becomes trivial to segment as in my a/b testing example, or to not send out more than one of a certain type of email a day etc.
Thanks for all the thoughts on it though - it's helped to push me in the right direction.
IronWorker (our product from Iron.io) has scheduling capabilities and can be combined easily with SendGrid/Mailgun to provide any type of rules engine.
In it's most simple form, you can use it like cron in the cloud.
Sweet, congrats guys! Been using Mailgun happily for ~2 years now, and it's great to see I won't have to change anything. Looking forward to the Rackspace integration!
Wow, that's great to hear - especially that Mailgun will continue along as-is. Their support has been phenomenal, and we've been extremely happy users.
Nooo. I absolutely love this company. The last company I loved this much was JungleDisk and we all know what happened to it once Rackspace acquired it.
This is not such a great news for customers. Sorry.
I'd love to get your feedback. We're always trying to improve the way we handle things and we know we can get better. We're on record publicly in the press about trying to do this differently and better. My email is bret.piatt@rackspace.com.
[From Dow Jones, from their interview with Pat Matthews, SVP of Corporate Development (my boss)], "Mr. Matthews said the acquisition is not an "acqui-hire" (a deal in which a start-up is acquired purely for its talent), and that Mailgun's team will continue to work in San Francisco, where Rackspace has an office.
However, they will report initially to corporate development and remain autonomous for awhile so they're not integrated too quickly into Rackspace, a mistake that Rackspace has made in the past, he said."
Mailgun is going to continue to run as Mailgun, as a startup team on the product and operations just as they did yesterday. We believe in the team and what they're doing. This is not an acquihire -- they have a great offering that they will continue to build and manage going forward.
Debatable. Past history supports negativity: the Rackspace acquisition of Slicehost marked a large, negative turning point in Slicehost's customer support and competitiveness.
CloudKick and Anso Labs seem to have fallen off the map as well. I'd be curious to hear what former Jungle Disk users felt changed with the acquisition.
I would be a bit worried if I were a direct Rackspace competitor and using Mailgun, but otherwise this seems like a good thing for users -- Rackspace brings more financial and other resources, and this sale (a safe one) precludes a bad sale which might have otherwise happened (if Mailgun sold to Zynga or something and was acquihired or pivoted to in house, or sold to oracle and only bundled with services.)
I looked at various options just last week and went with Postageapp. Main reasons were easy Rails integration and the lowest plan lets you use your own domain. (Mailgun's lowest plan is $19; the free plan you have to use a mailgun subdomain.)
I came here to express my fear of mail gun being not as much awesome anymore. I think it's a legit feeling.
That doesn't mean Rackspace is going to join the club of companies killing great startups but the last few times I saw acquisitions, things were not very sweet.
Hope mailgun will do even better under Racksapce. I wish them all the best.
I've heard just one caveat about Amazon SES. One of our russian customers wanted to make sure we didn't use it to deliver mail because apparently it's blocked by a few of the big ISPs in Russia.
Not to be rude or anything, congrats! But from the website itself it sounds like "woohoo, we can send email". Atleast the features page lists 99% standard-mail features like "can send mail, can do SPF, can do DKIM, can filter mails"..
I guess that's not why they were aquired, so what is the real value of the company?
I too did not consider sending mail from applications a big deal, until I had to do it on a huge scale. Turns out it gets quite difficult to maintain an email module that consistently avoids your outgoing app emails being spam-flagged or otherwise corrupted. It's a neat service.
I agree that it's not easy to do mail right, that's my daily business. But that's also the reason why i was wondering.
I probably just don't like the marketing speak of the website (as if it would be something unusual to do SPF or mail routing or filtering or regex, etc. etc.). On the other hand it is hard enough in this business already. You need to point out that stuff, ok..
Anyhow, i have been downvoted for a serious question. Sorry i did upset people with a question....
I think you were getting down voted because its not the kind of comment folks come to HN to read. It sounds like from this comment that you're a competitor? ("that's my daily business")
There is a lot of information on mailgun, both on HN and on the web. They've made no secret of the problem space they were going after.
So Rackspace felt like they were worth acquiring, the product and customers are supported so its not a strict acquihire exit, and while the questions about sendgrid are good here (which are proxies for "What is Rackspace's strategy as a services provider really?") there clearly was enough to Mailgun to make this worthwhile. That you don't "get it" is ok but instead of the snarky "Soo they just send email?" kind of thing why not dig into their product and ask specifically about it? If it seems un-remarkable then talking about how you implement the same features and qualifying the scale of that would be helpful too.
I didn't downvote you, but I suspect it might have more to do with the style of the question that was maybe somewhat easy to misunderstand. I don't think anyone is upset.
But I go disagree about the marketing copy. It says on the front page "Email for developers. Mailgun is a set of powerful APIs that allow you to send, receive, track and store email effortlessly." To me this conveys exactly the information I need about the service. I'm just disappointed they didn't play with the railgun analogy more, but still there is a reasonably cute mail gun gadget ;)
It's not just email deliverability. Mailgun's email API is super useful and worth learning because once you do you'll realize you can now do things with transactional emails in your app you never considered doing before. A few ways in which they are better than Sendgrid: (1) much better inbound JSON parsing of emails that can be used with any "route"; (2) On the fly route creation, modification and removal; (3) Pass through routing of individual mailboxes to your GoogleApps account for corporate email addresses. This is better than the Sendgrid approach because it allows you to put Mailgun in front of Gmail instead of the other way around. That could mean a noticable difference in speed of delivery of transactional emails reaching near real time relative to what you'd normally expect with email (<20 seconds).
If you're just sending in bulk, go with SendGrid, but if you want to do anything mildly interesting with email-as-an-interface, Mailgun cannot be beat. I'm honestly surprised it has taken other mail providers to offer these same features.
I just finished my first integration with MailGun (moving over from PostMark because MailGun has a better feature set imo) ... could not have been easier.
They have webhooks built in that can call your application when mail is delivered, bounced, opened, clicked, etc. That's huge for me. I allow my clients to send out emails to their users — now I can use that information to show my clients who has opened which emails ... I can also alert users if their email has become blocked or had a bounced email.
They give you a ton of functionality out of the box that would take a lot of time and effort to recreate on your own.
Their support for incoming messages is pretty slick, especially in that they provide a message body that strips out signatures and replies. At Posterous, we managed that mechanism ourselves, and it was really hellish – it's great to be able to offload that responsibility for Kinsights.
That feature alone made us switch from SendGrid, and the more reasonable price point for our stage just sweetened the pot.
I assume you were downvoted for saying there is no value in being able to send (and receive) email, but there is.
Deliverability is a huge important issue for most people, if I send an email and it doesn't arrive then I'm in a bad spot. I used a similar service to Mailgun (http://postmarkapp.com) and the amount I paid per month (when I was sending emails) meant if I spent more than 1 hour of my time configuring and managing a mail server every month I would be losing money.
This is an especially big issue for people that are using virtual servers or not that great server providers, ones that recycle IPs, if I'm correct in my understanding of mail deliverability, if an IP has sent spam before it's almost guaranteed to be blocked by most spam protection companies, that sort of thing isn't good.
To me the real value is that for a very fair price I no longer have to be concerned with the ins and outs of sending email. Once you start sending tens of thousands of emails you run into problems. People don't receive the emails. They get blocked. Users accidentally mark them as spam. And so on and so on.
I don't want to focus on figuring out email - I just want to send them and have them get to the users that want them.
I use MailGun for email for the same reason that I use FreshBooks for invoicing my clients — because I want to spend my time building my business rather than focusing on solving a problem that someone else has already done a great job of solving.
This is a great example. I think some of the disconnect with other commenters is thinking that sending email is trivial. It isn't. Even at small scale, deliverability starts to become a problem, there is infrastructure management (for example, this why people use heroku rather than just AWS) and receiving and tracking email requires managing all sorts of email weirdness that are not addressed by using software libraires (this is analogous to html parsing - getting all the non-standard or ambiguous cases right is hard).
