On Mon, Jan 29, 2007 at 03:14:51PM +0100, tdldp wrote:
> I'm using since a certain time exim 4.x (we are on 4.63 and will be
> upgrading soon), with no difficulty really, setting up RBL and other rules
> for our personnal usage..
> Yet i now wish to setup a secondary mx on a second server we have... (We
> have had on primary server a 4 hours downtime, and saw that we lost certain
> messages)
>
> My problem is, i have found nowhere a tutorial on how to set this up...
> I am therefore asking community for a clean "what to do" in order to setup a
> proper secondary MX on the second server i have...
>
> Must i install a second exim on this server ??? Must i change configuration
> on both servers (in order for primary to receive messages) ???
> What are the security advices (i have concerns on open relay servers, and
> rbl non listing we have managed to cope up to know) ???
Yes, you should install Exim on that other machine; that's sort of the whole
point of another mail server, to have another mail server... :)
The primary machine generally doesn't need configuration changes when you
introduce a secondary. The secondary machine can start off with a copy of
the primary's config files, but with the local domains list changed into a
relay-to-domains list; that is, it should not keep the mails for your
domain, it should send them on. (It should, however, have its own hostname
in the local domains list, in order to be able to receive postmaster mail.)
As far as ACLs go, you need something like this:
domainlist relay_to_domains = CONFDIR/relay_domains
acl_check_rcpt:
[...]
require domains = +local_domains : +relay_to_domains
[...]
warn domains = +relay_to_domains
!verify = recipient/callout=40s
deny domains = +local_domains
!verify = recipient/callout=20s
accept
You could change that first 'warn' into a 'deny' if you guaranteed equal
uptime for both machines; but since the most common purpose of secondary MXs
is to actually catch mail when the primary MX goes down, this dependency
would defeat the whole point.
A side-effect of only warning on recipient callouts will be some bounces,
but it's usually bearable. If not, figure out a way to export a list of
recipients from the primary, regularly transfer it to the secondary, and
use it there for definitive lookups.
Another useful thing to do is to extend the retry strategy for the domains
you're relaying to, for example:
relayeddomain.tld * F,2h,15m; G,16h,2h,1.5; F,4d,6h; F,8d,12h
Notice the final 8-day pattern - just in case the primary doesn't wake up
within the regular four days.
On the secondary, use the same anti-spam settings that you have on the
primary MX, otherwise you'll have the queue filling up with excess trash on
the secondary, and wasted CPU time on both. Don't change anything on the
primary MX that would favour the secondary; in fact, experience would
suggest that it's better to explicitly mark it as non-privileged, in order
to avoid spam. Make sure that the secondary's IP address is not in
relay_from_hosts hostlist on the primary; exclude it if so.
Test delivery logic on the secondary machine with
exim -bt foo@???, and if it shows that it'll go to the
primary, you're all set. Change DNS to add the new machine's address to
the relevant MX records with a lower priority (a higher number).
--
2. That which causes joy or happiness.
