5 ms·

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

j45 15y ago
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.
- old-gregg 15y ago
  Disclaimer: I work at http://mailgun.net/ 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.
  - citricsquid 15y ago
    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.
    - j45 15y ago
      Looks can be deceiving either way.
    - old-gregg 15y ago
      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!
    - alabut 15y ago
      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: http://alabut.com/projects/emailyak/home.png http://alabut.com/projects/emailyak/home.png
RobertAdams 15y ago
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

j45 15y ago

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.

old-gregg 15y ago
Disclaimer: I work at http://mailgun.net/ 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.
- citricsquid 15y ago
  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.
  - j45 15y ago
    Looks can be deceiving either way.
  - old-gregg 15y ago
    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!
  - alabut 15y ago
    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: http://alabut.com/projects/emailyak/home.png http://alabut.com/projects/emailyak/home.png

RobertAdams 15y ago

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