mx vs ns
mij at bitchx.it
Tue Jan 20 10:37:54 PST 2004
On 20/gen/04, h 16:31, Olafur Osvaldsson wrote:
> I see nothing wrong with this setup as when a MX is down the
> mail gets queued at the sender server untill the MX is reachable
> again but NS requests don't queue up and people get impatient
> so multiple NS records are needed but not multiple MX.
Technically, this is not completely wrong.
Anyway, this way you rely on sender's service for solving possible
problems on your side. This is not good. The maximum age
for a message in the queue, the tryouts and retry intervals
are not specified in any RFC. Anyone can push the queue maximum
size lower, or shorten the max life of message in it. It's also possible
me to run a mta without a "hard" queue, just suddendly reporting
an error to the sender on failures, although rare.
This way you let your mail completely up to the sender's server
> Also, multiple MX servers makes more work for the postmaster
> in regard to filters and such in addition to be not needed.
Yes, of course more complexity implies more work.
A backup mx does not require very much work anyway.
You just have to choose a backup server and set it not to
"reject" mail for those domain. This way it will queue
messages for the master, and then try itself to deliver them,
making the sender's mx believe everything went fine.
So your mail is kept by a trusted server, the one you've chosen,
and you're safe because you do know how it will handle its
On a qmail server, for example, this would require seconds to be
set up, and probably no maintainance at all.
mx1.freebsd.org may have proven its stability over the years,
and this could suffice you to say "no thanks, the current solution
is enough for me".
Since a backup mx doesn't require the load of work of a dns server
(the are no syncs nor stuff like that) probably the compromise
would pend to this latter solution instead of leaving things like they
More information about the freebsd-hubs