In Part 1, I explained how the “Date:” header of an email is actually the “sent date” and introduced a couple of issues with how the sent date is created by different email clients. Now in Part 2, I’ll give a similar rundown of the problems with the received date, starting with a nod to the the title of this series of posts by telling you there is no such thing as a received date.
That’s right – it doesn’t exist. The format of all Internet mail, as it goes over the wire (or over the air, whatever) is specified by RFC-2822 – the standard Internet Message Format. It defines the structure of a message, including the various header fields you may be familiar with, like “From: ” or “To: ” or “Subject: ” and many more that you may never see. The point here is that RFC-2822 does not define a header field for a received date, and this is a problem because then every email client application is free to interpret and create a received date pseudo-header which may not map to any other email client’s interpretation.
For example, Mail for Mac OS X uses the date found in the top (last written) “Received:” header as a received date. It’s a novel approach because it doesn’t require the injection of proprietary non-portable headers like “X-Received-Date:”, but the date it is using is when the last mail server in the delivery chain received the message. Specifically, it is not the date that the email recipient saw or even read the message. The email could have a received date of today, even if you don’t check your email for the next week!
Other email clients will do effectively the same by asking the mail server for the date of receipt, or they will try to derive a received date based on when the message is first “seen” on the server, or the time of actual download from the server (if it is downloaded at all vs. just viewed on the server), or the time that the message was read.
So, when you send a message to multiple recipients, although it is to be expected that they will all receive the message at different times, unless they are all using the same email client configured the same way, chances are they will all have received dates that reflect different events. This all makes answering questions of “Who got it first?” or “When did they read it?” very difficult.
More importantly, from the standpoint of email migration, because there is no standard for a received date, after moving messages to a new email client you may lose all “received date” information. In this case, you can always fall back to the “sent date” for sorting by date.
Why do email clients try to show a received header at all? Well, it’s convenient, and I can only assume that end users asked for it. People like to process messages in the order in which they arrive. Does “sent date” work for this too? Yes, mostly, but because messages may arrive in an order different from how they were sent and email can sometimes take hours to days to be delivered, when processing your inbox you would have to check back in the list every now and then for new arrivals.
I think that last point is crucial — the received date was introduced on the client side as a convenience and not as trace information. Treat it accordingly.