Thanks to the many people who replied!
The short answer: procmail.
The long answer follows...
I originally wrote:
=> I'm trying to implement quotas on my mail spool, mainly to prevent a
=> denial of service in the event where the disk fills up.
=>
=> I already refuse any single message over 5mb, but I want to implement
=> quotas and bounce any message when the user is over their 10mb quota.
=>
=> The problem seems to be that sendmail happily accepts the mail if the
=> disk itself isn't out of space...it doesn't check for user quotas.
=> Since /bin/mail writes individual mail files as the user "mail", then
=> "gives them away" to the specified user, the writes succeed. The user
=> is never doing a write in excess of their quota.
=>
=> I'm looking for a replacement for the local delivery agent, /bin/mail,
=> that will not write the temp file to the user's mail file when the user
=> has exceeded their quota, but will bounce the mail back to the sender
=> and notify postmaster.
=>
The most-often-recommended suggestion was procmail. I was initially
looking for a simpler solution (I already use procmail for some mailing
lists etc.), but I ended up using procmail as my local delivery agent. All
in all, an easy replacement for /bin/mail, particularly if you are using
a modern version of sendmail (v8.8.n+).
Some things to watch out for:
If any users have .procmailrc files these will be used
immediately. This was only a situation where people had previously
called procmail via a .forward file, then disabled the .forward
file and left the .procmailrc (such as returning from vacation).
Procmail does honor quotas (it does delivery as the local user),
but the message that sendmail returns when bouncing undelivered
mail is "typical sendmail". Ideally, the sender would get
something quite clear ("quota full for john_doe"), rather than
"write failed".
Make sure that someone checks the mail to "postmaster", or that
you actively (via a cron job/script) monitor quotas, otherwise
you may not know that individuals are above their quotas, unable
to retrieve mail (via POP), and unable to send mail to you
(if they use POP services to send mail).
If you are going to impose mail quotas, spend some time to think about
the problems you are trying to solve/prevent and your particular
configuration:
* Are you most concerned about an individual being mailbombed?
* Are you most concerned about a deliberate denial of service attacks
against everyone by someone trying to fill up your mail disk?
* Do most users read their mail via POP, so they generally have only
the newest messages on the server?
* Does your POP server use the same mail spool for it's
temporary files?
* What's an appropriate soft quota?
* How long can a user exceed the soft quota?
* What's an appropriate hard quota?
* How many users can you afford to have at the hard quota at once?
* How will users who are at or above their soft quota download their
mail if the POP server uses the same partition for temporary files?
Answering those questions should make you think carefully about the
habits of your users, your disk space, and appropriate quotas.
In our case, I set the soft quota at about 1.5X the average use of the
largest 10% of the mail spool files, and the hard quota at slightly more
than double the soft quota. I adapted Chris Marble's script to report on
disk usage nightly, with escalating warnings to users who are into the
soft quota, and reports to postmaster. I also notified our users about
the new policy, in detail.
Finally, thanks to Chris Marble (chris_marble@hmc.edu), who included
a pointer to http://www3.hmc.edu/docs/coolstuff. In addition to the
variety of notes on how they have set up their systems, there was a
Perl script to notify admins and users when they are approaching or over
their disk quotas.
---- Mark Bergman bergman@phri.nyu.edu System and Network Administrator 212-578-0822 Public Health Research Institute Rm. 1074, 455 1st Ave, NY NY, 10016
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:12:33 CDT