[ On Wednesday, October 18, 2000 at 10:05:34 (+0100), John Sloan wrote: ]
> Subject: Re: [Exim] Failing behviour based on SMTP codes.
>
> responses, so we're only saving people with badly behaved systems. Not
> worth it.
Yes, that's an excellent summary of what I said in the unquoted part of
your reply! ;-)
> I have sympathy with this viewpoint, but I don't think it is as true as
> you might think. There are yet still excellent reasons for having backup
> MXes.
>
> A common one is for a dial-on-demand or ISDN type corporate connection to
> an upstream ISP, which is the case I'm interested in. The primary MX is
> intermittently connected. The backup MX is always available.
This is a rather silly and possibly expensive use of a secondary MX,
especially if the connection is down any appreciable amount of time. If
the connection is dial-on-demand then the one and only primary MX should
be the ISP's server and some other batch mode transport mechanism
(i.e. other than MX records), such as UUCP should be used to direct the
e-mail to its final destination when the connection is established.
Note that any mail delivery attempt while the connection is down will
cause unnecessary delays from the sender's point of view. If the
secondary host ends up handling most of the domain's e-mail then it
should be the one and only primary host, not a secondary.
> There are also still parts of the world where connectivity remains
> intransitive (A can see B and B can see C but A cannot see C) where backup
> MXes can help.
If I understand your example correctly These situations do not require a
*secondary* MX. The MX which can be seen by the whole world all at one
time can be the only advertised MX. Indeed as with the above scenario
the advertising of `unreachable' hosts as primary MXers will only slow
things down enormously for any mail comming from the outside world.
So, there are still rarely any reasons to ever use a *secondary* MX, and
*MANY* reasons to avoid them like the plague they can be!
(Note that of course there can be many reasons to use several equivalent
priority MXers.)
--
Greg A. Woods
+1 416 218-0098 VE3TCP <gwoods@???> <robohack!woods>
Planix, Inc. <woods@???>; Secrets of the Weird <woods@???>
