On Wed, Nov 12, 2003 at 06:49:43PM +0000, Tony Finch wrote:
> This argument assumes that your primary MX is sufficiently unreliable
> that you need some kind of local backup in addition to SMTP's built-in
> resilience. I would focus on reliability before worrying about backup MXs.
Hi Tony,
No matter how much effort you put into designing and implementing a reliable
primary MX platform, unforeseen outages are always going to occur, albeit
rarely. It's on these rare occasions that backup mail exchangers come into
their own.
The mail platform under my control is a commercial one, and I can appreciate
that some of my considerations for its design may not apply to all people or
all sites, so you may disagree with some of the points I am about to make.
Luckily the mail platform in question has not had its lowest priority component
wholly unavailable for some years. However, the last time this happened (and my
memory's a little sketchy since it was a long time ago), the volume of mail
that was queued on the backup mail exchangers was quite considerable. Being
able to manage the flow of this email back to the primary platform in a
controlled way when it became available again was invaluable.
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 am afraid you seem to put too much faith in other sites and make unrealistic
expectations of them. You can only really trust yourself! Of course remote
sites would ideally queue mail for you for quite a long time (a few days at
least, hopefully), but this is not always the case. I have come across some
sites which would only retry deliveries for a few hours before giving up on the
message.
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 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.
> The biggest problems with backup MXs are that they must implement the same
> security policy as the primary MXs, and they must work when things are in the
> shit despite the fact that they can be broken most of the time without anyone
> noticing. The first requirement has serious implications for resource-heavy
> SMTP-time checks,
You are correct. But I don't class it as a "problem", more a "requirement". The
backup mail platform will be a duplicate of the primary mail platform with one
exception (it will try to deliver to the lowest MX rather than do a local
delivery). In every other sense the policy must be the same.
The backup platform needs to be of a similar specification to the primary to be
able to apply the same content controls and inbound mail policy. For some
sites, I appreciate that this may not be a realistic business proposition.
However, I would say the expense is worth it to ensure continuity of service to
users to cater for the rare occasion of a total failure on the primary
platform.
> and even if you only have lightweight checks you must still have a lot of
> control over the machine in order to verify addresses etc. The second
> requirement puts heavy demands on your update and testing procedures -- I see
> little point in a machine that requires sysadmin time without doing much
> useful work.
If you automate policy, such that they are replicated on the backup platform,
this isn't much of a concern.
Cheers,
Ollie
--
Oliver Cook Systems Administrator, Claranet UK
ollie@??? 020 7903 3065
