[Dovecot] OT: Looking for a robust IMAP client

Ed W lists at wildgooses.com
Mon Dec 15 21:01:32 EET 2008


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


More information about the dovecot mailing list