A separate table would be superfluous I think. I just have a cron job that runs dbmail-maintenance on a periodic basis, right now it's weekly, but I may change it to daily or hourly as more accounts get placed on the server.
If you need to list the deleted messages an appropriate SELECT statement could be conceived of pretty easily. On Wed, 2002-12-04 at 17:11, Richard Barrington wrote: > FWIW, running dbmail-maintenance -d and then -p on my system resulted in > 0 messages being deleted. A check of my tables showed none listed with > other than 0 status... That was with RC4 Postgresql. It looks like the > various flags are being used, rather than the status. > > I think the idea of keeping old messages around is good from a user's > point of view, but bad from an admin/resource point of view - how many > GB of spam will be sitting on machines? I guess I'd like to see a less > "admin-intensive" method of dealing with it... Maybe moving the deleted > messages to a separate table, so that could be backed up or emptied as > required. Any solutions are welcome :-). > > On Thu, 2002-12-05 at 06:39, Roel Rozendaal - IC&S wrote: > > Well, it depends. Messages aren't actually deleted until you run > > dbmail-maintenance - twice. Let's see how it works: > > each message has an extra attribute called 'status'. For the moment, it > > can have the following values: > > > > 0 - new message > > 1 - message has been read > > 2 - message has been deleted (pop) or deleted&expunged (imap) by user > > 3 - message is set for deletion > > > > the change from 2 --> 3 is done by running dbmail-maintenance -d > > the change from 3 to actual deletion is done by running > > dbmail-maintenance -p > >
