It's as long as a piece of string
2008-05-23
I've been asked a number of times lately how long it takes for e-mail to arrive. My answer is this:
It varies.
In a normal scenario your e-mail software on your local machine makes a connection to an outgoing server (provided by your ISP, or perhaps your company's IT department) which accepts the mail and agrees to send it on. The outgoing mail server then makes a connection to the server listed as being responsible for the domain to which you're sending (the bit after the '@') who accepts it in turn. That machine normally checks the username (the bit before the '@') to decide which mailbox to put it into. Then the recipient can come along using the protocol of their choice and get that mail (or a copy of it) out of the mailbox.
Apart from the last part (or assuming that the person you're on the phone to is impatiently spamming 'Send & Receive') that can all be done in a fraction of a second. People have seen it happen, so they assume it always will.
The first problem is that this is pretty much a minimal setup; best case scenario. It might be a touch shorter if you're using webmail. It's shorter if you have have a mail server on your local machine, but if that's the case you probably don't need to hear what I think about e-mail. In any case there might be more machines in the chain. In our office, for example, local machines submit mail to the internal mail server which then sends it on to the ISP for an extra outgoing stage. On the incoming side, in a large organisation the front-end receiving server might need to pass it back to another mail server to actually get it into a mail box in the right department.
Even without adding more links though, one crucial fact of the mail chain is that not everything can be done at the speed of electricity. Mail - reading envelopes, making connections to pass them on - isn't a very intensive job for a computer, but most mail servers are dealing with... well, I don't want to guess how much mail some of them get. If a server receives mail to relay and doesn't currently have the memory and processor time spare, it'll stick the message in a queue. It might get to the front in seconds - it's a small job in the grand scheme of things - but equally it could be in a very long queue and be there for minutes.
Scanning mail for viruses or trying to spot spam adds to the work a server must do, increasing the likelihood and size of queues. (Notwithstanding the obvious effect of spam increasing the sizes of queues by its nature).
Sometimes servers aren't available. They might have crashed, they might have lost their network connection, they might have had someone unplug them so that he's got a socket to charge his phone, and so on. Well, most mail servers normal people use are in data centres and unlikely to lose power, but network links have to leave the centre and become vulnerable at some point, and anything can crash.
Even stuff that looks unrelated can affect it: if a significant internet pathway is unavailable then it could puts lots of extra traffic down the route you need as a backup route, and that slows everything down. I play WoW (servers in Paris) with some guys in Iceland from my home in the UK: one day last week Iceland lost its connection to the US for a while and all the traffic was going via Europe; one guy whose latency (the time data takes for a round trip) might normally be a couple hundred miliseconds was playing with two second latency. With too much latency, connections are more likely to be given up for dead by a machine that has waited too long for a response from the other party.
Mail servers behave in a variety of ways when they can't contact one another, but one of the more common responses is to put the mail aside for another attempt later, with or without trying to inform the sender. 'Later' might be in a few minutes' time, but it's more likely that a busy server will wait longer before putting the same mail back in its queue, perhaps hours.
Worst of all are those that might need human intervention. Every so often a mail can flag the security rules in server software, normally the in-office servers, and be set aside for an administrator to look at it. Then it will vary even more: some administrators are busy people.
Don't wait days for mail; by far the most common complaint is that it was addressed wrong. In theory the specifications of the mail standards mean that if mail doesn't arrive the sender will be informed, but in practice if you get the username slightly wrong the mail may well end up being delivered to a default recipient for the domain, which is generally someone who gets more mail than he can read and has a habit of deleting it with at best a cursory glance. If you get the domain wrong you might be told when your mail server can't find the domain, but if your incorrect name matches a domain that does have a mail server the mail may end up at another default recipient, this time one in another organisation entirely.
If you do get a failure report for a mail you genuinely sent, for goodness' sake read it. The report will say which server generated it, but note that often one server writes to tell you about a problem it had talking to the next one in the chain. The type of error will normally be described in fairly clear English; the most common reasons include:
If a delivery notice tells you that an error is permanent, don't bother resending the mail unless you find something you can change about it. Otherwise it might be worth resending, just refrain from doing so on such a scale that you'd seem impatient or obsessive if all the mails arrive at once (which is entirely possible).
There you go, enough ranting. I've kept it non-technical but that's most of what regular users should realise about e-mail. If any of my peers (or betters) disagree with any of it, say so and I'll do more research and correct anything that's inaccurate.
It varies.
In a normal scenario your e-mail software on your local machine makes a connection to an outgoing server (provided by your ISP, or perhaps your company's IT department) which accepts the mail and agrees to send it on. The outgoing mail server then makes a connection to the server listed as being responsible for the domain to which you're sending (the bit after the '@') who accepts it in turn. That machine normally checks the username (the bit before the '@') to decide which mailbox to put it into. Then the recipient can come along using the protocol of their choice and get that mail (or a copy of it) out of the mailbox.
Apart from the last part (or assuming that the person you're on the phone to is impatiently spamming 'Send & Receive') that can all be done in a fraction of a second. People have seen it happen, so they assume it always will.
The first problem is that this is pretty much a minimal setup; best case scenario. It might be a touch shorter if you're using webmail. It's shorter if you have have a mail server on your local machine, but if that's the case you probably don't need to hear what I think about e-mail. In any case there might be more machines in the chain. In our office, for example, local machines submit mail to the internal mail server which then sends it on to the ISP for an extra outgoing stage. On the incoming side, in a large organisation the front-end receiving server might need to pass it back to another mail server to actually get it into a mail box in the right department.
Even without adding more links though, one crucial fact of the mail chain is that not everything can be done at the speed of electricity. Mail - reading envelopes, making connections to pass them on - isn't a very intensive job for a computer, but most mail servers are dealing with... well, I don't want to guess how much mail some of them get. If a server receives mail to relay and doesn't currently have the memory and processor time spare, it'll stick the message in a queue. It might get to the front in seconds - it's a small job in the grand scheme of things - but equally it could be in a very long queue and be there for minutes.
Scanning mail for viruses or trying to spot spam adds to the work a server must do, increasing the likelihood and size of queues. (Notwithstanding the obvious effect of spam increasing the sizes of queues by its nature).
Sometimes servers aren't available. They might have crashed, they might have lost their network connection, they might have had someone unplug them so that he's got a socket to charge his phone, and so on. Well, most mail servers normal people use are in data centres and unlikely to lose power, but network links have to leave the centre and become vulnerable at some point, and anything can crash.
Even stuff that looks unrelated can affect it: if a significant internet pathway is unavailable then it could puts lots of extra traffic down the route you need as a backup route, and that slows everything down. I play WoW (servers in Paris) with some guys in Iceland from my home in the UK: one day last week Iceland lost its connection to the US for a while and all the traffic was going via Europe; one guy whose latency (the time data takes for a round trip) might normally be a couple hundred miliseconds was playing with two second latency. With too much latency, connections are more likely to be given up for dead by a machine that has waited too long for a response from the other party.
Mail servers behave in a variety of ways when they can't contact one another, but one of the more common responses is to put the mail aside for another attempt later, with or without trying to inform the sender. 'Later' might be in a few minutes' time, but it's more likely that a busy server will wait longer before putting the same mail back in its queue, perhaps hours.
Worst of all are those that might need human intervention. Every so often a mail can flag the security rules in server software, normally the in-office servers, and be set aside for an administrator to look at it. Then it will vary even more: some administrators are busy people.
Don't wait days for mail; by far the most common complaint is that it was addressed wrong. In theory the specifications of the mail standards mean that if mail doesn't arrive the sender will be informed, but in practice if you get the username slightly wrong the mail may well end up being delivered to a default recipient for the domain, which is generally someone who gets more mail than he can read and has a habit of deleting it with at best a cursory glance. If you get the domain wrong you might be told when your mail server can't find the domain, but if your incorrect name matches a domain that does have a mail server the mail may end up at another default recipient, this time one in another organisation entirely.
If you do get a failure report for a mail you genuinely sent, for goodness' sake read it. The report will say which server generated it, but note that often one server writes to tell you about a problem it had talking to the next one in the chain. The type of error will normally be described in fairly clear English; the most common reasons include:
- Recipient doesn't exist/not recognised
- Check the spelling of the part before the '@' (and that you have the correct contact person).
- Recipient has reached their mail quota
- Contact them some other way and tell them.
- Can't find server
- Check the spelling of the part after the '@'.
- Recipient cannot receive external mail
- i.e. address is for internal use only. Contact them and tell them: check that the address you're using is the correct one, and if necessary get them to talk to their IT department.
If a delivery notice tells you that an error is permanent, don't bother resending the mail unless you find something you can change about it. Otherwise it might be worth resending, just refrain from doing so on such a scale that you'd seem impatient or obsessive if all the mails arrive at once (which is entirely possible).
There you go, enough ranting. I've kept it non-technical but that's most of what regular users should realise about e-mail. If any of my peers (or betters) disagree with any of it, say so and I'll do more research and correct anything that's inaccurate.
Comments