email like it’s 1995
The old joke
There used to be a joke that people who didn’t ‘get it’ would send an email and then call the recipient up to check if it had been received.
Now the joke’s on us
Now, I am that joke. I think we all are. Email has reached a point where it’s just not reliable enough for business use.
Update 17 Dec – clearly I’m not the only one to notice this. Babbage over at The Economist shares my pain.
The heart of the problem is of course spam
The real trouble though is that the cure is maybe worse than the disease. Our reaction to spam, and the systems that we use to filter it out are destroying the utility of email.
I can think of numerous examples in the last year or so when I’ve emailed somebody and got no reply, only to hear sometimes weeks later that my message got caught in their ‘junk folder’.
One of the problems with spam is how to define it. There’s obvious stuff from the peddlers of dodgy drugs, body enhancements and financial scams – the stuff that none of us really want to see in our inboxes. Then there’s the stuff from marketing droids, where you had to give your email address to register for an event, but never really want to hear from them again. Then there are the mailing lists that you chose to subscribe to, but don’t want to read right now (for which the term ‘Bacn‘ was coined – it’s fine for breakfast, but you don’t want to eat it all day).
Caught in the crossfire
The problem is when legitimate mail, that’s neither spam nor bacn get’s classified as junk. I noticed last week that a perfectly normal email from a colleague had found it’s way into my Postini quarantine. When I fished it out of limbo I had a look at the headers to see if anything odd was happening. I found this:
Received-SPF: error (google.com: error in processing during lookup of [email protected]: DNS timeout) client-ip=184.108.40.206; Authentication-Results: mx.google.com; spf=temperror (google.com: error in processing during lookup of [email protected]: DNS timeout) [email protected]
Oops – looks like it’s time for me to set up SPF.
Sender Policy Framework (SPF) is a system where a domain can nominate approved senders for its email as a means to cut down spam. Sadly Google Apps doesn’t configure this for us (hardly a surprise as they don’t manage our DNS), and nor do they have any tool to help you configure SPF. Luckily there’s a bunch of stuff out there on the web, which led me to the following settings (for our Postini outbound servers, and Blackberry):
@ TXT v=spf1 ip4:220.127.116.11/20 ip4:18.104.22.168/20 ip4:22.214.171.124/22 ptr:blackberry.com ~all
This seemed to work fine, and I started seeing the good news in email headers from colleagues:
Received-SPF: pass (google.com: domain of [email protected] designates 126.96.36.199 as permitted sender) client-ip=188.8.131.52;
Troubles not over
Sadly SPF doesn’t seem to cut it with Postini, and a few days later another colleague told me that an email I’d sent him had been quarantined (it was a reply to an old thread asking if he’d made any further progress). I could see nothing more that I could do, so I raised a support case with Google/Postini. Here’s their reply in its full horror:
Chris,This is a known issue and our team is working to correct the issue. The Problem is that you internal mail goes out to the internet and back in through Postini. The Postini system is designed to be very critical on spoofed mail, because a huge percentage of spoofed mail is spam. I have no ETA as to when this will be corrected, but we do have a work around.We have a feature called IP lock. Turning this feature on will allow you to specify the IP’s you allow to spoof your domain. Once you’ve turned this on and added the Google Apps IP ranges you can add your domain to the organization level approved senders list and not have to worry about unauthorized spoofed mail making it through to your end users.Here’s a link that provides configuration instructions for the IP Lock feature.http://www.postini.com/admindoc/secur_iplock.html
and here is are our IP ranges…
184.108.40.206 to 220.127.116.11
18.104.22.168 – 22.214.171.124
Technical Support Engineer III
Wow – how incredibly unhelpful is that?
Postini could have a system that works (and that respects SPF showing that mail has originated from their own servers) – but they don’t.
The support engineer could have configured IP Locks for me – but he didn’t.
The support engineer could have provided me with the script that I needed to run – but he didn’t.
So… off to the documentation, and a bit of trial and error to discover that I needed to run the following batch script in the Postini services console (Orgs and Users > Batch):
# add Postini IPs
addallowedip [capitalscf.com] Account Administrators, capitalscf.com:126.96.36.199/19
addallowedip [capitalscf.com] Account Administrators, capitalscf.com:188.8.131.52/19
addallowedip [capitalscf.com] Account Administrators, capitalscf.com:184.108.40.206/20
addallowedip [capitalscf.com] Account Administrators, capitalscf.com:220.127.116.11/18
addallowedip [capitalscf.com] Account Administrators, capitalscf.com:18.104.22.168/17
addallowedip [capitalscf.com] Account Administrators, capitalscf.com:22.214.171.124/20
addallowedip [capitalscf.com] Account Administrators, capitalscf.com:126.96.36.199/16
addallowedip [capitalscf.com] Account Administrators, capitalscf.com:188.8.131.52/20
addallowedip [capitalscf.com] Account Administrators, capitalscf.com:184.108.40.206/20
# add BlackBerry IPs
addallowedip [capitalscf.com] Account Administrators, capitalscf.com:220.127.116.11/24
addallowedip [capitalscf.com] Account Administrators, capitalscf.com:18.104.22.168/24
addallowedip [capitalscf.com] Account Administrators, capitalscf.com:22.214.171.124/24
addallowedip [capitalscf.com] Account Administrators, capitalscf.com:126.96.36.199/20
addallowedip [capitalscf.com] Account Administrators, capitalscf.com:188.8.131.52/20
addallowedip [capitalscf.com] Account Administrators, capitalscf.com:184.108.40.206/19
addallowedip [capitalscf.com] Account Administrators, capitalscf.com:220.127.116.11/20
addallowedip [capitalscf.com] Account Administrators, capitalscf.com:18.104.22.168/19
addallowedip [capitalscf.com] Account Administrators, capitalscf.com:22.214.171.124/19
addallowedip [capitalscf.com] Account Administrators, capitalscf.com:126.96.36.199/19
addallowedip [capitalscf.com] Account Administrators, capitalscf.com:188.8.131.52/20
# show what happened
showallowedips [capitalscf.com] Account Administrators
Note how complex the OrgName is compared to the examples in the documentation.
It’s also completely unclear to me whether IP Lock should be used in combination with having my domain as an ‘Approved Sender’ or not? For the time being I do (I can always tighten things up if a flood of spam ensues).
Fix this Google
I only use Postini for its ability to add footers with a disclaimer, and this whole thing has me wondering if it’s more trouble than it’s worth – after all the anti-spam in regular gmail is pretty good (and it’s a question for another day why that functionality isn’t better integrated into Postini quarantine – still, they’ve only had 3 years – how hard can it be?).
Or will Facebook fix it for us all?
There has been much fuss in the last few weeks about Facebook launching an integrated email/messaging service. I personally can think of few things I’d less like to do than use Facebook more. I don’t see them as a business service, and I’ve yet to hear anything about how they will deal will the spam problem. But many others seem to think what they’re doing is the shape of things to come – so I could be wrong.
[update 22 Nov] Google/Postini have now been in touch to say that I was apparently the victim of ‘a recent incident that we have since resolved’. PIR_11_Nov_16_Spam_Quarantine. This leaves me wondering how often this sort of thing happens and I don’t notice, and why the first support engineer went straight down the IP lock route?
[update 22 Nov #2] Looks like I missed a bunch of BlackBerry IP ranges first time around – one of the inherent problems with using such a fragile approach. The definitive list is here. At this stage I’m quite tempted to turn IP Lock off given that Google have come clean about their incident.
Filed under: could_do_better, grumble, howto, software | 7 Comments
Tags: bacn, batch, blackberry, business edition, DNS, email, fail, false positive, GABE, GAPE, gapps, google, Google Apps, IP Lock, Postini, premier edition, quarantine, spam, SPF, support