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