[Dovecot] Need a quick, safe method to empty /home/user/Maildir/{.Junk, .Trash}

[Bill Cole]

At 9:22 AM -0400 6/12/08, Jeff Kowalczyk wrote:
>I have some (Thunderbird client, dovecot-1.0.13, Maildir) users who get an
>appalling amount of spam-with-attachment, and it's causing backups to take
>an inordinate amount of time.
>
>I'll implement some quota and server-side spam management when I go to
>dovecot-1.1, but in the meantime:
>
>What is the safest way to empty all messages within, but not delete, the
>following folders from the server command line:
>
>/home/user/Maildir/.Junk
>/home/user/Maildir/.Trash
>
>I don't want the Thunderbird-2.0.14 client to report corrupt
>indexing, or worse not show the folder at next use.

The way to do that in a shell (rather than via Dovecot) would be to 
remove all of the current message files and all of Dovecot's indexing 
and metadata caching:


cd /home/user/Maildir/.Junk
rm dovecot-index* cur/*
cd /home/user/Maildir/.Trash
rm dovecot-index* cur/*

(restructure that as you like, I've written it that way to make the 
operations clear)


There is no need normally to delete the dovecot-uidlist or 
dovecot-keywords files, although in principle you could do so and a 
well-designed client would be untroubled. The former maps IMAP UID's 
to specific messages, and the later maps custom keywords to numeric 
ID's. Dovecot will rebuild those as needed, but if you happen to 
whack them while a message is being delivered or moved into that 
folder you could end up with a confused client and lost keywords. 
However, I DO clobber the dovecot-uidlist in .Trash as part of my 
monthly housekeeping because it tends to get very large and I'm not 
so worried about clients getting confused about the contents of the 
Trash. If you are forcibly removing the messages and index files at a 
time when there isn't likely to be client activity in progress, 
there is very little risk in removing the dovecot-uidlist. There's 
unlikely to be any point in ever removing the dovecot-keywords file, 
since it tends to only have a handful of entries anyway and there's 
no harm in keeping the ones not actually in use by current messages.

-- 
Bill Cole
bill at scconsult.com