Wandering Thoughts archives

Our self-serve system for 'vacation' autoreplies and its surprising advantage

In the old days, it was just broadly and tacitly assumed that everyone around here could and would learn (and use) Unix to get things done in our environment, and so we could provide services purely through traditional Unix command line things. This has been less and less true for years, and so there has been a slow drive to provide access to various services in ways that don't require logging in and using a shell. One of the traditional painful experiences for people was setting up a vacation or out of the office autoreply for email, because the traditional Unix way of doing this involves editing your .forward to stick in a magic vacation command, or going even further to use procmail to filter some things out before you run vacation. This became not very popular with our users, and the Points of Contact spent a certain amount of their time helping people deal with the whole mess.

So, many years ago (it turns out to be just over a decade), we added a special feature to our Exim configuration to handle this automatically. If you had both $HOME/.vacation.msg (with your vacation message itself) and the magic flag file $HOME/VACATION-ACTIVE, our central Exim mail server took care of generating the autoreply for you. If you removed VACATION-ACTIVE, this stopped. Later we added a little web CGI frontend so that you could write your vacation message in a HTML text box and toggle things on and off without ever having to touch the Unix command line.

Perhaps unsurprisingly, this feature has turned out to be quite popular. Almost no one runs vacation from their .forward files any more (either directly or through procmail); pretty much everyone uses the VACATION-ACTIVE magic, even people who are perfectly familiar with Unix (and I can't blame them, it's a lot easier than fiddling around with .forward).

It turns out that there's another advantage, one that we hadn't really noticed until recently, which is that how autoreplies are generated is under our full control. The program or script that gets run, the arguments it gets run with, and any filtering it does on what gets autoreplied to are all ours to both decide and change as we need to, because the users just tell us their intention (by creating the files) instead of specifying the mechanics, the way they would be doing with .forward files. We don't even provide an officially supported mechanism for controlling how frequently people get autoreplies; instead it's officially just some appropriate interval.

(For a long time this was not something we needed and so we never really noticed it. For reasons beyond the scope of this entry, changing parts of how our autoreply system works has become necessary, so I'm suddenly very happy about this advantage and how many people use this system. The few people who still use vacation through .forwards are going to be harder to deal with.)

Sidebar: The mechanics of this in Exim

The important mechanics are an Exim router and a transport to go with it. The guts of the router are:

user_vacation:
  [...]
  driver = accept
  transport = vacation_delivery
  check_local_user
  require_files = $local_part:$home/VACATION-ACTIVE:$home/.vacation.msg
  unseen = true
  [...]

The important bit is the require_files directive, which checks for them (as the user, because of NFS permissions issues).

The core of the transport is just:

vacation_delivery:
  driver = pipe
  [...]
  command = /our/vacation/command $local_part
  [...]

(I have left out various less important and more obvious directives.)

If you do this, you'll need to decide whether to do your filtering on what email doesn't get autoreplies in Exim, in the vacation command you run (possibly with the help of information passed from Exim to it in environment variables), or both.