DSpam INSTALLATION - Revision history

Ledhed: /* THE WEB UI */

2009-07-27T22:47:05Z

‎THE WEB UI

Ledhed: /* NOTIFICATIONS */

2009-07-27T22:46:47Z

‎NOTIFICATIONS

Ledhed: /* NIGHTLY MAINTENANCE AND HOUSEKEEPING CRONS */

2009-07-27T22:46:26Z

‎NIGHTLY MAINTENANCE AND HOUSEKEEPING CRONS

Ledhed: /* MAIL SERVER INTEGRATION */

2009-07-27T22:45:56Z

‎MAIL SERVER INTEGRATION

Ledhed: /* PERMISSIONS */

2009-07-27T22:45:42Z

‎PERMISSIONS

Ledhed: /* BUILDING AND INSTALLING */

2009-07-27T22:45:28Z

‎BUILDING AND INSTALLING

Ledhed: /* CONFIGURATION */

2009-07-27T22:43:31Z

‎CONFIGURATION

Ledhed: /* Upgrading from 3.8 */

2009-07-27T22:39:08Z

‎Upgrading from 3.8

Ledhed: /* CONFIGURATION */

2009-07-27T22:38:15Z

‎CONFIGURATION

Ledhed: /* CONFIGURATION */

2009-07-27T22:38:04Z

‎CONFIGURATION

@@ Line 509: / Line 509: @@
 === THE WEB UI ===
 The Web UI (CGI client) can be run from any executable location on a web server, and detects its user's identity from the REMOTE_USER
 environment variable. This means you'll need to use HTTP password authentication to access the CGI (Any type of authentication will work, so long as Apache supports the module). This is also convenient in that you can set up authentication using almost any existing system you have. The only catch is that you'll need the usernames to match the actual DSPAM usernames used the system. A copy of the shadow password file will suffice for most common installs.

@@ Line 492: / Line 492: @@
 === NOTIFICATIONS ===
 DSPAM is capable of sending three different notifications to users:
 * A "First Run" message sent to each user when they receive their first message through DSPAM.

@@ Line 466: / Line 466: @@
 === NIGHTLY MAINTENANCE AND HOUSEKEEPING CRONS ===
 <br>
 ==== Non-SQL Based Nightly Purge ====

← Older revision		Revision as of 22:45, 27 July 2009
Line 364:		Line 364:

	=== MAIL SERVER INTEGRATION ===		=== MAIL SERVER INTEGRATION ===
		+	-----
	As previously mentioned, there are three popular ways to implement DSPAM:		As previously mentioned, there are three popular ways to implement DSPAM:

@@ Line 320: / Line 320: @@
 === PERMISSIONS ===
+-----
 In the typical UNIX environment, you'll need to worry about the following
 permissions:

@@ Line 307: / Line 307: @@
 === BUILDING AND INSTALLING ===
+----
 After you have run configure with the correct options, build and install
 DSPAM by performing:

@@ Line 167: / Line 167: @@
 <br>
-===== FILESYSTEM SCALE =====
+==== FILESYSTEM SCALE ====
 The default filesystem scale is "small-scale", and writes each user to its own directory in the top-level DSPAM home data directory. The following two switches allow the scale to be changed to be more suitable for larger installations.
@@ Line 180: / Line 180: @@
 <br>
-===== INTEGRATION SWITCHES =====
+==== INTEGRATION SWITCHES ====
   --with-storage-driver=DRIVER[,DRIVER2[...,DRIVERN]]
@@ Line 217: / Line 217: @@
 <br>
-===== DRIVER SPECIFIC CONFIGURE SWITCHES =====
+==== DRIVER SPECIFIC CONFIGURE SWITCHES ====
 Some storage drivers have their own custom configuration switches:
@@ Line 280: / Line 280: @@
 <br>
-===== DEBUGGING SWITCHES =====
+==== DEBUGGING SWITCHES ====
   --enable-debug
@@ Line 294: / Line 294: @@
 <br>
-===== FEATURE ACTIVATION =====
+==== FEATURE ACTIVATION ====
   --enable-clamav
@@ Line 300: / Line 300: @@
 <br>
-===== ADDITIONAL CONFIGURATION OPTIONS =====
+==== ADDITIONAL CONFIGURATION OPTIONS ====
 The remainder of configuration options are located in dspam.conf, which is installed in sysconfdir (default: /usr/local/etc) upon a make install. It is generally a good idea to review dspam.conf and make any changes necessary prior to using DSPAM.
@@ Line 306: / Line 306: @@
 <br>
-==== BUILDING AND INSTALLING ====
+=== BUILDING AND INSTALLING ===
 After you have run configure with the correct options, build and install
@@ Line 319: / Line 319: @@
 <br>
-==== PERMISSIONS ====
+=== PERMISSIONS ===
 In the typical UNIX environment, you'll need to worry about the following
@@ Line 363: / Line 363: @@
 <br>
-==== MAIL SERVER INTEGRATION ====
+=== MAIL SERVER INTEGRATION ===
 As previously mentioned, there are three popular ways to implement DSPAM:
@@ Line 396: / Line 396: @@
 <br>
-===== ALIASES =====
+==== ALIASES ====
 There are essentially two different ways a user might train DSPAM. The first is by using the Web UI, which allows them to retrain via the "History" tab. This works quite well, as users must visit the Web UI occasionally to review their quarantine anyway (and reverse any false positives). We'll discuss this shortly in section 1.1.8.
@@ Line 410: / Line 410: @@
 <br>
-====== The Simple Way ======
+===== The Simple Way =====
 If you are using the MySQL or PgSQL storage drivers, the original numeric user id can be embedded in the signature, requiring only one central spam alias to be necessary for the entire system. To configure this, uncomment the appropriate UIDInSignature option in dspam.conf:
@@ Line 429: / Line 429: @@
 <br>
-====== The Kind-of-Simple Way ======
+===== The Kind-of-Simple Way =====
 If you're not using one of the above storage drivers, the next easiest way to configure aliases is to have DSPAM parse the 'To:' header of the message and use a catch-all subdomain to direct all mail into DSPAM for retraining. You can then instruct your users to email addresses like 'spam-bob@relearn.domain.tld'. The ParseToHeaders option (available in dspam.conf) will parse the To: header of forwarded messages and set the username to either 'bob' or 'bob@relearn.domain.tld', depending on how it is configured. DSPAM can also set the training mode to either "learn spam" or "learn notspam" depending on whether the user specified a spam- or notspam- address in the To: header.
@@ Line 444: / Line 444: @@
 <br>
-====== The Old Way (A.K.A. The Hard Way) ======
+===== The Old Way (A.K.A. The Hard Way) =====
 If neither of the easy ways are possible, you're stuck with doing it the hard way. This means you'll need a separate spam alias (and notspam alias, if users are tagging mail) for each user. To do this, you will need to create an email address for each user, so that DSPAM can analyze and learn for that specific user.  For example:
@@ Line 464: / Line 464: @@
 <br>
-==== NIGHTLY MAINTENANCE AND HOUSEKEEPING CRONS ====
+=== NIGHTLY MAINTENANCE AND HOUSEKEEPING CRONS ===
 <br>
-===== Non-SQL Based Nightly Purge =====
+==== Non-SQL Based Nightly Purge ====
 If you are NOT running a SQL-based solution, then you should configure dspam_clean to run under cron nightly. This clean tool will read all signature databases and purge signatures that are older than 14 days (configurable), purge abandoned tokens, and remove unimportant tokens. Without this tool, old signatures will continue to pile up. Be sure the user running cleanup has full read/write permissions on the DSPAM data files.
 0 * * * /usr/local/bin/dspam_clean [options]
@@ Line 472: / Line 472: @@
 <br>
-===== SQL-Based Nightly Purge =====
+==== SQL-Based Nightly Purge ====
 SQL-Based solutions include a nightly SQL script to perform the same basic
 tasks as dspam_clean, and it does it much faster and with more finesse.
@@ Line 482: / Line 482: @@
 <br>
-===== Log Rotation =====
+==== Log Rotation ====
 The system log and user logs can fill up fairly quickly, when all that's really needed to generate graphs are the last two to three weeks of data. You can configure a nightly log cleanup using dspam_logrotate:
@@ Line 489: / Line 489: @@
 <br>
-==== NOTIFICATIONS ====
+=== NOTIFICATIONS ===
 DSPAM is capable of sending three different notifications to users:
 * A "First Run" message sent to each user when they receive their first message through DSPAM.
@@ Line 505: / Line 505: @@
 <br>
-==== THE WEB UI ====
+=== THE WEB UI ===
 The Web UI (CGI client) can be run from any executable location on a web server, and detects its user's identity from the REMOTE_USER
 environment variable. This means you'll need to use HTTP password authentication to access the CGI (Any type of authentication will work, so long as Apache supports the module). This is also convenient in that you can set up authentication using almost any existing system you have. The only catch is that you'll need the usernames to match the actual DSPAM usernames used the system. A copy of the shadow password file will suffice for most common installs.

@@ Line 5: / Line 5: @@
 <br>
 === Upgrading from 3.8 ===
+-----
 . Ensure MySQL is using the new database schema. The following clauses should be executed for upgrading pre-3.9.0 DSPAM MySQL schema to the 3.9.0 schema:
   ALTER TABLE `dspam_signature_data`
@@ Line 62: / Line 62: @@
 <br>
-==== Upgrading From 3.6 ====
+=== Upgrading From 3.6 ===
+-----
 . Add 'Tokenizer' setting to dspam.conf The 'Tokenizer' setting in 3.8.0 replaces tokenizer definitions in the "Feature" clause of previous version configurations. See src/dspam.conf (after make) for more information about this seting.
@@ Line 80: / Line 80: @@
 <br>
-==== Upgrading From 3.4 ====
+=== Upgrading From 3.4 ===
+-----
 Follow all of the steps above, and the following steps:

@@ Line 142: / Line 142: @@
 <br>
 === CONFIGURATION ===
+-----
 DSPAM uses autoconf, so configuration is fairly standardized with other UNIX-based software:
   ./configure [options]