mx vs ns

[Olafur Osvaldsson]

Mij,

On Tue, 20 Jan 2004, Mij wrote:

> 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 
> strategy.

The sender should hold onto the mail untill the recipients problems
are solved, secondary MX doesn't help with delivering sooner, and
the mail is also the property of the sender untill delivered and if
he wants he can set the queue to zero...

> >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
> delivering.

It is not always possible to run a secondary MX on a trusted server
outside your network...and if run on your own network it is mostly
useless.  And if the secondary MX is not run by the same person then
it can't be trusted.

Also if you don't apply all the same filters to both boxes then lots
of unwanted email such as SPAM wich normaly would be stopped by the
filters on the primary MX would get in as the primary trusts the
secondary and can't lookup the remote hosts on rbl lists and such...

> 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
> are now.

A secondary MX might require a higher workload for the postmaster and
possibly opens a hole for unwanted email, there is no reason to change
a completely fine setup.

/Oli

-- 
Olafur Osvaldsson
Systems Administrator
Internet a Islandi hf.
Tel:   +354 525-5291
Email: oli at isnic.is
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hubs/attachments/20040120/d231bcf8/attachment.bin