Hacker News new | past | comments | ask | show | jobs | submit login
Using Email Yak To Provide Bidirectional Email In Your WebApp (bennadel.com)
42 points by kirubakaran on Dec 7, 2011 | hide | past | favorite | 25 comments

"Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can." -jwz

If you don't want your app replaced, enable it to read email. Parsing email is generally a clusterfuck. But I found out that it is really easy with EmailYak.

Glad to see more companies jumping into the receiving email market. In my experience, it's been incredibly difficult to set up a website that can actually respond properly to emails, though Lamson has helped a lot.

Partly as self-promotion, and partly because it might be useful to someone, here is a link to what lamson is:


and a series of blog posts I wrote on setting up a simple lamson server:


How does this compare to SendGrid, Mailgun, and Amazon SNS? Any notable features that make it an improvement or would convince me to switch?

Robert from Email Yak here.

Keep things simple for the devs: That's why we chose to put the API key in the URL, for easy authentication, and stick with just GET and POST request with absolutely no headers required on requests.

It may not be the most RESTful API in existence, but I get alot of emails saying that is sure is an easy API to work with.

MIME's? Seriously? Give me a break. I just want to send and receive email, I don't care how it is made! Email Yak doesn't ask for MIME's and doesn't provide them, just send and receive in plain text or html. Easy.

Even the control panel is minimalistic. Few screens. Just keeping it simple.

Focus on receiving email: Receiving email is one of those programmer white whales, it looks alot easier than it actually is. We chose this task to focus on to make it as easy as possible for devs.

ParsedData: We split each reply in the email thread. That makes it easy to work with the most-recent reply or any individual one.

Sandbox Playground: You can do everything from the UI that you can from the API. So you can see the exact request you need to send to the API and the responses you will get back.

No POP / IMAP: Again, we want to do one thing well and keep things simple, so no need to muddy the waters with these protocols.

If you guys have any questions, shoot me an email at robert@emailyak.com

One thing I think that differs between these is most only do 1/2 of email -- sending. Mailgun and a few others do two way emails.

Disclaimer: I work at http://mailgun.net/

Sending is actually 1/3 of email. The other two are receiving and storing. :)

Even sending by itself is such a complicated beast that only a select few allow customers to do it properly, and to properly do sending you must have receiving end set up as well. Your deliverability goes up when you allow replies to the sending host. ESPs see replies as participation and it makes a difference. That's why we keep preaching: No more no-reply emails.

Another elephant in the room is spam. If you silently accept everything coming to your MX host, you're asking for it. That's how some email platforms do the receiving end. GMail can get away with this because they employ a small army of PhD's to deal with spam. To have manageable volumes of spam, you've got to be able to generate SMTP bounces for invalid addresses. The list of things to do in order to receive properly goes on and on. Hooking up incoming SMTP traffic to a Python function is the easiest part of receiving mails.

Long story short: if email is critical to your app, you have very limited options. Roll your own or sign up for Mailgun, which is basically a Gmail-like back-end which makes your application look and feel like a real email server to other ESPs, not a mass sender of $0.0001 emails. Mailgun also has other advantages like automatic cleanup of garbage MIME bodies - this always hits you hard in production, and standard MIME parsers for most languages won't cut it.

I really wish Mailgun.net was a nicer website. It's terrible of me, but I just can't take Mailgun seriously with such an.... amateur website, I just can't accept that it's a legitimate company. Postmark on the other hand (and mailchimp etc.) have really nice websites, it makes me want to use them.

Agreed 100%. We've been slacking on the web design fronts. Check out the design of our APIs instead! :) We invested all our attention to the queue, to maintaining high traffic quality and the parsing engines.

Check back soon and I'm sure you'll be pleasantly surprised!

Al from EmailYak here - I'm happy that people are finding the service useful as it looks now, but we're also going to overhaul our design and explain the service better. Here's a sneak preview:


Looks can be deceiving either way.

I have only just looked at this service, but it may be exactly what I'm looking for. I see a lot of advice against operating your own mail server, and while SES might work for outgoing you're still screwed for incoming. Thank you for this, I'll check it out more!

Can we use this as a comments system? For example, a blog would have an email address and leaving a comment would basically send an email to the address, and then it would be displayed as a comment beneath the blog entry. The benefit would be that we can use email spam filtering on the comments. The email could be sent either from the user's email address or you could send it from the application's email address to itself.

Sure. You could use plus+addressing to identify the individual post or you could register an address that was specific for that post. Email Yak lets you call Register Address (http://docs.emailyak.com/register-address.html) to create as many email addresses as you want.

All plans have unlimited emil addresses included.

I've thought about implementing something like this; but, I keep coming up against two different arguments:

1. I think there's value to having people come to your site. Not just for traffic, but to keep them involved and aware of changes to the site.

2. Content being posted in the email can be far more complex than the content being posted in a simple Textarea. There's a nice dependency on the clean input of a textarea and a form submission. With rich email clients, you just need to take more care.

... of course, maybe that's just me being intimidated about thinking about the whole workflow in a different way than I'm used to.

What about Still providing a simple text box, but the action upon submit is sending an email. It needn't be from the commenter's email address, it could be from a separate email address "comments" or perhaps a separate adress for the individual post.

I considered building a commenting system like this myself, but I decided that users would find that more annoying than just filling in a textarea beneath the article.

I agree but there is no reason the text box couldn't achieve the same result -- sending an email. External client would nit be necessary. I have wondered why comments and google plus don't already work this way.

I didn't know people still used ColdFusion in 2011.

I thought the same thing, too. I had to look at the date to make sure this wasn't a really old article. I haven't seen anyone using Coldfusion "in public" in years and years.

Kind of bizarre yet fascinating. I wonder if anyone still uses classic ASP on anything? :)

raises hand

Can't say I love it but it pays the bills; you'd be surprised at the number of companies that still use it to a degree. Thankfully, CF these days is much improved compared to when I first heard about it many, many moons ago.

Same here.

Railo is a powerful, open source and (mostly, Adobe) CF compatible engine. Its very fast and feature-rich. If you need to work with CF then definitely have a peek at Railo.


ColdFusion is how I rock out with my code out. It's extremely powerful and has an awesome community of developers.

It might be interesting to compare with mailgun too, one that I recently heard about.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact