Ask HN: How could buildings apps that process incoming email be less painful?

6 points by ajstiles 15 years ago | 7 comments

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!

carbocation 15 years ago |

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.

ajstiles 15 years ago | |

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?

carbocation 15 years ago | | |

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!

tomiles 15 years ago |

Check out Lamson: http://lamsonproject.org/

It includes OneShotBlog(.com) as an example of using email processing to build a blog system.

ajstiles 15 years ago | |

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.

tomiles 15 years ago | | |

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.