Subversion Repositories greylisting

[/] [trunk/] [sendmail-perl-milter/] [relaydelay/] [INSTALL] - Rev 149

Compare with Previous | Blame | Download | View Log


PREREQUISITES:

1. Make sure you have a version of perl with threading compiled in.  I 
   recommend at least 5.8.0.  If for some reason you want to keep an older 
   version of perl for your system, just build a new threaded perl somewhere 
   and call it directly when starting the perl script.  
   Note: Perl 5.8.2's threading support seems to be a lot more stable than i
   5.8.0, at least in our test environment.
2. Make sure you have Sendmail 8.12.x with the milter interface compiled in, 
   and the milter libraries installed.
3. Make sure you have a functional mysql database server, I recommend later
   subversions of 3.23.xx.  Or better yet, get 4.0.
4. Grab Sendmail::Milter and build and install it.
5. Make sure you have the perl DBI modules installed, plus the DBD::mysql.


INSTALLATION:

1. Modify relaydelay.conf to your liking and drop it in the default location
   of /etc/mail, or pass the location of the config file as the parameter 
   when starting the milter. 
   I suggest you make it readable only by root so local users can't see the 
   user and password used for the database.
   
2. Configure the database using the commands in mysql.sql.  Make sure that
   you created the user defined in the config file, and that that user has 
   access to login from the machine you're running the milter on, and that 
   the login and password match those configured in relaydelay.conf.

   Also make sure your database can handle enough total connections as you
   are may have milter threads running.  Each thread the milter starts has 
   its own db connection.  While you can limit the number of threads one
   instance of the milter will spawn, keep in mind that if you have more 
   than one machine pointed at the same db, you will need it configured to 
   handle enough total connections for them all, and any other tasks you i
   have using the same db server.
   
3. Add the milter config to your sendmail.mc and rebuild your sendmail.cf.
   An example set of config lines (using the defaults for relaydelay) is:

   define(`MILTER',1)
   INPUT_MAIL_FILTER(`relaydelay', `S=local:/var/run/relaydelay.sock, F=T, T=S:1m;R:2m;E:3m')dnl

   Note that the define line is only required if it's not already in the 
   config file somewhere.  It's probably already there if you're using 
   another milter like amavis with spamassassin (which is recommended).

   If for some reason the milter is unavailable, with the lines above, the 
   F=T parameter indicates that sendmail should tempfail any connections if 
   it can't communicate with the filter.
   
   If you want to have sendmail just ignore if the milter is unavailable,
   simply omit the "F=T, " parameter from the INPUT_MAIL_FILTER line above,
   and sendmail will process any mail as if the milter wasn't configured
   for as long as the milter is unavailable.

4. If your mail system gets a mid- to large- amount of either spam or "real"
   mail, you may also want to limit the number of sendmail children to a 
   reasonable number if you haven't already done so.  To limit this, add 
   something like:

   define(`confMAX_DAEMON_CHILDREN', `40')dnl

   to your sendmail.mc.  Adjust the limit as appropriate for your normal
   level of email.

5. Make sure the script has the execute bit set, and test the configuration 
   by opening another window and running relaydelay.pl.  If the 
   relaydelay.conf file is located somewhere other than the default 
   /etc/mail/ directory, simply specify the file location as the only 
   parameter.

   Or, if you built a threaded perl somewhere else that isn't the system 
   installed perl, run something like:

   /usr/src/perl-5.8.0/perl relaydelay.pl [optional config file]

6. After you see mail being processed and entries being created correctly,
   then you probably want to make sure $verbose is turned off, and put 
   the startup of the script into your sendmail start script(s).

If you will be doing initial install learning by setting the $delay_mail_secs
configuration parameter to zero, you may also want to reduce the lifetime of
the successful transmission records so that you don't pollute the database
with too much spam.  And don't forget to change them back to normal values
after a few days of learning runtime.  

To perform nightly maintenance on the database table (keep it pruned for
speed reasons), add the db_maintenance.pl script to your nightly
crontab.  Note that no records should be lost, as before they are deleted
from the active table, they are copied to the reporting table.

UPGRADING:

If you are upgrading from a prior version, please make sure that you 
have updated your config file to reflect the new available options, 
and that the socket name specified in the relaydelay.conf file matches 
the socket name in your INPUT_MAIL_FILTER line in your sendmail config.


Enjoy!

Compare with Previous | Blame | Download | View Log