l.rinetti@??? wrote:
> I need to install from scratch an MTA based on Exim4.
> Supposing to use:
> ClamAV
> Spamassassin
> Razor and Pyzor
> Courier Imap
> SA-exim
> could you recommend me the correct sequence of installation of these
> packages?
>
> Regards
>
> luciano
>
The term 'SA-Exim' refers to an older version. Provision for calling
scanner(s) has been built-in to 'Vanilla' Exim for several years now.
Please use the very latest release - there were some important security
concerns recently addressed.
===
Installation order is not as critical as order of startup.
Taking it in reverse order:
Exim *if* so configured, will expect to use ClamAV and Spamasassin.
Ordinarily it will 'defer' if they are not reachable.
So both should be installed and confirmed stable - and more importantly
- *started* before Exim is switched-on.
This is the only 'show stopper' of interdependency.
====
SpamAssassin in turn will utilize Pyzor and Razor if so configured, but
IIRC will proceed w/o stalling if it cannot find them.
======
Courier-IMAP doesn't care which MTA is used, (if any), so long as it can
use the mailstore. It expects, and prefers Maildir(++).
==========
Exim doesn't care which IMAP/POP (if any) is used, so long as it can use
the Mailstore. Exim can use any of several mailstore forms, including a
mixture.
Maildir(++) makes for a comfortable match to either Courier-MTA or
Dovecot, but it is not the only form they can use, so long as both the
MTA and IMAP/POP are in agreement on the type of mailstore and its
location, and both have usable permissions.
It is inconvenient if they are not both running, but not really a
show-stopper, because:
- If the MTA is offline, 'old' messages can still be accessed by the
IMAP/POP.
- if the IMAP/POP is offline, 'new' message will still be accepted and
transferred to mailstore by the MTA.
Other caveats:
- all IP and ports or socket-'seats' that any of the above are expecting
to use must be available AND NOT prohibited by perms or firewalled off
from their use.
- all files any of the above require must be available. Check also their
perms.
- all SSL/TLS certs (and keys if not concatenated) must be available.
- Refresh mechanism for ClamAV (freshclam) and SpamAssassin & sputniks
should be run 'first', and periodically thereafter, but this usually
will not require your intervention. Do check that they are run
'sometime' ELSE these worthies get out-of-date and newer phish can swim
through.
- any DB any of the above players will utilize needs to be available.
DB/BDB, GDB, cdb, SQLite look like files to their 'customers' and are
not generally an issue w/r 'starting'. They just have to be in place..
Any 'daemonized' RDBMS, OTOH (MySQL, PostgresSQL, DB2, Oracle, et al)
should be started first and stopped last. Some of these need a bit more
time than others. Or a great deal more money.
;-)
In general, it all 'JFW' if you make sure the players agree on paths and
privs.
That area is the one most likely to need your intervention - insuring
that paths to shared resources and Unix sockets match, and that perms
and privileges agree with the needs of the players which share them AND
NOT open the door to remote (or local) exploits.
Useful tools:
Tail -f -n 200 <a main, panic, or system messages log>
.. will usually show you what is complaining that it 'cannot...'.
See also 'exiwhat' and exim's debugging - pure magic at showing all that
can be known.
Likewise the ability of various players to be started and run in the
foreground, not detached, and/or with verbose debugging.
After more years than most, I had to do this with Dovecot just last
night .. had made a simple error on paths to the SSL certs during
migration from FreeBSD 7.x to OpenBSD 4.9
Don't let it frustrate you!
Once sorted, it can run for multiple years w/o intervention.
That said - frequent attention to security advisories and regular
upgrades are *highly* recommended. MOST (not all) just 'drop right in',
needing nothing more than a restart.
HTH,
Bill
