[Dovecot] Quota handling - v2 - updated FR

[Bill Landry]

Charles Marcus wrote the following on 5/23/2007 4:30 AM -0800:
> This revised proposal for a Feature Request is the result of my desire
> to implement quotas, but not have the attendant headaches that
> inevitably accompany its implementation.
>
> Ralf Hildebrandt wrote:
>> I have to face it, my users are retards:
>
> Is there any other kind of user?  ;)
>
> <snip>
>
>> Thus I need a feature in dovecot that will tell them via email:
>>
>> Level1: "You ALMOST exceeded your quota, you're at 90% now"
>> Level2: "You're very close to exceededin your quota, you're at 95%
>> now"
>> Level3: "Would you please clean up now? You're at 99% now"
>
> What I'd *really* like to see implemented is something along the lines
> outlined below - but of course, this will depend entirely on whether or
> not Timo thinks it is doable - or desirable...
>
> I'm thinking this would be best handled by the Quota plug-in - either 
> as part of the current one, or as a separate/different one...
>
> *** 1. Have a 'special' user-specific folder (by special, I mean like 
> the Drafts, Sent, Templates folders) that dovecot controls. For 
> purposes of this FR, call it the 'over-quota' folder.
>
> Question: could the .tmp folder be used for this? No sense in 
> reinventing the wheel if necessary... and then if someone migrated 
> from dovecot to something else, and messages were left in there from 
> an over-quota condition, that other solution would most likely just 
> move these to .new the first time it ran, right?
>
> Or, possibly, could dovecot create a new one maybe, .oqt (for 
> over-quota), and store the queued messages there until the over-quota 
> condition was rectified?
>
> Anyway, the main thing is, this folder should be essentially hidden 
> from the user so they do *not* have access to it, and should 
> temporarily hold messages that come in that are unable to be delivered 
> due to an over-quota condition.

Would seem to me that this would then require quota management over the 
.oqt folder.  What happens if someone is on an extended 
vacation/leave-of-absence, or leaves the company or ISP and the account 
is not removed?  The .oqt would continue to grow indefinitely.  I guess 
one could implement a max .oqt folder size, but then that would 
duplicate what quota is already doing anyway.
>
> *** 2. Make dovecot aware of and use a special 'Quota Status' message 
> that it uses to inform a user that they are over quota. This message 
> should be able to be customized, with variables (like, for example, it 
> should list the messages that are currently being prevented from being 
> moved to the Inbox - including, optionally, the Subject, the sender, 
> date/time, attachments, size, etc - as well as provide general quota 
> information (ie, how close to or over quota they are, and how much 
> they'd need to delete or move to Local Folders to allow delivery of 
> all of the messages being held), and lastly, any custom information 
> the System Admin wanted to provide - like, maybe, specific 
> instructions for how to move messages to Local Folders, how to request 
> additional storage allowance, etc.
>
> *** 3. When user is over quota, have LDA deliver to the folder 
> referenced above (# 1) - (yes, accept the message for final delivery 
> from the sending mta), and then update the Quota Status message and 
> move it to the Inbox.
>
> Optionally, a bounce/notification could be generated to the sender, 
> informing them that their message is being 'held in queue' or 
> something to that effect, due to the recipient being over-quota.
>
> *** 4. Once the user deletes enough mail to come back under quota, 
> dovecot would then move messages from the 'over-quota' folder to his 
> Inbox.
>
> Ok, again, am willing to hear *valid* reasons how/why this is a 
> terrible idea... :)

I think a system that simply warns a user like Ralf outlined above seems 
a better solution to me, and is more resilient and less likely to cause 
admin headaches due to account maintenance oversights.

Just my 2 cents...

Bill