From owner-freebsd-isp Mon Nov 27 09:01:23 1995 Return-Path: owner-isp Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA12985 for isp-outgoing; Mon, 27 Nov 1995 09:01:23 -0800 Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.20.4]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id JAA12980 for ; Mon, 27 Nov 1995 09:01:16 -0800 Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id LAA11217; Mon, 27 Nov 1995 11:00:03 -0600 From: Joe Greco Message-Id: <199511271700.LAA11217@brasil.moneng.mei.com> Subject: Re: limiting mailbox size? To: boot@mosquito.com (Bruce Bauman) Date: Mon, 27 Nov 1995 11:00:01 -0600 (CST) Cc: freebsd-isp@freebsd.org, boot@itchy.mosquito.com In-Reply-To: <199511271558.KAA27423@itchy.mosquito.com> from "Bruce Bauman" at Nov 27, 95 10:58:31 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-isp@freebsd.org Precedence: bulk > We are a small ISP running FreeBSD. We run quotas to prevent users from using more disk > space than their limit, but occasionally we find users with huge mailboxes in /var/mail. > How do other providers deal with this? Should I just write a perl script that sends mail > to the user, or sends a mail message when they log in? Actually, threats work well :-) "Users exceeding 5MB in their incoming mailbox will automatically have their mailbox zeroed". This is a tough one to deal with. What do you do? You can write a local mailer that checks their mailbox size and refuses to deliver if the mailbox is too full. Listservs will interpret the bounce message as an error and unsubscribe the user. That pisses people off. You can write a local mailer that checks their mailbox size and (if it is too full) gzip's their current mailbox into their home directory, zeroes the mailbox, and mails them a note about what happened, why, and how they can read the gzipped mail. This is an advantage if you charge by the byte for home directory space. If you quota limit home directories, this doesn't buy you anything other than to move the problem elsewhere. No clean solutions that I've seen. :-) ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847