Oending Letters

Oh dear, could it be that my brief career as a documentation engineer is about to come to an abrupt and unexpected end? Has my recent sin been so dreadful that I will be thoughtlessly cast aside, and once again reduced to wandering aimlessly around conference circuits and local dev shops with all my worldly goods in a shopping cart, trying to scratch a living by talking and writing about enterprise software architecture? Next time you see a sad and lonely figure dressed in a grubby (but geeky) T-shirt and scruffy jeans, clutching the tattered remains of a book on design patterns in one hand and a seriously out-of-date laptop in the other, spare a thought - it might be me.

What was my dreadful sin? Well, in a recent article I used a rather too well-known abbreviation in the section that encouraged potential users to carefully study the documentation provided with the product before using it. And I nearly managed to sneak it past my editor, the policy checking people, and the entire legal team. But they caught up with me in the end. It seems, as a colleague explained, that they "have something against the letter F". Of course, I immediately took steps to ensure that we as a team never make that mistake again by sending them all an urgent email:

Please be aware that, in uture we need to be ully aware o company policies and careully avoid any oending letters.

Thankfully, and perhaps in part due to my prompt action, it looks like we've all escaped with just a slap on the wrist this time. OK, so I have to sit in the corner with a pointy hat on, and I'm not allowed any of those fancy p&p cheese sandwiches for a week, but it could have been worse. Especially if they'd known about my other recent word crime. And this was one that you can very easily commit.

Imagine you're answering an email from someone asking about your new product. You reply in an encouraging "please buy it" way with something like: "The new Abracadabra Mark 2 is reliable, robust, and secure." No problem? Well, what if your customer buys one and it falls over the first week (reliable?), dies the second week when someone presses the wrong key (robust?), and finally suffers a successful attack from an intruder in week three (secure?). Yep, you should have said "designed to be reliable, robust, and secure", because - no matter how hard you try and how well you design it - nothing is ever going to be absolute. It's so easy to slip up when you're bashing out a quick email, but at least now you've been warned. Luckily my email never actually reached the "clicked Send" point...

And, talking of email, if you'd been here last week by the server rack in my garage in the windswept and rainy (but strikingly beautiful) Derbyshire Dales, you'd have seen me jumping up and down like a cheer-leader, and whooping like a supporter at a presidential rally. Why? Well, stepping back a bit, it's all to do with "Unsolicited Commercial Email" (and isn't that a great acronym for junk email? I once wrote an article that was fairly iffy, but had the wonderful title "Spam Filtering - Is It Any UCE?").

Anyway, I've been using the same personal email address for about 10 years, it's on every spam list out there, and so I get tons of junk email every day. I now use an outsourced email filtering service to control it, and they bounce something like 1200 spam messages per day (yes, per day) that are sent to random and non-existent names at my domain. Some spam does still get through, but not enough to be an issue. And with the money from all the lotteries I've won, the profit on my Nigerian Oil Company shares, and the commission for handling the legacy of the recently deceased King Alibongo, I'll soon be able to afford one of those brand new Rolex watches anyway.

But the emails that really annoy me are those System Administrator messages informing you that "...your email offering Valium and male enhancement services could not be delivered to one or more recipients". Of course, when you examine the original message headers, it clearly didn't come from you at all - it came from somebody who spoofed your email address (assuming that your mail server is properly secured and you haven't been botted). Even more annoying, the Non-Delivery Report (NDR) says that "...delivery will be reattempted over the next three days." And it's absolutely pointless getting worked up and shouting "No, don't bother, just forget it!" at your mail server, because that's not where the message is coming from.

So, a couple of years ago, I went to all the trouble of learning about Sender ID / Sender Policy Framework (SPF) in the hope that it would fix the woefully inadequate Simple Mail Transfer Protocol (SMTP) that we seem to be stuck with. I figured it out, created the appropriate text string for all my domains, and inserted the records into my DNS servers. And, to be perfectly honest, it seemed to do pretty much nothing - until last week when I opened an NDR from Google and found this:

Delivery to the following recipient has been delayed: trin46yds@gmail.com

And, there amongst the message headers, was:

Received-SPF: fail (gmail.com: domain of a1ex@stonebroom.com does not designate as permitted sender);

Wow, they actually checked my SPF records and bounced the email because they knew it wasn't from me - it had a spoofed "From" address! At last all that effort was worthwhile. But further down the message it said: "...delivery will be reattempted over the next three days." And you thought I was the one who sent stupid email messages...

Skip to main content