I'm confused. First you say that the mail "is silently dropped" when it would take the user over quota, then you say that "dmail hangs". Which is it?
"Silently dropped" is a known behavior of procmail. You have to do something to cause an error from the delivery program to be passed back up to the mail delivery system. I don't know what it is, since I am not a procmail expert, but it apparently is more than just piping. "Hanging" is a different matter. c-client reacts to an appending write() error (including over-quota) by revoking the append and putting the mailbox file back to the way it was before. Unfortunately, it seems some UNIX variants, once it decides that the file is in "write error" status, keeps the file descriptor in that status even after the condition which caused it is corrected. The result is that the write() to put things back fails again. dmail doesn't know what to do other than try again, because it doesn't want to leave the file in a corrupted state. So that may be the cause of the hang; dmail is trying to revert the file back to the way it was before it started the append, but the operating system keeps on returning error. Note that this is supposition based upon empirical observations from third parties; I have never seen this behavior on any operating system that I use. If this is what is happening, then I don't know of anything (that I am not already doing) that would make the system let me write into the file again. In my humble opinion,... Hard disk quotas are a mistake. Historically, operating systems (all operating systems, not just UNIX) have *always* made hard disk quotas problematic for applications. It's not such much that a quota exceeded error can happen, but rather the variance in operating system behavior (even in different releases of the same OS) that make it difficult for an application to recover. It is a much more productive strategy to buy enough disk for user's needs. As the Dilbert cartoon says, "here's a quarter; now you can afford to double my disk quota." To check abusive behavior, soft disk quotas are preferable; allow the mail to be delivered, but then flag the account to start nagging the user to get under quota. It may be necessary to have a second level of flagging that stops mail delivery when if the user defies the nags and stays over quota, but never use hard disk quota. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
