Order of the Bath

We have a problem that perhaps someone can help us with.
Emails from certain ISPs to west-penwith (hosted by DotEasy) take an extraordinary long time to arrive. The most noticable are mails from BlueYonder because we use it ourselves as do a lot of our friends locally. I have seen delays of anything from 20 to 25 hours. Studying the headers confirms that the delay is between the last Received: header in blueyonder.co.uk and the first at doteasy.com (after correctly compensating for timezone).
My question is “who is responsible?” Do I contact BlueYonder because they are hanging on to it in their queues or do I contact DotEasy for refusing to accept it in a timely manner?

Email viruses are another plague on the electronic utopia. To fulfil its definition a virus has to be able to replicate itself and pass on to another victim, preferably without manual intervention (else it is properly called a trojan, a subtle difference which can often be ignored). Because the email protocol is so simple, this is the easiest way for it to achieve its goal either via the native email client found on the machine or by a crude one built into the virus itself. As a result, once a machine has become infected it becomes the source for further infection. In the early days this involved attaching itself to legitimate outgoing mail and sending further infected mails to known addresses found on the source machine e.g. from the address book or a disk scan. Later this developed to the virus itself containing a database of potential targets which was shared out between victims in a cascade process. Ultimately it became more of a spam mechanism with the virus generating names semi-randomly using dictionary type techniques.

There are a number of places that viruses can be trapped and dealt with. All users are recommended to have a good anti-virus product installed. These are capable of scanning incoming and outgoing mail so attempting to deal with the symptoms as well as any potential infection. The better ones do this directly on the port drivers, between the applications and the outside world, so they can catch hidden email clients as well as the standard ones used by the owner. If your anti-virus tool reports outgoing infected mails then look to updating it and doing a major disk scan because you are probably infected.

Trapping infected emails on arrival is not really sufficient. Despite all the warnings, some people run without anti-virus software and can become infected increasing the problem. Also there is the cost involved with storing and distributing these emails. I said in part 3 that the mail servers only see the text stream and pass it though untouched. This is no longer true. Since the flood of malicious emails started there has grown, rather slowly in some places, a need to staunch it on the carriers rather than wait for the users. So now, most ISPs and company mail servers scan each email, decoding the MIME formats and checking each attachment before delivery. I believe that even some inter-network routers also do this.

This is a reasonably acceptable form of mail intercept—there are rarely false positive alerts with good mail being declared infected, and the better scanners just remove the attachment and pass the rest of the mail through with a note so that you know what has happened. The cruder ones strip off all attachments of certain types, such as .exe, which is less helpful and it becomes difficult to send legitimate files reliably. All sorts of subterfuge is used by good citizens to get their files though, the favourite being to change the file extension to something like .xex and give the recipient instructions how to restore it. The paranoid strip off all attachments reducing email to its basic text messaging form. This tends to only be short term at times of high risk.

The body of an email is a continuous stream of plain text lines, each no more than 80 characters long (remember punched cards?) and terminated by a line containing just a single dot “.” this doesn’t allow for much other than simple messages. To get round the restrictions and allow the sending of other types of data, uuencode (unix to unix encode) was borrowed from another system. This allows any data, including binary, to be transformed into plain printable characters, though you wouldn’t want to read them. A corresponding program uudecode converts it back to the original form without loss. The drawbacks to this are that the message increases in size and that the process is very manual. The first problem was addressed by compression but that made the second problem even worse as it is now a three stage process at each end i.e. compress, uuencode send—receive uudecode uncompress, and some data needed different handling, perhaps a different compress program.

The major development to resolve this was MIME (Multi-purpose Internet Mail Extension). Using this the body of the email is divided into a number of sections, still all in plain text and the whole lot terminated by the “.” The mail server knows nothing about it, it is all handled by the client at each end. Each section has its own sub-header which contains details about what sort of data the section contains and how it is encoded. Then when the mail arrives, it is all sorted out into the message (now perhaps formatted in HTML) and the attachments all with their correct type and name.

What we saw in part 1 is the simple case with just a sending and receiving mail server, but quite often a number of intermediate hops are required to reach the ultimate destination. Using the “Received: ” headers in reverse order you can see what route a mail item took to get to you.

When email was invented, the networks weren’t as richly interconnected as they are now and consisted of small islands connected by narrow, unreliable pipes. So the technique to deliver a message was to forward it to another server which was a bit closer to the final destination. There was even a way you could suggest the route you wanted your mail to take. A system evolved where servers would discover the best routes by learned experience. This meant that servers became accustomed to accept any mail and forward it on as required.

In more recent times this custom was exploited as the servers didn’t care where the mail came from. Spammers arranged to send mail to random servers and specify obscure routes knowing that they would dutifully forward them on and their tracks would be hard to detect. This is called the “Open Relay Exploit.” To avoid this, servers began to be more selective and mostly they now only accept mail from their own clients or, alternatively, mail destined for places that they know about and are responsible for. They will no longer accept mail from anywhere to anywhere. In practice you will see from the headers that most mail gets moved around internally at the source end, makes a big leap to the destination, and then moves around a bit there before being stored.

An organisation called ORDB (Open Relay Database) tracks down the few remaining open relays and system managers can use this list to ban them from contact as their transmissions will be unreliable.