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
