weird kid software

Dealing with the prospect of a “digital dark age” is one of the reasons why we built Emailchemy, but I’ve found that many have trouble with this new term because they may not be familiar with the definition of the original. The term “Dark Ages” refers to a time period between the fall of Rome and the Age of Enlightenment, and historians often referred to it as “dark” because there is little in the way of contemporary written history or literature.

The concept of the “Digital Dark Age” is similar, in that through the use of proprietary file formats we may be setting the stage for a future Dark Age because we will no longer have the legacy technology required to read those proprietary file formats.
… Read more

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!
… Read more

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.”

… Read more

I think the title says it all, but the problem is bigger than that. The whole idea that the last 3 or 4 letters of a filename are an indication of underlying file format and structure is flawed. More than flawed, it’s wrong, but 3 decades of MS-DOS (yes, it’s still part of Windows) and its usability nightmare known as filename extensions is hard to overcome.

Interestingly, I don’t blame Microsoft for this particular confusion though, since it was Apple that broke the generally accepted, or de facto, standard in this case.

With the release of OS X, Apple introduced a new kind of file — or really a folder that acted and looked like a file to the user — called a package. The idea was that the insides of certain folders were only for system usage and should be hidden from users. For example, applications and all the various libraries and resource files and executables were packaged into a .app folder. To the end user, this .app folder looked and acted like a standard file and it could be double-clicked to launch the application. Early versions of Mac OS X even hid this package extension from the user, but to this day, to see the contents of a package, you have to “right-click” or “control-click” on the package and select “show package contents” to see what’s inside.
… Read more