From owner-freebsd-questions Tue May 14 10:58:21 1996 Return-Path: owner-questions Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA28209 for questions-outgoing; Tue, 14 May 1996 10:58:21 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id KAA28199; Tue, 14 May 1996 10:58:17 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA12661; Tue, 14 May 1996 10:55:44 -0700 From: Terry Lambert Message-Id: <199605141755.KAA12661@phaeton.artisoft.com> Subject: Re: Setting up user accounts but with no email access To: paul@riker.comcirc.com.au (Paul Sondhu) Date: Tue, 14 May 1996 10:55:44 -0700 (MST) Cc: freebsd-questions@freebsd.org, questions@freebsd.org In-Reply-To: from "Paul Sondhu" at May 14, 96 10:13:00 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-questions@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I am setting up a few user accounts on our WWW server so that users can > FTP to the server to post up their web pages into their relevant > web page directories. > > How can I disable email access for these users. ie. I dont want them > to have an email account, only an account to FTP files to. The easiest (grossest) way would be to define another name for the machine and *not* put in a Cw entry for it. Then set up aliases for all the users that you don't want to get mail to forward to the illegal host. Alternately, you could bounce mail with a refusal using an alias script (but that would require a bit more work). This will keep the mail from accumulating, anyway. > At the moment they can use a pop client since a pop server is running on > the machine. I dont want to remove the popper daemon since there are > a few accounts on there who need pop email access. This is more of a problem, since they will be able to send from your system anyway. Probably, you want to hack the popper to not accept users unless they have a valid shell. Really, this is what user classes should have been, but aren't, in the BSDI user class code. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.