Gnus development mailing list
 help / color / mirror / Atom feed
From: Mats Lidell <matsl@contactor.se>
Subject: Re: spam filtering using IMAP ?
Date: Thu, 16 Jan 2003 11:43:31 +0100	[thread overview]
Message-ID: <m3fzrtqsrw.fsf@mail.contactor.se> (raw)
In-Reply-To: <m31y3dph4q.fsf@heechee.beld.net> (Ted Zlatanov's message of "Thu, 16 Jan 2003 04:40:21 -0500")

>>>>> Ted wrote:

Ted> Some people (quite a few, in fact) don't have login access to the
Ted> IMAP server.  Most people can't install software on the IMAP
Ted> server.  So it's not always that easy to do classification on the
Ted> server.

Agreed. Even if it is natural it might be impossible for practical
reasons.

Ted> What exactly would you like moved to that special folder?  I'm
Ted> not sure how spam.el could help you for server-side splitting.

I haven't designed the details (much less tested it) but what I
envision is to move an article that is spam and not classified as such
to one folder, lets say mark-as-spam, and move good articles that are
classified as spam to another folder, lets say mark-as-ham. Then I
would have some server code that feeds these articles to the spam
statistics engine and at the same time move the mark-as-spam articles
to the spam folder and the mark-as-ham articles to the inbox(!?).

What this all is about is to feed the article back to the server so
that the spam processing can be adjusted. One alternative is to mail
the article back to the server and there could be other ways
too. Using imap directly seems natural though.

It is here that spam.el comes in for supporting this scheme in
gnus. If I get how this works it uses different marks to intelligently
find out whether articles need reclassification based also on normal
operations on the article. (Philosophy: If I do this with the article
then it must be spam or it must be ham.)

On the other hand a very natural thing to do with ham found in the
spam folder is to move them directly to the folder where they should
be. This deletes the article in the spam folder and I don't know if
spam.el on exit from the summary buffer will be able to access the
article so that it could be copied to the mark-as-ham folder for later
statistics processing.

There might also be other problems with this approach that I haven't
realized yet that might make spam.el not the right vehicle for this.

Yours
-- 
%% Mats




  reply	other threads:[~2003-01-16 10:43 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-01-09 19:20 Arnd Kohrs
2003-01-09 19:38 ` Ted Zlatanov
2003-01-10  2:02   ` Simon Josefsson
2003-01-16  7:20 ` Mats Lidell
2003-01-16  9:40   ` Ted Zlatanov
2003-01-16 10:43     ` Mats Lidell [this message]
2003-01-16 11:22       ` Ted Zlatanov
2003-01-16 12:41         ` Mats Lidell
2003-01-16 14:11           ` Ted Zlatanov
2003-01-16 15:32 ` Kai Großjohann
2003-01-16 20:02   ` Mats Lidell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m3fzrtqsrw.fsf@mail.contactor.se \
    --to=matsl@contactor.se \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).