The main Spamikaze configuration file (the php web scripts use their own config file) uses the well-known .ini format. The example configuration file can be copied to /etc/spamikaze/config or ~/.spamikaze/config. The configuration file is split into multiple sections, which are described here.
Database
This section of the configuration file specifies which database Spamikaze connects to. Note that the Type keyword corresponds to the DBI perl module name, which could be DBI::MySQL or DBI::mysql depending on your version. For postgres the module is DBI::pg, resulting in Type = pg. Which Spamikaze database layout you want to use can be chosen with the Schema option.
The Host and Port keywords correspond to the host on which the database is running and the network port at which the database is listening. The Name keyword indicates the name of the database Spamikaze should use, while Username and Password are used to authenticate with the database server.
Example:
[Database] Type = mysql Schema = MySQL_2 Host = localhost Port = 3306 Name = spamikaze Username = spamikaze Password = s3kr1t
This section of the configuration file indicates what Spamikaze should do with incoming spam. The IgnoreRFC1918 parameter tells Spamikaze skip over local network addresses when searching the Received: headers for the IP address to blocklist; leave this option on unless you know what you are doing.
If IgnoreBounces is set, Spamikaze will ignore messages that look like bounces. This should help reduce the false positives on a general purpose Spamikaze DNSBL. However, since spam bounces can be very abusive if received in big quantities, some people may want to switch this option off and block hosts sending out bounces...
By far the most important option in this section of the Spamikaze configuration file is BackupMX, which indicates exactly which IP addresses are your MX servers. Spamikaze will never blocklist any of the IP addresses in this list. It is essential to configure the IP addresses of all your incoming mail servers (including servers that forward mail to you), otherwise there is a chance of Spamikaze blocklisting your own mail servers. Make sure the BackupMX list is complete!
In order to prevent Spamikaze from listing other high volume mail servers, which would lead to too many false positives, you can configure Spamikaze to use a number of WhiteLists, using the WhitelistZones config option. At spam parsing time, passivetrap will query the configured whitelists and skip the listing of any IP addresses encountered in such whitelists, in exactly the same way it skips IP addresses specified in the BackupMX config option.
Example:
[Mail] IgnoreRFC1918 = 1 IgnoreBounces = 1 BackupMX = 192\.0\.2\.1 192\.0\.2\.13 WhitelistZones = whitelist.surriel.com nlwhitelist.dnsbl.bit.nl whitelist.example.org
Expire
In this section you configure how many hours a host is blocked after the first spam (FirstTime) and how many hours a host is blocked for every subsequent spam (ExtraTime). Note that the ExtraTime parameter is cumulative; if a host sends 3 spams, it will be blocked for FirstTime plus 3 times ExtraTime, measured from the last spam that arrived. The cumulative extra listing time can be switched off by setting ExtraTime to 0.
If a host has sent more than MaxSpamPerIp messages into the spam traps, it will not be expired from the list automatically; in order to remove the IP address from the list, somebody will have to request removal using the web interface.
Example:
[Expire] FirstTime = 168 ExtraTime = 24 MaxSpamPerIp = 100
Note that database expiration is done by the expire script, so the Spamikaze user will need to run that script regularly, eg. by placing it in the crontab.
DNSBL
This section of the configuration file governs the creation of the bind zone file that holds the blocklist. The Domain keyword is the domain of your DNSBL, which will also need to be configured into your MTA.
The ZoneFile keyword determines where the named script puts the zone file and the TTL keyword specifies the time-to-live of the DNSBL entries in your zone. Note that in order to avoid excess DNS queries, the other entries in the zone (eg. the NS records) have a much longer TTL.
UrlBase specifies the URL mentioned in the TXT record; this allows people whose email bounced to visit the web page of the DNSBL. This way people can see why their mail servers got listed, and they have the ability to remove their mail server from the blocklist. For the IP address 192.0.2.3 the query results would look like this:
$ host -t any 3.2.0.192.spamikaze.example.com 3.2.0.192.spamikaze.example.com has address 127.0.0.2 3.2.0.192.spamikaze.example.com text "http://spamikaze.example.com/cgi-bin/listing?ip=192.0.2.3" $
The PrimaryNS and SecondaryNSes configuration variables are used to specify the name servers for your Spamikaze zone. The PrimaryNS keyword is also used in the construction of the zone's SOA record.
Example:
[DNSBL] Domain = spamikaze.example.com ZoneFile = /var/named/master/spamikaze.example.com.zone TTL = 300 UrlBase = http://spamikaze.example.com/cgi-bin/listing?ip= PrimaryNS = ns.example.com SecondaryNSes = ns2.example.com ns.example.net
Spam Archiving
There are two options to archive spam. The first is to have Spamikaze connect over nntp to inn, and temporarily archive spam in a news group. News servers are very efficient at storing up to a fixed amount of spam, and automatically expiring old messages. The first step is to do is ensure your Spamikaze system is allowed to post to the news server, by editing /etc/news/readers.conf and running the following command to create the Spamikaze news groups:
for i in notspam `seq 0 255` ; do
/usr/lib/news/bin/ctlinnd newgroup spamikaze.$i y your@email.tld
doneSpamikaze can be pointed at the news server by editing the [NNTP] section of the Spamikaze config file:
[NNTP] Enabled = true Server = news.mydomain.tld Groupbase = spamikaze From = spamikaze@mydomain.tld
The second way to archive spam is to feed it to a helper program on STDIN. This is achieved with the [Pipe] config section:
[Pipe] Program = /patch/to/helper-program
Web
This section is used to configure the web scripts. For details, please see the SpamikazeWebScripts page.