/var/spool/mail growing too much: summary

From: Roberto Baglioni (baglioni@arcetri.astro.it)
Date: Fri Jul 17 1992 - 08:34:48 CDT

In my article of july, 15 I asked:
> The question is: is it possible to have incoming mails directly created in
> the users' home directory instead of /var/spool/mail?
> We haven't reserved enough space to /var/spool filesystem so we
> continuosly econter problems because of the quantity of new arriving mails:
> mails arrived but not read because the recipient is away or mail read
> but left in the public area etc...

Here is a summary of the answers I got.

My question was twofold.
Q1) How can I cope with /var/spool/mail running out of space.
Q2) How can I definitely get rid of the need of watching after the
   users' behaviour about managing mails. I don't like private mails
   in system areas, because this is in some way a workaround of the
   user's disk quota and, worst, because a single unprivileged user can
   compromise the system. So, about this second point, I was looking
   for a mean to force the mail delivering agent (MDA) to write the new
   incoming mails into the users' area.

A1) About the first point I received some answers indicating the
simple solution: create a symbolic link /var/spool/mail pointing to
another larger filesystem. This is a good solution for the first
problem, but it just defers the problem, because the users without
control tend to accumulate messages in /var/spool/mail, and whatever
the filesystem's size is it will overflow soon or later.

FROM: gdmr@dcs.edinburgh.ac.uk
>> The question is: is it possible to have incoming mails directly created in
>> the users' home directory instead of /var/spool/mail?
>We do precisely that, using MMDF as our MTA.
>MTA = Mail Transfer Agent. The thing that moves the messages between systems.
>sendmail is an example of one such. MMDF, PP and smail are some more.
>According to xarchie, you should be able to pick up MMDF from most good
>archive sites. ftp.uu.net and src.doc.ic.ac.uk are just two of the ones
>it listed.

I didn't try it.


FROM: eplunix!raoul@harvard.harvard.edu

> ln -s ~username/Incoming_mail /var/spool/mail/username

This works only if the file Incoming_mail is world writable, a bad
solution for a mail folder...

The same consideration applies to forwarding the mail to some file
using the ~/.forward file and to using aliases like
username: /home/username/incoming_mails


FROM: mills@ccu.UManitoba.CA

>My solution to this problem was to place a limit on the size of
>user's mailboxes in /var/spool/mail, and enforce the limit with
>a cron command that runs at night and truncates oversize mailboxes.

That sounds dangerous, because you can automatically delete some
valuable messagges and get users infuriated.

Something of the same type but smoother is proposed by

FROM: peteg@seismo.CSS.GOV

>To cut down on excessive mail I use a program posted to the net called
>mailclean. You set up the max size of each mail file and the program
>truncates the mail to the appropriate size and copies the excess to
>/var/tmp where it is deleted after a week. The program also comes with
>mailsize a program run at login that reminds users that their mailbox
>is too big.

I find delivering directly to user's home directly attractive because
makes the user responsible of the bytes occupied by his/her messages.


suggested to use *procmail* which is very flexible MDA. procmail enables
you to deliver incoming mails everywhere, it is simple to compile and

I hadn't enough time to try all the things promised in the manual, but it
certainly solves MY problem.

Once installed procmail in the bin directory you have to do the following

1) instruct sendmail to use /usr/local/bin/procmail instead of /bin/mail
   as delivering agent.
2) ask the users to create in their home directory a file .procmailrc
   with the following line:
   This tells procmail where to put incoming mails

3) ask the users to define the MAIL environment variable as ~/.incoming_mails
   This tells the mail-reading program where new mails are stored.

That's all.

A recent version can be picked up at various comp.sources.misc archives.
The latest version can be obtained directly from the ftp-archive at:

        amaru.informatik.rwth-aachen.de (
        as compressed tar file: pub/unix/procmail.tar.Z <100KB
        or in compressed shar format: pub/unix/procmail.0?.Z

The author of procmail is:

       Stephen R. van den Berg at RWTH-Aachen, Germany.

Internet E-mail: berg@messua.informatik.rwth-aachen.de

Or: P.O.Box 21074
        6369 ZG Simpelveld
        The Netherlands

Feature summary for procmail: >> from the file FEATURES of the distribution <<
        + It's small
        + Very easy to install (rated PG6 :-)
        + Simple to maintain and configure because
          all you need is actually only ONE executable (procmail)
          and ONE configuration file (.procmailrc)
        + Is event driven (i.e. gets invoked automagically when mail arrives)
        + Does not use *any* temporary files
        + Uses standard egrep regular expressions
        + Allows for very-easy-to-use yes-no decisions on where the mail
          should go (can take the size of the mail into consideration)
        + Filters, delivers and forwards mail *reliably*
        + Provides a reliable hook (you might even say anchor :-) for any
          programs or shell scripts you may wish to start upon mail arrival
        + Performs heroically under even the worst conditions
          (file system full, out of swap space, process table full,
          file table full, missing support files, unavailable executables,
          denied permissions) and tries to deliver the mail somehow anyway
        + Absolutely undeliverable mail (after trying every trick in the book)
          will bounce back to the sender (or not, your choice)
        + Is one of the few mailers to perform reliable mailbox locking across
          NFS as well (DON'T use NFS mounted mailboxes WITHOUT installing
          procmail, you may use valuable mail one day)
        + Supports four mailfolder standards: single file folders (standard
          and nonstandard VNIX format), directory folders that contain one file
          per message, or the similar MH directory folders (numbered files)
        + Variable assignment and substitution is an extremely complete subset
          of the standard /bin/sh syntax
        + Provides a mail log file, which logs all mail arrival, shows
          in summary whence it came from, what it was about, where it went
          (what folder) and how long (in bytes) it was
        + Uses this log file to display a wide range of diagnostic and error
          messages (if something went wrong)
        + Does not impose *any* limits on line lenghts, mail length (as long
          as memory permits), or the use of any character (any 8-bit character,
          including '\0' is allowed) in the mail
        + It has man pages (boy, does *it* have man pages)
        + Procmail can be used as a local delivery agent (a completely
          integrated substitute for /bin/mail), in which case it can heal
          your system mailbox, if something messes up the permissions
        + It runs on virtually all (old and future) operating systems which
          names start with a 'U' or end in an 'X' :-) (i.e. extremely portable
          code; POSIX, ANSI C and K&R conforming)
        + Is clock skew immune (e.g. in the case of NFS mounted mailboxes)
        + Works with (among others?) sendmail, smail and MMDF

Roberto Baglioni - System Administrator
     Dipartimento di Astronomia
       Universita' di Firenze


This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:45 CDT