[Dovecot] maildirsize update error

[Ben Marsh]

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:
> 1. 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).

> 2. 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