[Spambayes] three kind of messages, three actions to be taken

Tony Meyer tameyer at ihug.co.nz
Thu Mar 10 01:47:45 CET 2005

[Tony Meyer]
>> However, your message seems to indicate that you'd say
>> that it was ham-to-discard, ham-to-keep, and spam.

[Felipe Romero]
> That's what I say. I do not refer to the spambayes point of 
> view, but the receiver's point of view.

There are problems with this, in that each receiver will have a different
point of view.  For example, I have not-that-important ham that is archived
in once place, important-ham that is archived somewhere else, current-ham
that hasn't been dealt with yet, but will eventually turn into one of the
other types, and spam-to-archive.  Everyone will have something slightly

(Some programs, for example POPFile, will let you do n-way classification,
which you might be able to use to get the effect that you're after).

>> SpamBayes doesn't get involved in organising mail apart from 
>> classifying as one of ham/unsure/spam.  
> Why not? I think it's easy and very helpful.
> Why do not enhance the program?

Three of the reasons are:

  1.  There is a school of thought that each program should do one thing,
and do it as well as possible.  The job of SpamBayes is to make spam less of
a problem by identifying it, as possible.  That's the focus.  A separate
program should look after general mail management.

  2.  Outlook does a fairly reasonable job as a mail manager (compare it to
Outlook Express!), and most of what people want to accomplish can be done
with existing Outlook functionality.  There's no point reinventing the

  3.  This is a project where everything is done by volunteers in their own
time.  In order for something to get done, it either needs to be something
the developer wants ('scratching their own itch'), or something that a
developer is willing to do for some other reason (e.g. removing bugs to
reduce people complaining about them, adding unit tests to make future
development more reliable).  None of the existing developers (AFAIK) want
this functionality themselves, so they'd have to be talked into it.  It's
also a large amount of work, which counts against it.

The latter is probably the main reason.  Of course, since this is
open-source, there's nothing stopping anyone taking up the code and creating
a patch that does exactly this.

This feature request is asking for roughly the same thing:

[ 844796 ] SpamBayes as mail manager?

>> I also don't understand what you mean by "three actions to 
>> take over three kind of folders".  Do you mean that there should be three

>> buttons rather than the existing "Delete as Spam" and 
>> "Recover from Spam"?  
>> Or do you mean that there should be three sets of actions in the 
>> Filtering tab/process.
> Basically, yes: Delete as spam, recover from spam, and "train 
> as ham and delete" But the esential idea is: when you press 
> "delete as spam" an also with "the train button", 
> spam message should be removed after the training.

Having "Delete as Spam" actually delete the message (or move it to the
Deleted Items folder) is covered in this feature request:

[ 973376 ] Make "Delete as Spam" *really* Delete the email

> Another idea is to keep two buttons: Delete as spam, recover 
> from spam, and later, in the training action, both the "spam" 
> and "d-ham" folder are deleted. "Unsure" folder: untouched 
> and untrained and a the rest of the ham folders are trained 
> but not deleted.

I don't think that we would ever want to have code that would delete mail
that the user has marked as ham.  It's asking for too many problems.

> Thank you so much for your work Tony,
> (sorry for my english)

You're welcome, and no worries.


Please always include the list (spambayes at python.org) in your replies
(reply-all), and please don't send me personal mail about SpamBayes.
http://www.massey.ac.nz/~tameyer/writing/reply_all.html explains this.

More information about the Spambayes mailing list