Subject: question about dmail when mailbox over quota

From: "J. A. Landamore" <[email-masked]>
Date: Wed, 17 Dec 2003 16:45:44 +0000 (GMT)

I am using dmail with postfix and procmail to deliver to mbx format mailboxes.  
There is a maximum mailbox size set in postfix, and before that is reached 
everything is fine.  However when dmail tries to deliver a mail to an INBOX that 
would take it overquota the mail just gets silently dropped.  By switching on 
debugging for dmail I get:

for an INBOX with plenty of space

procmail: Notified comsat: "testfred@:/usr/local/bin/dmail -D"
>From [email-masked]  Wed Dec 17 16:25:18 2003
 Subject: test number 2
  Folder: /usr/local/bin/dmail -D                                           718
procmail: Executing "/usr/local/bin/dmail,-D"
delivering to testfred+INBOX
Verifying safe delivery to /home/testfred/INBOX
mbx appending to #driver.mbx/INBOX (file /home/testfred/INBOX)
delivered to /home/testfred/INBOX
Verifying safe delivery to /home/testfred/INBOX

for an INBOX where the message will take it over quota

procmail: Notified comsat: "testfred@:/usr/local/bin/dmail -D"
>From [email-masked]  Wed Dec 17 16:28:00 2003
 Subject: What happens now
  Folder: /usr/local/bin/dmail -D                                           747
procmail: Executing "/usr/local/bin/dmail,-D"
delivering to testfred+INBOX
Verifying safe delivery to /home/testfred/INBOX
mbx appending to #driver.mbx/INBOX (file /home/testfred/INBOX)

and there it hangs.

Any ideas anyone?

Thanks in advance

John Landamore

School of Mathematics & Computer Science
University of Leicester
University Road, LEICESTER, LE1 7RH
[email-masked]
Phone: +44 (0)116 2523410       Fax: +44 (0)116 2523604

-- 
------------------------------------------------------------------
 For information about this mailing list, and its archives, see: 
 http://www.washington.edu/imap/c-client-list.html
------------------------------------------------------------------

---

From: Mark Crispin <[email-masked]>
Date: Wed, 17 Dec 2003 09:39:41 -0800 (PST)

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.

---

From: Christian Kratzer <[email-masked]>
Date: Thu, 18 Dec 2003 19:38:49 +0100 (CET)

> debugging for dmail I get:

mailbox_size_limit in the postfix main.cf sets process resource limits
before forking the local delivery agent in this case procmail.  The resource
limits are inherited by all process the procmail forks and also dmail.

I would suspect the problem might be that your procmail rules somehow
stop dmail from returning a proper error condition to procmail.

I would recommend that you setup test cases with different kinds of
procmail rules with and without dmail to further narrow this down.

Greetings
Christian

-- 
CK Software GmbH
Christian Kratzer,         Schwarzwaldstr. 31, 71131 Jettingen
Email: [email-masked]
Phone: +49 7452 889-135    Open Software Solutions, Network Security
Fax:   +49 7452 889-136    FreeBSD spoken here!