OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: Backup MX configuration
From: Kenn Martin (kmartininfoteam.com)
Date: Mon Feb 14 2000 - 14:04:28 CST

I am in need of a pointer for which config variables affect the
operation of a MX backup server and the timing of attempts to
empty its deferred queue. The backup's current `postconf -n` is:

command_directory = /usr/sbin
daemon_directory = /usr/libexec/postfix
local_destination_concurrency_limit = 2
maps_rbl_domains = relays.mail-abuse.org, dul.maps.vix.com, rbl.maps.vix.com
mynetworks = $config_directory/mynetworks
myorigin = $mydomain
relay_domains = $mydestination, $config_directory/relay_domains
smtpd_helo_required = yes
smtpd_recipient_restrictions = check_recipient_access regexp:$config_directory/c
heck_recipient.regexp permit_mynetworks permit_mx_backup reject_m
aps_rbl check_relay_domains

Both primary and secondary MXs are running snapshot-20000204, if it matters.

The question arose because I actually did a `postfix stop` prior to
upgrading the primary from 19991231-pl02 and there was about 22 minutes
elapsed from the `postfix start` to the time the backup connected to the
primary and emptied the deferred queue. The `make install` and subsequent
review of changes took about 4 minutes before postfix was restarted. I
realize that stopping probably was unnecessary, but the question is how do
we go about tuning the retry attempts on the backup MX?

The log on the backup MX only showed one "Connection refused (port 25)"
for each deferred queue file.

From `postconf -d` and the docs, the following look promising:

maximal_backoff_time = 4000
maximal_queue_lifetime = 5
minimal_backoff_time = 1000
queue_run_delay = 1000

From rate.html, I would expect that changing these to accomodate a
backup MX for brief outages in the primary MX would potentially cause
problems (or at least create extra overhead) when trying to connect
with external unreachable hosts. 

-- 
Kenn Martin
InfoTeam Lexington