Using Email Yak To Provide Bidirectional Email In Your WebApp
bennadel.com
bennadel.com
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.
and a series of blog posts I wrote on setting up a simple lamson server:
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.
Check back soon and I'm sure you'll be pleasantly surprised!
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
All plans have unlimited emil addresses included.
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.
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.
Kind of bizarre yet fascinating. I wonder if anyone still uses classic ASP on anything? :)