Spam.el tutorial

Spam.el tutorial

[Xavier Maillard]

Hi,

This post is a request for people who use spam.el and for whom it works.

Here is why I think we should produce a tutorial for this package.

After tons of tries and setups I am still not satisfied with the way my
spam is detected even with lots of training.

Spam.el sounds really cool but according to many people I have been
talking with, spam.el is way far from being simple to understand and so
to setup.

Even clever people I know, they are good at emacs lisp, agree with the
fact, you, Ted, have produced such an awesome and complex code, that
even them can't really understand :)

This results in having people totally lost (like I am) because of the so
different way we can all manage spam.el to work.

So I think a tutorial is something useful to show people different way
to set all things up. The most important thing is to show people a
maximum of different setup according to way you, gnus users, read your
mails.

So this covers customize and plain emacs lisp setup. I mean there is a
big hit on the fact some people (like me) are totally lost(or doesn't
like) customize stuff and prefer doing their own receipt.

So I think, if people can post here, in this thread, the portion of
their own spam.el setup, would be a good start to produce a final
document. Posting emacs lisp with comments explaining users choice is
higly recommended though. 

Note that if people have used the customize interface (like I did), it
would be interesting to explain also what is the result of such
settings (where goes spam, where does ham is processed, ...).

Any opinion ?

zeDek

P.S: if this topic is serious (that is if there are posters), I can
then take the stuff and write the final document.

Re: Spam.el tutorial

[Ted Zlatanov]

On Sun, 14 Dec 2003, zedek@gnu-rox.org wrote:

> Spam.el sounds really cool but according to many people I have been
> talking with, spam.el is way far from being simple to understand and
> so to setup.
> 
> Even clever people I know, they are good at emacs lisp, agree with
> the fact, you, Ted, have produced such an awesome and complex code,
> that even them can't really understand :)

I agree.  The problem has two sides:

1.  Managing spam is HARD.  Sure, you can have a simplistic
    "everything to the spam folder" approach, but most people quickly
    ask for refinements.

2.  The Emacs customization functionality, especially concerning Gnus,
    is really insufficient as it stands to produce easy configuration
    screens.

I don't think we can reduce (1) so we have to improve (2).
Personally, I think it would be nice and not too hard to produce a
wizard-like interface for Gnus.  I just don't have the time to do it
right now.  Such an interface would have to have the concept of
screens and moving back and forth between them; also it should be able
to detect nonsense configurations, branch between different paths, and
have lots of help text.

If people have the patience to wait for me to finish my changes to
spam.el (we're approaching a point where it will have all the
features I wanted last year, when I started work on it) then I can
jump into this problem.  It should be fun.  But please, if anyone
else has ideas and would like to do this work, do it!

Anyhow, regarding tutorials.  They are fine, but they have limited
uses.  Specifically regarding spam.el, a tutorial would have to cover
a very basic configuraiton to be useful to all users.  There are big
differences between all the backends, all the ways you can check
incoming mail, and all the ways you can move spam/ham around.  I
think a tutorial should get the user started, but it shouldn't set an
expectation of "this is how Ted does his spam setup, so you should
too."  I've received a lot of good ideas from people who have
unorthodox setups.

That being said, I would love to see a spam.el tutorial.  I would
help with it, but my next goal after tonight's commit is to update
the CVS manual.  So don't wait for me :)

> So I think a tutorial is something useful to show people different
> way to set all things up. The most important thing is to show people
> a maximum of different setup according to way you, gnus users, read
> your mails.

You could do that.  It would be terribly confusing to users, to be
given so many different and usually mutually exclusive approaches.
Be careful.

> So this covers customize and plain emacs lisp setup. I mean there is
> a big hit on the fact some people (like me) are totally lost(or
> doesn't like) customize stuff and prefer doing their own receipt.

I'll add more examples in the manual of how to do things without
customize.  I don't see the big deal, though.  Use customize once,
then look at the variable and you can see the format easily.  But
then again, I'm used to spam.el arcana.

> So I think, if people can post here, in this thread, the portion of
> their own spam.el setup, would be a good start to produce a final
> document. Posting emacs lisp with comments explaining users choice
> is higly recommended though.

I would, but is there a way to extract all the Gnus group and topic
parameters and put them in gnus-parameters?  That would be nice,
otherwise it's hard for me to show my full setup.

> P.S: if this topic is serious (that is if there are posters), I can
> then take the stuff and write the final document.

That would be great.

Ted

Re: Spam.el tutorial

[Reiner Steib]

On Sun, Dec 14 2003, Xavier Maillard wrote:

> So I think a tutorial is something useful to show people different way
> to set all things up. The most important thing is to show people a
> maximum of different setup according to way you, gnus users, read your
> mails.
[...]
> So I think, if people can post here, in this thread, the portion of
> their own spam.el setup, would be a good start to produce a final
> document. Posting emacs lisp with comments explaining users choice is
> higly recommended though. 

Here's my setup:

--8<---------------cut here---------------start------------->8---
* Using `spam.el' on an IMAP server with a statistical filter on the
  server

** Background
 
My provider has set up bogofilter (in combination with DCC) on the
mail server (IMAP).  Recognized spam goes to "spam.detected", the rest
goes through the normal filter rules, i.e. to "some.folder" or to
"INBOX".  Training on false positives or negatives is done by copying
or moving the article to "training.ham" or "training.spam"
respectively.  A cron job on the server feeds those to bogofilter with
the suitable ham or spam options and deletes them from the
"training.ham" and "training.spam" folders.

** Setup

With the following entries in `gnus-parameters', `spam.el' does most
of the job for me:

   ("nnimap:spam\\.detected"
    (gnus-article-sort-functions '(gnus-article-sort-by-chars))
    (ham-process-destination "nnimap:INBOX" "nnimap:training.ham")
    (spam-contents gnus-group-spam-classification-spam))
   ("nnimap:\\(INBOX\\|other-folders\\)"
    (spam-process-destination . "nnimap:training.spam")
    (spam-contents gnus-group-spam-classification-ham))

*** The Spam folder:

  In the folder "spam.detected", I have to check for false positives
  (i.e. legitimate mails, that were wrongly judged as spam by
  bogofilter or DCC).
  
  Because of the `gnus-group-spam-classification-spam' entry, all
  messages are marked as spam (with `$').  When I find a false
  positive, I mark the message with some other mark (see `ham-marks'
  in the manual: `C-h i d gnus RET i ham-mark RET').  On group exit,
  those messages are copied to both groups, "INBOX" (were I want to
  have the article) and "training.ham" (for training bogofilter) and
  deleted from the "spam.detected" folder.

  The sort-by-chars entry simplifies detection of false positives for
  me.  I receive lots of worms [1] (sweN, ...), that all have a
  similar size.  Grouping them by size (i.e. chars) makes finding
  other false positives easier.

*** Ham folders:

  In my ham folders, I just hit `S x' (`gnus-summary-mark-as-spam')
  whenever I see an unrecognized spam mail (false negative).  On group
  exit, those messages are moved to "training.ham".

* Reporting spam articles in Gmane [2] groups with `spam-report.el'

With following entry in `gnus-parameters', `S x'
(`gnus-summary-mark-as-spam') marks articles in gmane.* groups as spam
and reports the to Gmane at group exit: 

   ("^gmane\\."
    (spam-process (gnus-group-spam-exit-processor-report-gmane)))

Additionally, I use `(setq spam-report-gmane-use-article-number nil)'
because I don't read the groups directly from news.gmane.org, but
through my local news server (leafnode).  I.e. the article numbers are
not the same as on news.gmane.org, thus `spam-report.el' has to check
the "X-Report-Spam" header to find the correct number.

[1] Of course worms aren't "spam" (UCE, UBE) strictly speaking.
    Anyhow, bogofilter is an excellent tool for filtering those
    unwanted mails for me.

[2] <URL:http://gmane.org/>
--8<---------------cut here---------------end--------------->8---

For people who prefer `gnus-parameters' instead of customize, it's
probably best to use customize (`G c') first and look at the correct
syntax with `G e'.  Then, use this format in `gnus-parameters' and
remove the customize entries with `G e' or `G c'.

Ted, please correct me if I described something inaccurately,
especially the copying/moving process (I didn't check the current
code).  Thanks for your work! :-)

Bye, Reiner.

-- 
       ,,,
      (o o)
---ooO-(_)-Ooo--- PGP key available via WWW   http://rsteib.home.pages.de/

Re: Spam.el tutorial

[Xavier Maillard]

Reiner Steib <4.uce.03.r.s@nurfuerspam.de> disait récemment que :

> On Sun, Dec 14 2003, Xavier Maillard wrote:
>
>> So I think a tutorial is something useful to show people different way
>> to set all things up. The most important thing is to show people a
>> maximum of different setup according to way you, gnus users, read your
>> mails.
> [...]
>> So I think, if people can post here, in this thread, the portion of
>> their own spam.el setup, would be a good start to produce a final
>> document. Posting emacs lisp with comments explaining users choice is
>> higly recommended though. 
>
> Here's my setup:
>

[...]

>
> Bye, Reiner.

Thank you for your contribution. I have learned many things especially
things concerning customize :)

'o' on your message so I can add it to the tutorial if more setup
examples come.

-- 
Xavier Maillard, zedek@gnu-rox.org

Re: Spam.el tutorial

[Kai Grossjohann]

I like the idea about a tutorial.  Instead of contributing my own
setup (which tries to do the same as Reiner's but probably fails), I'd
like to suggest some scenarios.

* A user who wants to rely only on Emacs, with no external software,
  and doesn't trust statistics.

  I guess this means blacklists and whitelists, mostly.  Maybe BBDB
  comes in, too.  Maybe spam senders are blacklisted whereas ham
  senders are whitelisted.  Not sure how BBDB comes in.  Maybe
  somebody does it.

* Like above but with statistics.

  So that means to use spam-stat.el.  Does it make a difference
  whether one uses nnimap or another backend?

  Incoming spam is put into the nnchoke:spam group.  Not sure whether
  it is useful to do spam training on those articles, suggest a setup.

  False negatives and false positives are sent to spam-stat.el; not
  sure whether they should go through nnchoke:makespam and
  nnchoke:makeham groups or not.  Suggestions?

* Like previous but use an external program for the statistics.  Still
  do it all through Gnus.

* Like previous, but filter incoming mail through the external program
  before Gnus sees it.  (==> spam-use-foo-headers)

I alluded to the problem of which groups to use and how many of them.
I don't have the foggiest, really.  The only reason I know what groups
to use for my setup is that I have a server-side setup (similar to
Reiner's) where it is clear that I must use the groups this setup
uses.

But I still don't know what to do with spam in NNTP groups.

Kai

Re: Spam.el tutorial

[Ted Zlatanov]

On Tue, 16 Dec 2003, kai@emptydomain.de wrote:

> But I still don't know what to do with spam in NNTP groups.

Have you looked at my recent post on the spam-autodetect and
spam-autodetect-methods group/topic parameters?  It tries to address
NNTP spam and generally backends where there is no incoming split.

Ted

Re: Spam.el tutorial

[Kai Grossjohann]

Ted Zlatanov <tzz@lifelogs.com> writes:

> Have you looked at my recent post on the spam-autodetect and
> spam-autodetect-methods group/topic parameters?  It tries to address
> NNTP spam and generally backends where there is no incoming split.

No, I only discovered that later.

From a short look at your post it seems that you give spam-autodetect
a list of things to try, then it will do so.  My problem, then, is
that I don't know what to put into that list.  I learned from Reiner's
post that there is GMANE spam reporting built into spam.el.  So that's
clearly a candidate.  But what about the other NNTP groups?

Or is spam-autodetect smarter than I think and it doesn't need a list
of things to try?

Kai

Re: Spam.el tutorial

[Kai Grossjohann]

Kai Grossjohann <kai@emptydomain.de> writes:

> From a short look at your post it seems that you give spam-autodetect
> a list of things to try, then it will do so.  My problem, then, is
> that I don't know what to put into that list.

Oops.  Completely off-base it seems.

I think *now* I understand: spam-autodetect can do like spam-split,
but without splitting.

It doesn't handle spam reporting at all, IIUC.  Silly me, I only
thought about spam reporting, not about spam detection ;-)

For me, spam splitting is done on the server side with bogofilter, and
there is no easy way for me to tell Gnus to invoke bogofilter on the
server side.  So spam-autodetect is out, I guess.

(I'd need a local bogofilter database it seems.  Wonder whether it's
worth it.  Maybe NOCEM can help?  What does it do, anyway?  There is a
vague connection between NOCEM and spam in my mind.)

Kai

Re: Spam.el tutorial

[Ted Zlatanov]

On Tue, 16 Dec 2003, kai@emptydomain.de wrote:

> I think *now* I understand: spam-autodetect can do like spam-split,
> but without splitting.

Yes, using all articles or only the unseen ones (default is unseen).
When you enter an autodetected group you'll basically run spam-split
on all those articles.  But you can specify whatever spam-split
methods you want to use.

> For me, spam splitting is done on the server side with bogofilter,
> and there is no easy way for me to tell Gnus to invoke bogofilter on
> the server side.  So spam-autodetect is out, I guess.

You can still use spam-use-BBDB, spam-use-blacklist,
spam-use-blackholes, etc.

> (I'd need a local bogofilter database it seems.  Wonder whether it's
> worth it.  Maybe NOCEM can help?  What does it do, anyway?  There is
> a vague connection between NOCEM and spam in my mind.)

NOCEM is definitely not what you want, although there could be a
spam-use-NOCEM variable for those who don't mind REALLY slow spam
autodetection.  NOCEM is sort of like a global spam-cancelling list
except with Gnus it was REALLY slow for me on a local fast news
server.

You could rsync the bogofilter database every hour or whatever is
appropriate to your local machine.  As long as the two versions of
bogofilter are the same, there won't be any binary compatibility
problems.  I do that and it works pretty well.

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
detection and better summary display of spam.  Mass spam detection
will be able to invoke certain programs once for a whole bunch of
articles, which will make spam autodetection much faster.  In fact,
people may start using spam autodetection instead of incoming mail
splitting :)

Ted

Re: Spam.el tutorial

[Xavier Maillard]

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

> On Tue, 16 Dec 2003, kai@emptydomain.de wrote:
>
>> I think *now* I understand: spam-autodetect can do like spam-split,
>> but without splitting.
>
> Yes, using all articles or only the unseen ones (default is unseen).
> When you enter an autodetected group you'll basically run spam-split
> on all those articles.  But you can specify whatever spam-split
> methods you want to use.
>
>> For me, spam splitting is done on the server side with bogofilter,
>> and there is no easy way for me to tell Gnus to invoke bogofilter on
>> the server side.  So spam-autodetect is out, I guess.
>
> 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) ?

>> (I'd need a local bogofilter database it seems.  Wonder whether it's
>> worth it.  Maybe NOCEM can help?  What does it do, anyway?  There is
>> a vague connection between NOCEM and spam in my mind.)
>

[...]

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

> detection and better summary display of spam.  Mass spam detection
> will be able to invoke certain programs once for a whole bunch of
> articles, which will make spam autodetection much faster.  In fact,
> people may start using spam autodetection instead of incoming mail
> splitting :)

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

> Ted

-- 
.o.   Xavier Maillard            Tel: +33 6 62 59 68 62
..o  
ooo   

Re: Spam.el tutorial

[Xavier Maillard]

Kai Grossjohann <kai@emptydomain.de> disait récemment que :

> I like the idea about a tutorial.  Instead of contributing my own
> setup (which tries to do the same as Reiner's but probably fails), I'd
> like to suggest some scenarios.

That is ok for me ;) (Note I didn't contributed by giving my own setup
which is quite "funny" at that time)

> * A user who wants to rely only on Emacs, with no external software,
>   and doesn't trust statistics.
>
>   I guess this means blacklists and whitelists, mostly.  Maybe BBDB
>   comes in, too.  Maybe spam senders are blacklisted whereas ham
>   senders are whitelisted.  Not sure how BBDB comes in.  Maybe
>   somebody does it.
>
> * Like above but with statistics.
>
>   So that means to use spam-stat.el.  Does it make a difference
>   whether one uses nnimap or another backend?
>
>   Incoming spam is put into the nnchoke:spam group.  Not sure whether
>   it is useful to do spam training on those articles, suggest a setup.
>
>   False negatives and false positives are sent to spam-stat.el; not
>   sure whether they should go through nnchoke:makespam and
>   nnchoke:makeham groups or not.  Suggestions?
>
> * Like previous but use an external program for the statistics.  Still
>   do it all through Gnus.
>
> * Like previous, but filter incoming mail through the external program
>   before Gnus sees it.  (==> spam-use-foo-headers)

Good idea. I more or less was thinking of organizing the "maybe future
tutorial" this way with "scenarios". I also guess there are quite a few
more we can elaborate on but my guess is, only users can tell what is
their own situation and how they setup things accordingly to their
specific organization.

> Kai

zeDek
-- 
 In Gruuik we trust

Re: Spam.el tutorial

[Ted Zlatanov]

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

Re: Spam.el tutorial

[Xavier Maillard]

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

Re: Spam.el tutorial

[Ted Zlatanov]

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

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

>> You can give specific checks to spam-split also - see the docs.
> 
> So if I understand correctly, I can in my split chain do something
> like (: spam-split 'spam-use-bogofilter) and so on ?

Yes, just like it says in the manual :)

>> Well, spam autodetection has these benefits:

>> - easier to see what's happening
> 
> Hum how so ?

It's in spam-find-spam, instead of all over the place in split-fancy
methods.  Debugging spam-find-spam is pretty easy.

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

Well I didn't say "only works."  It should work for all mail groups,
and I've used it that way.  What did you expect to happen?  Some mail
will be marked as spam, but you probably don't have any spam in your
mail groups so there was nothing to mark.

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

No worries, this will not come up again for a while, and if it does
I'll be sure to discuss it at length with the other Gnus developers
and users before I write any code.

Ted

Re: Spam.el tutorial

[Xavier Maillard]

[-- Attachment #1.1: Type: text/plain, Size: 1552 bytes --]

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

> On Wed, 17 Dec 2003, zedek@gnu-rox.org wrote:
>
>> Ted Zlatanov <tzz@lifelogs.com> disait récemment que :
>
>>> You can give specific checks to spam-split also - see the docs.
>> 
>> So if I understand correctly, I can in my split chain do something
>> like (: spam-split 'spam-use-bogofilter) and so on ?
>
> Yes, just like it says in the manual :)

Sorry ;)

[...]

>>> - 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.
>
> Well I didn't say "only works."  It should work for all mail groups,
> and I've used it that way.  What did you expect to happen?  Some mail
> will be marked as spam, but you probably don't have any spam in your
> mail groups so there was nothing to mark.

So activating for all groups can't hurt then ? Except the slowness of
entering any group.

[...]

>> 
>> Hmmm. I don't think I have correctly understood this part. Best for
>> me is to try that way.
>
> No worries, this will not come up again for a while, and if it does
> I'll be sure to discuss it at length with the other Gnus developers
> and users before I write any code.

Ok.

zeDek
-- 
Xavier Maillard
7 rue Jeanne Jugan, 51100 Reims, France
phone: +33 3 26 77 02 21, mobile: +33 6 62 59 68 62
email: zedek@gnu-rox.org


[-- Attachment #1.2: Type: application/pgp-signature, Size: 188 bytes --]

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]