Mailgun (YC W11) Raises $1.1 Million For Its "Twilio For Email"
techcrunch.com
techcrunch.com
Detailed searchable mail logs: we actually tell you what happens to every single one of your messages - nobody else is that brave!
Incoming email push - and our parsing/cleanup of incoming traffic is pretty impressive - if it's time to self-promote, it's now. And our incoming email handling if flexible: we do routing/forwarding, similar to Rails/Django routes.
Storing/hosting your email traffic and giving POP3/IMAP access to it - nothing stops you from giving each user of your app their own email address. Some customers do that very, very creatively.
Piping it through some battle-tested Mixpanel-powered analytics doesn't hurt too: some companies charge an arm and a leg just for that one feature.
Mailgun is not about merely pushing mail, we're more of an "sexy programmable ESP" :) We're just a bunch of oddballs who thought that running an ESP business would be fun!
I personally have a hard time parsing how much money $0.5 is. I'm assuming you're charging 50 cents per 1K messages. My mind groks $0.50 per 1K messages, much more easily.
to some degree, customers make up their own minds about what's "better" when comparing two products/services that may be identical in functionality and pricing.
Someone may prefer the colors/logos on one site vs another, some may prefer where one is located (located in my city/state/country vs the competitor). Some may care about the technology, wanting to support one supplier vs another.
Sending email isn't hard. Amazon SES solved that.
Receiving email is just slightly more work, but still well within the comfort zone of most developers:
$ cat /etc/aliases
comment_reply: "|/path/to/email_handler"What kind of intelligent processing are they offering?
In the use case of turning a reply into a comment the hard work is not receiving and parsing the email, it's authenticating the user/adding the comment to the database.
I'm a potential customer who just doesn't see the value proposition. I'm sure they can build a business as a Sendgrid competitor, but I don't see anything as disruptive as Twilio here.
Risking to re-type our own front-page, I'll go ahead and give you some tips for how Mailgun can be useful:
Once a message is sent, what happens to it? We give you searchable SMTP logs: see if some crazy admin guy in Canada misconfigured greylisting (because he likes to do everything himself :) and your customer's mail is sitting in a repeat-later loop for 5 days.
Once a message is received, are you sure you'll figure out the encoding of it? Or what happens if your process/machine is down when the message arrives? What if it's spam? And why not record computer-to-person email conversations you're software is doing in a real POP3/IMAP mailbox? No coding required.
On intelligent processing: we transcode all your traffic to UTF-8 and figure out what parts of the message is quoted - so you won't have to. It's not easy, ever wondered why some folks resort to "reply above this line"? Also, if there's no plain text part, we'll generate it from HTML. More is coming.
Mailgun is not an email sending service. We're a full-featured programmable ESP, it's up to developers what they want to use our email servers for. The creative ones keep amazing us every day! :)
It doesn't sound very interesting for sending email. The receiving part is more interesting.
Still, it doesn't seem like it would save me enough time to warrant implementing your API, dealing with yet-another-service, and paying.
I don't mean to be too negative. One of my favorite kinds of businesses is taking something every company already does and "productizing" it.
Maybe I'll get tired of dealing with it myself and sign up. Either way, good luck!
Having just gone through the process of setting up a VPS to handle sending and receiving email, processing bounces and recording delivery receipts I'd say that, fundamentally, this isn't challenging.
Then again I've also setup my own SMPP server for sending SMS and didn't find that particularly difficult either :)
Some of the inbound processing features sound pretty good - how about offering them as a paid-per-transaction service? I wouldn't bother outsourcing the sending and receiving per se because it's cheap and easy to do that myself, and I then have control over the up (or down!) time but being able to pass a message through your service and pay, say, $1 per 1000 messages processed with no storage costs would be kinda cool.
I'm imagining getting back some kind of structured document (XML and/or JSON) allowing me to see quoted messages, interleaved replies, attachments, encoding blah blah basically all that stuff you're talking about.
One major difference I've found with SMPP vs. HTTP APIs is on the inbound side of things - ie. receiving messages on a virtual number. Some aggregators I've used don't pass the UDH (user data header) through in inbound requests so you can't stitch long inbound messages together (this is, in my opinion, the driving force behind Twitters much vaunted 140 character limit - if they'd had an SMPP connection with the UDH in-tact they wouldn't have had to restrict posts to "140 characters reserving 20 characters for the username).
Even with kannel, though, you still need to stitch long messages together manually. I posted my sample implementation for this in PHP to the Kannel lists a few years back:
http://comments.gmane.org/gmane.comp.mobile.kannel.user/1664...
I've been using the same setup for years with no problems.
I've heard people say before that to beat Gmail you can't just build an email service 10% better. Gmail works well enough that 10% isn't worth the switching costs. Same goes for this I believe.
Where's your evidence that anyone has better deliverability than SES?
1. Infrastructure. A lot goes into this, and you can Google what needs to be done, and do it yourself if you have the time.
2. Content quality. If your recipients keep flagging your mails as spam, nobody will help you - that's your responsibility not to spam people.
Myriads email sending services do #1. Mailgun, among many other things, does that too. Plus, we can give you a completely separated, dedicated setup where your reputation won't be affected by other senders (something SES can't promise you).
But in the end, you need to send something people want to read. Saying "email company X gives you automatic deliverability" is a bit like saying that "hosting company Y gives you automatic PageRank" :-) Yes, your emails will be 100% solid on protocol/format/rate level and the IP you're sending from is watched, but you'll be taken down if you're spamming.
Hope this helps. And if you need assistance regarding deliverability (on your own server, or with Mailgun) - shoot me an email at ev@mailgun.net BTW, this mailbox is hosted by Mailgun itself. see? we're eating our own dogfood here!
Ahh, so you're using a different IP / subnet for each customer, then? With the internet running out of IPv4 space, I think that companies that do this kind of thing should just have all their addresses revoked. Same goes for "SEO web hosting"
I don't see how Amazon SES can be said to have "solved" a problem when you need a dedicated 3rd party to do it. As long as you still have to pay regularly, there's still a problem in need of a solution. (And there's still space for someone else to come in and either solve it better or charge a lower fee.) We can't resign ourselves to Amazon, Google and the other big players being the sole providers of these sorts of services.
I've spent a bunch of time talking to them about email, and they really know their stuff.
After hours of configuring postfix and looking at files I never wanted to even know about I took a break on HN.
Then I saw Mailgun, boom.. problem solved. (With more bells and whistles then I even imagined)
I've now saved part of my life thanks to this product.
Even chatted with one of their dev's who is extremely helpful. This is the kind of company I would want to invest in.
Thanks.
You don't need something flashy. Something Neat, simple and attractive that gets the USP across will do. Check out the sites of some of your YC classmates, like Indinero for example.
It seems to me that the analogy "Twilio for email" works better when applied to context.io, which aims to give a uniform API to all mailbox operations.
from what I get, mailgun makes it easy to send/receive emails, so that email is a completely integrated feature of your web app, meaning users won't even have to check their email, the experience is all within the app. You can also do it the other way around with mailgun, which is interacting with the user in his email client, so he doesn't have to go in the app.
Not seen one myself yet, but $Boss who went to infosec came back impressed and is trying to arrange some for testing.
I'm working through the pivot tech changes, then will update the web site at that point.
Q: So a customer can reply back to one of your emails and it turns into a comment?
thanks
Put another way--I want to send an outbound email in relation to a specific thread/ID, and if someone replies I want to associate their reply with that ID. What's the best way to do this with your system?
And it will be posted as In-Reply-To HTTP parameter to your app. There's also "References" MIME header you can use.
I hope this helps.
No disrespect to twilio, I think they've done a great job, but they aren't huge yet. They also weren't the first infrastructure PaaS to hit the market.