OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: Re: Backup MX configuration
From: Wietse Venema (wietseporcupine.org)
Date: Mon Feb 14 2000 - 14:51:09 CST

The permit_mx_backup restriction looks at the DNS, not at the
relay_domains parameter. If a host lists you as their backup,
then permit_mx_backup will accept the mail.

Re: faster flushing: you can tweak the {min,max}imal_backoff_time
parameters.

        Wietse

Kenn Martin:
> Yes, it has been working, my question was more along the line of
> "Can I make the backup MX try the primary MX more frequently, or
> with less backoff, without adversely affecting communicating
> with other servers on the internet?"
>
> But thinking more about how my backup MX is really used (backup-only)
> I should probably be able to do whatever I want.
>
> As for other people using it without permission, won't my list in
> "relay_domains = $mydestination, $config_directory/relay_domains"
> prevent that? Yes they can specify my machine as a backup, but
> I will reject everything, correct?
>
> Thanks,
> Kenn
>
> On Mon, Feb 14, 2000 at 03:18:12PM -0500, Wietse Venema wrote:
> > If you use the permit_mx_backup feature, then you should be all
> > set. The only problem with it is that people can list you as backup
> > relay without your permission.
> >
> > Wietse
> >
> > Kenn Martin:
> > > 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
> > >
> > >
> > >
> >
> >
>
> --
> Kenn Martin
> InfoTeam 606.335.7233 888.463.6482 http://infoteam.com
> Nationwide Access for only $12.95/month! http://infoteam.com/access
>
> Thousands of free hits and you could win ONE MILLION!
> http://infoteam.com/hits
>
>
>