Helping people with computers... one answer at a time.
Counting on email being almost instant is probably a bad idea. Email is designed to tolerate many delays, and delays do happen.
When someone sends me an email I don't get it right away - sometimes it takes hours. It is time stamped hours before I actually get the message. Could it be because my inbox is too full?
We've all gotten so used to email being an almost instantaneous communications medium that we really notice when there's a delay. The fact is email delivery can be delayed for many reasons, and counting on it to be nearly-instant is just a bad idea.
Couple that with the fact that the timestamps on email often lie, and it can be really difficult to understand exactly what happens when email takes a little too long.
When mail is sent, it may travel across multiple servers. The sender's email server and yours, of course, but it's also possible that several mail servers may also be involved, each one receiving the mail, and then passing it on to the next server along the route. There's actually no requirement that those servers operate quickly, or in any timely fashion. In fact, if they're overloaded with mail, spam or other things, they could simply be slow - and technically that's ok.
In fact, in most cases of delayed email, it's simply due to one of the mail servers along the way being overloaded and running slow - most frequently due to flood of spam. Naturally there are other potential causes for delays, including even how often you check your mail. And delays could be minutes, hours, or in worst case scenarios, even days.
A full mailbox is typically not a reason for a delay. For most email services, if your mailbox is full, the message is returned to the sender indicating that it could not be delivered. On rare occasions, it might also simply be discarded. Now, the sender, on getting that notification could try again, and if you'd made room in your mailbox since the first attempt, the mail might be delivered. Depending on how long all that took, it could look like a delay, but it definitely wasn't automatic. The sender had to take steps to re-send the mail.
One thing that can make things very confusing to you as the recipient of email, is that the date and time displayed on the email are, usually, the date and time on the sender's computer. If they have that date and time wrong? Doesn't mater - that's the date and time that shows up on the email. If you've ever seem email (particularly spam) "from the future", that's often what's happened. The clock on the computer sending the email is set wrong.
If you examine the mail headers of a message, you can see the date and time that each mail server along the way acted on the message. The header will have a series of lines that look similar to this:
Received: from bay107-f18.bay107.hotmail.com (HELO hotmail.com) (220.127.116.11) by pugetsoundsoftware.com with SMTP; 13 May 2005 21:33:53 -0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 13 May 2005 14:33:53 -0700
It's important to note that each timestamp also includes its time zone designation. In this example "21:33:53 -0000" recorded by the first transaction is UTC or Universal time (less accurately referred to as Greenwich time.) The "14:33:53 -0700" is the same time, but in the Pacific time zone which, at that point, was 7 hours behind UTC.
In theory, once you account for time zones, you can trace relatively accurately how long mail spent on each server along the way, and thus identify any potential bottlenecks.
However, this has one interesting flaw: it still assumes that everyone's clock is set correctly - including all the mail servers. In most cases this is fairly accurate, at least to within a few seconds, but it's definitely not foolproof.
Comments on this entry are closed.
If you have a question, start by using the search box up at the top of the page - there's a very good chance that your question has already been answered on Ask Leo!.
If you don't find your answer, head out to http://askleo.com/ask to ask your question.