kyle-qmail at memoryhole
Aug 18, 2009, 6:30 PM
Post #4 of 5
(1812 views)
Permalink
|
|
Re: Validity of Having Secondary MX Servers
[In reply to]
|
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Tuesday, August 18 at 04:12 PM, quoth Ken S.:
> This is something that's been on my mind for a few years now, and I
> would like to know what other's opinions are about having secondary MX
> servers.
I've actually thought a lot about this, usually in the context of
people doing it wrong or for idiotic reasons.
The fundamental question here is: what is the purpose of having
secondary MX servers? Since SMTP-compliant senders are already
required to queue undeliverable messages and retry later, the primary
benefit of a backup MX is to reduce latency in catastrophic
situations. For example, you may have an arrangement where you can
tell the backup MX to deliver all of the messages it is holding for
you all at once as soon as your primary email system comes back
online. That way the messages get delivered as soon as you're ready,
rather than waiting for all the myriad of senders to realize that
you're back online and retry---which, depending on their retry
schedules, could take hours.
Now ask yourself, what would take your primary email system down?
There are two major categories of reasons: things that take your whole
network down (power outages, network outages, etc.), and things that
take your single system down. A backup MX only makes sense to deal
with the first category, not the second. In the case of a single
system failure, why have the "backup" MX be a "backup" rather than in
use with the same priority as the "primary"? Giving it the same
priority increases your ability to transparently handle spikes in
email traffic, and generally reduces message latency by reducing
single-system average load. Given that, having a backup MX as simply
another server in the machine room (with a less preferable MX record)
is ridiculous. Having a backup MX with an entirely independent power
supply and an entirely independent network in an entirely different
location is an effective backup.
So now we know the situation a backup MX is good at addressing: it
reduces message delivery latency when your entire network is down for
more than an hour. And that's assuming you have an arrangement with
that MX so that you can get it to quickly deliver all the messages
it's holding for you.
Is that a situation you're worried about? Is the latency of that email
critical? If so, then a backup MX is a useful tool. If not, especially
if you simply have multiple email systems in the same room on the same
network, then it is more useful and more effective to give them all
the same MX priority.
> 1) do you maintain secondary MX servers and continue to do so? If
> so, any advice on how to keep them up with minimal spam connections?
No, I don't maintain secondary MX servers.
> 2) did you at one time maintain them, but later stopped? If so, how
> has it affected you and your customers?
Once upon a time, I worked for a company that had an arrangement with
our ISP to provide backup MX service, such that if our building lost
power, they would hold our mail for us. We never had to use it, but...
it was a very cheap insurance policy. At the time we had it set up
that way simply because it was considered "best practice" to have an
offsite backup MX. But if I was in the same position today, I probably
wouldn't opt to do it.
These days so many people (particularly spammers) play games with MX
records that they're less worth maintaining than they ever used to be.
At least, that's my opinion.
~Kyle
- --
It is an established maxim and moral that he who makes an assertion
without knowing whether it is true or false is guilty of falsehood,
and the accidental truth of the assertion does not justify or excuse
him.
-- Abraham Lincoln
-----BEGIN PGP SIGNATURE-----
Comment: Thank you for using encryption!
iQIcBAEBCAAGBQJKi1WzAAoJECuveozR/AWehtgP/ierJLfFZyEsrIjoLzShbXK9
vetyYYKAUsWnQLmck6bVrtLi9mGPHc4upgtMIN1/qq7wyv41rxFvR+cbSiLhttgG
02N3XeWm/9UBthFO6CmsuXpmGIOaQ91ZE97zZsVXqWS6Fz495cxn0mPQCGcKrf8u
vmKDOYs29ZRcl2jAj2vq2z/TtHzyXFp8PhO7tpA2DqyCEvpbncCquZinp5yE4qvp
sMRoK39bmZqojY9L6pMpJ4AMGRcUZD8bMEt6Hk6AdDdTMeXaRAx4ZRS6S6dQwwX0
NVtWc75+aAEvNmW/5mjqvlDvh2v7XJi1zz+UpUcTqxI+MZEQxvx9/3dRzjWcxVnI
2zLt2XhQurv6UcYFuObAz2T0GajDZfhl4KKfnHRDe1R67WUD4dkGvXnlIOR3+Lj6
jIkxNY1/L6vak10jTH0uazbCn/chpSq6bV/UiKVh9z0SIk0IA1W+II9h1t7yhE/H
qp29bsYL12f3zGFrroaByXbYrB/QE2rA+cSS74IiVB8P+kf4L8XGzvt5iO9ZfOhG
aN5s/uM49NP50OQqBoCSfMFPasaicWCSavzzasvYkSlyKq49NuPB/Kib6kSKC3bH
lqfcPeAhHVH6Z4cJNwpF9ve0b/lyuwcDtTG/Nq3kOUCyYFJM1w/eozOuEIzUOKJH
gsr3pb3YCpfhPqvfjRzx
=SZmY
-----END PGP SIGNATURE-----
|
