Ed Hill <edhill(_at_)strobe(_dot_)weeg(_dot_)uiowa(_dot_)edu> writes:
Currently we have quota's turned off, but we plan on turning them back on
soon. What is the expected behavior when procmail can't update a person's
mail file because he/she is over quota. Does it die with a hard error and
bounce back to sender?
<checks the source>
It treats it like any other write error and considers the write as
failing. If the -t flag was given then it'll exit with EX_TEMPFAIL and
sendmail will requeue it, otherwise it'll exit with EX_CANTCREAT and
sendmail will bounce it. It *will* spew a little note to stderr
("Quota exceeded while writing") which sendmail should nicely include
in the bounce message.
Of course, you can always catch write errors in your .procmailrc with
the 'w' or 'W' flags:
:0 w:
$DEFAULT
# Hmm, maybe I'm over quota. Try the fallback in Bob's account on
# the other disk.
:0 w:
/home/users2/bob/freds-stuff/mbox
# Still no soap, forward to my account at the other site.
:0
! me(_at_)another(_dot_)site
We would like it to die with a soft error and place the message in a local
queue (a queue other then the default queue would be great). That way we
can keep those messages local for a few days giving our users a chance to
come back under quota and be delivered.
1) Add the -t flag to the local mailer definition.
2) Check to see if sendmail includes the "Quota exceeded while writing"
note in the queue file somewhere (I don't remember if it does). If so,
write a script which watches for these and moves them to the alternate
queue, being sure to lock them in the correct fashion.
3) If not, uhh, hack procmail to exit with another code, then hack sendmail
to recognize it, then,... then, uh...?
Philip Guenther