Well the main thing I can say is don't share secondary MX with other
services. I've seen it happen many times where an ISP does secondary MX for
a downstream (perhaps on ISDN) mail server. That mail server gets
mailbombed, and becomes unreachable. Now the attack moves over to take out
your server too. If you put secondary MX on a box by itself thats fine, but
often people share it with a web server or something, and the box is
hammered by the attack moving over to the secondary...
----- Original Message -----
From: Efg� <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, May 08, 1999 10:44 AM
Subject: Re: secondary MX
> Thanks for all your answers.
>
>
> > I didn't see your explanation of the problem that you expect to solve
> > with a secondary MX record, though.
>
> Oh right, now I remember that a number of you people are against the use
> of secondary MX. Could you restate your reasons ? Have you had by
> experience with them ?
>
> Would you also hold the same position against an _intelligent_ secondary
> MX that could do mail distribution exactly like the primary (but this
> was not the point of my original question).
>
> Basically, I think I'd rather have a secondary MX because I'd rather
> have mail queued at my end than at sender's end, where I don't control
> delay before bounce, queue reliability, and so on.
>
> Also, if I remember well, you stated that secondary MX was even
> unnecessary in the case of service outage on the primary due to
> maintenance, given that mail will wait at the other end. Again, I'd
> rather have mail wait at my end. Maybe this is a misguided attempt at
> controling too much ?
>
