There is no such thing as a “received date”. Not in the standards, anyway. Is this a quibbling technicality? An omission?

Nope. And I’ll tell you why. Why? Because the date of a message matters. It matters more than it probably should, with the advent of email forensics, being that the date is inconsistently defined across email clients, and being that it is easily forged. Still, the date of a message is good enough for most purposes, as long as you understand what it means and where it came from.

First, let me tell you that the “Date:” header field in the RFC-2822 header of every message is the “origination date” field. From section 3.6.1 of the specification:

“The origination date specifies the date and time at which the creator of the message indicated that the message was complete and ready to enter the mail delivery system. For instance, this might be the time that a user pushes the “send” or “submit” button in an application program. In any case, it is specifically not intended to convey the time that the message is actually transported, but rather the time at which the human or other creator of the message has put the message into its final form, ready for transport.”

Note there is significant leeway given here to what event the Date field can represent. In practice, this date is usually when the user hits “Send”, but I’ve seen it also implemented to be the time of message creation — even if the message is sent days later. I argue the latter case is an incorrect usage of the Date field, but that doesn’t stop it from happening.

Now consider if there is an error the first time I hit “Send” — or if it takes a really long time to send. My point is that it’s difficult to build a science around the meaning of this Date. All you can really derive is that the Date header represents when the sender intended to send the message.

True, it often does has some correlation to when the message was actually delivered to a mail server for delivery, but its frame of referential consistency is extremely limited. What I mean by that is that if you were to sequence the messages of multiple users — or even the same user who uses different email accounts or email client programs — the sequence could not be considered scientifically sound. At best, you have a sequence of intents, not events.

I’ll talk more about the Myth of the Received Date and how some applications choose to derive a date of message receipt in Part 2. In the meantime, try a few experiments yourself to determine how accurate the Date header reflects what you consider to be the “sent date” of a message. I suggest trying this with accounts on different domains or even different hosting providers and with different email clients.

Tagged on:

2 thoughts on “The Myth of the Received Date – Part 1

  • April 8, 2009 at 4:26 pm

    I had an untested repair guy try to debug my aol email so that I could discover 14 months of missing email (Never saved) I ok’d him to burrow deep into my system and try to duplicate what a CIA guy looking for who and what I would communicate about to bad guys, since every key stroke on a computer is viewable.

    I sense he f*ed up my start up….how can I stop disk warrior and aol from starting up every time I log on to my system. How do I discover who he’s directing my communication to?

  • April 8, 2009 at 8:15 pm

    Because you mention Disk Warrior, I’ll assume you are talking about a Mac system. Go into System Preferences, click on “Accounts”, click your ID and then click the “Login Items” tab. There you will see what apps are being launched at startup. Turn off any you don’t think you need. To look for unexpected outbound communications from your computer to points unknown, try the utility called Little Snitch by Objective Development.