Re: Spam.el tutorial

[Ted Zlatanov <tzz@lifelogs.com>]

On Wed, 17 Dec 2003, zedek@gnu-rox.org wrote:

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

>> You can still use spam-use-BBDB, spam-use-blacklist,
>> spam-use-blackholes, etc.
> 
> 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.

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.

>> I've promised I'll stop adding spam.el features, so I won't do this
>> for No Gnus, but the next features of spam.el will be mass spam
> 
> Are we in the No Gnus development cycle yet ? I asked it not that
> long and nobody answered.

I defer to the Gnus overlords :)

> 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

- 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)

- easier to see what's happening

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

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

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

- 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

But there are disadvantages:

- entering a group is slower with autodetection than splitting
  incoming mail

- 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

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.

Ted