Hi
This weekend we had a runaway email endless loop. When it was killed after 18 hours, my inbox had 135,000 messages in it...there were two messages that were being endlessly sent and bounced and I'm on the postmaster alias.
By far the fastest option is to simply use a tool which can examine the file system and delete - eg SSH. (try winscp on windows if you want a gui...)
Thunderbird was able to do a mass select of one of the two messages, and deleted 65,000, but after that it locked up. I ended up firing up Pine to do the final 65,000...whereas TBird had had mulitple imap sessions (and failed), Pine only had one and did the job. And even after I had done the mass delete of the other 65,000 and the inbox was down to 2000 messages, TBird was still hiding under the covers and telling me there were still 135,000 messages. In the end, I had to kill the TBird profile for that account and recreate it.
To be fair to tbird - probably what happened was that it was shuffling lots of delete commands to the backend server. When you "cheated" and used another tool, it was then doing it's sync to discover which messages were deleted. Unless you have a VERY fast internet connection then be aware that the commands it uses to check for new messages could actually take multiple minutes to execute and many more while it deletes from the local offline index.
Basically it's a good little program but not really optimised for this requirement
I'm wondering if there is something we can tell users to use when Things Are Dire. GUI would be better since it removes one of the few remaining reasons for a logon server
You might want to consider scripting a little perl micro interface? I saw someone once write a very basic curses mail client in perl (ruby, etc would also be fine, nothing magic about perl) and for the kind of use case you have in mind something like a "delete by user" or "delete by message_id" might be helpful?
Additionally consider adding some protection against mail loops to your server - it used to be de-riguer back in the procmail days, but something as simple as checking for an "X-Been-Here" on any auto generated content is a good first start. Your choice of MDA is likely to determine the exact favoured approach.
Auto "out of the office" responders should definitely only notify every X days as well to help with this kind of thing.
Finally checking for the mandatory headers that all auto generated stuff should create should help...
Good luck
Ed W