[Dovecot] Maildir++ quota: When is it recalculated?
We use Maildir++ quota, with the rules taken from our LDAP backend. We also have an old expunge script that's not quota-aware; it removes old messages from the maildir by simply deleting the files.
Sometimes, a mailbox is over quota before the script runs, but well under quota after the old messages are deleted. This change does not seem to be picked up, however: When I try to deliver a new message (using Dovecot's deliver), the attempt fails with an "over quota" error.
I tried finding out from the source code whether this is intended behavior, but unfortunately, I'm not enough of a programmer, so I have to ask here: Should I be able to delete mails from a maildir, and expect the quota plugin to notice the change?
We use Dovecot 1.1.8, by the way.
Ulrich
On Wed, 2009-01-14 at 14:30 +0100, Ulrich Zehl wrote:
We use Maildir++ quota, with the rules taken from our LDAP backend. We also have an old expunge script that's not quota-aware; it removes old messages from the maildir by simply deleting the files.
Sometimes, a mailbox is over quota before the script runs, but well under quota after the old messages are deleted. This change does not seem to be picked up, however: When I try to deliver a new message (using Dovecot's deliver), the attempt fails with an "over quota" error.
I tried finding out from the source code whether this is intended behavior,
http://www.inter7.com/courierimap/README.maildirquota.html explains it in "Calculating the quota for a Maildir++". Dovecot uses the same method.
but unfortunately, I'm not enough of a programmer, so I have to ask here: Should I be able to delete mails from a maildir, and expect the quota plugin to notice the change?
I think it should notice most times, but not necessarily always. Can you reproduce this with simple steps? Meaning that if maildirsize file is either older than 15 minutes or longer than two lines, does Dovecot not recalculate the quota when user is over quota?
On Wed, Jan 14, 2009 at 10:18:30AM -0500, Timo Sirainen wrote:
but unfortunately, I'm not enough of a programmer, so I have to ask here: Should I be able to delete mails from a maildir, and expect the quota plugin to notice the change?
I think it should notice most times, but not necessarily always. Can you reproduce this with simple steps? Meaning that if maildirsize file is either older than 15 minutes or longer than two lines, does Dovecot not recalculate the quota when user is over quota?
Yes, I can. However, the user is, strictly speaking, not over quota, since there are still a few bytes free. The new message would push it over quota, though. Does this make a difference?
These are the steps I took, starting from a "fresh" account (one whose home directory I deleted), and using swaks[0] to generate the mails. We use Postfix to pipe the messages to deliver, and have set quota_full_tempfail = yes.
Delete the user's home directory
Deliver 3 messages to the user, using
swaks -f ulrich@topfen.net -t grmpfl@example.net -s localhost
- maildirsize now shows:
cat Maildir/maildirsize
2000S 0 0 510 1 510 1 510 1
- Try to deliver a fourth message (also 510 bytes). As expected, it fails.
tail -n 2 /var/log/mail.log
Jan 14 17:15:02 carolyn deliver(grmpfl@example.net): msgid=<20090114161502.7F2AA1C104@carolyn.beispiel.at>: save failed to INBOX: Quota exceeded (mailbox for user is full) Jan 14 17:15:02 carolyn postfix/pipe[8461]: 7F2AA1C104: to=<grmpfl@example.net>, relay=dovecot, delay=0.18, delays=0.12/0.03/0/0.03, dsn=4.3.0, status=deferred (temporary failure. Command output: Quota exceeded (mailbox for user is full) )
- Remove one of the files:
rm Maildir/new/1231949258.M463705P8296.carolyn\,S\=510\,W\=524
- Try to deliver the message again, and watch it fail again:
postqueue -f
# tail -n 2 /var/log/mail.log Jan 14 17:15:55 carolyn deliver(grmpfl@example.net): msgid=<20090114155631.BCDB71C0DA@carolyn.beispiel.at>: save failed to INBOX: Quota exceeded (mailbox for user is full) Jan 14 17:15:55 carolyn postfix/pipe[8461]: BCDB71C0DA: to=<grmpfl@example.net>, relay=dovecot, delay=1164, delays=1164/0.04/0/0.02, dsn=4.3.0, status=deferred (temporary failure. Command output: Quota exceeded (mailbox for user is full) )
- Try ageing maildirsize and a new delivery:
touch -t 01010101 Maildir/maildirsize
# postqueue -f # tail -n 2 /var/log/mail.log Jan 14 17:18:42 carolyn postfix/pipe[8553]: 7F2AA1C104: to=<grmpfl@example.net>, relay=dovecot, delay=220, delays=220/0.05/0/0.03, dsn=4.3.0, status=deferred (temporary failure. Command output: Quota exceeded (mailbox for user is full) ) Jan 14 17:18:42 carolyn postfix/pipe[8554]: BCDB71C0DA: to=<grmpfl@example.net>, relay=dovecot, delay=1331, delays=1331/0.01/0/0.03, dsn=4.3.0, status=deferred (temporary failure. Command output: Quota exceeded (mailbox for user is full) )
- Try deleting maildirsize and a new delivery:
rm Maildir/maildirsize
# tail -n 3 /var/log/mail.log Jan 14 17:19:48 carolyn deliver(grmpfl@example.net): msgid=<20090114161502.7F2AA1C104@carolyn.beispiel.at>: saved mail to INBOX Jan 14 17:19:48 carolyn postfix/pipe[8553]: 7F2AA1C104: to=<grmpfl@example.net>, relay=dovecot, delay=286, delays=286/0.04/0/0.13, dsn=2.0.0, status=sent (delivered via dovecot service) Jan 14 17:19:48 carolyn postfix/qmgr[3599]: 7F2AA1C104: removed
On Wed, 2009-01-14 at 17:24 +0100, Ulrich Zehl wrote:
On Wed, Jan 14, 2009 at 10:18:30AM -0500, Timo Sirainen wrote:
but unfortunately, I'm not enough of a programmer, so I have to ask here: Should I be able to delete mails from a maildir, and expect the quota plugin to notice the change?
I think it should notice most times, but not necessarily always. Can you reproduce this with simple steps? Meaning that if maildirsize file is either older than 15 minutes or longer than two lines, does Dovecot not recalculate the quota when user is over quota?
Yes, I can. However, the user is, strictly speaking, not over quota, since there are still a few bytes free. The new message would push it over quota, though. Does this make a difference?
Yes, it makes a difference. The recalculation isn't done unless user really is over quota. Hmm. I did just consider adding code to recalculate the quota also if adding a new mail would bring user over quota, but it would require pretty large changes to the code.
How about you simply delete maildirsize file after deleting files from maildir?
On Wed, Jan 14, 2009 at 11:31:43AM -0500, Timo Sirainen wrote:
On Wed, 2009-01-14 at 17:24 +0100, Ulrich Zehl wrote:
On Wed, Jan 14, 2009 at 10:18:30AM -0500, Timo Sirainen wrote:
but unfortunately, I'm not enough of a programmer, so I have to ask here: Should I be able to delete mails from a maildir, and expect the quota plugin to notice the change?
I think it should notice most times, but not necessarily always. Can you reproduce this with simple steps? Meaning that if maildirsize file is either older than 15 minutes or longer than two lines, does Dovecot not recalculate the quota when user is over quota?
Yes, I can. However, the user is, strictly speaking, not over quota, since there are still a few bytes free. The new message would push it over quota, though. Does this make a difference?
Yes, it makes a difference. The recalculation isn't done unless user really is over quota.
Just out of curiosity: How can I actually make the maildir go over quota, short of changing the limits after delivery or using a non-aware LDA?
Hmm. I did just consider adding code torecalculate the quota also if adding a new mail would bring user over quota, but it would require pretty large changes to the code.
Well, for what it's worth, I'd be very happy if this was implemented in Dovecot in the future, but for now ...
How about you simply delete maildirsize file after deleting files from maildir?
... I'll do that.
On Wed, 2009-01-14 at 21:37 +0100, Ulrich Zehl wrote:
Just out of curiosity: How can I actually make the maildir go over quota, short of changing the limits after delivery or using a non-aware LDA?
Maildir++ quota doesn't do any kind of locking, so it's possible that two processes deliver a new mail at the same time and together they bring the user over quota.
participants (2)
-
Timo Sirainen
-
Ulrich Zehl