The hat industry was one of the casualties of the latter half of the twentieth century.

As servicemen demobbed and women’s hairdressers promoted the perm, hats were cast aside and we more commonly walked out bareheaded. Despite this loss of thousands of jobs, and whole trades such as milliners, phrases referring to hats remain firmly ensconced in the English language: none more so than referring to the wear of many hats, indicating the many roles that each of us has.

We quickly become used to receiving post addressed to “The Parent of” our children, “The Occupier of” our property, and so on, as well as variants of our name according to whether it is the Inland Revenue or Aunt Ethel who is writing to us – each a different role or hat.

One of the great unsolved problems with email is how to support such multiroling in addresses and mailboxes. Two approaches seem popular: use multiple email accounts (addresses) but dump everything into single mailboxes, or have one mailbox per account.

Neither is a good solution, and mixed measures are even messier. Let’s say that I am the Chief Brim Designer at Hot Hats, with a working role email address of cbd@hothats.co.uk and a personal address of h.oakley@hothats.co.uk. If I manage to keep my role and personal email separate in two different mailboxes, when I move to the Boater department, I can leave cbd to my successor, assume a new role address of boaters@hothats.co.uk, and take my personal address with me.

That is perfectly logical and impeccably clean on paper, but in practice running two, three, or more roled mailboxes gets infernally complex, even with the superior interface available in Apple’s Mail. Combine them in a single virtual mailbox, as Microsoft Entourage used to, and they quickly become merged and muddled. Moreover, each email address attracts its own trickle of spam and other junk, so the more addresses you have, the more detritus you must wade through.

Email messages are delineated in an antiquated (1982) Internet standard known as RFC 822, and define 25 different fields of metadata that can be used in email headers.

Of those, only three are required: the date, sender’s identity (From), and the primary recipient(s) of the email (To). Any number of user-created labels or metadata can be supplied, their field names starting with ‘X-’, commonly including X-Mailer revealing the name of the email client used to send the message, junk mail scores in X-Junkmail-Status, and others.

RFC 822 and the design of email metadata need to be revised in the light of developments in the last quarter century.

Metadata in email header fields offer an excellent opportunity to assign different roles to the recipient, allowing mail servers the chance to sort and redirect incoming email according to those roles.

I could thus keep a single address of h.oakley@hothats.co.uk, swapping roles from cbd to boaters, so that once I have changed jobs, email tagged for cbd could be automatically redirected to my successor in that role. This would spare me having to send out hundreds of emails informing all my contacts of my new role address, and forwarding mis-addressed emails to my successor.

For all its success in transforming much of business, at its heart email is painfully primitive. If it is going to remain a primary tool, it needs to change with the times, or it could find itself going the way of the hat, as some have recently claimed is happening.

Updated from the original, which was first published in MacUser volume 25 issue 18, 2009.