

Ask HN: Anybody want a hosted email API? - mflindell

Its really hard to set up an email host﻿, I have tried doing it myself and it was really too crazy to set up. I had a problem where I was serving email across about 40 domains and I needed something that would work for everyones different DNS settings.<p>So we outsourced, got it done but its still very clunky, its hard to administrate and monitor and I couldn't build on top of it.<p>I was thinking of maybe building an API service where people can build their own email hosts really easily without buying hardware, getting a system admin etc.<p>If you dont know, IMAP and POP are so hard to work with programmatically but if you had an API where you just ask for /users/134234/mailbox and got all your data, you pretty much just cut out 2 months of programming.<p>Plus: People could build apps on top, like shopify
Plus: We wont have to rely on google anymore!
Plus: Google doesn't seem to let you do this or anything similar, I might be mistaken though.<p>Just to clarify, this is not a transactional email service, its a fully hosted imap server.<p>Thanks!
======
dangrossman
It's not clear where you're trying to innovate here. IMAP mailboxes on my
domains are hosted by Rackspace Mail [1] at $1/mailbox/month. I don't use any
other Rackspace services, just point my MX records there so I don't have to
manage mail servers and spam filtering myself.

Where I need an API for both inbound and outbound mail, there's SendGrid and
SendGrid Parse [2], among others.

1: <http://www.rackspace.com/apps/email_hosting/rackspace_email/>

2: <http://sendgrid.com/docs/API_Reference/Webhooks/parse.html>

~~~
mflindell
At the core I will be building an API that hooks straight into an IMAP server.
So instead of making an IMAP call from your application you make a much faster
API call.

I always thought that Sendgrid was a transactional email service, not so much
a business oriented and more full featured email server.

This would make building new applications that use email as a feature much
faster to build because you only have one endpoint to hit.

------
stevekemp
The problem is that mail-clients speak IMAP - if you present your own new API
you'll need to wrap it in an IMAP-presentation layer before anything can use
it.

Sure the simple case of reading/polling/creating mails is not difficult, so
your API idea seems attractive initially. But when you say setting up IMAP is
hard I suspect you're getting in over your head - IMAP is not hard, even at
scale, certainly not compared to writing a damn IMAP-server (I've done it.)

(PS. Besides your API will need more granularity than "GET /user/foo/mailbox"
because my mailbox is _very very large_.)

------
saurik
<http://context.io/>

------
jonathanyc
Why not just use Google Apps/FastMail/any other IMAP provider?

~~~
mflindell
Other providers don't allow you to extend the platform and if you tried doing
it through imap, its sometimes slow and becomes unmanageable to interpret the
mail it gives you.

I am building this for my own webmail project and it really helps to have a
fast api so I don't have to worry about the data.

Having an api call to build a new mailbox would be quite handy for small web
hosting companies too.

