Let me start off by saying that I’ve been working with electronic communications since I was about 8 or 9 years old. I’m now 43, nearly 44. I started off being allowed to “play” (read: carefully dictate messages) with a major international re-insurance broker’s telex system whenever my dad took me to work with him. I found it absolutely fascinating. And the beautiful mechanical DEC keyboards were a joy to type on. Much later on I’d spend a few summers on work experience at the same company, telexing and working with spreadsheets and FileMaker Pro databases on expensive early Macintosh kit.

At secondary school I wrote an internal email system in BASIC which made use of the local school’s Windows network. It was super simple and merely demonstrated how a typical email system would work. But work it did. I did all this for my Computer Studies GCSE.

The combination of work experience and the GCSE project very much defined my career because for the past 24 years I’ve been a systems administrator. My first ever gig after leaving university was setting up a local Norwich ISP. This included providing email services for both dial-up (remember that?) and web hosting customers. Things back then where much simpler than they are now. We had very few spammers, phishing was a mere twinkle in scammers eyes, and anti-virus was something that only naughty people caught. Generally any filtering was performed client-side. We didn’t have much in the way of webmail – everything was POP3. IMAP was considered a novelty.

But even then, it took some effort to manage and maintain an email system. As years went on, Sendmail (for it was the de facto at the time) filtering started and both commercial and free anti-virus scanning became essential. Then SpamAssassin integration. When I was working for The Moving Picture Company (MPC) in London, I looked after the main mail servers. I split off anti-spam filtering (powered by SpamAssassin) onto its own server (which cost us nothing – I used an old render farm machine – whereas when we were looking at Barracuda’s anti-spam system at the time (circa 2002-2003) it was merely an expensive pimped up SpamAssassin box with a fancy user interface) and replaced the ageing 486 that was powering the entire company’s email with something beefier – as well as performing a major upgrade of Exim and having to rewrite its filtering/configuration files. Oh, and integrating Mailman for internal mailing lists and writing some PHP code to make it all look prettier and easier to use for the VFX producers. All that took a LOT of work. But when the business/non-production side wanted Microsoft’s bloated and super expensive Exchange – I explained I could implement a cheaper system at a third of the price which could do everything Exchange could – I was ignored. They went with Exchange and old muggings here had to implement a split email system (which worked well enough).

During all this time, my personal email was hosted by myself. I usually had some kind of Linux virtual machine running Exim and some IMAP/POP3 daemon, or in some cases, a Windows virtual machine and MDaemon. MDaemon was (and still is) a lovely Windows-based mail system. Very comprehensive. But for a single user or household, it’s flipping expensive and I had to eventually give it up. There were other times when I hosted my email on a cPanel account or server. But the point is that I’ve managing my own email with my own domain (the one you’re reading this post on, in fact) since 1997. I went through more ISPs than people have had hot dinners. But my email address always remained the same.

When Google’s Gmail came on the scene around 2004, I thought it was one of the best web-based email systems around. It beat the living daylights out of Yahoo! and Hotmail. It had genuinely useful features. But you couldn’t attach a domain to it. You had to make do with a @gmail.com address, and you had to put up with advertising. This also meant no easy support from Google. But in 2006, Google started trialing Google Apps For Your Domain. It was initially free, and allowed you to attach a domain to Gmail and use it alongside other Google applications too. I started getting involved in the Google forums helping to support it, as I had liked it enough to move my email over to it. Having to use only a web browser for email when I was very disappointed in all dedicated email clients was wonderful. It meant that I could use different web browsers, but the functionality would remain the same. My bugbears against dedicated email clients included the use of fixed width fonts and word wrapping, email filtering was bad, or the quoting methodology was insane. I kind of liked Outlook for a while, and there were some workarounds to the quoting system, but when Microsoft updated Outlook, everything broke and I gave up.

When Google started offering paid versions of Google Apps For Your Domain (which had subsequently become just Google Apps), I started to pay for it. £5/month (well, less – but you need to factor in VAT). It enabled me to turn off advertising, so I had email privacy (with the usual caveats – you need to allow an email system to scan incoming email for spam, phishing and viruses – all this is automated and no human sees it). I had email privacy and a much bigger email quota to boot. And I had official support.

When I worked for Imagineer Systems (now Boris FX), I migrated the email system from a single virtual machine running on a dedicated box to Google Apps for Business. The cost saving alone was worth it. It just made everything easier and simpler to maintain.

Meanwhile back in workland (during my time at Memset), I was supporting customers who were also rolling their own email – albeit mainly via cPanel/WHM which does provide a very comprehensive set of tools. Some customers rolled their own separate Exim or Postfix configs, but mainly it was cPanel. Many a time I discussed us becoming a Google partner and supporting Google Apps, but Memset rolls its own cloud services and it was not something that ever was going to happen.

Where I work now, we using G Suite. And it makes light work of maintaining a corporate email system. It’s survived a company rebranding easily enough and the tools and services it provides is having a very positive impact on the business. We’re looking to extend that too, so’s all good. My experience with working with G Suite over the years is paying off!

Phew. After that long introduction, I’d like to get around to the whole reason I’m posting this thing in the first place. The cost of ISP branded email and its use after you move ISPs.

As you can appreciate from above, a lot of work goes into managing email systems and it’s also not cheap depending on the system you go for. Many ISPs used to roll their own email systems using open source applications like Sendmail, Exim, Postfix, Amavis, etc. but when Google opened up its Google Apps for Domains to ISPs, a number of them switched to that.

Then Google ended Google Apps for ISPs, and they had to move to yet another system. Some moved to Yahoo!, some moved back to hosting email internally again, others to other externally hosted services.

And many did move to externally hosted services because maintaining a functioning email system for thousands of customers – even using open source tools – takes considerable time, effort and money. Scaling such a system is expensive. Keeping it functioning when many hundreds or thousands of people keep hitting the POP3 or IMAP server every few minutes requires monitoring and maintenance.

So why should ISPs expect to maintain your email, for free, and for life, when you leave their broadband service? I find it doesn’t make any kind of sense either economically or practically.

Apparently Sky do let you keep your email address when you leave them, but as they’re using Yahoo!, I doubt it costs them much to do so. Yahoo! does the heavy lifting and you probably get adverts within your mail which recoups the cost of the maintaining your account.

They key thing here is: how much do you want to pay for your email? It’s never free. There is always some cost attached to it. One option may be using an ad-blocker – but this is deprives the provider from any income which is used to pay for your hosting. Another option is to move to a dedicated email provider such as Yahoo!, Gmail or Outlook.com – but you’ll end up with having to cope with adverts. Yahoo! offers a paid upgrade option which gets rid of them. Outlook.com too (Outlook Premium).

You could use your old ISP mail when you move ISPs, but for the likes of BT and TalkTalk who charge – it’s not an unreasonable charge in comparison to other hosting options out there. But here’s what I would do:

  • Buy a domain. Any domain. They don’t need to be expensive, but you what to find something that’s going to last a bloody long time.
  • Find a dedicated email hosting provider. Follow any instructions they give on how to set things up (or get your family IT tech support to help out!) – or consider the likes of G Suite, Office 365, or even Rackspace.
  • Depending on how you have your email set-up at the moment, you’ll either need to migrate all existing mail into the new hosting provider, or you’d need to move you email to the new account within your email client. With Outlook, it may be easier to export your old mailboxes as PST files and import them into the new account, then delete the old ISP mail account afterwards. Again, your new email hosting provider can help you with this (or your friendly family IT manager can!).

The domain part is important because it means that you get to choose any email address you like at that domain. Providing you continue to pay for the domain and hosting, you never need to change email addresses ever again. I also think that if you’re running a business, a domain name makes things a lot more professional.

So I completely disagree with Ofcom’s assessment that ISPs are charging too much to keep old email addresses. I think this would become less of a problem if ISPs allowed you to host a domain name with them for the purposes of email (or free web space – which is still a thing, apparently). You either import or buy (cheaply) a domain and use it with the ISP for your email. When you need to move ISPs, you provide the new ISP with the domain name they take care of the move for you. How about that? That could potentially work.

For the love of all things holy, I cannot believe this company. 5 days compensation is better than nothing, but when you consider it was a full 27 days, it still feels rather stingy. But that’s not what’s got my goat. After reading the initial blurb, there’s a link to an update site which allows you to put in your name and email address.

ALAS!

They’ve not put a valid SSL (or TLS, if you prefer – technically it should be referred to TLS these days, but people are set in their ways) certificate on their site. Which means that any form data transmitted will be sent unencrypted between the user’s browser and the server. This could (unlikely, but still possible) for data being sniffed and captured by a third party.

Another method is by spoofing the southwesternrailway.com domain. I could register a domain such as southwestermrailway.com (as an example) and duplicate the same hostname and the site contents (changing the form details so that anything is sent to me or a file on the server), leaving out the SSL certificate. I could potentially hoover vasts amounts of data as people don’t bother to check the URL or SSL certificate.

In any event, putting an SSL/TLS certificate on your site is vitally important these days, and it’s not difficult to do. I’m still amazed that Bafta.org hasn’t put its entire site behind SSL/TLS (try going to https://www.bafta.org, and it’ll redirect you back to non-SSL content), nor Milk VFX which solicits job applications to submit entries via an unencrypted form. Bad, Milk VFX, bad!

Update: Looks like they’re using external Salesforce CRM to capture the information. The Javascript form code is hosted securely – thank goodness – and it looks like the form data is also submitted securely to Salesforce servers. Even so – I’d still be pretty weary about any site without a proper SSL certificate and encrypted traffic between the browser and server, and not everybody is going to want to scour the page’s source code to determine what’s going on.