We have a small e-mail server running on Debian GNU/Linux. All users are local (in /etc/passwd), have mail delivered via procmail to mailboxes in /var/mail and can access it with POP3, IMAP or squirrel-mail webmail. Pretty standard, simple setup which works quite well. The only thing missing was an “out of office responder”.

The standard and simple setup would be to use the ‘vacation’ program. However, this was not suitable. The users don’t have shell access to the server for security reasons. And even if they did, they wouldn’t be able or willing to use SSH to log on and type commands. Let alone use vi to edit the actual message. We needed to come up with something more user friendly.

The idea was to have something which would:

  1. plug in easily to the existing infrastructure of local users, Postfix, procmail and
  2. be user friendly.

We evaluated a couple of existing options, especially phamm and gnarwl. They all fell short, because they were too complex.

Phamm stores users in LDAP and uses postfix virtual domains to deliver e-mail to some other component, completely replacing procmail.

Gnarwl also uses LDAP but then delivers e-mail to local mailboxes with procmail. Unfortunately, while testing it, we couldn’t get it to work at all and the debugging was not helpful at all. Even looking at the source code didn’t help to find out why it didn’t work.

So, decision was made to create a new solution.

The workflow of the new system is simple:

  1. Postfix delivers e-mail to local user via procmail
  2. Procmail pipes a copy of the e-mail to a newly created component – responder.
  3. The responder parses the message, finds out whether a reply message is needed and if so, it creates and sends one.

We also need some data storage to store information about users and their out-of-office message. We also need to store data about who did we already sent our reply, so they only get the message once and not for every e-mail they send.

There already was a MySQL server running on that machine so we decided to store the data in a MySQL database. We created two tables – User and KnownSender.

+------------------+--------------+------+-----+---------+-------+
| Field            | Type         | Null | Key | Default | Extra |
+------------------+--------------+------+-----+---------+-------+
| login            | varchar(255) | YES  |     | NULL    |       |
| password         | varchar(255) | YES  |     | NULL    |       |
| vacation_active  | tinyint(1)   | YES  |     | NULL    |       |
| vacation_message | text         | YES  |     | NULL    |       |
+------------------+--------------+------+-----+---------+-------+
+--------+--------------+------+-----+---------+-------+
| Field  | Type         | Null | Key | Default | Extra |
+--------+--------------+------+-----+---------+-------+
| user   | varchar(255) | YES  |     | NULL    |       |
| sender | varchar(255) | YES  |     | NULL    |       |
| date   | datetime     | YES  |     | NULL    |       |
+--------+--------------+------+-----+---------+-------+

Then we implemented the responder component. It is a perl script using DBI for database access and Email::Simple for parsing and creating e-mail messages. We needed to get some more perl packages from cpan related to Email::Simple but that is very simple.

use DBI;
use Email::Simple;
use Email::Simple::Creator;
use Email::Send;
use Email::Address;

The responder is actually quite clever. It doesn’t respond to spam because junk filtering is done beforehand with spamassassin. It only responds to messages directly addressed to us to avoid sending replies to mailing lists etc. As we mentioned before, it only sends one reply to one address. It also does some other sanity checks – doesn’t respond to messages from mailer-daemons, mailing lists, or other vacation responders.

We plugged it in with an entry in global procmailrc:

DROPPRIVS=yes
:0cw
* $^To:.*< $LOGNAME>
* !^FROM_DAEMON
* !^X-Spam-Status: Yes
|/opt/smuooor/responder.pl

When the responder was done and tested, we needed to implement the user interface. There were several choices. We could do a stand-alone exe application to connect to the MySQL database. Or even better a stand-alone web application. Or we could use an existing deployed user interface for e-mail – the webmail application. Users were already accustomed to use it and if done properly, it would provide authentication so there was no need to remember another password to change your out-of-office message.

In our case, it is squirrel mail. It turned out that it has a nice plugin possibilities, even with some examples so implementing a simple plugin in PHP, with just one database connection and an HTML form was quite simple.

smuooor-shot.PNG

You can download the finished product here: smuooor. It is released in public domain (no copyright, no warranty).

Leave a Reply