Re: Spam.el tutorial

[Xavier Maillard <zedek@gnu-rox.org>]

Ted Zlatanov <tzz@lifelogs.com> disait récemment que :

>>[...]

>> 
>> Is it recommended to 'mix' the spam methods ? I mean if I want to
>> use all spam methods at once, is this supposed to work or may I
>> expect some bad side effects (except the slowness of spam detection)
>> ?
>
> No, I encourage it.  As long as you call spam-initialize, you don't
> ever have to set any spam-use-XYZ variable to t.  You can give
> specific checks to spam-split also - see the docs.

Good to know that then. Until I read this i explicitly set to t all the
spam-use-XYZ when I wanted to use them.

So if I understand correctly, I can in my split chain do something like 
(: spam-split 'spam-use-bogofilter) and so on ?

> spam-split can also take a group name, which will override
> spam-split-group.  So your nn{mail,imap}-split-fancy lists can get
> pretty complicated, you can for instance send all blackhole-detected
> spam to one place and all blacklist-detected spam to another place.

Thank you for the tip.

[...]

>> Are we in the No Gnus development cycle yet ? I asked it not that
>> long and nobody answered.
>
> I defer to the Gnus overlords :)

Eh eh ;)

>> Does this mean incoming mail splitting for spam will disappear soon
>> ? I am currently actively testing your spam autodetection new
>> features and it really works/rocks :)
>
> Well, spam autodetection has these benefits:
>
> - faster to get mail

Correct if and only if you don't do spam-split on your split receipts.
 
> - less complication with the splitting process, which has had some
>   issues (especially nnimap)
>
> - easier to customize for particular kinds of splitting you want (with
>   incoming mail splitting, you can only choose splitting chains based
>   on the backend essentially)

Ok.

> - easier to see what's happening

Hum how so ?

> - it's less problematic to interrupt spam autodetection than mail
>   splitting

Yes.

> - you can set spam-process-destination to any group name, across
>   backends, and the spam will be moved correctly

Nice.

> - mass autodetection is much easier than mass spam-splitting of
>   incoming mail

Agree.

> - all headers, etc. Gnus info is in place whereas with splitting
>   incoming mail that information is not necessarily available
>
> - obviously, spam autodetection works for read-only backends

Ah here is the point. Since now, I set spam-autodetect even for my
normal mail groups (nnml backends) and I just didn't see anything
happening except a bunch of CPU used when entering mailing-list groups.

> But there are disadvantages:
>
> - entering a group is slower with autodetection than splitting
>   incoming mail

Clearly. 

> - spam will not go away, it will still be in the group when you enter
>   it - this may be annoying.  We can actually deal with this pretty
>   easily, by moving spam explicitly after spam-find-spam is called.
>   Of course, this will be an option :)
>
> The best solution, as always, may be a compromise:
>
> - spam-split in incoming mail will move mail to a temporary queue
>   folder
>
> - right afterwards, spam autodetection will be done on the queue
>   folder
>
> - ham will be sent to the next item in the nn{mail,imap}-split-fancy
>   chain

Hmmm. I don't think I have correctly understood this part. Best for me
is to try that way.

> I'm not sure how this may work, and I'm not going to worry about it
> until the current Gnus development cycle is done.  Fixing the manual
> to discuss the current features is much more important.

Yes.

Thank you for your useful post.

zeDek
-- 
Xavier Maillard

main(){printf(&unix["\021%six\012\0"],(unix)["have"]+"fun"-0x60);}