Email is not IM

| 3 Comments
Anyone who has worked with email knows this, but that doesn't stop mail users from calling us and asking why a message is late. But hey, what's yet another example? This describes the mail routing a specific message followed.

Received: from [140.160.12.34] by web120819.mail.ne1.yahoo.com via HTTP; Sun, 20 Feb 2011 17:48:33 PST
Received: (qmail 81576 invoked by uid 60001); 21 Feb 2011 01:48:33 -0000
Received: from [127.0.0.1] by omp1039.mail.ne1.yahoo.com with NNFMP; 21 Feb 2011 01:48:33 -0000
Received: from [98.138.88.239] by tm4.bullet.mail.ne1.yahoo.com with NNFMP; 21 Feb 2011 01:48:33 -0000
Received: from [98.138.90.51] by nm24.bullet.mail.ne1.yahoo.com with NNFMP; 21 Feb 2011 01:48:34 -0000
Received: from nm24.bullet.mail.ne1.yahoo.com ([98.138.90.87]) by BAY0-PAMC1-F6.Bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675);Sun, 20 Feb 2011 19:37:38 -0800
Received: from mail pickup service by SNT0-XMR-002.phx.gbl with Microsoft SMTPSVC; Sun, 20 Feb 2011 19:37:48 -0800
Received: from SNT0-XMR-002.phx.gbl (10.13.104.140) by BL2PRD0103HT012.prod.exchangelabs.com (10.6.4.137) with Microsoft SMTP Server id 14.0.650.68; Mon, 21 Feb 2011 03:37:54 +0000

Normally these headers are read from bottom up, but this is ordered top down. Translated, this means:

  1. A message was sent from a computer on campus via a Yahoo mailer (98.138.88.239) at 17:48:33 PST.
  2. This was processed by another Yahoo mailer (98.138.90.51) at 17:48:33 PST
  3. And again (98.138.90.87), at 17:48:33 PST
  4. It was picked up by the Microsoft mailer (10.13.104.140) at 19:37:48
  5. And forwarded on to an ExchangeLabs server (10.6.4.137) where it came to rest.
Note the nearly two hour delay from start to finish. And yet, the mail shows a timestamp of 17:48 in the mailbox in question even though it arrived much later then that. That's because the Date: field was set by the sending mailer and not modified throughout its travels. In this case, the exact source of the delay is uncertain, it could be a queuing delay on the Yahoo side when talking to Microsoft, or it could be a queuing delay on the Microsoft receiving side. Can't tell from here.

This does show that mail consumers tend to assume two key things:

  1. Mail transit is very fast (where 'fast' can be defined as anything under a minute to up to five minutes depending on the user).
  2. The Date is when it is received.
The fact that mail can legitimately take hours to get to where it is going is not good enough for these users. The fact that it takes less than 5 minutes nearly all the time is really gravy, but it does set the service expectation of the entire email service. So we get grief when the expectation runs against the reality of it.

3 Comments

Oh, wow, yeah, I go through this ALL the time with my users. You know what they like even less? When I try to explain to them that, by definition, e-mail is an unreliable service. It was right in the original RFC, if I remember correctly. Their eyes just bug out at me. If I'm feeling patient, I slowly, sometimes with illustrations, explain how e-mail works. If I do it right, they end up being amazed that an e-mail message ever gets delivered at all!

Next post: Why email is NOT a file storage and/or sharing system...

I think the old IBM mainframes introduced an intentional delay, so mail always took the same amount of time to get there whether the system was heavily loaded or not.