From owner-freebsd-isp Wed Mar 31 10:59:31 1999 Delivered-To: freebsd-isp@freebsd.org Received: from heaven.gigo.com (ppp.gigo.com [207.173.132.1]) by hub.freebsd.org (Postfix) with ESMTP id 9DE8214CC1 for ; Wed, 31 Mar 1999 10:59:30 -0800 (PST) (envelope-from jfesler@gigo.com) Received: from heaven.gigo.com (heaven.gigo.com [207.173.133.57]) by heaven.gigo.com (Postfix) with SMTP id 4AEFF84C; Wed, 31 Mar 1999 10:59:14 -0800 (PST) Date: Wed, 31 Mar 1999 10:59:14 -0800 (PST) From: To: Mark Conway Wirt Cc: Dan Busarow , freebsd-isp@FreeBSD.ORG Subject: Re: sendmail melissa blocker In-Reply-To: <19990331135304.K10095@intrepid.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-isp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > I've wondered about this -- we use procmail. If there any performance > hit to use filters in the .procmailrc file? In a nutshell, yes. The question is, is it an acceptable performance hit? Keep your rules list fairly short. A rule set of 500 lines or so takes about 10 seconds on a ppro 180. [Don't ask how I know ;-)]. That sample was doing full body text searches. My "normal" procmail file has <50 lines in it, and mostly subject filtering only. Local delivery is quite fast. Best I can suggest, is if you are considering doing this globally, is to go ahead and do it - and watch the system for a little while. If you kept historical data on your server's load, it would be easier to evaluate real performance penalties. Either way, you can wing it and see what happens - and back it out pretty easily and quickly otherwise. [If you aren't keeping historical data.. reconsider!. MRTG is handy at recording anything that can be put to numbers. I track messages incoming, messages outgoing, mail queue length (in terms of queue entries and recipients both), and uptime.. It's REALLY nice to use for historical data and for planning.] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isp" in the body of the message