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

November 6, 2018

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.


Comments on this page:

From 104.195.208.125 at 2018-11-07 17:57:32:

Do you think it will ever be possible for you to move to a non-homedir-based mail server at all?

By cks at 2018-11-09 00:01:42:

This is such a good question that I wound up writing an entry about part of the answer, about why I now think we should stick with our current setup.

As to whether we could move away, it's probably always going to be a political question because I suspect we'll always have some number of people who use .forwards and other things that would have to be abandoned in an IMAP-only environment with an inaccessible mail server.

The one thing that would force our hand is if we could no longer get mail server and IMAP server software that supported our current setup. But that seems unlikely; Exim, Postfix, Dovecot, and so on are all well established and look like they're going to be around for decades to come. And if they stop being available or viable, I suspect we'd be in a world where we couldn't run our own local mail system at all and would have to move everyone over to the big university-wide cloud-based email system.

From 104.195.196.168 at 2018-11-09 06:54:06:

For server-side filtering, see possibly:

Written on 06 November 2018.
« rate() versus irate() in Prometheus (and Grafana)
What email messages to not send autoreplies to (late 2018 edition) »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Tue Nov 6 23:32:09 2018
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.