From owner-freebsd-questions@FreeBSD.ORG Wed Mar 18 00:09:43 2009 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2FFE61065677 for ; Wed, 18 Mar 2009 00:09:43 +0000 (UTC) (envelope-from steve@ibctech.ca) Received: from ibctech.ca (unknown [IPv6:2607:f118::b6]) by mx1.freebsd.org (Postfix) with SMTP id AF1358FC1A for ; Wed, 18 Mar 2009 00:09:42 +0000 (UTC) (envelope-from steve@ibctech.ca) Received: (qmail 75352 invoked by uid 89); 18 Mar 2009 00:14:27 -0000 Received: from unknown (HELO ?192.168.1.114?) (steve@ibctech.ca@::ffff:208.70.104.100) by pearl.ibctech.ca with ESMTPA; 18 Mar 2009 00:14:27 -0000 Message-ID: <49C03BB7.1040009@ibctech.ca> Date: Tue, 17 Mar 2009 20:09:27 -0400 From: Steve Bertrand User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: "freebsd-questions@freebsd.org >> \"freebsd-questions@freebsd.org Questions -\"" X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Stop all manner of periodic scripts from running X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2009 00:09:43 -0000 Hi everyone, Taking the questions regarding my routing boxes one step further, I have strict rules that allow only certain control and management protocols to communicate on the network. Although SMTP is denied, I just realized that there are numerous messages from periodic scripts that are queued up that can't be sent. Can someone advise how to find out each and every periodic script that tries to send out email (given a standard install), and/or how to disable this? Or, is there a way to completely cripple a FreeBSD machine, so the system actually realizes that it can not send any email, and everything it tries to send email will realize this? (preferably a more subtle approach than simply rm'ing the sendmail binary :) Steve