On 21/11/2006, at 9:11 AM, Maykel Moya wrote:
El lun, 20-11-2006 a las 13:43 +0100, Steffen Kaiser escribió:
On Sat, 18 Nov 2006, Timo Sirainen wrote:
On Thu, 2006-11-16 at 16:07 -0500, Maykel Moya wrote:
According to [1], Trash is a reserverd folder name. When moving a message to it, maildirsize should be update with a negative byte
count.Well, yea.. I'm ignoring that part of the Maildir++ spec. Perhaps it could be done optionally, but I'm not sure if it's still that
good of an idea.I think a better idea is to give Trash mailbox a bit of extra quota, instead of unlimited quota. Unfortunately this won't work with
v1.0's quota plugin, but it is possible with my rewritten quota plugin:The original post mentioned that to move a message into Trash
fails, when the user is over quota. This, in the end, prevents an user to get under quota in MailDir++, because the messages are expunged from Trash only.I detected the problem with complaints from users trying to empty
their mail boxes. The webmail tried to move the deleted messages to Trash.I desirable behaviour would be:
- Add a negative byte and message count to maildirsize whenever a
mail is moved into Trash.
What happens when users find that they can store stuff in the Trash
dir when they are out of quota in the other folders? Such behavior
would make trash a haven for getting around quota limits. You could
perhaps threaten users with periodic enforced purges of the trash but
that wouldn't go down well (At least where I work).
- While moving a message do not touch maildirsize at all at least
that one of the folders involved (origin / destination) were Trash.
Given that there is no move in the IMAP specification, Dovecot would
have to do a lookahead to find the expunge command after the copy
command for all move operations. That would mean that dovecot would
have to falsely return success for all copies in order to "see" the
next IMAP command. In short I don't think that it is good/desirable
behavior because of these problems.
Regards,
Ben Marsh