I want to code, not configure mail servers

I really don't understand how people are afraid of email. It's no rocket science and smtp is a well documented and used standard.<p>Why would I lock myself into some API of a third party service (code I will have to change if I change services) instead of using practically any distributions default configuration of any SMTP server and then just talk SMTP.<p>If you own a static ip address not previously used for spam and if you have a valid PTR record, your mail will get delivered.<p>If you are in an ip block with a bad reputation (amazon ec2), you might need to sign up with an external provider but there are many more (and cheaper) smtp providers than there are json2mail services.<p>Of course if you need to track statistics, browsers, responses and bounces, it's a whole different problem which is solved by value-added services like Campaign Monitor or MadMimi and whatnot. But just sending mail?<p>Maybe I'm getting old. Back in my days, talking SMTP and setting up a mail server was nothing special at all.<p>(edit: just to reiterate: Even if you don't want to deal with the administrative issues, there is still the problem of the lock-in. Why not find a provider who does the work for you but speaks SMTP? That way, you can replace them if you need a different service level or if they go away. Using a proprietary API means that you can't easily change providers any more)

While I like SendGrid, there are a few things I'd like to note:<p>* It's extremely expensive compared to handling your own email. If you count dollars, what they deliver isn't really worth the cost (expontentially so if you already have your own dedicated sysadmin, which you will want to have anyway). Our app currently sends out around 800,000 notification emails per month, or about $600/mo.<p>* It's been a rocky road. It's been quite buggy for us. I think I had two support tickets within an hour of starting to use it, then another 3-4 tickets open within a week. Things like their email activity and graphs page not working (badly optimized and overloaded, basically); JSON mangling in their API output; and thousands of emails being stuck in their mail server for several hours before being delivered. Everything has been resolved, however, so right now it's fine.<p>* There are some stupid weaknesses. For example, it's not possible to turn off their built-in spam and bounce handling. If a recipient accidentally marks an email as spam (it happens more than you think), SendGrid will simply stop sending email to that user. Similarly, if a recipient's mailbox goes full or has a temporary failure, SendGrid will often hard bounce, and stop sending emails. You can set the expiry times for bounces, but you can't turn them off.<p>Pretty much the only feature that is worth paying for is their stats; they have nice APIs to get stats about deliveries, reads and clicks. So while we are ditching SendGrid for our notification emails, we will continue to use them for newsletters.

We have to use SendGrid at work and more often than not email gets delayed way beyond acceptable (about 1 hour, for example). It does have great features but if I could choose, I'd chose not to use it... at least not for everything.

It'd be rude not to post a wedgie in this thread -<p>How do you send email from your webapp?<p>Choose One: mail server on my web server <a href="http://wedg.me/qdGcZg" rel="nofollow">http://wedg.me/qdGcZg</a> or Sendgrid <a href="http://wedg.me/rg65fD" rel="nofollow">http://wedg.me/rg65fD</a>