Article View: comp.admin.policy
Article #227Re: Full mail spool policy?
From: Wes Morgan
Date: Thu, 05 Nov 1992 22:17
Date: Thu, 05 Nov 1992 22:17
67 lines
3867 bytes
3867 bytes
dan@cubmol.bio.columbia.edu (Daniel Zabetakis) wrote: > > We are having a problem with a full mail spool. Some users have >large amounts of mail kept there. I am pretty sure that much of it is >from mailing lists that they don't want to dump into thier account mbox, >but don't really want to delete. Well, it is going to have to go now. I run into the same problem about once each semester. > My question in regard to policy is whether it is OK to threaten to >remove the mail. I intend to write to the active users by e-mail and ask >them to remove excessive mail (or explain why it is neccessary to keep >it). If they fail to respond to a reasonable attempt, I intend to delete >the mail. (probably won't happen). Our general policy sets a size limit of 150 Kb on user mailboxes. I check the mailbox sizes (rougly) biweekly. I also wrote a quick shell script, named "mailsize", that will tell users the size of their mailbox and issue a gentle reminder if they're over the limit. If a user mailbox is over the limit for two consecutive checks (which cover a month), I send a quick piece of mail, asking them to delete/save mail from their mailbox. If they fail to do so, and if they are still over the 150 Kb limit after two weeks, the entire mailbox is moved into their home directory. (If the mailbox is *really* large, I'll compress it) I then send a piece of mail (which will be the first one they see) explaining my action and telling them how to access the old mailbox (the -f option to mailx). I consider this a decent solution for our users, because: - The user has up to 6 weeks to deal with the situation - The mail is not destroyed - The mail is still accessible - The diskspace consumption counts against their resource quotas (For our users, resource quotas are a constant goad to responsibility) > The real question comes up for the occasional users. Some people only >log on every few months, if that. I don't want to have to track them >down and explain the problem to them individually. How much effort should >I take to get in contact with them before deleting the mail as unwanted. >We don't often remove accounts (being a depertmental machine with not too >many users). The same scenario applies to all user mailboxes. > What about runaway mailing lists? I think some of our users who don't >log in often have joined mailing lists, but never read the mail. Can I >look at the mail to determine if this is the case? What should I do if it >is? I don't think you should look at the actual mail. However, you can (and I do) examine the mailer logs, which only show date, time, sender, desti- nation, and size. (Alternatively, you can extract the From: headers with any grep-like tool) I believe that this approach minimizes your intrusion into user's confidentiality. If an large but untouched mailbox has a lot of mailing list traffic, AND if the user ignores (or misses) my earlier messages, I'll contact the mailing list owner and request that the user be removed. I've only had to do this about 6 times in 3 years....... --Wes -- MORGAN@UKCC | Wes Morgan | ...!ukma!ukecc!morgan morgan@ms.uky.edu | Engineering Computing | morgan@wuarchive.wustl.edu morgan@engr.uky.edu | University of Kentucky | JWMorgan@dockmaster.ncsc.mil Mailing list for AT&T StarServer S/E - starserver-request@engr.uky.edu
Technical Details
Message-ID:
<1992Nov5.171745.8868@ms.uky.edu>Path:
arc1-ca.pugleaf.net!sparky!uunet!ukma!morganReferences:
<1992Nov5.194200.3673@news.columbia.edu>Show Full Headers
Complete Article Headers
Newsgroups: comp.admin.policy Path: arc1-ca.pugleaf.net!sparky!uunet!ukma!morgan From: morgan@engr.uky.edu (Wes Morgan) Subject: Re: Full mail spool policy? References: <1992Nov5.194200.3673@news.columbia.edu> Message-ID: <1992Nov5.171745.8868@ms.uky.edu> Organization: University of Kentucky Engineering Computing Center Sender: morgan@ms.uky.edu (Wes Morgan) Date: Thu, 5 Nov 1992 22:17:45 GMT Lines: 67