Date: Tue, 20 Jan 2004 19:37:54 +0000 From: Olafur Osvaldsson <oli@isnic.is> To: Mij <mij@bitchx.it> Cc: hubs@freebsd.org Subject: Re: mx vs ns Message-ID: <20040120193754.GC27983@isnic.is> In-Reply-To: <C16A59A6-4B77-11D8-BB67-000A95CCF092@bitchx.it> References: <93570F3C-4B56-11D8-9538-000A95CCF092@bitchx.it> <20040120153117.GL86062@isnic.is> <C16A59A6-4B77-11D8-BB67-000A95CCF092@bitchx.it>
next in thread | previous in thread | raw e-mail | index | archive | help
--UugvWAfsgieZRqgk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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. >=20 > This way you let your mail completely up to the sender's server=20 > 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. >=20 > 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 --=20 Olafur Osvaldsson Systems Administrator Internet a Islandi hf. Tel: +354 525-5291 Email: oli@isnic.is --UugvWAfsgieZRqgk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFADYOS8xNRBRknOFwRAqmiAJsEAGpxJg26suBtfhMowq/HlNaVcwCeMd1A V21qRkeD/DOxjT1IyBStnjQ= =0CAd -----END PGP SIGNATURE----- --UugvWAfsgieZRqgk--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040120193754.GC27983>