SpamCorral Documentation

1. Installation

The steps to installing the SpamCorral spam handling utilities on a Linux or Unix system, running sendmail and some sort of spam filter, are:

  1. Check that your system meets the requirements.
  2. Configure the spam handling utilities to run the way you want.
  3. Create a spam handler robot.
  4. Configure sendmail to allow forwarding to work.
  5. Set up a cron job to run spam notification at regular intervals.

1.1 Requirements

Before beginning with the installation of SpamCorral, you might want to check that your system meets the requirements listed below:

1.2 Configure the Spam Handlers

1.2.1 Untar the Distribution

You should untar the distribution files to a separate directory where the spam handlers can be built on their own. By default, the tar ball has all of the distribution files in a subdirectory called "SpamCorral-x.x.x". We suggest that you put the spam handlers in a subdirectory off of the main sendmail directory. For example, if you have a main sendmail directory that looks something like this:


  SendMail
  -rw-r--r--  1   93628 Jan 31 13:54 SpamCorral-1.0.5.tar.gz
  -rwxr--r--  1  290418 Sep 19  2001 sendmail-8.11.6-1.7.1.i386.rpm
  drwxr-xr-x 22    4096 Sep 19  2001 sendmail-8.12.0
  -rwxr--r--  1  783911 Sep 14  2001 sendmail.8.12.0.tar.gz

You could cd to this directory and unpack the tar ball with one of the following commands:

tar -xvzf SpamCorral-1.0.5.tar.gz
gunzip -c SpamCorral-1.0.5.tar.gz | tar -xv

If you do so, your directory structure will now look something like this:


  SendMail
  drwxrwxr-x  2    4096 Feb  1 14:09 SpamCorral-1.0.5
  -rw-r--r--  1   93628 Jan 31 13:54 SpamCorral-1.0.5.tar.gz
  -rwxr--r--  1  290418 Sep 19  2001 sendmail-8.11.6-1.7.1.i386.rpm
  drwxr-xr-x 22    4096 Sep 19  2001 sendmail-8.12.0
  -rwxr--r--  1 1783911 Sep 14  2001 sendmail.8.12.0.tar.gz

1.2.2 Run "configure"

The distribution is meant to configure itself using a shell script produced by the GNU autoconf program. To configure the spam handlers, switch to the installed directory and type "./configure". If you're using "csh" on an old version of System V, you might need to type "sh ./configure" instead to prevent "csh" from trying to execute "configure" itself.

Running "configure" takes a few seconds. While running, it prints some messages telling which features it is checking for.

The "configure" shell script creates a shell script "config.status" that you can run in the future to recreate the current configuration, and a file "config.log" containing output useful mainly for debugging "configure". It can also use an optional file (typically called "config.cache" and enabled with "--cache-file=config.cache" or simply "-C") that saves the results of its tests to speed up reconfiguring.

1.2.3 Sharing Defaults

If you want to set default values for "configure" scripts to share, you can create a site shell script called "config.site" that gives default values for variables like "CC", "cache_file", and "prefix". "configure" looks for "PREFIX/share/config.site" if it exists, then "PREFIX/etc/config.site" if it exists. Or, you can set the "CONFIG_SITE" environment variable to the location of the site script. A warning: although this "configure" script does so, not all "configure" scripts look for a site script.

1.2.4 Configure the Spam Notifier

To configure the spam notifier, you can hack the source file SpamNotify.pl (note that I use a setting of five for tabs so the source will look weird unless you set your tabs to five also) and change the appropriate variables therein. However, the easiest way to configure it is to copy the appropriate configuration file for your language (or the closest one to it) to the file "SpamNotify.cf". The original files are named "SpamNotify-xx.cf". The format of these files is the same as a Perl script and they are simply evaluated by Perl that way. You can change these variables:

$CORRAL The path name of the directory where suspended spam is saved until it is released or deleted. If you are using MailCorral, this should match the directory used in the SPAM_NAME_TEMPLATE manifest constant set in smfopts.h.
$STAMPFILE The name of a file to use for holding the timestamp of the last spam notification message. You may pick any name you like, provided it doesn't collide with the names used by the mail fitler (e.g. none of the names in the message file name templates in MailCorral's smfopts.h).
$SPAMROBOT The userid of the spam handler robot (that will be created in Section 1.3, below). However, you probably won't have to change this variable if you are using a version of sendmail that forwards mail to programs via smrsh. The reason is because SpamNotify automatically detects which userid is being used for the spam handling robot, at runtime. The value set by this variable is only used as a fallback, default. Note that, if a value is set in the config file, it is taken as the absolute name and the results of automatic detection are ignored.
$MAXHEADERLEN The maximum number of message header bytes to be read while processing messages for notification. If the end of the headers isn't found after reading this many bytes, the message is skipped and no notification is sent.

There is a tradeoff between the speed of processing messages and the number of bytes read while looking for headers. If there is a large amount of corralled spam, you might want to reduce this variable from its default setting of 16384 to a smaller value. However, be advised that smaller values (e.g. 4096) might cause some messages with long delivery lists (common with some types of spam) to be skipped.

$DATEFMT The date/time format string that is to be passed to sprintf whenever date stamps are formatted for display. This value consists of the format pattern string, followed by the variables to be substituted into it. Note that the double quotes around the format string and the dollar signs in the variable names must be escaped, since this value is evaluated multiple times. If you don't escape these items, your date stamps will come out broken or all zeros.

Within this parameter, you can use the variables: "$Year" (the full, four-digit year number); "$Mon" (the two-digit month number); "$MDay" (the two-digit day of the month); "$Hour" (the twenty-four hour clock); "$Min" (the minutes in the hour); "$Sec" (the seconds in the minute). The default value is:

\"%04d-%02d-%02d %02d:%02d:%02d\", \$Year, \$Mon, \$MDay, \$Hour, \$Min, \$Sec

which gives a date stamp that looks like "2003-04-18 03:27:05". If you live in Europe, you might want to try:

\"%02d.%02d.%04d %02d:%02d\", \$MDay, \$Mon, \$Year, \$Hour, \$Min

which gives a date stamp that looks like "18.04.2003 03:27".

$NOTIFYSUBJ The subject line to be used on notification messages sent to the users about spam held for them.

The foreign language configuration files packaged with SpamCorral contain a translation of this subject text into the target foreign language.

$NOTIFYMSG The text of the message that is sent to the users, describing the spam that is waiting for them and what to do about it. This is a multi-line message that begins the body of the notification message.

The foreign language configuration files packaged with SpamCorral contain a translation of this notification into the target foreign language.

$XXXXTAG The various tags that are used in the body of the notification message to identify the components of each piece of spam. Things like the from, subject and date headers.

The foreign language configuration files packaged with SpamCorral contain a translation of these tags into the target foreign language.

1.2.5 Configure the Message Remailer

Next, to configure the message remailer, you can hack the source file MailRelease.pl (note that I used a setting of five for the tabs here too so the source will look weird unless you also set your tabs to five) and change the appropriate variables therein. However, the easiest way to configure the remailer is to copy the appropriate configuration file for your language (or the closest one to it) to the file "MailRelease.cf". The original files are named "MailRelease-xx.cf". The format of these files is the same as a Perl script and they are simply evaluated by Perl that way. You can change the variables noted below.

One word, though, before you proceed to setting up MailRelease.pl. If you have installed or will be installing MailCorral, you do not need to install MailRelease.pl (you still can if you want to) because it is redundant. MailCorral includes a copy of MailRelease.pl, which is identical to the MailRelease.pl in this package and which will work for both products.

$CORRAL The path name of the directory where suspended spam is saved until it is released or deleted. If you are using MailCorral, this should match the directory used in the CORRAL_DIR manifest constant set in smfopts.h.
$LOG_FILE The name of the log file where information about all messages that are remailed, etc. is written. You will need to define this variable to and set it to a valid file name to turn on logging (which is off by default).
$REMAIL_HDR_BYPASS The remail header string that is used to indicate that a message can be remailed. This string must match the tag placed in the message by the program that corralled it (e.g. MailCorral).
$MAXHEADERLEN The maximum number of message header bytes to read while looking for remail tags in compressed, corralled messages. If the remail tag isn't found after reading this many bytes, the message cannot be released for remailing. Note that this only applies to compressed messages.

There is a tradeoff between the speed of releasing messages and the number of bytes read while looking for the remail tag. If the users are releasing large numbers of messages, you might to reduce this variable from its default setting of 16384 to a smaller value. However, be advised that smaller values (e.g. 4096) might cause some messages with long delivery lists (common with some types of spam) to be unreleasable when compressed.

$IGNORE_DOMAINS This variable should be defined to any value, if you wish MailRelease to ignore the user's domain name when processing release requests. Normally, the domain name of the requestor is checked against a list of valid domain names, before they are allowed to release corralled mail. This feature is normally turned on, since it isn't troubling to most users and turning it off is a moderate security hole.
$CHECK_USER_NAMES This variable should be defined to any value if you wish MailRelease to check that a user's name matches the recipient of the message before it can be remailed. This feature defaults to off, since it proved to be more trouble than it was worth to most users. However, it is a big security hole.
$DELETE_ON_RELEASE This variable should be defined to any value if you wish MailRelease to delete messages from the corral, once they are released for remailing. This keeps the corral cleaner but it can cause problems if the message is not delivered for some reason. Consequently, this feature defaults to off and released messages are kept in the corral until the regularly scheduled cleanup program finds and deletes them.
@LOCAL_DOMAINS The list of domain names that are considered local to this site. Spam will only be remailed to users who send mail from one of the approved domains. This prevents outside users from remailing spam ("Its a good thing!").

The list may also include file names, which can contain lists of local domain names, one per line. Typically, this feature would be used to point to the file "/etc/mail/local-host-names" or the same place where sendmail gets local domain name information from.

$ERRORXXXX A series of error messages that can be sent back to the user, if release fails for some reason or another.

The foreign language configuration files packaged with SpamCorral contain a translation of these error messages into the target foreign language.

1.2.6 Test the Spam Handlers

Test out any changes you make to the spam handling programs by running them standalone. In production, they will be running under cron or from a ".forward" file so they are likely to fail silently.

To test SpamNotify.pl, as root, try the following command line:

./SpamNotify.pl username

In the above command line, "username" should be the name of a user who has received some spam while the sendmail filter was running. The sendmail test suite has a sample ("spam_html_encoded") that will suffice. If you send it to yourself while the filter is running, it should get redirected to the spam corral. Running the notification script should send email to "username".

To test MailRelease.pl, make up a test email message in a file and pass it through the script. Your test email message must include a from header and a line that matches a spam file in the spam corral. Note that it is of the utmost importance that there be a blank line between the "From:" line and the "File:" line in the test message, just as there would be in a real mail message. For example:

From: joe@localhost

File: /var/spool/MailCorral/spam_to_joe_3D2E9A9B

If your test file was called "testrel", as root, try the following command:

./MailRelease.pl <testrel

Note that you should pick a piece of spam that you don't really care about, for this test, since it will be deleted once it is remailed. If all is working, "joe" should see the remailed spam.

1.3 Create a Spam Handler Robot

The spam handler robot is actually a separate userid that is created for the sole purpose of releasing spam to the general public whenever users ask it to do so.

Spam is corralled by the sendmail filter when it is received. Periodically, the spam notification program ("SpamNotify.pl") is run under cron. It sends notification of all spam received by a particular user to that user. By replying to this notification message, the user can selectively release spam to be sent to them.

The reply to the notification is directed to the userid that you create in this section. The userid has a .forward file which directs all incoming mail to the spam handler ("MailRelease.pl"). This script scans the replies to any notification messages, from the other users, and releases the appropriate spam to them for delivery.

SpamCorral shares the message corral with its sister product, MailCorral, consequently, the message release function is also shared. If you have set up or are setting up MailCorral, you will be instructed how to set up a message handler robot to release messages that are corralled because of content. In that case, you do not need to set up a spam handler robot too. MailCorral's message handler robot will do both jobs of releasing messages and spam. The userid you are asked to set up under MailCorral is called "mailrobot". If you have already done or will do this, subsitute that name herein and skip the setting up of the new userid (immediately below). Most of the other setup steps can be skipped too, although it doesn't hurt to verify that each one has, indeed, been done.

First, you must set up a new userid with a name that matches the one you chose for the $SPAMROBOT variable in Section 1.2. For example, under Linux:

useradd -c "Spam handling robot" -m spamrobot

Note that it is very important that the userid which you create have a valid shell named in its /etc/passwd entry. This shell need not be one that actually works (if you wish to keep people from logging in to the robot's userid) but it must be one that is named in /etc/shells. The default shell, assigned by new user creation, should work but be aware of this fact if you assign any specialty shells to this userid. Sendmail will not forward mail to MailRelease.pl if this isn't the case.

Next, we are going to copy "MailRelease.pl" to either the spam robot's home directory or a subdirectory under it (henceforth, we assume the home directory). But, before we do this, make certain that whatever directory you choose is not writable, except to the owner (no, not even the owner's group can have write permissions). If the directory is writable by anyone but the owner, sendmail will not forward mail to MailRelease.pl

Now, copy "MailRelease.pl" to the spam robot's home directory (skip this part, if you're using MailCorral's MailRelease.pl). Give it the right kind of permissions, etc. to allow sendmail to execute it when it reads the ".forward" file. Generally, sendmail runs as the recipient of a message so this script should have permissions that look like "-rwsrwxr-x" and it should have ownership of root/spamrobot. Note that this program is running as setuid root to allow it to manipulate the files that it needs to mess with. Be careful if you make any modifications to this program. Also, on SuSE there is a permission system which will reset the setuid bit each time SuseConfig is run so you will have to change the permissions in /etc/permissions.easy to 4775 for MailRelease as well, otherwise they will have to be reset manually each time SuseConfig is run.

Pay particular attention to the operation of the setuid bit. Some operating systems (e.g. Linux) ignore the setuid bit on shell scripts, for security reasons. If yours is one of these operating systems, Perl may attempt to simulate the action of setuid. If it does, MailRelease.pl will run correctly when invoked under a non-root userid. If Perl doesn't simulate setuid, you will need to run the setuid version of Perl. Normally, the "configure" script determines this fact and makes the appropriate changes to MailRelease.pl. However, if it doesn't you will have to hack the first line of MailRelease.pl and point it at "suidperl" (probably the same path as is already there but with the name of "suidperl" instead [if you can't find suidperl, it may not be installed, in which case you will need to get it and install it -- under RedHat Linux, suidperl comes as a separate RPM, called perl-suidperl]). You should check that MailRelease.pl can release messages from the corral when run from the userid spamrobot to make sure setuid is working (run the same test as above but do "su spamrobot" first).

On some systems, suidperl will not work either (e.g. on RedHat 7, with Perl 8.5.0, I could not get it to work under any circumstances). In this case, create the following C wrapper ("MailRelease.c"):

#define REAL_PATH "/home/spamrobot/MailRelease.pl"
main(ac, av)
    char **av;
{
execv(REAL_PATH, av);
}

Compile it with your favorite C compiler (e.g. "cc -o MailRelease MailRelease.c"). Give this program the setuid root permissions instead of MailRelease.pl.

If you modified the config file or are using one of the foreign language config files, copy MailRelease.cf to the same place as MailRelease.pl and give it permissions of -rw-r--r--. You can have the owner and group of the file be whatever you want but spamrobot/spamrobot will work fine. If you are using MailCorral but want to use one of the foreign language config files from the SpamCorral distribution, copy the appropriate file to MailRelease.cf to the same directory where the MailCorral install put MailRelease.pl.

While you are at it, you can copy "SpamNotify.pl" to this user's home directory and give it permissions that look like "-rwxr-xr-x". The ownership should be spamrobot/spamrobot. This will allow cron and anyone else who wants to execute this program to do so.

If you are using one of the foreign language config files or you modified the config file, copy SpamNotify.cf to the same place as SpamNotify.pl and give it permissions of -rw-r--r--. You can have the owner and group of the file be whatever you want, probably spamrobot/spamrobot. If you are using MailCorral but want to use one of the foreign language config files from the SpamCorral distribution, copy the appropriate file to SpamNotify.cf in the same directory where the MailCorral install put SpamNotify.pl.

Set up a ".forward" file under this userid that reads:

"|MailRelease.pl"

Note that in some cases, sendmail requires that the full path name of the executable file be used in the ".forward" file and that the name used match exactly the name that is pointed to by the symlink in the "/usr/adm/sm.bin" or "/etc/smrsh" file (see the next section). In that case, the ".forward" file should look like this:

"|/home/spamrobot/MailRelease.pl"

Make sure that the permissions are "-rw-------" and the owner/group is set to the userid (e.g. "spamrobot") that you created above or forwarding won't work. Sendmail checks the ownership and permissions, for security reasons, before it will do any forwarding.

1.4 Configure Sendmail

Sendmail now has additional security that prevents ".forward" files from executing programs directly. It uses a special shell ("smrsh") that performs extra security checking before allowing a program to be run from a ".forward" file. This shell is very restrictive, almost to the point of being ridiculous, resulting in a good many reasons why it should prevent MailRelease.pl from working (most of which fail silently). You should first read "man smrsh" for more information about "smrsh" and then follow these instructions carefully to get it working.

Note that, if you don't follow these instructions to the letter, there is a very good chance that sendmail will simply drop the message to your spam robot or, just as bad, deliver it to the spam robot's local mailbox (this is a good thing to check ["mail -u spamrobot"], by the way, if the sendmail log says your messages are being delivered but MailRelease.pl is, none the less, failing to release anything). You will get no error message or warning as to why this happens. Sendmail's attitude is that you made a mistake so its not going to do what you wanted and it isn't going to give you any clues why, either. If you end up reading its code to see why its not forwarding messages to your spam robot, you'll see that it even has a flag that it sets (DONTBLAMESENDMAIL) to indicate its not its fault. Too funny! Hopefully, if you follow these instructions scrupulously, it won't come to that.

When you built sendmail, smrsh should have been built along with it. If not, build it now. If the sendmail install did not do so already, copy smrsh to a convenient location (e.g. "/usr/sbin/smrsh"), probably the same directory as sendmail resides in. Apply execute permissions so that the world can execute smrsh, if they aren't already there.

For forwarding of any kind to work, the shell chosen for the userid that is forwarding must be a "valid" shell. This means that the shell named in the userid's entry in /etc/passwd must be listed in the file /etc/shells. Verify this fact. The shell chosen need not be one that actually works (if you wish to keep people from logging in to the robot's userid) but it must be one that is named in /etc/shells. The default shell, assigned by new user creation, should work but be aware of this fact if you assign any specialty shells to this userid.

To get smrsh to execute programs, you need to create a directory named "/usr/adm/sm.bin". You must give it ownership and permissions of root/root/755 and put into it soft links to any programs which will be executed by a ".forward" file. Be very careful what programs you put in this directory because programs therein can be executed by mail messages if a hapless user decides to add them to their ".forward" files.

In our case, we need to put in a soft link to the spam handling robot. For example:

ln -s /home/spamrobot/MailRelease.pl /usr/adm/sm.bin/MailRelease.pl

Alternatively, some versions of sendmail use "/etc/smrsh" to implement this feature. You can look at the source code for sendmail (specifically, see the code in smrsh.c) or try both of them until you get it to work.

The sendmail configuration file must be altered to enable message forwarding. This is done by adding some lines to the ".mc" file for "sendmail.cf" (this is way better than hacking "sendmail.cf" directly, which is definitely not for the faint of heart) and running it through M4. Start by copying the canned configuration supplied with the OS, if you haven't already done so and add the following:

FEATURE(`smrsh', `/usr/sbin/smrsh')dnl

Note that, in the above line, you should change "/usr/sbin/smrsh" to point to wherever you actually installed smrsh.

Also note that the default "cost" for mail passed to the program mailer that invokes smrsh is "expensive". This has the unwanted effect of placing mail forwarded to programs into the mail queue where it can sit for hours before being delivered. I cannot even speculate why this choice was made for the default but you may not wish it to be so.

If you would like your spamrobot to respond quickly to requests, you will need to change the expense of the local mailer. First, you should check your sendmail.cf file to see if the expensive flag is, indeed, one of the flags being passed to the program mailer. If you see the letter 'e' in the flags, defined by the parameter "F=", for the "prog" mailer, you'll need to remove it. For example, if your config file reads something like:

Mprog,     P=/usr/sbin/smrsh, F=lsDFMoqu9e,
     S=EnvFromL/HdrFromL, R=EnvToL/HdrToL, D=$z:/,
     T=X-Unix/X-Unix/X-Unix, A=smrsh -c $u

You will need to change the expense of this mailer. To do this, add the following line to the ".mc" file:

define(`LOCAL_SHELL_FLAGS', `u9')dnl

Be sure that this line occurs before the line that says "MAILER(`local')", since that macro uses the values set by it. And, if there is no definition for a local mailer, be sure to add it.

Compile the configuration and install it. First, build a new "sendmail.cf" by running the M4 macro processor over the ".mc" file and then copy that file to the usual sendmail configuration file. You can use the following commands:

m4 mysys.mc >mysys.cf
cp mysys.cf /etc/sendmail.cf

If you prefer to hack the "sendmail.cf" file directly, you should add something that looks like this to the end of the file:

Mprog,     P=/usr/sbin/smrsh, F=lsDFMoqu9,
     S=EnvFromL/HdrFromL, R=EnvToL/HdrToL, D=$z:/,
     T=X-Unix/X-Unix/X-Unix, A=smrsh -c $u

Its time to try smrsh to see if will run MailRelease.pl. To do this, logon as JoeUser (i.e. not root) and run MailRelease through smrsh, using the following command (or whatever is appropriate for where you installed smrsh):

/usr/sbin/smrsh -c /home/spamrobot/MailRelease.pl

Due to the fact that smrsh looks up all of the programs it executes in /usr/adm/sm.bin, it might seem to you that the actual path used to execute MailRelease.pl is unimportant. One might think that only the program name matters, and you might even be correct for some of the earlier versions of smrsh. However, it would now appear that smrsh is checking to see that the path that you use to execute the program matches exactly the path pointed to by the symlink in /usr/adm/sm.bin. So, you should use the correct path wherever you reference MailRelease.pl (e.g. in the command above and in the .forward file).

If you can't get smrsh to execute MailRelease.pl, check all of the permissions, etc. and keep trying until it works. If it does execute, type a couple of characters (it reads from stdin) and give it an eof. It should do nothing but terminate. Or, if you like, you can feed it the test message you made up earlier and see if it really works, although here we're basically just testing to see that smrsh will load the program.

For the next step, you'll probably want to turn on logging by aiming $LOG_FILE at a file (e.g. "/var/log/spamrobot"). Once this is done, send a message to spamrobot that has the name of a corralled piece of mail as its subject line. For example:

mail -s /var/spool/MailCorral/recv_from_ew@jg.sp_3E2278A4 spamrobot

You should see a log entry for the request and, if the message is a real one, it should get released. If no log entry is created, you may need to run MailRelease with suidperl (see the "Create a Spam Handler Robot" section, above). You should also check to see that the message is not in the queue, waiting to be delivered (see above for sendmail configuration changes needed to circumvent this), that the permissions on MailRelease are "-rwsrwxr-x" and that it has ownership of root/spamrobot.

If MailRelease doesn't work, its usually not its fault. There are a lot of things that must be right before sendmail will condescend to execute the program. Please check them all before blaming MailRelease.

1.5 Alternative to Message Handler Robot

Kai Schaetzl has suggested an alternative to setting up a separate userid for the spam handler robot. Although my personal preference is the separate userid approach, it is somewhat difficult to set up and get working. Kai's alternative is easier and works fine on SuSE (we haven't tried it elsewhere). Basically, here's what he had to do:

To the aliases file (/etc/aliases or /etc/mail/aliases), add this alias (or something like it):

mailrobot: |/usr/sbin/MailRelease.pl

Set the setuid bit for MailRelease. If you'd like to restrict access to this program, use the following permissions:


  -rwsr-x---  1  root daemon  14831 Mar 11 18:08 MailRelease.pl

Make sure that /usr/sbin/suidperl has the setuid bit on, as well. With this arrangement, mail is piped through MailRelease by sendmail as "daemon:daemon". That's the reason for setting MailRelease to group daemon. If the permissions are not set correctly, you'll get an unknown sendmail error 162. Sendmail itself doesn't seem to be running as "daemon:daemon", maybe as "mail:mail", so the shell for piping may be different from the user sendmail runs as.

Note that the same warning about the SuSE permission system applies here. This system will reset the setuid bit each time SuseConfig is run so you will have to change the permissions in /etc/permissions.easy to 4755 for MailRelease, otherwise they will have to be reset manually each time SuseConfig is run.

1.6 Set up Periodic Notifications, Etc.

Spam that is corralled by the sendmail filter is placed in the mail corral, pending release for remailing by the recipient or, ultimately, deletion by the cleanup prcoess (after a set period of time has elapsed). In order for the recipients of the spam to know what they have been sent, so that they can decide whether they want it remailed to them or not, the spam notification program should be run at regular intervals.

The spam notifier is run by an entry in your cron table, probably once or twice a day (depending on how often your users want to see what spam they've received). I like to do these kinds of things at the end of the day, when the load on my systems is low. Here's the crontab entry that I use:

# Once a day at 01:00, notify the users of all of the spam received in
# the last 24 hours.
00 1 * * * root /home/spamrobot/SpamNotify.pl

Alternately, if you are expecting huge amounts of spam, you may wish to partition the corral (this puts less load on the file system and avoids "out of resources" type crashes when processing the corralled spam). Here is a crontab entry that requests 24 hour partitioning (the default):

# Once a day at 01:00, notify the users of all of the spam received in
# the last 24 hours. Partition the corral at the same time.
00 1 * * * root /home/spamrobot/SpamNotify.pl --Partition

The sendmail filter generates an unaltered copy of every piece of spam that is not delivered asis. You should add something to your cron table to clean these files up after a reasonable length of time.

As an example, the script "filterclean", provided with MailCorral, cleans up all of the older filtered messages, retaining those that are less than thirty days old. If you are using partitioning, you must make sure that you use the filterclean script from version 1.0.16 of MailCorral or greater. Here is the crontab entry that invokes the filterclean cleanup script:

# Once a day at 00:30, remove all of the filtered mail messages that are
# over 30 days old.
30 0 * * * root /etc/mail/filterclean

If you don't use the filterclean script from MailCorral, you may have success with the following find command:

/usr/bin/find /var/spool/MailCorral/ -depth \( -type f -or -type l -or -type d \)
-mtime +30 -exec rm -rf \{\} \;

If you create debugging files (enabled by default), you should clean them up weekly using logrotate. Here's the lines you need to add to the logrotate config file (/etc/logrotate.conf):

/var/log/spamrobot {
     missingok
     notifempty
}