DSPAM php Control Center
[ Main Index ] [ DSPAM php Control Center ] [ Control Center FAQ ] [ DSPAM Case Study ] [ Apache2 Configuration ] [ Reference Links ]
This site has a php implementation of the dspam user interface. I wrote it because I wanted to customize and augment some of the features found in dspam.cgi but it was written in perl and perl hurts my eyes.
dspamCC aspires to be a simple spam quarantine control center suitable for 'Executive Use' with the following features:
Here is the latest version of the interface:
If your web server is running php as an Apache2 module, use dspam.php otherwise, use dspam.cgi. If you use dspam.cgi, you will probably need to change the first line of dspam.cgi to match your installation.
Try using dspam.php instead of dspam.cgi
Change the first line of dspam.cgi to match your installation of the php binary.
Make sure to setup the .htaccess file or httpd.conf so that authentication is required to access the Control Center. It assumes that user authentication will be handled by the web server. It attempts to find the user name in any one of these three php environmental variables:
SERVER["REMOTE_USER"] SERVER["REDIRECT_REMOTE_USER"] SERVER["PHP_AUTH_USER"]
Check the ownership and permission settings on the file and the directories in the path leading to the file. (see Configuring Apache2)
File locking relies on the php function flock() which does not work on NFS and many other networked file systems. Check your operating system documentation for more details. On some operating systems flock() is implemented at the process level. When using a multithreaded server API like ISAPI you may not be able to rely on flock() to protect files against other PHP scripts running in parallel threads of the same server instance! flock() is not supported on antiquated filesystems like FAT and its derivates and will therefore always return FALSE under these environments (this is especially true for Windows 98 users). You can disable file locking in inc/config.inc.php like this:
This feature is not enabled by default. In inc/config.inc.php set these variables accordingly and a "Display HTML" link will appear at the top of the screen when a message is being viewed:
$dirWebTMP = "tmp/"; # must exist and be writable (see Configuring Apache2) #$bDefangPolicy=true; # default is to defang messages $bDefangPolicy=false;
Yes. You can use procmail rules, spamassassin, etc. As long as the program using the quarantine writes the messages in Unix mail format the Control Center will work.
Use dspam as the local delivery agent and dspam must be built without --enable-delivery-to-stdout and --enable-spam-delivery either of which would prevent a spam quarantine from being created.
e-mail aliases are used to handle false-positives, spam reporting and whitelisting. Here are some example alias definitions suitable for sendmail given a username "tammy":
spammy-tammy: "|'/usr/local/bin/dspam' --user 'tammy' --addspam" hammy-tammy: "|'/usr/local/bin/dspam' --user 'tammy' --falsepositive" family-tammy: "|'/usr/local/bin/handleWhitelist.sh' 'tammy'"
$sp_prefix="spammy-"; $fp_prefix="hammy-"; $wl_prefix="family-";
Those are informational messages. Try using the default settings for error reporting in /usr/local/lib/php.ini or change it to something like this:
error_reporting = E_ALL & ~E_NOTICE
Sure. e-mail firstname.lastname@example.org
We are a privately held multinational manufacturer. On an average day we quarantine around 30,000 junk messages with a combination of spamassassin and DSPAM, with DSPAM being responsible for quarantining about 15% of the total each day. We trained the DSPAM filter for about one month prior to putting it into production use. For the first three days of production use we had to monitor the results closely for false positives but within five days false positives were no longer an issue.1
We have about 550 e-mail accounts handled by a Linux server running postfix and we were filtering exclusively with spamassassin. Just after the beginning of the year (2004) we received a complaint regarding a single mail message from a vendor to a high-level executive that had been blocked by spamassassin. We found that the vendor's message was not only sent from an advertising-supported free e-mail service but also was delivered by a black-listed server. In spite of the obvious considerations, the repercussions of this one incident became so dramatized that we were forced to remove the blacklisting from our spamassassin filtering scheme altogether.
At about the same time other high-level executives began complaining about increasing levels of spam. The worst cases were those whose addresses had been published on our company's website since it went on-line in the late 90's and those whose jobs required them to make frequent purchases on-line. The number of spam messages received by these individuals ranged from about a dozen per day in one case to over 200 per day in the worst case we found. In many cases we found that the spammers had designed their messages such that they would just pass under spamassassin's radar. We experienced a surge in messages that included random word lists and obfuscated spelling designed to fool spamassassin's style of filtering, ie V\@gra and the like.
We noticed a slashdot report about DSPAM and decided to test it. We installed it on a UNIX System V server running sendmail and configured it for one user. DSPAM performed so well that after just a few days of testing we were confident enough to announce to the corporation that we had begun training an intelligent e-mail filter and would be ready to put it into production use within one month.
Our initial DSPAM filter training procedure consisted of a number of elements:
At the end of one month of training we had accumulated a mySQL database containing over 800,000 tokens (~104Meg) which we copied from the test server to the production server. We created a "dspam" user account on the production server and updated the database with the corresponding user ID. To put the DSPAM filter into production we populated the user directories with a procmail recipe based on the template below. The template shown here has been obfuscated a little bit regarding directory names and aliases. Some customization and all the logging has been removed. In this example the aliases are mapped as follows:
Consideration of the procmail recipe and the discussion above demonstrates several ongoing methods for training the DSPAM filter automatically.
Here are some things we avoid doing to protect our corporate filter's "intelligence" (Had we decided to implement DSPAM on a per user level they would not be necessary):
As our experimental Control Center is nearly ready for "executive use", the next phase of our implementation will be to provide user administered spam quarantines and whitelists.
The greatest vulnerability of our system is the reliance on whitelisting as the "From: " field of a message is easily faked. By auditing our results on an ongoing basis we hope to be able to fend off those kinds of attempts with countermeasures tailored to specific instances.
DSPAM seems to learns from false positives very quickly but we think the use of whitelisting greatly reduced the number of false positives we had to deal with at the beginning of production use. We created an e-mail alias such that users could forward a message to it and the system would extract the "From: " plus the original sender of the forwarded message which would then be added to the user's personal whitelist.
This is an example of a working Apache configuration such that dspam.cgi runs as the user dspam on a virtual host like dspam.yourdomain.com.
The assumptions are that dspam is a valid user on the webserver's system, that user mailbox files will be will belong to the "dspam" group and that the group access is "rw" i.e.
-rw-rw---- 1 michael dspam 4386 Mar 27 11:06 /etc/mail/dspam/michael/michael.mbox