(Note: A current version of this document can always be found (in more
readable HTML form) at http://www.renaissoft.com/maia/install.php)

Installing Maia Mailguard

1. Create a user and group for amavisd to run under, if necessary

The amavisd-new process should be running under its own userid and group,
as specified in Section I of your /etc/amavisd.conf file as:

$daemon_user = 'amavis';
$daemon_group = 'amavis';

Throughout this documentation we'll be assuming the username you're using
for this purpose is amavis, and the group name is amavis; substitute your
own values if you've chosen something different.

If you haven't already created this user and group, do so now, making sure
to set a password for this user:

[root]# useradd amavis
[root]# passwd amavis
[root]# groupadd amavis


2. Create a new database for amavis and Maia Mailguard

Maia Mailguard supports a number of SQL databases. The documentation may
refer in places to MySQL, since this is a common database, but bear in mind
that you should be able to get Maia Mailguard working with PostgreSQL as
well.

To create a new database with MySQL, type the following (you can omit the
"-p" if your MySQL installation allows root to login without a password, but
really, you should always have a password, especially for root!):

[root]# mysql -u root -p mysql

mysql> CREATE DATABASE maia;

The procedure for creating a database will vary from one database to another;
consult your database documentation to find the right way to do this for your
database.

To create and stock the necessary database tables, use the definitions in the
maia-mysql.sql file, i.e.:

[root]# mysql -u root -p maia < maia-mysql.sql

The SQL syntax in this file is designed for MySQL, and may need to be
modified slightly to accommodate other databases (e.g. your database may have
different keywords for unsigned or auto_increment). The maia-pgsql.sql file
contains the table definitions for use with PostgreSQL, for example.

Now you need to give the amavis user limited access to this database (in place
of passwd be sure to use the password you set for the amavis user):

[root]# mysql -u root -p maia

mysql> GRANT CREATE, DROP, ALTER, SELECT, INSERT, UPDATE, DELETE ON maia.* TO
       amavis@localhost IDENTIFIED BY 'passwd';

Again, how you grant privileges to a database user will vary from package to
package. Consult your database documentation for more specific details.

If you're using MySQL, you'll also need to add (or increase) the
max_allowed_packet setting in your my.cnf file. This setting determines the
size of the largest mail item you'll be able to process with Maia, so make
sure to set this value large enough to accommodate your needs. (You'll be able
to tell Maia later on what to do with mail larger than this.) Note that in
MySQL version prior to 4.0.1, the maximum packet size is 16M; later versions
can accept packets as large as 1G.

MySQL versions prior to 4.0.2:

[mysql]
set-variable = max_allowed_packet=5M

MySQL 4.0.2 or later:

[mysql]
max_allowed_packet=5M


3. Install the Maintenance Scripts and Templates

Maia Mailguard comes with a collection of Perl scripts in the scripts
subdirectory. Install these files in a place that your web server can't
access (i.e. outside of your document root), so that they can't be triggered
by web visitors. A good place for these is in a subdirectory of your amavisd
directory, e.g. /var/amavisd/maia. Create two subdirectories there, one for
scripts, the other for templates:

[root]# mkdir /var/amavisd/maia
[root]# mkdir /var/amavisd/maia/scripts
[root]# mkdir /var/amavisd/maia/templates

Now copy the contents of Maia's scripts subdirectory into
/var/amavisd/maia/scripts, and put the contents of the templates subdirectory
into /var/amavisd/maia/templates.

Set the ownership of all of these files to the amavis user and group, and
tighten up the permissions on these files so that they're accessible only to
the amavis user:

[root]# chown -R amavis /var/amavisd/maia
[root]# chgrp -R amavis /var/amavisd/maia
[root]# chmod 640 /var/amavisd/maia/templates/*.tpl
[root]# chmod 750 /var/amavisd/maia/scripts/*.pl
[root]# chmod 640 /var/amavisd/maia/scripts/database.cfg

Before any of the supplied scripts can be used, you need to edit the
database.cfg file in the scripts subdirectory that you just installed. This
is a simple file with just three items to configure--the username, password,
and connection string that Perl needs in order to access the Maia Mailguard
database. e.g.

# Configure your database DSN here
dsn = "DBI:mysql:maia:localhost:3306"

# Your database user's login name
username = "amavis"

# Your database user's password
password = "passwd"

Finally, you'll want to edit the Perl scripts themselves to make sure they
know where to find the database.cfg file, since they rely on it to be able
to connect to the Maia Mailguard database. You'll find the configurable
portion of the scripts near the top of each file, e.g.:

# CONFIGURE THIS: Location of your database.cfg file
my $cfg = "/var/amavisd/maia/scripts/database.cfg";


4. Test your amavisd and SpamAssassin configuration

SpamAssassin and amavisd both rely on a number of Perl modules and system
utilities to function properly. Before going any further, you can use the
configtest.pl script to verify that you have all of the necessary modules
and utilities installed, and that their versions are new enough to be
useful. You'll want to run this script on all of the machines where you
run SpamAssassin and amavisd.

If the script tells you that you need to upgrade or install a Perl module
or utility, do so now, and then re-run the script to make sure. The output
should look something like this:

[root]# configtest.pl

amavisd-new:

file(1)              :     4.07 : OK
Archive::Tar         :     1.05 : OK
Archive::Zip         :     1.09 : OK
Compress::Zlib       :     1.22 : OK
Convert::TNEF        :     0.17 : OK
Convert::UUlib       :     0.31 : OK
MIME::Base64         :     2.20 : OK
MIME::Parser         :    6.108 : OK
Mail::Internet       :     1.62 : OK
Net::Server          :     0.87 : OK
Net::SMTP            :     2.26 : OK
Digest::MD5          :     2.27 : OK
IO::Stringy          :    2.108 : OK
Time::HiRes          :     1.51 : OK
Unix::Syslog         :     0.99 : OK
DBI                  :     1.40 : OK
DBD::mysql           :   2.9003 : OK
DBD::Pg              :      N/A : NOT INSTALLED (required if you want to
                                  use PostgreSQL)

SpamAssassin:

Mail::SpamAssassin   :     2.63 : OK
File::Spec           :     0.87 : OK
Pod::Usage           :     1.16 : OK
HTML::Parser         :     3.31 : OK
DB_File              :    1.806 : OK
Net::DNS             :     0.40 : OK
Digest::SHA1         :     2.04 : OK

Maia Mailguard:

Crypt::Blowfish      :     2.09 : OK
Crypt::CBC           :     2.08 : OK

Database DSN test    : PASSED


5. Load your SpamAssassin Rules

Maia Mailguard needs to index all of the SpamAssassin rules you have
installed on your system, so that these rules, their descriptions and
scores can be loaded into a database table. To do this, use one of the
scripts in the scripts subdirectory called load-sa-rules.pl.

Before you run this script, edit it to make sure that the SpamAssassin
rule directories are set properly, e.g.:

# CONFIGURE THIS: SpamAssassin directories to search for rules files
# (*.cf and user_prefs)
my $local_cf_dir = "/etc/mail/spamassassin";
my $system_rules_dir = "/usr/local/share/spamassassin";
my $user_rules_dir = "/var/amavisd/.spamassassin";

$local_cf_dir should be set to the directory that contains your site's
local.cf file.

$system_rules_dir should be set to the directory that contains
SpamAssassin's own *.cf files.

$user_rules_dir should be set to the amavis user's SpamAssassin
directory, where its (optional) user_prefs file may be found.

Run it without arguments, e.g.

[root]# ./load-sa-rules.pl

If all goes well, this script will scan the three specified subdirectories
for *.cf and user_prefs files, reading any rule names, descriptions and
scores it finds and storing them in the Maia Mailguard database.

You can safely run this script anytime you add new SpamAssassin rules or
update your SpamAssassin rule files with new scores. The script will not
add the same rule twice, but it will update the score value of a rule that
it has seen before. If you use a scheduled job to fetch updated versions of
popular SpamAssassin rule sets, for example, add this script to the end of
your update job to make sure the changes are picked up by Maia Mailguard.

If you use the Rules_Du_Jour script to automatically update your
SpamAssassin rules for you (highly recommended), you'll want to modify the
SA_RESTART setting in the my_rules_du_jour script to ensure that it runs
process-quarantine.pl after it makes any rule changes:

SA_RESTART="/var/amavisd/maia/scripts/load-sa-rules.pl;/etc/rc.d/init.d/amavisd restart";


6. Install the PHP scripts

Decide where you want to install the PHP scripts. This should be a
subdirectory somewhere within your web tree. For this example we'll assume
a directory called mail, just off the document root of the web server (i.e.
the relative path to the folder would then be /mail, accessible to the outside
world as http://www.example.com/mail). Copy the contents of the /php
subdirectory of the Maia Mailguard distribution to this folder.

There should be two subdirectories beneath the directory with your PHP
scripts--one called images, which contains the logos, icons, and other
graphics, and the other called locale, which contains the language-specific
text used by the rest of the scripts. Your directory tree in this example
should look something like this:

<document_root>/mail
<document_root>/mail/images
<document_root>/mail/locale
<document_root>/mail/locale/en


7. Configure Maia Mailguard: Database and Authentication

The config.php file contains a few basic configuration settings that must
be adjusted for your site before you can configure the rest of Maia
Mailguard's settings. In particular, the language defaults, database
connection information and user authentication parameters must be hard-coded
here.

Language Defaults

$default_display_language is set by default to "en" (English). If you have
other language files installed, you can change this setting to the ISO-639
two-letter language code (e.g. en, fr, ja, de, etc.) that corresponds to the
language you wish to use. Note that users can override this on an individual
basis, selecting from any installed language. This is simply a default to
use if no other language has been selected.

$default_charset lets you set the default character set to use, if no other
character set has been specified by the user. The default of "ISO-8859-1"
is fine for most Western languages.

Database Connection

$maia_sql_dsn is the database connection string that the Pear::DB functions
will use to try to connect to the Maia Mailguard database. The supported
database types include:

Pear::DB Type		Database
==================================
mysql 			MySQL
pgsql 			PostgreSQL

The connection string syntax for a TCP-based connection generally looks
like this:

$maia_sql_dsn = "dbtype://dbuser:passwd@tcp(hostname:port)/dbname";

In our case, with database type "mysql", database name "maia" and user
"amavis", a host of "localhost" and the standard MySQL port (3306), the
connection string should end up looking something like this:

$maia_sql_dsn = "mysql://amavis:passwd@tcp(localhost:3306)/maia";

There are many more variations on the connection string if this doesn't
work for you, including options to use Unix sockets instead of TCP, etc..
The syntax reference may help you if you get stuck.

Authentication

$auth_method determines which authentication method Maia Mailguard uses to
verify the login credentials of its users. The currently available options
are:

$auth_method	Server Type
========================================================
pop3		POP3 server
imap		IMAP server
ldap		LDAP server
exchange	Microsoft Exchange Server (experimental)
sql		SQL database server
internal	Internal SQL

$address_rewriting_type and $routing_domain allow you to compensate for any
rewriting that your upstream mail server performs on e-mail addresses. To
learn more about this issue and how to configure these settings (if
necessary), see Virtual Hosts, Aliases, and E-mail Addresses
(http://www.renaissoft.com/maia/addresses.php).

Authenticating with a POP3 server

POP3 support is provided by the University of Washington's c-client
library, which must be downloaded, compiled and installed. PHP itself must
be rebuilt after this, with the --with-imap=/path/to/imap flag (and
possibly the --with-imap-ssl=/path/to/openssl flag).

$auth_pop3_params defines the connection string your POP3 server requires
in order to authenticate a user. The general syntax is:

$auth_pop3_params = "{hostname:port/flags}INBOX";

The "flags" can be one or more of the following:

Flag			Meaning
================================================================
/pop3			The server uses the POP3 protocol
/norsh			The server does not use RSH
/notls			The server does not use TLS
/ssl			The server uses SSL
/novalidate-cert	The server has a self-signed certificate

Red Hat Linux users report having to use /norsh/notls to connect with the
IMAP server that ships with RH8+. If you have trouble connecting to your
IMAP server, try reading the user comments at the bottom of this reference.

Authenticating with an IMAP server

IMAP support is provided by the University of Washington's c-client
library, which must be downloaded, compiled and installed. PHP itself must
be rebuilt after this, with the --with-imap=/path/to/imap flag (and
possibly the --with-imap-ssl=/path/to/openssl flag).

$auth_imap_params defines the connection string your IMAP server requires
in order to authenticate a user. The general syntax is:

$auth_imap_params = "{hostname:port/flags}INBOX";

The "flags" can be one or more of the following:

Flag			Meaning
================================================================
/imap			The server uses the IMAP protocol
/norsh			The server does not use RSH
/notls			The server does not use TLS
/ssl			The server uses SSL
/novalidate-cert	The server has a self-signed certificate

Red Hat Linux users report having to use /norsh/notls to connect with the
IMAP server that ships with RH8+. If you have trouble connecting to your
IMAP server, try reading the user comments at the bottom of this reference.

Authenticating with an LDAP server

LDAP authentication is provided by client libraries from the OpenLDAP
project, or the University of Michigan's ldap-3.3 package. One of these
must be downloaded, compiled, and installed, and PHP must be rebuilt with
the --with-ldap=/path/to/ldap flag.

$auth_ldap_server is the hostname or IP address of the LDAP server you
want to authenticate with.

$auth_ldap_password is the password your LDAP server requires in order
to answer queries. This is not the password of the user you want to
authenticate.

$auth_ldap_query is the LDAP authentication query. The %%USER%%
placeholder will be replaced with the username of the user to be
authenticated.

$auth_ldap_bind_dn is the LDAP distinguished name for binding purposes,
typically your organization's name and domain name.

$auth_ldap_base_dn is the base LDAP distinguished name, typically your
domain name.

$auth_ldap_attribute is the name of the query attribute that will return
the e-mail address associated with the user's LDAP account.

Authenticating with a Microsoft Exchange Server

Modern versions of Exchange Server are IMAP-compliant, and should work
fine using IMAP authentication, except that an additional "NT Domain"
parameter may be required. See the IMAP section above for more information
about available option flags.

$auth_exchange_nt_domain is the default NT domain to use, if the user
leaves the domain field empty.

$auth_exchange_only_one_domain can be set to true if all of your users
are part of the same NT domain. If this is the case, there's no need to
prompt for a domain, the value in $auth_exchange_nt_domain will always
be used.

$auth_exchange_params is essentially an IMAP connection string (see the
IMAP section above), but two additional flags are available as
placeholders:

Flag		Meaning
====================================================================
/%%NTDOMAIN%%	User-supplied NT domain, or $auth_exchange_nt_domain
/%%USER%%	Username

Authentication with an SQL database server

SQL authentication uses the Pear::DB library to look up a username and
password against a database table, to return an e-mail address for the
user, if successful. The password may be stored in plain text, or hashed
via crypt() or MD5.

$auth_sql_dsn is the database connection string to be used to access the
authentication database. This may be a different database from the one
Maia Mailguard uses, however the connection string follows the same format.

$auth_sql_table is the name of the table that contains the user's
authentication information.

$auth_sql_username_column is the name of the column that contains the
user's username.

$auth_sql_password_column is the name of the column that contains the
user's password.

$auth_sql_email_column is the name of the column that contains the user's
e-mail address.

$auth_sql_password_type indicates the way the user's password is
encrypted in the database:

$auth_sql_password_type		Encryption Type
===============================================
plaintext			No encryption
md5				MD5 hash
crypt				crypt() hash

Authenticating with Maia's Internal SQL Database

If you want Maia Mailguard to handle its own user database, rather than
authenticate against an external source, select the internal method. With
this method, Maia stores usernames and passwords in its own database.

When new accounts are created, Maia automatically sends the new user an
e-mail containing a temporary username and password, which she can change
once she logs in (and at any time thereafter).

This authentication method is handy for situations where the other
external authentication methods would be impractical, such as hosting mail
filtering services for other companies downstream, where there would
otherwise be many different sources to authenticate against.


8. Test your PHP and database configuration

At this point, you'll want to verify that your web server has its PHP
correctly compiled, all the necessary PEAR modules installed, and the
database DSN correctly configured in config.php. You can do this by
loading the configtest.php page in your browser.

This script will verify that the prerequisites are properly installed on
your web server, and that PHP scripts can successfully communicate with
your database server. It will point out any missing components or outdated
version numbers and offer some advice for fixing the problem. Fix any
problems that get highlighted at this stage and reload the script to
verify that they've been properly fixed before proceeding.


9. Patch amavisd-new

First, make sure you've got a fresh amavisd-new-20030616-p10, so you can
start with a clean distribution. You can download
amavisd-new-20030616-p10.tar.gz from the official amavisd-new site. Unpack
the distribution in a temporary directory somewhere.

In order for Maia Mailguard to keep track of quarantined items and add
some extra functionality, a patch must be applied to amavisd-new to make it
update the SQL database whenever e-mail is processed. The file
amavisd-maia.patch contains this patch.

Place the amavisd-maia.patch file in the same directory as your
freshly-unpacked 20030616-p10 distribution, cd to that directory and type:

[root]# patch -b amavisd < amavisd-maia.patch

Now you can install the amavisd file wherever you'd typically install
system binaries (e.g. /usr/sbin, /usr/local/sbin, etc.):

[root]# cp amavisd /usr/local/sbin/
[root]# chown root /usr/local/sbin/amavisd
[root]# chmod 755 /usr/local/sbin/amavisd


10. Generate your site's encryption key (optional)

Maia Mailguard can use strong encryption to protect the contents of the
e-mail that it quarantines/caches, as a safeguard against prying eyes
with database access. It uses the Blowfish algorithm with a 56-byte
(448-bit) key, and chained-block cipher (CBC) mode to do two-way
encryption of stored mail. This encryption is completely transparent to
the users, and does not require them to install any special software.
All encrypting and decrypting is done by Maia Mailguard.

To take advantage of this encryption feature, you first need to generate
a random key for your site. The generate-key.pl script can do this for
you, just redirect its output to a file:

[root]# generate-key.pl > /var/amavisd/blowfish.key

Put the key file in your amavisd directory, and be sure to keep another
copy of it in a safe place, preferably on another machine offsite,
and/or a backup disk/CD. If you suffer a disk crash and lose your key
file, you'll need this backup to be able to recover the encrypted
contents of your Maia database.

You'll also need to copy this key file to your web server, so that Maia
can use it to properly decrypt the stored mail.  You can put it anywhere
you like on the web server, as long as you tell Maia where it is (using the
System Configuration page).

You can safely enable encryption at any time, even after you've already
got mail in your database. Maia is smart enough to detect encrypted vs.
unencrypted mail, so if your database contains a mixture of both types,
it won't cause any problems.


11. Configure amavisd-new

Edit your /etc/amavisd.conf file to configure it for your installation
as usual, with the following particulars:

You'll probably want to turn up debugging output as much as possible to
make sure everything is working the way it should:

$log_level = 5;

With quarantine management, you can safely set the final destiny of
viruses and spam to D_DISCARD, since in a manner of speaking these items
are being "delivered" to a place where the recipients can review them
(and recover them if desired). This avoids sending out a lot of noisy
Delivery Status Notifications (DSNs), most of which bounce anyway (and
create still more noise).

$final_virus_destiny = D_DISCARD;
$final_spam_destiny = D_DISCARD;
$warnvirussender = 0;
$warnspamsender = 0;

You should also take a look at the other $final_*_destiny settings. Keep
in mind that if you specify D_PASS as the final destiny for a type of
mail, you effectively render per-user settings in Maia Mailguard useless
for that type of item. For instance, if you set
$final_bad_header_destiny = D_PASS (the default setting), there's no point
in offering users the ability to be a $bad_header_lover or to
$bypass_header_checks, since these will not override D_PASS. To make these
settings meaningful and give users control over these things, choose any
other final destiny (e.g. D_BOUNCE, D_DISCARD, or D_REJECT).

The $QUARANTINEDIR setting is irrelevant to this version of Maia Mailguard,
since quarantining now takes place entirely within the database, and not
on the filesystem. Similarly, you can ignore the values of
$virus_quarantine_method, $spam_quarantine_method, $virus_quarantine_to,
and $spam_quarantine_to, since amavisd-new (after Maia Mailguard's patch is
applied) will no longer use these values.

Specify the information amavisd needs in order to connect to the database
(where passwd is the amavis user's password):

@lookup_sql_dsn = ( ['DBI:mysql:maia:localhost', 'amavis', 'passwd'] );

Leave the $sql_select_policy and $sql_select_white_black_list variables
commented out, since Maia takes care of these for you. Similarly, you
probably want to comment out the $whitelist_sender_* and
$blacklist_sender_* variables, since Maia uses a database table to store
this information.

If you want to include support for Blowfish encryption of
quarantined/cached e-mail, you'll have to add a new $key_file setting to
amavisd.conf to tell it where to find your key file:

# Blowfish encryption key file (optional)
$key_file = "$MYHOME/blowfish.key";

The @local_domains_acl, %local_domains, and $local_domains_re settings are
observed as usual, but these are not strictly necessary with Maia
Mailguard, since you can add domains to Maia using the administration
interface, which effectively causes such domains to be treated as "local"
for amavisd's purposes. You will want to do this for all of the domains
you process mail for, even if those domains are downstream from your
server.


12. (Re)start amavisd-new

In case there's already an amavisd-new process running, you can make sure
it's stopped and the new version started by typing:

[root]# /etc/rc.d/init.d/amavisd restart

Now amavisd should be connecting to your new database to look up user
settings and whitelist/blacklist configurations, as well as logging
quarantined items to the database. Check the amavisd logs to make sure
of this. If you see errors in the logs about failures to connect to the
database, double-check the @lookup_sql_dsn line in your /etc/amavisd.conf
file.

If everything looks good in the log files, you can turn the $log_level
back down to something less noisy (e.g. 0, 1, or 2). Reload (or restart)
amavisd again to make this change take effect.


13. Login and become the super-administrator

Since in our example we installed the Maia Mailguard scripts in /mail
relative to the document root of our web server, the scripts themselves
should now be accessible at:

http://www.example.com/mail/

This is where you (and your users) will go most of the time to login to
Maia Mailguard. This first time, however, you'll want to do something
different in order to register yourself as the Maia Mailguard
super-administrator. Do this by going to:

http://www.example.com/mail/login.php?super=register

You'll be presented to the login page as usual, but if you login
successfully and no other user in the database currently has super-
administrator privileges, you'll be assigned these privileges. You only
have to do this once; after that, you can login just like any other user,
and your super-administrator privileges will be granted to you
automatically.

NOTE: If you selected the internal authentication method, you'll need to
get yourself a temporary username and password to login with. You can get
this by visiting the internal-init.php page. This script will only run if
there's no super-administrator defined yet:

http://www.example.com/mail/internal-init.php

The internal-init.php script will create an account for you, and you
should received an e-mail from Maia that contains your temporary login
credentials. Use these at this stage to login, and change them from your
Settings Page.

As super-administrator, you have all the privileges of administrators
(e.g. "impersonating" other users, and deleting users), but also the
ability to grant administrator privileges to others (and revoke them,
if desired). Maia Mailguard only allows one super-administrator account,
but there can be as many administrators as the super-administrator wants.
The super-administrator cannot be deleted, and cannot have his privileges
revoked by anyone else. Should the super-administrator ever wish to give
up his privileges, he has to do so by logging in at:

http://www.example.com/mail/login.php?super=unregister

Note: after a super-administrator "unregisters" himself, the system
effectively has no super-administrator, so the next user to login with
the ?super=register argument will become the super-administrator. My
suggestion, then, is to ensure that super-administrator privileges are
handed off to someone else quickly--have the current super-administrator
"unregister" only when the new candidate is ready to "register".


14. Configure Maia Mailguard: System Configuration

Now that you've logged in successfully as the super-administrator, you
can finish configuring Maia Mailguard by going to the [Admin] link on
the toolbar (the "key" icon). The System Configuration link from there is
where you'll find the rest of the system-wide settings you'll want to
adjust before Maia Mailguard "goes live". The help file in the
Administration Menu provides more detailed explanations of all the
configuration options available to you there.


15. Customise the help page

A stock help page for end-users is provided in the help.php file, which
describes the various settings and their implications, as well as how
the whitelist/blacklist settings work. If you wish to modify this file to
add some site-specific information, extra tips, etc., this is the time
and place to do it.

The text of the document itself can be found in the "localized" version
of the help file (e.g. the English version is in ./locale/en/help.php).
You can edit the text there if you have minor changes to make, but if you
have major changes in mind, you can completely replace the help page
itself without breaking anything.


16. Customise the e-mail templates

If you want to enable the sending of e-mail reminders to users when
their quarantines/caches start to get large, you may also want to edit
the reminder.tpl file or create your own new template, using some of
these placeholders:

Placeholder		Expands To
==========================================================================
%%VIRUSCOUNT%% 		Number of viruses in quarantine
%%SPAMCOUNT%%		Number of suspected spam items in quarantine
%%BANNEDCOUNT%%		Number of items with banned file attachments in
			quarantine
%%HEADERCOUNT%%		Number of items with invalid mail headers in
			quarantine
%%VIRUSSIZE%%		Total size of all viruses in quarantine
%%SPAMSIZE%%		Total size of all suspected spam items in
			quarantine
%%BANNEDSIZE%%		Total size of all items with banned file
			attachments in quarantine
%%HEADERSIZE%%		Total size of all items with invalid mail
			headers in quarantine
%%MAIAURL%%		URL users should visit to login to Maia Mailguard
%%ADMINEMAIL%%		E-mail address of the mail administrator
%%EXPIRYPERIOD%%	Number of days items are allowed to live in
			quarantine
%%OLDESTITEMTTL%%	Number of days before the oldest quarantined item
			is deleted
%%OLDESTITEMAGE%%	Age (in days) of the oldest item in quarantine

If you're using the internal authentication method, you'll also want to
configure the newuser.tpl template, which Maia sends to new users when
their accounts are created.

The newuser.tpl template is used to send a new user his temporary login
credentials, and supports the following placeholders:

Placeholder	Expands To
=================================================================
%%LOGIN%%	The new user's temporary login name
%%PASSWORD%%	The new user's temporary password
%%LOGINURL%%	URL users should visit to login to Maia Mailguard
%%ADMINEMAIL%%	E-mail address of the mail administrator


17. Schedule the maintenance scripts

You'll want to schedule some of the provided maintenance scripts to run
at regular intervals to do things like learn from (and optionally report)
confirmed spam, as well as expiring old items from the quarantine and the
ham cache, and sending e-mail reminders to users whose quarantines/caches
are overflowing.

It's important to note that these scripts must be run by the amavis user,
due to the security precautions we took earlier, so these scheduled jobs
should be added to the amavis user's crontab, and not root's.

process-quarantine.pl should be run about once per hour, to train your
Bayes database and report any spam your users have confirmed.

stats-snapshot.pl should be run at the beginning of every hour, to take
a snapshot of your stats table and update certain counters that are used
to generate graphical charts.

expire-quarantine-cache.pl should be run once per day, to expire
unconfirmed spam and cached ham that has exceeded your specified age
threshold.

send-quarantine-reminders.pl should be run once per week or so, to remind
neglectful users to check their quarantines and ham caches if they exceed
your size or item count threshold.


18. Join the Maia-Users mailing list

Support for Maia Mailguard is handled on the Maia-Users mailing list.
That's where you can get your questions answered and find out about any
known bugs in the current release, along with workarounds and patches. If
you don't want to subscribe to the list, there are archives available as
well, but if you want to post to the list you have to subscribe first.


19. Educate your users

Maia Mailguard quarantine management features offer users some control over
how their mail gets scanned and/or filtered. However, Maia Mailguard only
offers these features to users who have logged in (and therefore registered
themselves in the database), so it's important that you inform your users
about the new system you've installed, and how to use it. Point your users
to:

http://www.example.com/mail/

(or whatever base URL you chose to install Maia Mailguard scripts at), and
encourage them to contact you with any questions they may have.


20. Contribute to the project

The Maia Mailguard project, like many free and open source projects, is the
work of volunteers who contribute their time and effort to produce something
that others can benefit from. Without the contributions of volunteer
programmers, testers, financial sponsors, and license purchasers, a project
like this could never survive, much less evolve.

Volunteer to help with the coding of new features and bug fixes, if you
have some skill with PHP, Perl, and SQL. There's always room for more chefs
in this kitchen, and if you've got a particular feature in mind, perhaps
you'd like to develop it and contribute the patches back to the project.

Provide feedback in terms of bug reports, feature requests, and general
comments about the project. This kind of feedback helps drive the project
and focus its direction. Don't just point out the things you don't like,
though--it's equally important that we hear about what you do like about
Maia Mailguard.

Donate to the project, using the PayPal button at the bottom of any of
the pages on the Maia website.  I'm not a rich man, and the money I
receive from donors like you buys me time to spend working on Maia
Mailguard, when I would otherwise be forced to focus on other paying
work.

Buy a Rebranding License to help support the project and give your
business the right to embed Maia Mailguard into its own web application.
License purchases also get you a receipt for expense purposes.

Sponsor the project, in return for advertising and goodwill, by making
regular financial contributions.

Spread the word about the project, add your own testimonial, or add
yourself to the list of Maia users and/or the list of service providers
using Maia.