Don’t Forget Your Mouthpiece

My name is James, and I am an AOL user.

Like they say, the first step is admitting you have a problem, and I have certainly been having those in the past few days.

When I bought my computer 3 years ago, I knew next to nothing about anything computer-related. I subscribed to AOL dialup because my flatmate had as well, and the nice integrated browser/email/chat software looked slick and functional to my untrained eye. A year or so later, embarking on my Open University web design course (building table layouts in Netscape Composer), alarm bells started to ring when my pages were mangled by AOL’s browser. Fine in Internet Explorer, and in Netscape, but AOL, despite being basically a combination of the two, couldn’t cope. More digging around revealed that AOL does many things in a non-standard way, from its popup blocking to the strange email system which did not at the time allow you to use an external mail client. I lived with these peculiarites for a while and then upgraded to broadband, which to my delight meant I didn’t have to use the AOL client at all, and was one of the better deals for high-speed unmetered access around.

However, a couple of weeks ago I suddenly noticed I couldn’t send email on any of my hosted accounts. I tried a number of different server names, having a vague idea it might have something to do with a number of different reseller domains referencing the same mail server, but no joy. An equally vague instruction from Ehostpros’ tech support people suggested changing the port number, or trying AOL’s outgoing server, but still to no avail. As soon as AOL’s tech support heard the words “not an AOL address”, out came the standard “We suggest you contact your web hosting provider” (for this read “We either can’t be bothered helping you, or don’t understand what you’re talking about”). I realised I needed to do some digging on the subject, and spent the next couple of days wandering around various permutations of the same Google search.

For the uninitiated, an Internet connection operates over a number of “ports”. Every application, be it a browser connection, a secure connection, inbound or outbound email, your own server or a database, operates on its own port. In the case of my culprit, SMTP outgoing email, this port is 25.

Or at least, it usually is.

Recently a number of ISPs have started blocking port 25 to all outgoing email servers except their own. That’s fine for your average home user, but for people like me, who have a number of different email addresses for a variety of reasons, or who would rather not spoil the professional face of their business with an email address from an off-the-peg provider, it presents a problem. They do this, they claim, in the name of cutting down on “spam” - it is, technically, possible for a worm or some other virus to get on your machine and sit there sending out thousands of emails without your knowledge. I know very little about whether blocking port 25 actually does any good, but I’m prepared in my ignorance to give them the benefit of the doubt.

Fine. So what do you do about it? Well, the stock answer is to use your ISP’s outgoing server to send your emails - this shouldn’t matter as the information on where the message has come from isn’t added by the server but is contained in the HTTP header that your email client generates. The problem is that AOL won’t let you do this either, unless you configure your client basically to pretend you’re using your AOL email address, which kind of defeats the point of having your own domain email in the first place.

The other solution is to use a different port. In theory this is easy, but it means you have to find a port that your ISP allows outgoing traffic on, and your mail server allows incoming traffic on. What I’ve found out (and there isn’t all that much published material available on this) is that policies on which port or ports to use differ widely from company to company. My hosting provider allows connections on port 25 or 26, AOL’s help pages recommend port 587, using a secure connection. They don’t say, however, that they explicitly block any other ports than 25. So I can use 26, right? Right, they tell me.

Wrong.

AOL deny that they block other ports, but I spent the best part of a day trying permutations of ports, server names, authenticated and not, and could not get a single email out. The worst aspect of this kind of problem is that technical support people take the fact that you are trying to get two different companies’ technologies to work together as an excuse to pass the buck to their opposite numbers, thus making it nigh on impossible to get useful information out of anyone. Once sent over to Ehostpros to check the details of email account settings (which you’ve already done six times), you are told to go back to AOL to investigate allowable ports. The person on the end of the phone, who is normally used to dealing with faults involving failing to plug something in, and who being in an Indian call-centre doesn’t quite understand what you mean by “Do I use SSL or TLS authentication?”, meekly offers “Well, you put your email address in the box that says “email address”, and you manfully resist the temptation to unleash the sort of tirade that Mr Blair would probably now have you banged up for. You then make the mistake of saying your server name is mail.jamestopp.com and are told “to contact mail.jamestopp.com and ask them for advice”, at which point you either go and stick your head in the oven, or go back to Ehostpros and repeat the whole sorry tale to your fourth different email help ticket guy of the morning.

As someone who believes strongly in an open Web and deplores the kind of practices that are designed to tie you in to one product for life, I find this frustrating in the extreme. I have to say also that I have generally been more than satisfied with AOL’s service over 3 years, and recognise that I do not really fall into the market they are aiming for. However, in the absence of any better ideas I am about to give them the push and move to an ISP that offers the same bandwidth at the same price, a fixed IP address and a promise not to block any ports. (It’s Eclipse.net.uk if you’re interested). Out of fairness, I’ll probably end up switching hosting providers as well, since mine doesn’t offer secure connections to their email servers.

As I mentioned above, there is a lack of information available on the Web on this subject, so I’d like to start a list of ISP’s and hosting providers and their port blocking policies on this page. I can only speak with authority on AOL and Ehostpros so far, so here they are:

Port blocking policies for third party email servers

• ISP: AOL
  • Allows ports: 587 (SSL connection)
  • Allows connection to own server: Well technically yes, but MAIL FROM and AUTH headers must match in order for the connection to be accepted, which is no use to anyone.
  • Claims not to block any other ports, but I suspect this is untrue.
• Host: Ehostpros
  • Allows ports: 25, 26 (no SSL connection)

If you’ve had a similar experience, please leave details in my comments on your own ISP and host, similar to above. I would urge you only to give information you’ve found out through experience, rather than simply by asking your tech support people, since I suspect that what these companies claim and what they actually do are rather different. Hopefully this will build into a handy reference for anyone considering compatibility between hosts and ISPs. There is of course the larger issue of how a web designer can help their clients configure email on a multitude of different platforms and service providers without wrangling with tech support every time.

Of course, I could be wrong about all this, and if you think I’ve missed something I’ll be grateful for suggestions. But the next person who asks if I’ve checked my firewall will instantly regret it.

This entry was posted on Thursday, February 16th, 2006 at 2:06 am and is filed under Web. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.