From owner-freebsd-hubs@FreeBSD.ORG Tue Jan 20 11:38:05 2004 Return-Path: Delivered-To: freebsd-hubs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8C9E216A4CE for ; Tue, 20 Jan 2004 11:38:05 -0800 (PST) Received: from aker.isnic.is (aker.isnic.is [193.4.58.91]) by mx1.FreeBSD.org (Postfix) with ESMTP id 388AF43D69 for ; Tue, 20 Jan 2004 11:37:55 -0800 (PST) (envelope-from oli@aker.isnic.is) Received: by aker.isnic.is (Postfix, from userid 1000) id 4F03C8CCB3; Tue, 20 Jan 2004 19:37:54 +0000 (GMT) Date: Tue, 20 Jan 2004 19:37:54 +0000 From: Olafur Osvaldsson To: Mij Message-ID: <20040120193754.GC27983@isnic.is> References: <93570F3C-4B56-11D8-9538-000A95CCF092@bitchx.it> <20040120153117.GL86062@isnic.is> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UugvWAfsgieZRqgk" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i cc: hubs@freebsd.org Subject: Re: mx vs ns X-BeenThere: freebsd-hubs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: FreeBSD Distributions Hubs: mail sup ftp List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2004 19:38:05 -0000 --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--