Imposing a limit on QuestMail.

[skolnick]

Is there a way for me to limit the amount of e-mail that can accumulate? I am looking for a solution I can turn on or off by e-mail account that--like the systems at Yahoo and Hotmail--can automatically delete messages more than some (preferably configurable) number of days old, and/or limit the size a mailbox is allowed to grow to.

I have a way to implement this myself, but it requires knowledge of the account password. Is there a more elegant solution?

[sheila]

Dave,

Try experimenting with the vdu command. The shell account in a telnet sessions can enter

$ vdu

at the command line prompt. You will get output that looks something like this:


shelluser(disabled) 0 0 0 0 0 0 20
joe 2 16 0 0 20 296 164
sales 1 4 0 0 0 0 16
tommy 12 100 0 0 0 0 20
devnull(disabled) 0 0 0 0 0 0 16


The account names that have "disabled" after them are forwarding aliases. The others are POP/IMAP accounts.

The information following is:

# of new messages
kB in new messages
# of old messages
kB in old messages
# of read messages
kB in read messages
kB in overhead files

It is possible that you could write a mail script that invokes vdu when an incoming email arrives (vdu can be called by either the shell userID or the xdomain userID. The former runs cgi scripts, the latter runs mail scripts.), and then have the script determine how much space the account has used so far and whether it should accept the message or bounce it.

Alternatively, you could write some script that would fire off at set times (via cron) and measure the occupied disk space and make a POP connection and delete the oldest messages from the account, or delete messages by some other criteria that you might determine.

Hope this gives you some ideas.

[sheila]

Alternatively, you could write some script that would fire off at set times (via cron) and measure the occupied disk space and make a POP connection and delete the oldest messages from the account, or delete messages by some other criteria that you might determine.

Sorry. The quoted solution also requires knowledge of the account password as well. But the first one I mentioned, about running mail scripts, checking the disk space as the messages come in, and bouncing if the account is "over quota" does not require knowledge of the account passwords.

Don't know what I was thinking this morning. :\

[skolnick]

The way I would really like it to work is as a circular buffer. In this little fantasy of mine I could set the buffer size in either number of messages, number of days, or number of MBs and as new messages came in they would push the oldest ones into the bit bucket.

I have yet to do a web site for someone that didn't turn into a consultation job on general business practice (which is really my field, much as I try to avoid spreadsheets and viewgraphs). In this case, I'm trying to get some folks off a potpourri of hotmail and yahoo addresses and onto a consistent set of branded e-mail addresses. Some will be hard to move off the web interface and I don't want to have to watch the file sizes manually.

[Terra]

as new messages came in they would push the oldest ones into the bit bucket.
One of my strict (hands-off) policies is that no FutureQuest email system or subsystem is allowed to automatically delete any piece of email... This is a manual task that must be accomplished by the site owner...

--
Terra
--We have just deleted: "You have won 10 Million Dollars - Claim your prize now!!!" - ironically that message was the real deal--
FutureQuest

[skolnick]

Originally posted by Terra:
as new messages came in they would push the oldest ones into the bit bucket.
One of my strict (hands-off) policies is that no FutureQuest email system or subsystem is allowed to automatically delete any piece of email... This is a manual task that must be accomplished by the site owner...

I wholeheartedly agree. I also know that one particular person will want to use the web interface and just let her mailbox grow to infinity (or until you yell at me).

Sounds like I am back to Sheila's original concept (golly she's smart). I'll write a script using vdu to get the box sizes, establish a threshold that fires off a tailored message to anyone who's box is getting too big (with a copy to me) and go from there.

[skolnick]

As long as I'm doing this, can I count on du -sc --exclude=stats /big/dom/xdomain/ to provide a good number for keeping track of non-e-mail related disk usage?

[skolnick]

Bless the split command and regular expressions. I have a Perl script that grabs the output of du and vdu, parses out the parts I care about and adds up the individual and aggregate totals. I just have to write the subroutines that notify the individual (copy to me) of overage and me of a total account approaching the limit. This will work fine, and keeps me in the loop if someone is letting his/her box get too big. I can even set different thresholds for different people if I like ...

[Terra]

dave:
How often do you poll these values?

Are you using a cronjob, or do you initiate manually?

I am concerned about the loads induced by 'du' and 'vdu', especially if we are working with a domain with a ton of tiny files...

--
Terra
sysAdmin
FutureQuest

[skolnick]

Well in the last hour or so it has run a whole bunch of times as I worked on it and tested the bits (piecewise implementation: capture the output in an array, okay that works, now parse it, okay that works, now add it all up, okay that works ...). I hadn't honestly given much thought to how often to run it. My log analyzer runs nightly at 0145, so I would probably default to some other obscure time in the middle of the night. How often do you run your disk monitoring? There is little point in me running daily if you run weekly, and I can't see the value in me running more often than daily even if you do.

Would you like to look at the script before I implement it?