Mailgun API 2.0: forget MIME(blog.mailgun.net)
blog.mailgun.net
Mailgun API 2.0: forget MIME
http://blog.mailgun.net/post/11622797058/mailgun-api-2-0-forget-mime
50 comments
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.
Lack of services to send emails? Seriously?
Mailchimp
SilverPop
CampaignMonitor
SendGrid
YMLP
MadMimi
JangoMail
TinyLetter (free)
Mailchimp
SilverPop
CampaignMonitor
SendGrid
YMLP
MadMimi
JangoMail
TinyLetter (free)
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).
Sure, but how many offer a simple API for flinging email programmatically?
That's the only thing Sendgrid does. And, they do it quite well.
SendGrid, Postmarkapp, amazon email service....all of them do.
Add CritSend to that list. I'm using it and am quite happy with it.
I think almost all of them.
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.
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.
Feature request: multipart/related attachments please, not just multipart/alternative.
http://en.wikipedia.org/wiki/MIME#Related
Makes for much nicer display of email attachments in some clients.
http://en.wikipedia.org/wiki/MIME#Related
Makes for much nicer display of email attachments in some clients.
That's on our radar, thank you for the suggestion.
I love the idea of using an HTTP POST to send email. I guess I'm the guy who has no idea how to use MIME, but find HTTP painless.
Plus, whenever I try and configure mail on a new system, especially an EC2 instance (or whatever) there are always lots of issues.
Plus, whenever I try and configure mail on a new system, especially an EC2 instance (or whatever) there are always lots of issues.
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?
There are no rules stating that a business has to run on complicated software that does a thousand things.
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.
Half a day of development costs at least a few hundred dollars in the US, so I don't see why a business can't make money by saving you that time.
And some argue that there are other ways to compete than on features and price:
http://gettingreal.37signals.com/ch02_Build_Less.php
And some argue that there are other ways to compete than on features and price:
http://gettingreal.37signals.com/ch02_Build_Less.php
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! :)
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! :)
It's pretty trivial to bind MIME C-libraries like GMime for use in any language on any platform.
http://spruce.sourceforge.net/gmime/
It's a high-level library (unlike most other MIME libraries) which makes constructing and parsing MIME trivial.
http://spruce.sourceforge.net/gmime/
It's a high-level library (unlike most other MIME libraries) which makes constructing and parsing MIME trivial.
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.
I'd love to see the actual question answered.
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".
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".
Mailgun also allows to receive emails, it will make http post request at your end-point. very neat stuff actually.
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.
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.
This should be out soon (w/in a few days, hopefully).
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.
So basically, if I get this right, Mailgun is an abstraction for SMTP? Sounds quite useful, actually. I'm tired of setting up SMTP servers...
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!
Didn't see this before I complained/wrote a PSA: http://news.ycombinator.com/item?id=3127588
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.
One service can email certain domains successfully while another service results in randomly bounced emails to the same domains.
Hey, I actually work for one of the competitors of the above, and I'm wondering if you had a bit more info about this?
feel free to email me, if you'd rather take this offline :) [email protected]
feel free to email me, if you'd rather take this offline :) [email protected]
For someone that is currently using SendGrid, what are the key points to make me move over?
Probably best to have this conversation elsewhere. Feel free to email [email protected].
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.
[1] http://www.furld.com/2011/lean-canvas-unique-proposition-sol...
[1] http://www.furld.com/2011/lean-canvas-unique-proposition-sol...
I'm also a sendgrid customer and would definitely want to see arguments for mailgun compared to sendgrid...
But I'm not bought yet into mailgun to actually spend time contacting your sales...
But I'm not bought yet into mailgun to actually spend time contacting your sales...
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.
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.
Great idea.
Great idea.
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.
Is this hosted only or can we run our own servers? Seems to raise legal and privacy issues
One thing I hope you can fix -- I can't read the orange on dark grey example boxes.
Mailgun, SMTP gone postal
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.
I want this for snailmail.
made me think of: http://news.ycombinator.com/item?id=3031118
[deleted]
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.