[Dovecot] Quota handling - v2 - updated FR
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
Hi Bill,
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.
No reason that this couldn't be configurable, but that isn't how I would implement it. The purpose of this - for me - is to insure that *no* mail is rejected or lost because of an over-quota condition.
What happens if someone is on an extended vacation/leave-of-absence, or leaves the company or ISP and the account is not removed?
I neglected to mention, but of course these quota status messages should also be provided to a designated admin account...
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.
Just notify the admin.
If the admin is so incompetent that they don't check their system logs and have themselves designated for being notified of conditions like this, then they're going to have many more problems than just a ever-growing .oqt directory.
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.
Well, definitely this is better in one sense - it is implementable now... :)
But, one of my clients simply refuses to consider rejecting mail due to over quota - so, this is the only way I can think of to guarantee this for him - and, to be honest, I really like the idea of doing it the way I'm describing. It just seems cleaner, and provides more consistent and reliable end-user feedback/notification...
But, no response from Timo yet so maybe he doesn't like the idea... ;)
Anyway, thanks for your thoughts,
--
Best regards,
Charles
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@amigo.net
How is this different from just telling the customer there quota has been increased by the size of their .oqt box?
Because it hasn't - they can't GET this mail until they deal with their over-quota condition. All this does is prevent mail from being REJECTED, and provide a more consistent and effective way to communicate the problem to the user.
Quota is there for a reason at my work, to stop accepting mail if the user already has too much mail.
Currently, that is correct - but I have a customer who wants to ACCEPT the mail for delivery (ie, never, ever REJECT a message due to over-quota), but just not give it to the USER until they fix their quota problem.
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.
Funny - I see what I am proposing as being much *more* clear, with LESS fuzzy gray areas.
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.
This is your *opinion*. Personally, I disagree - but, of course, I would never force my way on you. As I have maintained, this should definitely be configurable - including the option of sending a notification to the sender that their message was accepted for delivery, but won't be delivered to the users Inbox until they fix their quota problem.
This means all the sender has to do is call the user and tell them 'I sent you the message - it is waiting for you - fix your quota, idiot'...
A soft bounce may take days of retrying before the sender is aware of a problem,
Who is talking about soft bouncing? Did you even read my proposal?
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.
True - but then they would be oblivious in either case, so I fail to see your point.
89% of the cases I see of users over quota, is due to negligence.
Yep... and my way, no mail is lost or bounced, it is just held pending resolution of the over-quota condition, after which it is *immediately* delivered to their Inbox within SECONDS.
10% is for mailboxes that are no longer in use.
Why are you leaving an account open that is no longer in use?
Admittedly, for an ISP, this may not be a good thing to do - but not every mail system belongs to an ISP. I can see a lot of benefit to Corporate mail systems.
I wouldn't think it a good idea to allocate extra disk space to either of these cases.
So set the hard limit on the over-quota box. But for 95+% of cases, it would never get used.
The other 1% calls us to ask for more space which we gladly sell to them.
Obviously, you are selling mail services - so yes, I agree, this may not be a good fit for an ISP or someone selling mail services - but maybe you could comment on this from the perspective that not everyone would use it like you do...
Do you seriously not see a benefit to a corporate user?
I guess I'm just way off base here...
Maybe I'll see if I can find someone willing to modify the Quot Plugin that exists now...
--
Best regards,
Charles
How is this different from just telling the customer there quota has been increased by the size of their .oqt box?
Because it hasn't - they can't GET this mail until they deal with their over-quota condition. All this does is prevent mail from being REJECTED, and provide a more consistent and effective way to communicate the problem to the user.
But they know that they can leave without cleaning up their mail, because their messages will be delivered anyways. So it merely encourages users to abuse quota. A smart user could abuse this as well, Forward several large messages back to themselves, to put them at the end of the queue, delete from inbox, get the new messages in, etc. Essentially giving them extra quota.
Quota is there for a reason at my work, to stop accepting mail if the user already has too much mail.
Currently, that is correct - but I have a customer who wants to ACCEPT the mail for delivery (ie, never, ever REJECT a message due to over-quota), but just not give it to the USER until they fix their quota problem.
Beat that customer with a clue stick? The whole I want quotas, but don't want them seems silly. But it's their money, they can probably hire someone to do it.
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.
Funny - I see what I am proposing as being much *more* clear, with LESS fuzzy gray areas.
option 1: if you go over quota you will not get any more mail option 2: If you go over your quota you will get your mail your mail will fall into a bucket nobody can see, but you will get status messages that messages are in this bucket, with detailed instructions to follow, which no matter how well they are written will generate more questions.
option one is easier to explain for me.
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.
This is your *opinion*. Personally, I disagree - but, of course, I would never force my way on you.
Correct, you were asking for opinions, whether or not you consider it is up to you.
As I have maintained, this should definitely be configurable - including the option of sending a notification to the sender that their message was accepted for delivery, but won't be delivered to the users Inbox until they fix their quota problem. This means all the sender has to do is call the user and tell them 'I sent you the message - it is waiting for you - fix your quota, idiot'...
Configurable is always good, and I have never disputed that. However I doubt I would appreciate a message like that coming back to me. The only time I would want a DSN is if the message wasn't delivered. I'd probably mark "delivered but over-quota" messages as spam. So if you do get this implemented be sure to opt me out of these notices if I happen to send a message that way. :)
A soft bounce may take days of retrying before the sender is aware of a problem,
Who is talking about soft bouncing? Did you even read my proposal? OK I admit this is not directly part of your proposal, but this is the "other solution" people often mention to not loosing mail that is over quota. My soapbox got carried away, sorry for drifting.
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.
True - but then they would be oblivious in either case, so I fail to see your point. The point being that extra complications wouldn't help, so why bother? Save the disk space for something else.
89% of the cases I see of users over quota, is due to negligence.
Yep... and my way, no mail is lost or bounced, it is just held pending resolution of the over-quota condition, after which it is *immediately* delivered to their Inbox within SECONDS.
Unless they take weeks to fix the problem, then it really isn't delivered for WEEKS.
10% is for mailboxes that are no longer in use.
Why are you leaving an account open that is no longer in use?
While they may not be used, the customer hasn't called to close them either.
Admittedly, for an ISP, this may not be a good thing to do - but not every mail system belongs to an ISP. I can see a lot of benefit to Corporate mail systems.
I wouldn't think it a good idea to allocate extra disk space to either of these cases.
So set the hard limit on the over-quota box. But for 95+% of cases, it would never get used.
Easier to set a hard limit on the mailbox. Rather than saying this is your quota, but if you don't wish to respect that, then this is your *real* quota.
The other 1% calls us to ask for more space which we gladly sell to them.
Obviously, you are selling mail services - so yes, I agree, this may not be a good fit for an ISP or someone selling mail services - but maybe you could comment on this from the perspective that not everyone would use it like you do...
Do you seriously not see a benefit to a corporate user?
Actually no. That's just the way I am, set a rule and stick to it. If I think the users need more space, I consider raising the quota.
I guess I'm just way off base here...
Not if you have somebody actually asking for it. But I'd seriously see how much it is truly worth to that customer. As this really feels like a marginal case, I don't think there will be enough others willing to sponser it.
-- Kenny Dail kend@amigo.net
Charles wrote:
Because it hasn't - they can't GET this mail until they deal with their over-quota condition. All this does is prevent mail from being REJECTED, and provide a more consistent and effective way to communicate the problem to the user.
[...] - but I have a customer who wants to ACCEPT the mail for delivery (ie, never, ever REJECT a message due to over-quota), but just not give it to the USER until they fix their quota problem.
For some environments, such as companies, universities, etc. this "accept but don't yet deliver" option is a good one. Indeed, if the incoming email is for a legal requirement (in UK, Freedom of Information, Data Protection, etc.) for that institution, then rejection/bounce simply because of a temporary quota glitch could be bad practice, bad for corporate image, and possibly even get legal if it were routine rather than one-off glitch.
For other environments, presumably some that Kenny had in mind, a single level is probably fine. (But see below.)
Different customer (or user community) environments may well have different preferences or requirements.
Charles's "accept but don't yet deliver" sounds like a good option to have available. Kenny's simpler "deliver or reject" may well be a reasonable option for his environment. This difference really lies in their human environments, not the teechnical options or implementations.
I know it's fashionable to knock and criticise Microsoft Exchange(!) but they have a multi-threshold quota system available. (One of the other thresholds is "you can't send outgoing until you get within quota" which is less easy to translate into a dovecot, IMAP-only, environment.) Perhaps (dare I say?!) MS have good reasons for making multi-threshold quotas available as an option.
Kenny wrote:
option 1: if you go over quota you will not get any more mail option 2: If you go over your quota you will get your mail your mail will fall into a bucket nobody can see, but you will get status messages that messages are in this bucket, with detailed instructions to follow, which no matter how well they are written will generate more questions.
Yes. Two options. Your environment may suit the first, simpler, option. Fine. Charles (and some of the rest of us) would assess our different environments as being able to benefit from the second being available in some circumstances.
Kenny continued:
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.
For some environments (e.g. users at a mass-market ISP) this may well be appropriate. For other environments (e.g. the financial/legal department within that same ISP) that probably is far from ideal.
In ITIL terms: two different (and necessarily different) Service Level Agreements (SLAs) for two different customer groups, whose implementation could be greatly eased by the availability of a multi-threshold quota option (perhaps used for one group, not the other).
Hope that helps.
--
: David Lee I.T. Service : : Senior Systems Programmer Computer Centre : : UNIX Team Leader Durham University : : South Road : : http://www.dur.ac.uk/t.d.lee/ Durham DH1 3LE : : Phone: +44 191 334 2752 U.K. :
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
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.
Or how about using a virtual folder instead (assuming they will be supported in Dovecot in the near future). It would work like this:
- A read-only global folder called overquota (normally not accessible) contains one generic message saying that you are over quota and will not receive any new messages (with instructions on how to delete email to go under quota).
- Using virtual folders, when a user goes over quota, the user's inbox is shown together (merged) with the read-only overquota folder.
- When a user is back under quota, the inbox will go back to normal.
Using this method, no additional disk space is required for writing over
quota messages, so it would work with a hard quota or filesystem quota.
On the filesystem is only one message (owned by an admin) that would be
shown to everyone over quota - no need to have multiple copies of this
message.
Additionally, this method could be further developed and configured with a setting to warn users that they are almost at their limit (using a different virtual folder containing a "you're at 95% or 99% of your quota" message). Having a constant, new, important (flagged), un-deletable message in ones inbox would be a constant reminder that action needs to be taken.
Scott Alter
Or how about using a virtual folder instead (assuming they will be supported in Dovecot in the near future). It would work like this:
- A read-only global folder called overquota (normally not accessible) contains one generic message saying that you are over quota and will not receive any new messages (with instructions on how to delete email to go under quota).
- Using virtual folders, when a user goes over quota, the user's inbox is shown together (merged) with the read-only overquota folder.
- When a user is back under quota, the inbox will go back to normal.
Interesting... and as long as there is only one message for each user (not sure how you meant 'global folder'), then this would work perfectly
- but wouldn't the size of the virtual folder count against the quota too?
Using this method, no additional disk space is required for writing over quota messages, so it would work with a hard quota or filesystem quota.
Ok, I like it...
On the filesystem is only one message (owned by an admin) that would be shown to everyone over quota - no need to have multiple copies of this message.
I really like the idea of a single message for each user, that shows a summary of all of the messages that were rejected while they were over quota (Message Date/Time, Subject, size, who it was from, etc).
Maybe the global folder could be non-virtual, then a message for each user could be deposited there, then create either:
a virtual sub-folder for each user that contains only their over quota message, that is then merged with their Inbox, or
just create a link to this message in the users Inbox
I don't really care how it is implementd on the back end, as long as the desired result is achived
Additionally, this method could be further developed and configured with a setting to warn users that they are almost at their limit (using a different virtual folder containing a "you're at 95% or 99% of your quota" message). Having a constant, new, important (flagged), un-deletable message in ones inbox would be a constant reminder that action needs to be taken.
I really like that too (flagged, undeletable message), although I had already imagined that this message would be undeletable...
Thanks for the input.
Do you think this could all be done via the Quota Plugin?
--
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.
participants (6)
-
Bill Landry
-
Charles Marcus
-
David Lee
-
Kenny Dail
-
Scott Alter
-
Timo Sirainen