[prev in list] [next in list] [prev in thread] [next in thread] 

List:       exim-users
Subject:    Re: [Exim] MX host to bypass RBL...
From:       woods () most ! weird ! com (Greg A !  Woods)
Date:       1999-07-30 16:27:39
[Download RAW message or body]

[ On Friday, July 30, 1999 at 01:33:05 (-0700), Pete Naylor wrote: ]
> Subject: Re: [Exim] MX host to bypass RBL...
>
> On Fri, 30 Jul 1999, Philip Hazel wrote:
> > On Thu, 29 Jul 1999, Greg A. Woods wrote:
> > 
> > > Why do you think you need a backup MX host that's not within your own
> > > administrative domain?
> > 
> > There is one possible advantage, which is that all your pending mail 
> > ends up queued on a single host during an outage. This means that, when
> > you do come back up again, you don't have a zillion hosts all trying to 
> > make TCP/IP connections at once. (This has been known to bring down 
> > machines not configured to cope gracefully with such a load.) 
> 
> Another advantage might be that when your host is returned to service, you
> ideally have the ability to cause a queue run on the backup MX - this
> effects a quick delivery of all the backed up messages.  Otherwise, it
> might be several hours or more before all of those other remote mail hosts
> run their queue and attempt delivery of the messages again.

Those are both really just aspects of the same feature.  ;-)

In any case they are both vastly outweighed by the fact that by
definition you don't have any control over a backup MX that's outside
your own administrative domain.

You cannot apply your own security or usage policies to such a secondary
MX host.  You can't even specify what kind of softare such a host might
run.  Doing SMTP-level spam rejection (e.g. RBL-style lists), or other
kinds of SMTP-level verification and validation, is right out of the
picture.

If you really need a backup MX for a disaster scenario you'll probably
know about it at the time.  At such time it should be possible to find a
friendly postmaster *anywhere* on the Internet to serve as such a
backup, and of course you'll already have arrangements with one or more
of your DNS secondary providers to switch your DNS over from being
secondary to primary so that you can make such a change when necessary
(and if not then hopefully they're sympathetic to your plight and will
jump through some hoops to help you out).

Note that if you're going to have an outage that's long enough that
e-mail might expire from the sending MTA's spool, then it's just as
likely that it'll expire from your backup MX's spool too, so you'd have
to make special arrangements to keep it longer (or deliver it all to a
single mailbox, etc.) anyway.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>

[prev in list] [next in list] [prev in thread] [next in thread]