Home — Manas Tungare

Home → Blog → Page → Home

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.

HOWTO Obtain metadata for a book given its ISBN using Amazon Web Services in PHP

This is a quick snippet I put together for an academic project. To be able to write this, I had to go through several documentation resources, for what is essentially a single web service method call. I figured it would help if I shared my PHP code.

Setting up WebDAV on Leopard

The good news is that all the bits and pieces of software that you need to run a WebDAV server on Mac OS X 10.5 Leopard are already installed. You only need to configure them correctly and turn them on. Some experience with Terminal is preferred, and you should be familiar with executing UNIX commands. Let's start!

Start Apache. (If you haven't already) You will need to enable Web Sharing, since the WebDAV service will be provided by Apache, the web server on Mac OS X. You do not necessarily need to have a web site running, but you will need to activate and run Apache. Go to System Preferences > Sharing, and turn on the box labeled Web Sharing.
Enable WebDAV support in Apache. Edit the file /etc/apache2/httpd.conf, (remember to use sudo to edit it) and locate this line:
```
LoadModule dav_module libexec/apache2/mod_dav.so
```
Make sure it is not commented (there should be no "#" at the beginning of the line.) Then locate this line (towards the bottom of the file):
```
Include /private/etc/apache2/extra/httpd-dav.conf
```
Again, make sure it is not commented out. It is disabled by default, so you need to remove the "#" from this line.</li>
Configure WebDAV. Next, edit the file /etc/apache2/extra/httpd-dav.conf. Add a section in it to create our new WebDAV share. Here's what the new section should look like. As a security precaution, you should also go ahead and delete the /usr/uploads share that is set by default.
```
Alias /webdav "/Library/WebServer/WebDAV"
```

Free as in freedom, not as in beer

I received a request today in the mail about one of my projects that is available under a free software license. It's a web template system that I wrote to scratch a personal itch. Its hallmark feature is that it has no features, at least none that contribute to the bloat that's rampant in Drupal and Joomla and their ilk.

His email was very well-written, asking about some of the specifics of the license, and how he could undertake projects for his clients building upon my framework. After I wrote a detailed reply to him, it seemed like a good idea to post it to my blog, for there are many who're not particularly clear on how free software licensing works.

I want to use your templating system to build static websites for personal and commercial projects. I don't have lots of money so I can't promise much now but later if I will be able to make any money I will happily donate for this project.
[...]
I like open source projects because it is fun to learn how magic happens. I don't want to use your code without permission because I just personally don't think it is right thing to do. I have no problem giving you credit for this system but I need your permission to use it for commercial use?

Sincerely,
[redacted]

And my reply:

Hi [redacted],

I'm glad you found the site and my projects interesting and useful, and thanks so much for writing back to let me know!

I think free software is a great way to learn and understand other people's code, that's why almost all of my projects are open-source with the license to tinker and play. All I ask in return (via the Creative Commons license) is attribution back to me if you use it in a project. I've licensed this as an Attribution-ShareAlike-Noncommercial license, so you're free to use it as you wish in any personal project as long as it is non-commercial: e.g. for an organization you belong to, or an academic department or program.

Things get a little more interesting when money enters the picture. While I'm not doing this (releasing my software) for the express purpose of making money from it, it does not seem right to me that someone else benefit financially from my work with no benefit to me. So, I politely ask that if you're planning to use this commercially, you should contact me for a separate license (the code will then be dual-licensed, and you can pick either the paid commercial license, or the default un-paid non-commercial one.)

You don't have to pay anything right away, and can play with the code as much as you want. But when you bag a client who wants to use a system based on my code, we can talk about royalties. That way, you retain the freedom to examine and modify my code as well as get a paying client, and I do not feel that someone has taken undue advantage of my generosity. This is how the open-source model was intended to work, and the free really refers to freedom, not free as in no-charge.

I'm glad you contacted me to check for permission first, and I got the opportunity to clarify. Often it's quite tricky, and lots of people have lots of misunderstandings about how free software licenses work.

Regards,
Manas.

SSH Port Forwarding on Mac OS X

After spending about an hour configuring what should, in theory, be a simple matter, I figured I’d write a blog post that might one day save another soul an hour or so from his or her life. So, for good karma, basically. In the past, I have set up port forwarding on Linux, Mac OS X and Windows, so I was a little worried that it took me about an hour trying to appease the SSH deities (and daemons).

« Newer Older »