Are spam filters damaging your cash flow?

One worrying trend we’ve noticed in recent months is the increasing likelihood that our customers’ spam filters catch our monthly invoices, either sending them to the oft-ignored spam folder, or rejecting them outright.

Needless to say this is concerning because our customers either won’t know their credit card is being charged (if they’re on our auto-bill system) or simply won’t know that payment is due; risking suspension of their account.

Intuitively it makes sense that spam filters would attach a high spam score to invoices & payment requests, as these sorts of documents very often feature in spam and phishing attempts.

So, what to do about it?

Our experiments revealed that nearly every major spam filtering system is substantially less likely to classify an email as spam if it originates from a well known, reputable mail service such as GMail, Yahoo Mail, Hotmail, etc.  The identity of the originator is determined by IP address rather than the unreliable From: header.

Bear in mind that your web server either has no reputation value at all or – worse – has an IP address that was previously leased to less scrupulous operators. As availability of IP addresses becomes tighter you can certainly expect that the IPs attached to your shiny new server have been used by numerous websites & servers before reaching you.

We’ve experienced this situation a number of times – as we maintain a large number of servers in physically disparate locations (hence on different networks) and need to ensure email alerts can be delivered from all of them.

Google to the rescue!

At this point a possible solution becomes clear – route important email via a well known and reputable service to improve its chances of successful delivery.

We’ve been trialling this by utilizing the SMTP relay service provided by Google Apps Premier Edition – which powers all email destined for the domain. It’s dramatically improved the situation for us thus far, and provides the additional benefit of archiving all web server outbound email within GMail.

To assist if you’d like to try something like this, I’ve posted a howto for configuring Postfix to relay via GMail’s SMTP service.

Filed under: Servers,Web 2.0,Web Services — Jules @ 15:56 - November 11, 2008 :: Comments Off on Are spam filters damaging your cash flow?

Relay mail via Google SMTP with Postfix

Using Google’s SMTP service to relay your outbound mail is a handy way to be able to send mail from Amazon EC2 instances, or other machines running IP addresses considered to be of dubious quality in the spam fighting world.

It’s also quite valuable in that your outbound emails will appear in your GMail sent messages folder and hence appear inline in conversations when your users reply.

Setup Instructions

These instructions are developed for Centos 5.2 – but no doubt they can be applied to other distributions with minimal modification.

Ensure that you have Postfix:
yum install postfix -y

We need to create the client keys for the TLS connection to Google’s SMTP service – and to do that we first need to become our own certificate authority (CA):

/etc/pki/tls/misc/CA -newca

Follow the prompts and make intelligent responses.

Now, create the client keys/certs (again with intelligent responses, and ensuring you use the same common name and country code):

cd /etc/postfix
openssl genrsa -out postfixclient.key 1024
openssl req -new -key postfixclient.key -out postfixclient.csr
openssl ca -out ./postfixclient.pem -infiles postfixclient.csr

Now you can configure Postfix accordingly. Add these to the top of /etc/postfix/
relayhost = []:587
smtp_connection_cache_destinations =
relay_destination_concurrency_limit = 1
default_destination_concurrency_limit = 5
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_use_tls = yes
smtp_sasl_security_options = noanonymous
smtp_sasl_tls_security_options = noanonymous
smtp_tls_note_starttls_offer = yes
tls_random_source = dev:/dev/urandom
smtp_tls_scert_verifydepth = 5
smtp_tls_enforce_peername = no
smtpd_tls_req_ccert =no
smtpd_tls_ask_ccert = yes
soft_bounce = yes

And store your password in /etc/postfix/sasl_passwd

(Note that if you’re using a regular gmail account instead of Google Apps For Your Domain, you would use above)

Get Postfix to parse the password file:
postmap /etc/postfix/sasl_passwd

Optionally configure Postfix to run on a different port (so as not to clash with your regular SMTP relay):

Open /etc/postfix/ and change the first line to:
10025 inet n - n - - smtpd

Now start Postfix!
service postfix start

And add it to your startup scripts:
ln -s /etc/init.d/postfix /etc/rc3.d/S96postfix

Filed under: Servers — Jules @ 17:06 - November 5, 2008 :: Read comments »