From owner-freebsd-current Sat Jul 20 16:53:57 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA25123 for current-outgoing; Sat, 20 Jul 1996 16:53:57 -0700 (PDT) Received: from MindBender.HeadCandy.com (root@mindbender.headcandy.com [199.238.225.168]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id QAA24946 for ; Sat, 20 Jul 1996 16:50:41 -0700 (PDT) Received: from localhost.HeadCandy.com (michaelv@localhost.HeadCandy.com [127.0.0.1]) by MindBender.HeadCandy.com (8.7.5/8.7.3) with SMTP id QAA24961; Sat, 20 Jul 1996 16:47:37 -0700 (PDT) Message-Id: <199607202347.QAA24961@MindBender.HeadCandy.com> X-Authentication-Warning: MindBender.HeadCandy.com: Host michaelv@localhost.HeadCandy.com [127.0.0.1] didn't use HELO protocol To: Bill Paul cc: dev@fgate.flevel.co.uk (Developer), current@freebsd.org Subject: Re: Help on setting up yp/nis In-reply-to: Your message of Sat, 20 Jul 96 14:45:32 -0400. <199607201845.OAA20691@skynet.ctr.columbia.edu> Date: Sat, 20 Jul 1996 16:47:36 -0700 From: "Michael L. VanLoon -- HeadCandy.com" Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >On my network, I have a single machine designated as the mail host >(you could do more to spread out the load, if your network is very >large) and all the 'client' machines mount its /var/spool/mail >directory via NFS (and the automounter). Each 'client' is also set >up as a sendmail 'null client': if you send mail from one of them, >it gets forwarded first to the mail host, and then the mail host >forwards it to its final destination. The mail host also strips out >the hostname of the 'client' machine from the header so that all >outgoing mail appears to come from 'user@ctr.columbia.edu' rather >than 'user@host.ctr.columbia.edu'. This means that all replies will >automatically be sent back to the mail host rather than the 'clients.' This is a lot of extra work for the "mail hub". You can configure it so that all the client machines send mail directly to its destination, without bogging down the mail hub, and still masquarade, so the mail appears to come from user@ctr.columbia.edu. When I worked at Iowa State, we did it just like that. We had a single mail hub that received all mail destined for iastate.edu, with backups in case it failed. It then distributed the mail to several internal pop servers. This works better than NFS mounting /var/mail. All user accounts were mounted over AFS, so it didn't matter which host were were logged into when you retrieved your mail (we used mh, with kerberos authentication). There were roughly 850 workstations. All of them were configured to send mail directly out, and masquarade it as coming from user@iastate.edu. This would have been an enourmous amount of unecessary load if we had funneled all that traffic into, and back out our mail hub. And it wouldn't have bought us any extra functionality. >Each 'client' also has an MX record that points to the mail host, >so any mail sent to 'user@host.ctr.columbia.edu' is re-routed to >'user@mailhost.ctr.columbia.edu'. The mail host is the only machine >on the network that runs sendmail in daemon mode, thus only it >can accept inbound mail anyway. (The other machines do run sendmail >in the background, but only with the -q30m flag. This allows them >to flush their queue directories every so often, just in case.) We didn't do this. Since all outgoing mail was, by default, masquaraded as coming from user@iastate.edu, it would come back to our mail hub, automatically, if replied to. We did not have MX records for *.iastate.edu. The reason was that by default, the workstations wouldn't receive mail, and would bounce it back (best anyway -- it would let people know they mis-addressed the mail, rather than silently letting them continue doing so). And, if the admin of a particular machine, or subnet of machines, *wanted* to receive email locally, they could do so without having to involve the adminstration of the Computation Center. For what it's worth, we didn't use NIS. We used Athena based distributed adminstration (hesiod, kerberos, moira, etc.). IMHO, NIS would have been a nightmare for that large of an environment. The Athena stuff worked really well, for the most part. ----------------------------------------------------------------------------- Michael L. VanLoon michaelv@HeadCandy.com --< Free your mind and your machine -- NetBSD free un*x >-- NetBSD working ports: 386+PC, Mac 68k, Amiga, Atari 68k, HP300, Sun3, Sun4/4c/4m, DEC MIPS, DEC Alpha, PC532, VAX, MVME68k, arm32... NetBSD ports in progress: PICA, others... Roll your own Internet access -- Seattle People's Internet cooperative. If you're in the Seattle area, ask me how. -----------------------------------------------------------------------------