

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

I'm doing some research about hard it is to build apps that process incoming email (think Posterous or TripIt), and exploring possible solutions.<p>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.<p>Thanks!
======
carbocation
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
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
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
Check out Lamson: <http://lamsonproject.org/>

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

~~~
ajstiles
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
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.

~~~
ajstiles
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?

