trinity-users@lists.pearsoncomputing.net

Message: previous - next
Month: December 2019

Re: [trinity-users] Re: [BULK] [trinity-users] Re: Re: [BULK] Re: [trinity-users] Re: [BULK] Re: [trinity-users] my KMail problems, continued

From: "David C. Rankin" <drankinatty@...>
Date: Mon, 9 Dec 2019 19:45:33 -0600
On 12/08/2019 06:46 AM, Gene Heskett wrote:
> I don't see a thing there that kmail should get a tummy ache over.  That 
> script has been running daily for close to 20 years now. If fetchmail is 
> running, incoming mail is handled automaticly by sending kmail a check 
> mail message over the dcop or dbus message bus.  All kmail has to do is 
> retrieve anything procmail has put in /var/spool/mail/* and sort it to 
> the correct folder. Since kmail is single-threaded, thats maybe a 200 ms 
> freeze of the composer while it's doing that.  The only independent 
> thread seems to be the parent thread doing the indexing as killing it 
> kills the other kmail instances seen by htop. 5 total, but the other 4 
> never record any cpu time.
> 
> Computers should save you work, not make it, so I write scripts to 
> automate it.
> 
> Thank you deloptes.
> 
> Cheers, Gene Heskett

I do the same thing with spamassassin but utilizing 4-folders:

spam
spam-learn
spam-probably
spam-unlearn

where spamassassin drops potential spam in spam-probabaly. I look through it
and move what is spam to spam-learn (where it is processed by sa-learn and
moved to spam automatically) and move what isn't spam to spam-unlearn where
unlearn is run on it and it is put back in the inbox.

The key here, and in your case, the movement of mail between folders should
not be causing a reindexing of your entire mail store. If that is what is
happening, then that is the bug that should be looked at and confirmed.

-- 
David C. Rankin, J.D.,P.E.