Ask HN: How could buildings apps that process incoming email be less painful?
I'm doing some research about hard it is to build apps that process incoming email (think Posterous or TripIt), and exploring possible solutions.
If you've built or are interested in building an app that processes incoming email, I'd love to ask you some questions. Drop me an email at ajstiles@gmail.com and I'll get in touch.
Thanks! Not exactly what you're asking, but I'd love to see software that: _ Obtains incoming email _ Parses it into something like a JSON object _ Hands it off to a database or some software in configurable fashion _ Explains how one configures it for a variety of common situations (email hosted mostly on Google Apps; email hosted locally; email hosted on mail server in same local network) If you're interested in building something like that, I bet you'd find a lot of people who were willing to pay for it. The solution I've been envisioning would require you to pick a domain or sub-domain and allow the service to handle all incoming mail for it. You'd change your DNS settings for that domain/sub-domain to point to something we'd provide. Then, when new emails come in, they'd be captured and we could do one of a couple of things with it:
- post just the headers to a webhook
- do something in response to the webhook response
- delete the message
- post full message to another webhook
- put the message in an S3 bucket
- put a pointer to the S3 message object in an SQS queue
...etc... I've worked on other solutions that monitor specific accounts via IMAP, or have monitored Maildir queues, and they can be kind of a pain... that's why I'm looking at the service solution. What do you think? That sounds pretty reasonable for a subset of uses. In fact, it's probably possible to route all incoming mail pointed at someAddress@domain.com to silently go to someAddress@sub.domain.com So your service could, at the end of the day, be more flexible than I first imagined when I saw your reply. This sounds like something pretty amazing, frankly! For an easy example, consider craigslist temp emails. With your service, I could generate those email addresses and have them end in @sub.domain.com. Your service would see any email sent to those addresses and then forward the reply along to S3/webhook/etc. I could then grab the contents and, if appropriate, forward those along to the actual user. This is just an obvious example that is pretty painful to set up manually, but would be pretty easy for a site to implement if it hooked into your service! Check out Lamson: http://lamsonproject.org/ It includes OneShotBlog(.com) as an example of using email processing to build a blog system. I have played around with Lamson. It still requires app developers to install, customize and maintain. I'm trying to understand if there is a market for a service that makes it super-simple to process incoming email. You mean like a hosted Lamson app? There could be a market if the price is right (not to high), because Lamson makes this already simple for developers. "It still requires app developers to install, customize and maintain"
That's kind of the job of a developer, right? if he uses a "simple service" he's not developing but he's a "User" using a service and outsourcing the development to the service provider. Sorta. SendGrid lets you point an MX record at them and they will process incoming emails by posting them a webhook. Google App Engine does something similar... but neither option is particularly flexible or can handle emails with large attachments. Personally, I'd pay for a service that let me point my MX records somewhere, then be able to specify if I wanted a webhook called, or to get the emails pushed to S3, or a message queue... or some combination thereof. I'd still be developing, just not worrying about the mail server interaction itself. There are lots of "simple services" that make developers jobs easier. Why write my own file storage system when I can use Amazon or Cloud Files?