Rev 97 | Blame | Compare with Previous | Last modification | View Log | Download | RSS feed
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!