Comment by buro9 | Hacker News Reader

Comment by buro9 | Hacker News Reader

Wouldn't it be great if there was a standard JSON representation of an email, and that multiple providers (SendGrid, AWS SES, MailJet, ElasticEmail, etc) all then provided such an interface.

So not only could you choose (swap out very very quickly) your outbound provider, but also your inbound provider.

After the thread the other day on outbound email, I ended up choosing MailJet who have been wonderful with the questions I had when I hit their new member ceiling within the first few hours.

The things that convinced me on MailJet were real-time outbound stats and meaningful data (recipient + subject), API of status notifications (who bounced), and the fact that they do campaign emails at a cost so low that MailChimp ruled themselves out (one of my email lists has over 23,000 members).

I need inbound handling (currently using /etc/aliases and piping), but would love all the reporting and info which centralisation from an external provider could deliver.

My only concern would be resilience. Email is really good at re-delivery when your end is down or something prevents delivery, would a HTTP REST interface offer the same level of re-try and timeouts to ensure it got through eventually. Would the provider queue for me?

Everything you're asking for (and much more) is handled by Mailgun (full disclaimer - I work there):

http://blog.mailgun.net/day/2011/11/07

Moreover, our incoming mail parsing doesn't stop at simple MIME parsing, we're dig deeper into the meaning of those characters and extract user signatures, quoted parts, etc.

Moreover, we retry inbound POST, allow you to filter incoming traffic on the server and (very important) we're the only incoming mail API processor that generates proper bounces for 3rd party servers (spammers) trying to hammer you with non-existent addresses.

We use Mailgun at UserVoice.com for incoming mail.

Of particular help to us:

- All emails are converted to UTF-8

- There's always a 'plain' (text only) version of the email sent to us, even if the original email only included HTML.

- They offer a 'stripped-text' field, which lets us easily see the new part of an email thread.

- Pretty great support

As a SendGrid Support Technician, I can tell you our Parse API retries for 72 hours, same as our outbound mail management. We use POST params, not JSON: http://docs.sendgrid.com/documentation/api/parse-api-2/ Our Parse API is complimentary, and doesn't use any credits.

We also have POST pushing of live data such requests received, deliveries, bounces, clicks, and opens down to address/link/time-specific detail. This is offered as either JSON strings or POST params: http://docs.sendgrid.com/documentation/api/event-api/

- Jacob

My only problem with your model is that it requires me to be already paying you a non-trivial amount of money (for a brand new app) to get started with your Inbound API.

Hey David, what kind of stats did you have in mind on inbound?

The topic is a constantly discussed one, however at some point you cross the line from handling email to handling CRM related tasks and there are better tools/patterns to dealing with that.

I'd love to hear what you have in mind: oren@wildbit.com

We have plans for handling retries and making sure that the HTTP interface with your app is reliable.

As far as stats go, that's on our list as well.

I need this. Given credentials, go get IMAP and dump everything JSON. This would be brilliant. Anyone up for a hackathon?

Reply on news.ycombinator.com