I am very happy to see Mailgun work towards sane API's for their email offering. I'm in the process of building an internal API for external IMAP accounts for http://snapier.com/ and it has been, well, rather exasperating... I can only imagine the frustration of trying to manage real infrastructure with such obtuse standards.
I'm hoping to open source our IMAP client wrapper soon, as it is a lot simpler than the standard library in Python.
In a lot of cases the Python standard libraries are just a wrapper that allows you to use a protocol without the need for socket-level programming, but not much above that in terms of abstraction.
It makes sense though. This allows several third parties to develop different interfaces that can iterate faster than something in the standard library can by providing them with a stable base.
I wrote the email handling code for a relatively small PHP project for a client which involved handling relatively large email attachments that needed to be processed. Needless to say MIME parsing was a pain, and Gmail's IMAP does strange things sometimes...
You should have a big Email your car pictures from your phone to spotted@wheelspotting.com (or some short email). Like the site, lacks content though :(.
Have to add my endorsement here. I spent far too long setting up postfix and working on some test code with lamson. In the end, I decided to try out Mailgun -- 2 hours later I had a working solution for parsing email responses. Good stuff.
Best part of working with Lamson? A dependency on a module that massively reorganized itself in a very minor version change, leading me to have to search back to see which version it worked with. Was it 2.8? 2.7? 2.6? 2.5? Aha, 2.5!
Training or filtering? A proper answer to this question requires its own blog post :)
Long story short, Mailgun does have a spam filtering system: if you enable it for your domain, we'll put all your traffic through a cloud of SpamAsassin machines. Those machines themselves need to be re-trained every once in a while and we do that ourselves without providing any APIs to control that process because, frankly, we believe we can do it better. The spam score along with "Mailgun spam verdict" is POSTed into your route handler - I will update the blog post to include this: thank you for reminding!
You're right, this is where per-mailbox spam filtering kicks in. But for that to work you need to create a programmatic mailbox (we have APIs for that) which allows us to collect your spam&ham datasets.
We do have a few customers who're using per-mailbox spam training via our "Beta API access" program, but we have not made the decision to launch it as a product yet. If this is something you may be interested in, reach me via email in my profile.
I used Mailgun for one of my projects at work and am impressed by how easy Mailgun makes it to integrate emails with web apps. They were quick replying back to e-mails when I had few questions about spam handling.
Needed to parse incoming emails for a project of mine and found Mailgun. Including the time it took to alter my DNS and write the script, it took just a few hours. I would say a good experience over-all.
I've been looking for something like this and MailGun looks awesome, but we need to be able for (sub)domain owners to require DKIM for security reasons.
I haven't used mailgun's API (yet) but I worked on a fairly involved incoming email system that used sendgrid's parse API and I'm currently deciding between the two for another reply system. Sendgrid's parse API (in it's current state) is pretty basic - they forward anything that match the MX record to your endpoint without any process. Mailgun seems to smooth out a lot of the nasty things. In particular:
1) Signature/Quoted reply removal - this is the part I'm most excited about (and cautious about since I've seen how much of a headache this can be). We wasted countless hours tweaking regexs to handle weird signatures - if they can get to even 90% I'd be happy.
2) UTF-8 transcoding - Sendgrid tries to parse out which format things are but it's still up to you to get it into UTF-8 (or whatever format you want it in). This wasn't a huge problem, but every now and then gmail would decide to use some really specific character sets that we had trouble converting (this could also be partially a PHP issue)
3) Routing on their server - this wasn't a big deal for what we were building, but it'd be nice to isolate the routing code from the processing code and have actual rules rather than just a catch all.
The other nice thing is that with sendgrid's pricing changes, you can't start to play with the parse API unless you're willing to shell out $80/month. Mailgun lets you use it on the free plan and it's only $20/month for custom domains.
I could add a few other things which were not mentioned in the blog post:
* Mailgun can forward cleaned up messages in MIME format to you as well, if you prefer to do your own parsing of some sort. By "cleaned up" I mean they're all UTF-8 and can be processed by your typical weak MIME parser (like Ruby's or even Python's)
* Mailgun can also store all incoming mail for you for debugging/archival purposes and you can query it later via POP3/IMAP
* Mailgun can also route messages to different email addresses, i.e. Mailgun routes aren't "parsing API" at all - they act as a proper mail processing engine and people are getting quite creative with their rules, parsing is just something they have to do. For example you can have multiple destinations for a route, i.e. by creating a route "sales@myapp.com -> [array of emails for your sales team]" you're essentially creating a mailing list without any coding on your end.
We had quite a few, but since the announcement of the API 2.0 we're working on a new set of samples.
If you're interested in writing webhook handlers (for events or/and incoming messages) there is nothing new to learn: use http://postbin.org for debugging and from there it's mostly about the PHP itself and its frameworks.
If you're interested in using our HTTP API, we can send you some samples and perhaps collect some feedback. Please contact me: ev@mailgun.net
I'm hoping to open source our IMAP client wrapper soon, as it is a lot simpler than the standard library in Python.