Beating Spam Filters (part two)

There are several different approaches to handling email deliver itself. Essentially these options fall into two broad approaches: sending mail from your own server or someone else’s server. Not wanting to have to setup my own mail server, I first looked to see what options I had if I wanted someone else to deliver my mail for me.

Webhost SMTP

The quickest way for me to get up and running was to use someone else’s SMTP email server. Early in development I worried less about how my email was delivered and more with making sure my application was working. I decided to use the mail server provided to me by one of my shared webhosts. This was not where my web application was actually hosted, but it was most accessible.

This is simple to setup within most web applications. In Rails, there are a few different ways you can go about this, but I just attached the following code to my enviroments/*.rb files.

ActionMailer::Base.delivery_method = :smtp
ActionMailer::Base.smtp_settings = {
:address => "smtp.site.example",
:port => 25,
:domain => "www.site.example",
:authentication => :plain,
:user_name => "username",
:password => "password"
}

To get this to work, you’ll have to set up an email account with your web host. I’d recommend something like support@site.example or noreply@site.example. Create this as you would any other email account. If your host doesn’t require authentication to use its smtp servers, you can drop :user_name, :password and :authentication from the above example. If your host doesn’t require authentication and you aren’t worried about getting replies, you can probably skip even creating an account with your server provider.

This worked well for testing. It was easy to setup and reliably delivered email. Those emails were reliably marked as spam, unfortunately. While this wasn’t an issue during early development, it would be unacceptable when others started using the site.

Google SMTP

The smpt server I initially used was run by a relatively small company and offered no special tools to beat spam filters. SMTP servers from the largest companies are already setup to deliver email that appears authentic. So I switched to using the server for my Google mail account. I was already using Google Apps to use Gmail for my domain. You should be able to use a normal Gmail account too.

For my Rails application, I used the same setup as for my host’s smtp server. A few additional parameters are required for it to work with Gmail, however. As before, I simply added the following code to my enviroment files.

ActionMailer::Base.delivery_method = :smtp
ActionMailer::Base.smtp_settings = {
:tls => true,
:address => "smtp.gmail.com",
:port => 587,
:domain => "site.example",
:authentication => :plain,
:user_name => "username@site.example",
:password => "password"
}

This will be a good solution for a lot of smaller applications. There was a clear improvement in delivery while still being relatively easy to setup. The results weren’t perfect, however, and Gmail have a daily limit of 500 outgoing emails. The average user registration use case generally involves at least two emails: one with an activation code and a second to confirm activation. Given that most users would register and activate on the same day, that leaves me with an SMTP limited 250 maximum user registrations per day. Given the spiky nature of early traffic, I couldn’t risk that limitation.

Email Delivery Service

If you need greater flexibility than that, another option is using a company that specializes in delivering email. Such companies have more advanced spam management techniques than Google and have “whitelist” agreements with most email providers. This makes sure their emails get through. One of the leading providers is AuthSMTP. There are many situations in which using a provider such as AuthSMTP is an excellent solution. In fact, if you have truly high volume, it may be outright necessary. A step above AuthSMTP and other similar services is to use a full email marketing provider, such as ConstantContact. These services have an array of options for tracking email and testing the effectiveness of email campaigns. These tools are designed more for newsletters than notification, though.

Like many entrepreneurs, I want to be able to handle any sudden surge in traffic to grow my site. Until this growth occurred and I found a way to monetize it, however, I was working with a pretty limited budget. Matching Google’s free limit would cost $250/year with AuthSMTP. ConstantContact doesn’t price per delivery, but maintaining a list of 5,000 users would cost $600/year. Additionally, integrating your email delivery with these services is a task no smaller than setting up your own. With a larger established site, it would likely probably be worth the time and expense, but until then, I decided to see what I could do on my own.

In my next post I will discuss installing Postfix MTA in a linux environment and setting up dkimproxy’s dependencies.

| Popularity: 47%