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.
A2)
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.
-------
drl@vuse.vanderbilt.edu
suggested to use *procmail* which is very flexible MDA. procmail enables
you to deliver incoming mails everywhere, it is simple to compile and
install.
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:
DEFAULT=.incoming_mails
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 (137.226.112.31)
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
berg@physik.tu-muenchen.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
Italia
Keywords:
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:45 CDT