Re: [exim] secondary MX: allow only a set of users

On 2007-12-28 at 15:32 +0100, Wouter Verhelst wrote:
> This will still work with receiver callout verification, for the very
> simple reason that callout verification is actually cached. It will be
> problematic to receive spam to non-existing email addresses which hadn't
> been seen before during the downtime of the primary, but that's a
> feature, not a bug.

The secondary won't normally be getting much legitimate mail whilst the
primary is up and working, just whatever might trickle through from some
place with weird connectivity problems to the primary MX. So the cache
is not going to be very warm.

Further, the callout cache has various expire timeouts.

So relying upon the callout cache as adequate is only going to even
partially "work" if you know when the primary is going down and put a
packet filter on it to only accept SMTP connections from the secondary
for a while ahead of time. This seems to be a practice with limited
utility.

For a secondary MX to be useful it needs to not depend upon the primary
and to know which recipients are valid for any given domain.

Really, it's not hard to adjust configuration build systems to push data
out to more than one place; if the config build is on the primary
system, then it's not hard to push out to a second place.

Heck, if anyone's using CDB files or other non-linear lookup type, then
hopefully they already have a tool set to build the data and can just
put "replicate with rsync over passphraseless SSH key" in as the last
step. Set that script as Exim's bi_command so that
"exim -bi"/"sendmail -bi" will do the right thing and you're laughing.

Where I've previously had to arrange for various people to be able to
edit config files, I had a script which did the "real" work run as a
dedicated user with the passphraseless SSH key (locked down on receiving
server side, of course) and a wrapper script which was bi_command and
that wrapper used sudo to invoke the real script as the right user.
sudoers had NOPASSWD: on the relevant item. Hey presto, configs built
as one consistent user, replicated with a key which the invokers can't
get hold of (unless they have root).

In the live production system for customer mail it was best to be able
to guarantee that all customer updates happened at once. A couple of
SSH connections, one of which did rsync (with --link-dest, I think; I
forget the details) and the other which would do the management of
sorting out updating the "live" config and cleaning up sufficienly old
copies of config; I think that I settled for the race condition of a
symlink update and 4xx delays for the relevant nanoseconds of missing
config. Atomic symlink replacement would be nice. *sigh* Multiple
machines in MX, multiple IPs, so clients would always just retry another
MX host and there was no outage.

-Phil