Email should have Expiration Dates
The entire idea behind this blog post has been summed up in the title, so all I need to do now is to explain why I think email should have expiration dates, and how that would make personal information management better.
Email, as we all know, started off as a way of sending short messages to colleagues within a department. It has since evolved into a monster of a tool that does everything it was never designed to do. The paradox is that it is exactly the kinds of messages that email was designed to handle that cause me the most trouble these days.
- I often receive email from my friends about meeting up for lunch. This is important, but only for that particular day (and that too, if I receive it before lunch time).
- My research collaborators send me email when a paper submission deadline is near, with the draft attached to it. Those emails are not nearly as important after the deadline.
- My friends and I exchange travel plans over email, but is it as useful after the trip is done?
These are the kinds of messages I’m talking about: important but time-sensitive. Then there are others which are not really important, but simply one-time notifications that I can take action on and then forget (“bill is due in 2 days”, “X added you as a friend”, “your order was received”, “your package has shipped”, “free donuts in break room”, “we are not meeting today”, etc.)
Why do they linger on in my mailbox for years? They become indistinguishable from the really important email that I need to save for years, such as some very interesting and intelligent discussions I have had with others. Note that I’m not including spam in this discussion, because in my opinion, there are adequate spam-filtering tools circa 2008 that perform well enough for most users for the most part with an acceptable false positive rate. Not perfect, but acceptable.
The Keeping Problem
Email is no longer ephemeral — people hold on to their email for years. This is what results in the Keeping Problem in Personal Information Management: there is so much of information coming at us that we don’t want to spend the time to decide what to keep and what to trash, so we end up keeping all of it. We hope we never have to do spring cleaning, and instead rely on search to find what we want.
Filing is not the answer
Many people file and tag their email, but the question is, is the cost of doing so (time as well as attention) worth the payoff at the end? Consider the two alternatives: spending 10 minutes each day filing your email, versus spending an hour a month looking for that one email. Pretty soon, the second alternative starts looking better while swimming in a sea of email with no signs of abating.
Same needle, bigger haystack
The bigger the haystack grows, the harder it is to find the needle. The solution is to reduce the size of the haystack. Automatically. Most other solutions empower the user to filter, sort, file, tag and do other sorts of things to their email that do not scale very well. That’s where Email Expiration Dates come into play. For it to work, they need to be (1) defined and (2) honored.
Defining an Email Expiration Tag
Email expiration tags can be defined in several ways by several entities that handle the email message at some point of time in transit.
- By the sender of that email who cares about the recipients;
- By the email client (MUA) used by the sender, automatically inferring from certain common-sense words; e.g. subject contains lunch and body is less than 100 bytes;
- By the email server software that intelligently tags email based on common patterns seen across multiple users;
- By the recipient’s email client, based on heuristics;
- By the recipient’s email client, based on a user-defined rule set;
- Or explicitly by the recipient in a spring cleaning session.
Honoring an Email Expiration Tag : Fully standards-compliant
RFC 822 allows custom tags (Sec. 4.7.5). These are commonly referred to as X- headers, since the specification requires that all such tags be prefixed with “X-”. Many applications built on email make use of such tags: mailing lists use the X-List-* headers to specify the list name, subscribe URL and unsubscribe URL in a mail message. Spam filtering software such as SpamAssassin assigns a score to each email, saved as an X- header. Mail clients are free to interpret these tags as they see fit.
An expired email will not be automatically deleted if the user does not want it to be. This is important for archival purposes and to satisfy the stringent reporting requirements of the Sarbanes-Oxley Act. But now the user can make a one-button choice about whether or not expired emails be deleted, archived, moved away or kept around.
With help from legitimate bulk email senders (not spammers)
Bulk mail such as Facebook notifications could have expiration dates set to “one week after receipt”. Bill reminders could set the expiration date to be “2 days past deadline” (and then send another notification if payment is not received by then.) Donut announcements could expire at the end of the day. Talk announcements could expire at the end of the talk.
Fixing the post-vacation blues
Returning from a vacation is no longer refreshing, as we are thinking about the sheer volume of email we need to process once we get home. If I was on vacation when the donuts were on the table, I should not be bothered about it when I return. Go away! If it’s an invitation to a talk that happened while I was away, I don’t need to hear about it now.
What will it take for adoption?
Defining a standard is no use if it isn’t used. The best way for such a solution to be adopted is for a major email provider implement it themselves, perhaps in a limited beta? On the interface side, this requires two additions: one for sending, one for processing received messages. The widget at the sender’s end is simply a calendar picker, or a drop-down with relative dates (“tomorrow”, “next week”, etc.) At the receiving end, it’s a three-way radio button that lets users “Delete”, “Archive” or “Leave alone” expired messages.
Till then, it’s back to manual spring cleaning. Oh well.
Acknowledgments: I have had several stimulating discussions with my advisor, Manuel Pérez-Quiñones, and my colleague, Pardha Pyla, about our respective email filing strategies, (that mostly began as venting sessions). This idea no doubt borrows from my analysis and conclusions based on some of those conversations.
I second this. Pretty detailed post :) I suggested this some time ago to GMail but i don’t know if they’ve really read it. This would also be useful with an issue management system (e.g. Google Code). If an issue appears with a project and someone fixes it, all the others won’t need to even see it in the mail box.
Teo — November 3, 2008
I understand the problem you’re trying to solve and I believe that you offer a reasonable solution, which I happen to completely disagree with.
Just to be clear, my understanding of the problem is that we have a deluge of email, a lot of it irrelevant after a certain period of time and you would like your client, or the “email system” per se, to automatically repriotize such email so you don’t usually care about it.
Your solution only solves part of the problem: as long as providers recognize that almost all email going out through their system – facebook meetups is a great example – is time sensitive, they can tag their email and your client can ignore it after a certain amount of time and so on.
However, this completely ignores the bigger problem – when your friends are setting up ad-hoc lunch dates, they are not going to be tagging their email with expiration. This requires intelligence on the part of the server or the client to figure out that this email probably doesn’t matter after a certain period of time.
And that, I think, is the true solution. Build in simple clustering rules that learn how to cluster email – source clustering is trivial, so you get all email going to / from lists clustered nicely. Clustering on some keywords like lunch and dinner is pretty trivial as well. I’m not a machine learning expert by any means and I would imagine that this is just as difficult as the spam problem, but luckily we don’t have to get it completely right since getting an annoying lunch mail or two that you shouldn’t have gotten is fairly easy to ignore.
Rushabh — November 3, 2008
Hey Rushabh, good to hear from you! I thought I already covered your concerns under “Defining an Expiration Tag”, bullet #2.
I think the only difference between our proposals is a level of indirection. My proposal places the Expiration Tags between the clustering phase and the doing-something-about-it phase. The tags allow extensibility on both sides — you can add more rules, or do it manually, or any other way. On the other end, once a tag is detected, the MUA can decide how (or whether) to act on it.
We already have mail rules, and I think they fit very well as a source of Expiration Tags, but we need to go beyond just rules. One example of where I feel clustering by mailing list isn’t working correctly: on academic lists such as those for all Grad Students, I see traffic that covers the gamut from “donuts in break room” to “interesting talk at 4:00pm” to “so how do I solve this really intractable problem”. I wouldn’t want them to end up in the same bin though they were posted to the same list.
Manas — November 3, 2008
Love it, where do I sign up for this? We can start it by defining rules in our email clients that look at this particular header and move the files to a folder. Lets do it…
Manuel — November 4, 2008
Manas, I think you hit on an important issues here. I love what you are proposing and the rationale behind this idea. Like you suggest, the expiration date can be set by the sender, receiver, or mail client (some sort of rule-based decision making).
I am thinking something along the lines of how Mail provides suggestions for iCal events by parsing dates embedded in the message body. So when there is a date in the text, it would be great if I can say delete this email n days after this date.
Sign me up for any prototypes/ideas you come up with. I would love to try it out. Anything to help manage my increasing quantities of email is a hit in my book.
Pardha — November 5, 2008
sounds like a good idea. I do tag n file my email like you mentioned and prefer using advance search options when it comes to finding something. But I do let it archive after 6 months
Shailen — November 9, 2008
btw.. some issue with your website on ie6. Dates are out of the date image, ads on the top push the first post after ads and the comment box spans beyond the scope of the slider.
Shailen — November 9, 2008
I stopped caring about IE6 a long time ago. :) Just get Chrome, Safari, Firefox (or if you can’t help it, IE8) and ditch IE6 already. The entire web developer community will thank you for it!
Manas — November 9, 2008
I see the problem as who will bell the cat!
By the sender of that email who cares about the recipients;
The last thing I want is my bank sending me my monthly statement and putting an expiry date on it. Then I have to pay them to retrieve my 3 year old statement that I could have got by searching my mailbox.
By the email client (MUA) used by the sender, automatically inferring from certain common-sense words; e.g. subject contains lunch and body is less than 100 bytes;
Hmmm, when was the last time you trusted your MUA to act intelligently, especially with purging stuff. Even your mail identified as Spam is still dumped in your mailbox so that you can review it.
By the email server software that intelligently tags email based on common patterns seen across multiple users;
The whole point of the internet is that people have individual preferences and you do not find patterns with a lot of accuracy. Case in point, Amazon/Ebay recommendations. They are perhaps one of the most advanced algorithms in use, but I doubt if their accuracy is anywhere near 90%.
By the recipient’s email client, based on heuristics;
Same problem as with point number 2.
By the recipient’s email client, based on a user-defined rule set;
Isn’t that what you call filters for your favourite MUA?
Or explicitly by the recipient in a spring cleaning session.
Isn’t that the same as manual sorting?
Rohit — November 10, 2008
being on the office laptop kinda stunts me from installing other browsers with full functionality like flash and the other stuff. So I stick to ie6 :P
Shailen — November 10, 2008
Regarding email expire headers, there is also this: http://www.ietf.org/internet-drafts/draft-welzl-expires-00.txt
Mason Lee — November 27, 2008
I found your page because I had the same exact thought. I get a lot of email from the many lists I am on and it would be nice if they would just “expire” after a while. One example is pizza chains. Always sending out specials and coupons. If they had an expiration date encoded into the email the receiver would not have to even see the email any longer once the deal has ended.
Ron — July 1, 2011
Is it done yet:-)
I too found your post because I was searching for something that would do this. I think the pizza company could be motivated to use this feature if people unsubscribed otherwise. I do think that most reputable companies, i.e. The ones you sign up for mailings with do unsubscribe you, and many ask why.
The clinet would need a lot of configuration though so Im not sure using this feature would be within the capability of most users.
Sarah — December 1, 2011
It’s finally ready! (Well, it has been for a while, but I forgot to post here.) It’s still fairly complex to setup, but it’s here: https://github.com/manastungare/timebomb
Manas — July 26, 2012