Note: please fix whatever caused your message to be posted to the procmail
list three times (or more), each with a different Date: header, signifying
that it was submitted three times, not simply replicated during mail transit.
#space check
#checks for necessary disk space:
MAXSIZE=20971520 #maximum mailbox size in bytes = 20Mb
Shouldn't this be a function of the individual users' quota (assuming that
either your mail spool is on a separate filesystem than the rest of the
users file, or that you've got no qualms with sharing space between
them)? What you're doing here is setting up an artificial quota mechanism,
which will make it difficult for you to assign larger quotas to some users
arbitrarily.
BOXSIZE=`ls -l /var/spool/mail/${LOGNAME} 2>/dev/null | while read a b c d
e f;
do echo $e; done`
FULL=`expr ${BOXSIZE} \> ${MAXSIZE}`
Q: wouldn't you want to include the side of the current message? a 5MB
message could send them significantly over quota.
OTOH, accepting the full message, and then BOUNCING it, telling the sender
to try again at some later date that they have no way of knowing when the
mailbox will be sufficiently cleared out, has some serious issues as
well. It can add up to a serious waste of bandwidth.
While I don't personally do this, if I found a need to enforce quotas on
mailboxes, I would probably consider something like so:
* periodically check mailbox quotas (using the real quota tools).
If an account remains over quota for some period of time (or perhaps,
even for any one check), update the virusertable/aliases with a
message for this user's account, thus rejecting mail AT THE SMTP
STAGE (before you've even suffered the message headers/body being
transferred over your network link - all you've done is accepted a
connection, echanged greetings, and ENVELOPE data).
* The same cron-invoked mail quota checker would revert the user
alias/virtuser entry when their mailbox is no longer over quota.
Such a script could insert messages into their mailspool, or update account
status information on a user-accessible webpage, etc, so that the recipient
is aware of their problem (though, if they're not checking email, they will
remaain blind to it). Some users "keep mail on server", using the mail
server for long-term storage of their email messages - those users would
benefit from being advised that their mail is over quota, since they might
actually see that message.
The main problem with this recipe is that the incoming mail that triggered
the quota warning is requeued, not discarded or bounced back to the sender.
EXITCODE. You should set it to a value which will dictate the action you
want the MTA to take when procmail terminates. The EXITCODE values can be
found in the sendmail source (sendmail/sysexits.h, which also contains
explanations of the different errors in plain english). Check sysexits.c
as well (which shows most of the logic for the conditions under which
different error messages are selected). The same values are likely to be
utilized by other MTAs, at least if they want to remain compatible with
programs which may be called by sendmail, but I can't tell you for sure
that they do.
BTW, you'd use the NUMERIC value - procmail doesn't support the text
names. It'd be easy enough to create your own INCLUDERC file that contains
variable definitions, so that you could use something like so:
# (in the SYSEXITS.RC file you'd create and include)
EX_UNAVAILABLE=69
# (in your rcfile, when you've decided you can't deliver because
# of mailbox full)
EXITCODE=${EX_UNAVAILABLE}
Be sure you're not specifying bogus error values - things get VERY
frustrating for the sender when the error doesn't represent the problem.
---
Sean B. Straw / Professional Software Engineering
Procmail disclaimer: <http://www.professional.org/procmail/disclaimer.html>
Please DO NOT carbon me on list replies. I'll get my copy from the list.
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail