Email Client

[Gene Heskett]

On Sunday 18 November 2007, Dotan Cohen wrote:
>On 17/11/2007, Gene Heskett <gene.heskett at verizon.net> wrote:
>> >> you shouldn't have spam detection implemented _in_ your
>> >> email client, when it's a separate task.
>> >
>> >Why?
>> >
>> >To me it seems that would be the obvious place.
>>
>> 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.
>
>I'd agree, except for the fact that false positives/negatives need to
>be marked. I go through the spam pile once a week and check all 15000
>of them.
>
So do I, that which procmail doesn't dispose of first.  I sort it into folders 
according to which server it came from and inspect it before deleting.

>> 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.
>
>You run Kmail as root? Who are you and what have you done with Gene?

Oh, I'm Gene alright, or was the last time I walked by the hall mirror. :)
As for the root operation, its my box.  I use the su - command to do what 
needs to be done as the user, like amanda for example, but normally I'm root 
99.9% of the time here.  There is also a DD-WRT on an old x86 box firewall 
between me & the net.  Which means 99.9% of the problems here are PEBKAC 
caused.  The other .1% that I haven't found yet might be because I run 
bleeding edge kernels here, 2.6.24-rc3 ATM.

>> 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.
>
>How do you train? Details, because I just may adapt your strategy.
>
My list of filters in kmail is sorted such that everything is disposed of 
before it gets to the last 2 or 3 rules, so in essence I have 2 sets of 
rules, and the sa-learn-ham and sa-learn-spam are saved in this never reached 
region of the list, and are checkmarked so they show up as optionals at the 
bottom of the message pulldown.  When I have a false positive, I move it to 
the ham folder, pull down the message menu to the apply filter and select the 
sa-learn-ham filter.  Spam that doesn't get caught gets moved to a spam 
folder and when there's 30 or so, I hi-lite them all and select the 
sa-learn-spam filter & go get a refill if theres any in the pot. It might be 
done by the time I get back if I stop & make small talk with the missus, 
who's probably doing a crossword puzzle.

>> 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.
>
>FWIW, Tbird doesn't pause at all when marking spam. You wouldn't
>believe how quick it marks them.

Yes, I know its quick, but its also unmitigated hell to configure too.  If one 
didn't write that code, one has NDI where all the special keystrokes to do 
this and that are, cuz the docs suck.   kmail is 'intuitive'.
I did use TB, for quite a while when I was last sitting in a motel in upstate 
Michigan.  That was because I hadn't configured kmail on the lappy, now I 
have.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Linux; a re-Gnu-able resource. 

   -- Gareth Barnard