Email Client

[Billie Walsh]

On 11/17/2007 Gene Heskett wrote:
> No, is not.  That puts all the onus to do all this into a foreground task,
> kmail, which when it has to do all that, freezes your user interface,
> sometimes for rather extended periods of time.  This should more
> properly be done as background tasks, separate from kmail itself.
>
> Here, I pull from 3 servers, as an unpriviledged user, with fetchmail
> running every 90 seconds as a background task, which hands it off to
> procmail, also running as a normal user, which in turn runs most of it
through
> spamassassin before dumping it into that users mail spool.  Then kmail,
running as
> root cuz I do, pulls from that spool file, sorts it into the various
> folders and presents it to me to read.  And procmail/spamassassin are
fairly well
> trained so its pretty safe to have procmail dump those with high spam
ratings
> (7+) straight to /dev/null.  I train on what gets through, watch the logs
> and haven't had a false positive except for some of the junk my kids &
> their winderz boxes send me.  The next door neighbor also sends me all
> sorts of chain letter crap that while we're good friends, winds up in
> /dev/null too.
>
> So the only pauses in kmail's composer now is only a second or two
while its
> doing that sorting of what procmail actually passes.  That's a much nicer
> user experience IMNSHO.

I was just curious. Thanks for your views.

My mail needs are much less elaborate than your. *<[:o) However, my ISP
mail server does have it's own spam trap. Took me a few days to get it
trained but now it's quite efficient. I guess this is rather analogous
to your "procmail/spamassin". Then I use the spam filter built into
Thunderbird to catch what gets through that. It doesn't seem to slow
Thunderbird down at all. It just drops into the "Inbox" with everything
else then falls over to the trash.

I don't usually sort it unless there is something special going on.