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. *** 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... :) -- Best regards, Charles
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
> 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. > > *** 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... :)How is this different from just telling the customer there quota has been increased by the size of their .oqt box? Quota is there for a reason at my work, to stop accepting mail if the user already has too much mail. As we deal with customers, and can't just fire them for being too stupid, it is much better to give them a clear policy with no fuzzy grey areas. I think this also better in the case of the few employees I have to support as well. A hard bounce is the right way to go in this case, because it will let the sender know right away that there is a problem sending to the user. A soft bounce may take days of retrying before the sender is aware of a problem, especially since very few servers can handle a quota bounce at the smtp level. The recipient is probably going to be oblivious that a problem exists because if they are over quota, it usually means they haven't been checking their mail and will not see a quota warning message. 89% of the cases I see of users over quota, is due to negligence. 10% is for mailboxes that are no longer in use. I wouldn't think it a good idea to allocate extra disk space to either of these cases. The other 1% calls us to ask for more space which we gladly sell to them. -- Kenny Dail <kend at amigo.net>
> 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.<snip> Ok, seems there is no interest in doing this - and I do understand the objections... but how about a more consistent method for handling over quota conditions? This could be as simple as: *** 1. 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 bounced - including, optionally, the Subject, the sender, date/time, 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 get back below a certain level (again, configurable)), 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. *** 2. When user goes over quota, update the Quota Status message and move it to the Inbox. *** 3. While the user is over quota, every time a message to them is bounced, update the Quota Status message with the new information (append the details of the message just bounced, so they will have a complete list of messages that were bounced while they were over quota). Hmmm... I think I like this idea much better anyway... -- Best regards, Charles
On Wed, 2007-05-23 at 07:30 -0400, Charles Marcus wrote:> *** 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.I think most of this could be scripted. deliver.sh: # -e is v1.1+ deliver -e -d $USER if [ $? = $EX_NOPERM ]; then # over quota is the only reason why it can fail deliver -c /etc/dovecot-noquota.conf -d $USER -m overquota # create your over quota email using some special maildir filename and # delete the existing one from the user's INBOX new_filename=overquota.$$.`date +%s` rm /home/$USER/Maildir/cur/overquota.* fi exit $? Then create a global ACL for the overquota mailbox so that it can't be accessed at all. Once user is under quota move the messages to INBOX, for example when logging in. The only problem is knowing easily when user is under quota. Maybe quota-warning.patch could be modified to support under-quota hooking as well. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://dovecot.org/pipermail/dovecot/attachments/20070604/2b8d7aca/attachment-0002.bin>