
Mailgun (YC W11) Raises $1.1 Million For Its "Twilio For Email" - old-gregg
http://techcrunch.com/2011/05/13/mailgun-raises-1-1-million-for-its-twilio-for-email/
======
lacker
I met the Mailgun guys and they seemed really sharp so it's good to see them
getting money. I wish this had been around a year ago - there are so many odd
corner cases to managing a transactional email system, it's a pain to deal
with. Companies like Sendgrid are only handling one small part of the problem.
Good luck and congrats on the funding!

------
jsdalton
Would somebody care to sell me on why this is superior to SendGrid or Amazon
Simple Email Service? (Or perhaps what use cases it better serves.)

~~~
old-gregg
Actually we do "everything email":

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!

~~~
lftl
This a completely off-topic and pendantic, but I just thought I'd throw this
out there. On this page:

<http://mailgun.net/pricing>

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.

~~~
old-gregg
Great feedback, we'll fix this - thank you!

~~~
z92
Also write it as "per thousand" messages. For the first 10 minutes I was
reading it as 50 cents per kilo byte ( 1KB ? ) of message which sounded
expensive.

------
staunch
Twilio is awesome because setting up Asterisk and acquiring phone numbers is a
big pain in the butt and requires knowledge most web developers don't have.

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"

~~~
paul
Sending and receiving email is easy, unless you want it to work reliably, do
intelligent processing, etc.

~~~
staunch
SES is extremely easy, and I seriously doubt any claims that they're more
reliable/faster than what Amazon is offering.

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.

~~~
old-gregg
Staunch: there will always be guys who want to do everything themselves. But
we're selling to folks who have other things to worry about.

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! :)

~~~
dools
Automatic detection of which bits are quoted sounds good.

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.

~~~
tworats
Would love to learn more about the SMPP server and your setup, is there a
writeup or pointers to more info anywhere?

~~~
dools
Hey, sorry I just checked this thread. I just use Kannel! You can use Kannel
with a GSM modem as a "fake SMSC" or you can get an SMPP connection to one of
the many SMS aggregators worldwide that allow it. SMPP is generally faster
than HTTP in terms of throughput, but in terms of functionality (for example,
setting the sender id) most aggregators have comparable offerings in both SMPP
and HTTP APIs.

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...](http://comments.gmane.org/gmane.comp.mobile.kannel.user/16642)

I've been using the same setup for years with no problems.

------
simonw
We've been using Mailgun for all of our email on <http://lanyrd.com/> \-
sending messages via their REST API (and using them to receive bounces and
email unsubscribe requests). It was easy to integrate and we haven't had any
deliverability problems - they gave us plenty of great advice about that.

I've spent a bunch of time talking to them about email, and they really know
their stuff.

~~~
muitocomplicado
Your recommendation in a previous blog post made me sign up for their service
and I have been a happy customer for a few months.

------
elb0w
This is literally the greatest service I have come across. Honestly, it was
like a godsend, all day I was studying on all these little details required to
having a solid, protected, non-blacklisted, works on ec2, stable, spam-free,
e-mail server.

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.

~~~
elb0w
Honestly just to add, I like this product so much that i've considered porting
their helper libs to every language they don't already cover.

------
rw
(I worked with Ev for a year, before he did YC.) The whole Mailgun operation
is top notch. If you want to do cool things with email, _definitely_ check out
MG.

------
mp3jeep01
For a over a month now we've been using the service, and it's been smooth
sailing without a hitch - really impressed and interested to see what these
guys do next

------
taphangum
Wow, this will save me hours in development time. Guess procrastinating on HN
is useful after all ;). Great service guys, congrats!

------
rumpelstiltskin
To the ppl at Mailgun following this thread: I want to see you guys succeed.
Please spend a portion of your funding on getting a better website design. The
content of the site was enough to get me to sign up, but you'd be surprised
just how much the look and feel of a site matter to some customers.

~~~
old-gregg
Will do! Do you mind if I contact you in private regarding specific design
issues you'd want to point out? My email is in my profile.

Thanks.

~~~
rumpelstiltskin
Sorry for the late reply. I'm not a designer myself, just know when a final
design is bad or good.

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.

------
jessedhillon
Can anyone comment how this compares to context.io? (which also appeared on
HN)

<http://context.io>

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.

~~~
mtw
context.io turns mailboxes into databases you can tap into. They are
especially good with attachments. is there an API call to send or receive
email with context.io? I am not sure.

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.

~~~
sjsjsj
Hey guys, it's Sarah-Jane, Community Manager at Context.IO. Yup, you got it.
We don't host dedicated mailboxes that your application can receive and send
emails from, but since we make the contents of any IMAP account available to
your app, whatever is received in that account is like your app receiving it.
For the sending part, we're leaving that to Mailgun and other services that
focus on this.

~~~
mtw
hey Sarah-Jane, the reply above was from me heri from @mtw

------
mtw
why mailgun.net? you're losing people who are typing mailgun.com

------
kyenneti
Congratulations on the funding. Feedback - Logo is not click able on the
documentation page. Can I use your service to send emails on behalf of my
clients. We have an bulk email campaigns app, that our clients use to send
their mail. I am looking for a SMTP service where we can send email on their
behalf.

------
kljensen
Killer service, but two things jump out. 1) Need dkim signing by own domain
and 2) envelope sender should match from address. These don't matter if you're
sending to consumer domains (gmail, yahoo), but, as I've learned, they do
matter for corporate environments, which are fragmented and antiqued.

------
justinksd
We use and love Postmarkapp (<http://www.postmarkapp.com>). They have an
awesome interface, and SMTP relaying is reliable, and nice reports. MailGun
seems to go further than Postmarkapp though, in that they doing inbound
automatons.

~~~
alexknowshtml
Hey Justin, thanks for the love. We've been battle-testing our inbound
processing before releasing it to the wild. If you'd like to take it for a
spin, drop me an email - alex@wildbit.com - and we can get you set up in the
private beta. You can be sure that it'll be just as reliable and easy to use
(and easy to look at) as the rest of the Postmark you're used to :)

------
smokeyj
An encrypted mailbox service would be nice, considering our privacy is pimped
out by the big guys.

~~~
handrake
I can see that on the top of their list already. Somebody has to fix this
problem with less-complicated solution than PGP.

~~~
SoftwareMaven
I'm working on it. :) We hope to have a private alpha start the end of next
month.

~~~
X-Istence
I am definitely interested in this, do you have any website up yet? Any
possible way to get onto that private alpha? ;-)

~~~
SoftwareMaven
Website is <http://ClickLock.com/>. We've pivoted slightly, so some of the
details are out of date, but there is a sign-up form at
<http://clicklock.com/install/> for people wanting an early look.

I'm working through the pivot tech changes, then will update the web site at
that point.

------
maneesh1
Congrats guys. I beleive this is going to be huge, especially for enterprises.

------
rishi
"Let your users leave comments, answer simple questions, upload data as
attachments and interact with each other using their email clients."

Q: So a customer can reply back to one of your emails and it turns into a
comment?

thanks

~~~
old-gregg
With a little bit of coding on your part - yes.

~~~
matthew-wegner
I'm curious about this. I found the tagging functionality for outbound mail.
If I tag an outbound message, and someone replies to it, can I easily read
back the tag from the reply message?

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?

~~~
old-gregg
For your use case I would add your own Message-ID MIME header to the outgoing
message. When a user replies, usually (in most cases) you'll see the ID of the
original message as In-Reply-To header.

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.

------
cagenut
hosted/saas james?

<http://wiki.apache.org/james/>

~~~
old-gregg
Far more complicated than that. You won't scale james to millions+ of
mailboxes as we're planning to :)

~~~
cagenut
Cool, best of luck. I've used two competitors services and spent far too many
days pulling my hair out over unexplained slowdowns and api errors. It would
be extra cool if you guys did an architecture blog post.

------
brianbreslin
ok why does everything these days have to be described as "Twilio for XYZ"

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.

------
seanp2k
lol....because E-Mail pipes are e-mail processing is "hard". I don't see a
real need for this. Twilio is useful because interfacing phones is hard.
E-Mail is just plain-text and is pretty simple to parse server-side.

