Andrea Mistrali wrote: > Hi to all! > I was doing maintenance on my dbmail installation and I found that too > many messages have status = 0. > > IIRC, > when I insert a message it is inserted with status=0, > when I read it it goes to status = 1 and read_flag is set to 1, > when I delete it it goes to status = 2 and deleted_flag is set to 1, > when I run dbmail-util -pdy it goes to status=3, > after all messages with status 3 are deleted. > > I've made some queries to check which folders are biggest and I've found > the INBOX of one of my user containing 5000 messages. I've checked and > most of them have deleted_flag=1, but status=0.
I checked. I see a similar pattern in my setups. Those are imap users that delete messages, but never expunge their mailboxes. > > I've made some check in a folder with a single message and everything > seems to work fine, but I still have some doubts... > > Is it safe to do: > UPDATE dbmail_messages SET status=1 WHERE seen_flag=1; yes. > UPDATE dbmail_messages SET status=2 WHERE deleted_flag=1; > ? That is a bofh thing: it forces an EXPUNGE on the mailboxes involved. I would suggest you only do that for: - users that never expunge. - messages older than X days. > > Plus, dbmail-maintenance give me errors of duplicate entries in > dbmail_datetimefield: > Repairing DBMAIL for cached header values... > Ok. Found [9] un-cached physmessages. > Jul 02 12:53:52 zeus dbmail-util[6308]: Error:[sql] > dbmysql.c,db_query(+290): [Duplicate entry '338845-1970-01-01 00:00:00' > for key 2] [INSERT INTO dbmail_datefield (physmessage_id, datefield) > VALUES (338845,'1970-01-01 00:00:00')] > Can I empty all cache tables and recreate caches? is it worth it? Depends. This is bug #688 you're talking about. Are you inserting non-MIME data into dbmail? > Last question: why user [EMAIL PROTECTED]@__ has some > messages in his INBOX? Those may well be transient messages being delivered. Messages in that mailbox older than say a couple of minutes are clearly bogus and can be deleted. They are most likely the result of delivery problems at some time in the past. I see them as well, and always clustered around a specific point in time (ldap failures would explain them in my situation). > > (dbmail ver 2.2.10, mysql 5.0.32 on Debian amd64) > > TIA > Andre > > > _______________________________________________ > DBmail mailing list > [email protected] > https://mailman.fastxs.nl/mailman/listinfo/dbmail > -- ________________________________________________________________ Paul Stevens paul at nfg.nl NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31 The Netherlands________________________________http://www.nfg.nl _______________________________________________ DBmail mailing list [email protected] https://mailman.fastxs.nl/mailman/listinfo/dbmail
