Going beyond the vacation program with dynamic status

Topic: 

I'm back from Burning Man, and this year, for the first time in a while, we didn't get internet up in our camp, so I only did occasional email checks while wandering other places. And thus, of course, there are many hundred messages backed up in my box to get to. I will look at the most important but some will just be ignored or discarded.

We all know it's getting harder and harder to deal with email backlog after travel, even connected travel. If you don't check in it gets even worse. Vacation autoreplies can help a little, but I think they are no longer enough.

Some years ago a friend tried something radical. He had is autoreply say that he was away for 2 months, and could not possibly handle the email upon his return. He said that thus the email you had sent had been discarded. You were told that if it was still important when he returned that you should send it again then. His correspondents were completely furious at the temerity of this action, though it has a lot of attractions. They had taken the time to write an email, and to have it discarded and left in their hands to resend seemed rude. (I believe the reply included a copy of the email at least.)

Worse, because we are always connected, vacation replies sometimes lie. People are scanning their email, responding to the most important ones if they can, even though a vacation autoreply was sent. And so we always hope for that.

I think the time has come for an extra internet protocol as a companion to mail. When you type an E-mail address into your mail client, it should be able to query a server that handles information for that domain -- something like an MX record -- and query it about the email that is about to be written, including the sender address and recipient address, and possibly a priority. If the recipient is in a vacation mode or other do not disturb mode, the sender would be told immediately, before writing the e-mail. They would have the option of not writing it, writing it for delivery at the designated date in the future, or writing it with various tags about its urgency in case the recipient is doing some checking of mail.

This could be an LDAP derived protocol or something else. Indeed it could be combined, when trusted, with directory lookup and autocomplete directory services. It's not easy because often (with things like MX) the server that handles mail for a user may not have a strong link to the user in order to serve this data. In the old e-mail regime of store and forward, live connections were not expected. Still, I think it can be done, and it would not be a mandatory thing.

There are some security and privacy implications here that are challenging:

  • Spammers will try to use this information to confirm addresses or hunt for them
  • This lets the recipient know if somebody just typed in their name to send mail, and when they did so, and thus how long they took to write a mail, or if they aborted one. To avoid this, the directory servers could be trusted 3rd parties.
  • This provides a reliable IP address for the sender's client, or at least a proxy acting for the sender.
  • It could be misused to build a general database of many people's vacation status, invading their privacy, unless there are tools to prevent broad spidering of this sort.

Mail servers would remember who queried, and in fact it might be encouraged to include a header in the email that came from the query, to officially tie them together. This would allow clients to know who queried and who did not, giving priority to messages which came from people who queried and acted upon the result (for example waiting to send) over those who just sent mail without checking. Users could get codes that would allow them to declare the message higher (or lower) priority that would not be available to those who just did plain SMTP.

Mailing lists might also make use of this data, and the response could tell mailing lists what the user wants to do, including temporarily unsubscribing until a given date, or asking for a digest of threads to be sent upon return, or other useful stuff. Responsible corporate bulk mailers could also accept that you don't want customer satisfaction surveys or useful coupon offers during your vacation and just not send them. Ok, I'm dreaming on that one, perhaps.

For security, it could be that only past correspondents could do this query, or only users with some amount of authentication. Anonymous email and mail from strangers would still be possible, but not with a pre-query. The response could also be sent back via a special email that servers know to intercept, so it can't be used to gain information that would not be gained by mailing a person today. (You could get a report of people who queried you and never mailed you when not on vacation.)

We might see some features in mailers, like a pop-up in your mailers that says, "Brad just started writing you a message" the way instant messaging programs do. I am not sure this is a good idea, but it would happen. Readers: what other consequences do you see happening?

Comments

Exchange has some of these features within our corporate email.
I see the vacation response floating on my screen whenever I add an addressee who has an auto-response configured.
It is pretty nice.

It's been in corporate or private email networks for a while. I am proposing we need this as a general function in E-mail, to help us deal with the e-mail glut -- and not waste our time writing emails to people who aren't there.

While this problem is annoying, it's not serious enough to get the required effort behind a necessarily complex solution. Any solution that had a chance of being adopted would need to provide many other improvements to mail as well, prime candidates being the features available only in Exchange-like private email systems. For instance, I still miss my 1970s ability to withdraw an email that I've sent and hasn't yet been read; it's 2013 now. I'd appreciate next-generation mail protocol(s).

I actually think the problem of getting overwhelmed with mail is a huge one, and it is vacations/trips which show this problem most strongly, because send it over the cliff. The goal here is only partly to save people the time of writing you just to get a vacation response, it's to make it possible for them to manage their inbox when they return, and focus only on priority items while doing occasional mail checks while on the road.

This is not a big re-architecture, fortunately, the way revocation of an E-mail would be. Indeed, it could be built as an independent service without changing servers much at all (though clients would change.)

I think it would get quick adoption because it would be pushed by the vacation autoresponse that goes out to people who didn't query first. They would get a response saying, "I'm away, blah, blah, and you would have known that before sending your email if you were running a new client, and your mail would get appropriate priority. I read mails from people who used the new protocol FIRST, and I get to mails from older clients later, when I get back."

As for other mail functions, revocation has always been very difficult. The reason is that with a distributed mail system (like SMTP) an attempt to cancel an e-mail is actually a red flag that the e-mail may be particularly interesting! E-mail cancel worked only on private email systems where the system the user is reading mail on can hide things from the user.

It has a number of other challenges, even there. For example, even though reading receipt is supported in many mailers today, people dislike it and sneak around it. We used to do that even on private email systems 30 years ago. It is a privacy violation, and one problem with cancel is the question of what to do with a cancel on a message that's already read? If you tell the sender, "You can't cancel that, they already read it" that's a privacy violation too.

But I do agree it's time to think about a re-architecture of SMTP e-mail to deal with the always connected world where live queries can be done. But it still has to support many of the features of store and forward mail such as:

  • The sender can't tell when you read the e-mail (this is why most mailers don't fetch images by default.)
  • You must be able to have another server act as relay for you (via MX)
  • You want to work as fully as possible when offline (such as on airplanes.)

Add new comment