[ On Wednesday, November 12, 2003 at 19:32:29 (+0000), Ollie Cook wrote: ]
> Subject: Re: [Exim] secondary MX in a world of spammers
>
> The process would have taken a great deal longer and would have gone much less
> smoothly if the email had been queued at N remote sites each with their own
> retry algorithms.
I'm afraid you're not seeing the bigger picture there. In fact having
the "backed up" e-mail queued and then delivered directly from the
originating sites would have been almost no different than had the mail
server not gone down and those sites had simply delivered the mail
immediately when it became available to be delivered. Even if your
primary MX downtime is stretched to the limit and mail is near to
bouncing (e.g. two days or more), the additional load imposed by having
all the normal SMTP peers deliver all their delayed mail is negligible
compared to the capacity you MUST have anyway to deal with the normal
burstiness and unpredictability of SMTP traffic. Furthermore you MUST
also already have appropriate controls in place to moderate the normal
incoming traffic and those controls will allow your SMTP peers to
deliver their delayed queue contents at the maximum speed you have
capacity to handle.
I have seen several cases, recently, where mail backed up on a secondary
MX actually took much longer to deliver than when the secondary did not
exist. Meanwhile after the secondary was removed and the primary again
had extended downtime it experienced no more than an ordinary "busy"
day when it was brought back online again.
I'm not an expert in operational and queueing theory to explain why I
say what I say is true -- but I do know enough of those theories to
understand that what I've observed is backed up by the theory and that
what you're saying is just a lot of hand-waving and paranoia that's not
backed up by what we know today about operational and queueing theory.
> The only way you can be certain of ensuring continuity of service to your users
> is to make sure there is always some host under your administrative control
> which is available to accept messages. If you can 100% guarantee that your
> primaries will never be unavailable, then I suppose you could do without backup
> mail exchangers, but can you really make that guarantee ?
If you think for one tiny second that you are improving the service to
your users by using a secondary MX when your primary MX is capable of
even say 80% uptime over a month then you are seriously confused and
mistaken in your understanding of the nature of SMTP in a complex
real-world network environment.
If your primary MX is normally available (e.g. even just 80% uptime on
average) then you are in fact doing a disservice to the sender by
slurping up messages into a secondary MX at any time your primary is not
responding. The sender will believe that the message has been delivered
since it has disappeared from his local queue, but since it is now
sitting in limbo where neither the sender nor ultimate recipient can see
it they will, and do, perceive it to be lost. This I know from repeated
past experience in the real world with real users.
A secondary MX is really only useful as a means of improving e-mail
service if the primary is down for _very_ extended periods of time (at
least 48, or even 72, consecutive hours).
> If you have off-site, off-network backup mail exchangers, you can tell your
> users with some confidence, "We are receiving messages destined for you, but we
> can't deliver them to your mailbox yet. Your mail is not lost, just delayed.".
> If the messages are queueing on remote hosts, you can't make any guarantees
> whatsoever to your users.
On the other hand if you leave the e-mail queued in the sender's own MTA
then it is at least somewhere where the sender has the potential for
more direct control over its disposition. In your scenario your
secondary MX is holding all the e-mail hostage where nobody directly
involved in its submission or ultimate receipt can have any knowledge of
it, let alone control over it.
In general there is little, if any, real need for any secondary MX service.
--
Greg A. Woods
+1 416 218-0098 VE3TCP RoboHack <woods@???>
Planix, Inc. <woods@???> Secrets of the Weird <woods@???>
