Seems to me like this has the potential to be something I'd pay for, but confusingly the article focuses on MIME, when the real problem you seem to be solving is providing a more usable abstraction over the complexity of sending email in general.
Having wanted a service to send emails to customers recently, I hit upon a distinct lack (or apparent lack at least) of services that allowed me to do this. While this should sound ridiculous, sending email reliably is a hard thing to do these days.
Yes, this blog post was meant to be the first in a series that described the new features of the new API release. Best way to see all of the capabilities is to look through the user manual and API reference.
I should have qualified that by saying that there were a lack of services that suited our particular needs. We ended up concluding pretty quickly that for our purposes services like Mailchimp would have been prohibitively expensive. Also, we weren't particularly interested in running a campaign oriented service, which seem to be what Mailchimp and most of the services on your list are for. I don't remember seeing Sendgrid though. That might be what we were looking for, a simple API for sending mails that aren't tied to campaigns, but which provide the template niceness of services like Mailchimp.
MailChimp also provides a great API and they even have an extended API (http://apidocs.mailchimp.com/sts/1.0/) on top of Amazon SES that doesn't cost you anything extra (you just pay for SES).
Love the changes. Whether or not there's a lack of a good mime library in any given language it's always good to go from something that focuses on a standard based file not everyone is familiar with to a simple list of parameters.
It's also always great to work with companies with such nice api documentation. It's so easy to do the facebook thing and have incomplete, unclear documentation and no real way of getting answers about it.
From reading this blog post, it appears that you have successfully attached the RESTEasy framework to the Apache Commons Email framework with one POJO. Uh, congratulations?
You're right, but for a successful business, you need to provide a service that would normally take more than half a day of development time, or have a wider breadth of functionality than your competitors (Mailchimp, Bluehornet), or -- worst case scenario -- compete on price. This appears to do none of those three.
I'm a little confused about the need for this service. What languages don't have decent email support at this point? I guess I've never run into this before.
You mean the support for MIME in stdlib, right? Based on the questions our customer support gets, quite a lot: just like we explained in the blog post. And based on the number of malformed and broken MIME we get via SMTP, even those that do aren't easy to understand for many.
Based on the calls/emails I personally had to answer, things like encoding, or making sure that HTML and text parts are specified in a certain order, or the aforementioned "Bcc mystery" bite quite a lot of people.
EDIT: forgot to add something: check out the "test mode" feature, you'd be amazed at how many people call us to flush up their email queue because they ran their unit tests on the production database! :)
You're like the people who said Dropbox wouldn't succeed, because they had no need for it, because they could just setup rsync. Fact of the matter is that mailgun seems to have empirical proof that a lot of programmers have no clue what they're doing, and would be willing to pay for something that makes their lives easier. That's like lesson #0 of hacker news: people will pay for things that make their lives easier.
JavaScript and PHP immediately come to mind. Ruby has a few MIME libs of a poor quality. Perl and Python have excellent MIME facilities but, as I said above, many developers simply aren't interested in learning MIME to begin with. We eliminated MIME on the receiving end earlier (see our "email routing" API) and now we've taken the next logical step: we have eliminated MIME on the other end.
Besides, email is huge. In includes at least 4 non-trivial network protocols, several storage formats and a sea of proprietary ESP-specific extensions is error codes. There is no such thing as an "email support" in any language, only bits and pieces of uneven quality, therefore the most honest and shortest answer would be "all of them".
That's a very compelling feature. When having to read mail comes up it's usually out of the ordinary from whatever I'm doing but if I could just make a page to process what's in it then that would be interesting.
It's nice having official servers to send email from. I had a simple little app a while back that sent email via Python's SMTP module, but most of the emails I was sending were getting caught by Gmail's spam trap. Using Mailgun to send those emails worked just fine, plus their api is nice.
> most of the emails I was sending were getting caught by Gmail's spam trap
The solution I came up with was to simply use GMail. With their business suite, you'll be able to use your own domain and get access to their SMTP servers.
This won't work if you're sending thousands of emails per day, but a few hundred should be ok.
You guys should consider a Heroku add-on with a small free plan (if you aren't already). SendGrid has one (200/day free) and they would be the first place I'd go if I needed a mail API because I have used them seamlessly for small projects (~10 emails/day) already.
That's great. Get in touch if you have any problems integrating it. We've tried to make the technical requirements for becoming an add-on provider pretty light.
Hey guys -- add a link back to your main site from your blog. I literally had to type the URL in because I couldn't find it anywhere. You should be showcasing your main site via the blog, not hiding it!
For me, the biggest issue w/ these email services is that the devliverability of email varies widely from service to service. The API is almost secondary in importance to me now.
One service can email certain domains successfully while another service results in randomly bounced emails to the same domains.
You really should consider making this public. It is the why part of your Unique Value Proposition[1]. In fact, I'd urge you to make this as obvious as possible on your landing page. And good luck on your enterprise.
I think from a sending/tracking perspective most of the services listed here are somewhat comparable. All of us realize that delivering to inbox is a high priority and we do many of the same things to make sure your infrastructure is optimized to achieve that. In addition, most services have analytics that track your emails. Of course, I am biased on which is best.
From a broader perspective, Mailgun's focus is being a complete mail platform (sending, receiving and storing messages) and integrating email with your application vs. a sending/delivery service. A quick glance at the front pages of the websites reveals that.
I would encourage you to review the documentation of all of the services in order to make the decision of what is right for you.
Cool! This will be awesome for implementing feature on cross-platform devices. I can definitely see a use case for standardizing mailing across, e.g., several different mobile platforms. Just keep the POST request object across all of them and send the request however is convenient.
obligatory xkcd http://xkcd.com/927/ ... i fear email will mostly broken forever, i think xmpp has a strong argument, and i'm not entirely sure throwing out mime will be possible for some time.
Awesome!!! Love that Mailgun specializes and focuses on making email easy for me. This means that I get to focus on what I do well and let someone else worry about the details of email stuff.
Having wanted a service to send emails to customers recently, I hit upon a distinct lack (or apparent lack at least) of services that allowed me to do this. While this should sound ridiculous, sending email reliably is a hard thing to do these days.