Hacker News new | past | comments | ask | show | jobs | submit login
Show HN: mailparser.io - extract data from inbound emails (mailparser.io)
73 points by krakaukiosk on July 13, 2013 | hide | past | favorite | 23 comments

Hey guys!

I built something like this to scratch an itch at Zapier (both personally and for a few of our customers). I've mulled over releasing it someday for fun. This is a real need because (frighteningly?) a majority of the business world runs on:

    * Generated emails
    * Spreadsheets
First of all, I realize this stuff can get complex. But I have one major critique: your extractor UI is way way way too complex. It should be outrageously simple. As in, here are your emails, highlight the data you want to extract. It's hard to build, I know, but I have doubts that your average user will sit through this: http://i.imgur.com/5xjy4dS.png.

The concept is great though. The landing page is wonderful. Simple, to the point, decent use cases, inside the app has a nice onboarding and great options around exporting, etc... I really dig it.

Best of luck guys!

Hi Bryan,

thanks a lot for testing it and giving some feedback! I really appreciate it.

The whole idea is based on exactly the assumption you mentioned: there are a lot of businesses who are stuck with clunky workflows of copy&pasting data. But who do I tell, you know that.

Regarding your issue with the extractor UI: Your screenshot is showing the second out of three steps. The purpose of this step is to refine the data selected in the first step. If you are sending html emails (with dom elements like h1, links, tables etc.) you can directly select the data in the first step with your mouse. So you don't need to refine the whole email body in the second step.

I saw that. I still think it needs a lot of simplification. But don't let me rain on your parade, the app is done very well so far. You are clearly good hackers working on a real problem, so it will get sussed out in time I expect.

I might very well be wrong too, it wouldn't be the first time!

We spent a LOT of time on our extractor UI at http://getdispatch.com :)

Add fields, highlight parts of your email, fields are mapped!

I just recently decided that I wanted an in-house solution to inbound email handling (the user can send emails into the server containing commands to run) as I didn't like the expense or having to rely on an external service to do it for me. In the space of about half a day I had a working test bed:

* Vanilla Postfix

* A user with a .forward file, calling curl to post the email to my receiver route on my app

* A receiver in my Go app using the inbuilt mail package

* Logic to recursively parse multipart emails to extract plain text where possible, or strip tags from HTML when there is no text/plain version

I've been amazed at the performance and the reliability of it even in staging. It automatically emails back a confirmation of the commands and the confirmation comes back lightning quick, back through the Postfix server.

Anyone considering creating their own inbound email handler shouldn't be scared to have a crack, I was amazed at how simple and rewarding it was.

Rather you than me... I set something up using mailgun which has been brilliant, both on the receiving and sending side. For small scale use cases like this it's free too. I send pictures of receipts from my phone to a special email and mailgun POSTs to a tiny Heroku webapp which parses the subject line for amount, currency and date and puts into out accounting software.

You get all sorts of goodies like nice attachment handling and automatic stripping out of quoted text which aren't exactly hard but fiddly.

There's no mention of security, or the trust involved in outsourcing email workflow handling to you.

The interest for attackers isn't as high as something like LastPass, but at a bare minimum a successful hack will come back with a big list of valid email addresses and companies they have relationships with -- which would be very valuable to someone interested in spoofing, for example.

And that's assuming that the people/person behind mailparser.io are honest.

It depends on what kind of data your clients might want to handle in email workflow, but I imagine most businesses will be wary of passing off potentially sensitive material to an outside party that they don't trust. Things like "first month free" don't address this -- the fear isn't "we'll try this service and it won't work for us, and our money will be wasted", it's "we'll try this service, and an employee or hacker will sell our data to competitors, spam/upsell our customers, sell our contact lists...".

Obviously these aren't the most likely scenarios, but it's a bit like hiring a new employee who will be working completely without oversight with your company data... You'd want to put serious time into interviews, checking references, etc..

The site as-is: as far as I can tell, there are no human beings behind the site, or any established company. There's no phone number or address. It's not even clear what country (and hence legal jurisdiction) the business is operating in.

I don't mean to come off as too negative -- there are still companies that will not have a problem with the risks (and/or for whom the risks will be minimal), but you'll cast a wider net with a more solid presence.

I have a need for something like this and had been planning to use Mailgun. Perhaps some additional information on your site explaining how you guys are different would help people decide.

thanks for pointing this out, we will surely improve our copy regarding your feedback!

To answer your question meanwhile: mailgun provides an API for developers who want to route incoming emails to their app. mailparser.io however tries to target the tech-savvy businness owner who wants to automate his email workflow, notable who wants to extract data from repetive automated emails. We see mailparser.io more in the corner of zapier and ifttt.

That's very helpful, thanks!

We (http://metascribe.com) use mandrill from mailchimp for our inbound mail which appears for now to be free - works great for our purposes. Everyone thinks of them as only outbound and inbound is not a function they highlight, so figured I'd mention it.


I think Mandrill is for sending out e-mails, which is quite different from what this post is about.

Updated patent to emphasize that this is why I'm mentioning it:

They offer an inbound feature which isn't emphasized!

So does SendGrid.com

Kudos on having a "use cases" section on your site. More services need to include this type of info.

"All you need to do is to send emails to us." - no thanks. If you've built something more sophisticated than I can implement with Perl and Exim's system filter functionality, I might be interested in giving you money to save me my time. Maybe a per-domain license?

Thanks for sharing. I have been a similar service called Cloudmailin.com to extract tracking numbers from third party drop shipping suppliers. They have a decent API, might have to check out your service next time I need to set one up.

I haven't fully automated this, but I've been using BBedit's batch regex to parse emails. Since these are emails coming from our iPhone app, they're all pretty generic in terms of payload (a few sentences). I just throw a months worth of emails into a folder, regex it, word cloud it, and then I see what people are yammering about the most.

Signed up; how do I parse the text in the Body of the email? Is there a tutorial?

Cool service! How can I secure the result dispatcher though? It seems to generate random character combinations at the end of the base URL. But someone might 'randomly' get my mailparser emails

I was just about to click your call to action but the carousel switched.


Carousels are bad. Stop using them.

Interesting :) I was about to ask what are the typical use cases for this, but then I noticed the quite prominent 'Use Cases' menu link.

this could actually be interesting for event organizers. one could forward their rsvp@event.com email address to mailparser.io and get a csv file back with all the attendee names in it.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact