On Sun, 2003-08-10 at 16:22, Christopher Ness wrote: > On Fri, 2003-08-08 at 17:48, Not Zed wrote: > > On Fri, 2003-08-08 at 16:19, Ettore Perazzoli wrote: > > > * We give the user a way to say what happens to messages detected > > > as spam; i.e. whether they should stay in the folder, or moved > > > to a "Junk" folder or deleted. (This should probably be > > > separate from the general filter dialog, because this choice > > > should be available without the user having to understand > > > filters.) > > > > > * We put a button in the mail toolbar to mark a message as spam or > > > not spam. When a message gets marked by the user as spam or not > > > spam, Evolution sends it to Spamassassin to train the filter > > > accordingly. > > Please don't clutter the toolbar. Why should a button exist if it does > not do anything. Such is the case of a basic user not having or using > SPAM protection? Because the "plug-in" is installed, and adds the toolbar button, and thus there isn't a toolbar button that does nothing. :) > Your above statement leads me to believe that Spamasassin is going to > become a dependency for Evo, is this your intention? If the spam filter integration stuff gets implemented for 2.0, the Evo packages will depend upon Spamassassin in some manner. If we get a plug-in framework going, beyond the bonobo cruft that we need to work around already, then whatever plug-in for the spam filtering will depend on Spamassassin (as well as be part of the default install). The way the gnome-pilot plug-ins work, is that they are actually plug-ins for gnome-pilot, and not Evolution, and depend on both to work. They are never actually loaded into the evolution binary to get something done. They use the CORBA and whatever APIs there are for the components, to get the needed information for syncing to the hardware. The current evolution packages (rpms), are built such that it is possible to install a minimal amount of necessary pieces to get evolution running. Unfortunately, some people have different ideas about what is "minimal" than others do. In the future, more decentralization of the evolution components should happen, such that the plug-in usage actually makes more sense. :) > > a lot of toolbar buttons already ... > > > > > * As an additional aid to the user, messages detected as spam > > > could be displayed with a header saying "this message is spam, > > > if it's not click here to mark it as non spam", like in Apple > > > Mail: > > > > > > http://www.apple.com/macosx/jaguar/images/mainmailbox.jpg > > > > > > This button would behave exactly like the "not spam!" toolbar > > > button. > > If you used a Vfolder I don't think this would be necessary. If you don't have a method of saying a piece of mail that was classified as spam, is not spam, how do you expect to train the filter such that it would know that something is not spam, or move the mail back to it's original folder. The point of a "VSpam" folder, is similar to that of how the "VTrash" works. It contains all the messages marked as spam, that are in your folders, and these messages are hidden from view in the original folders. This makes it easier to determine where a message came from, when you retrain the filter to see that it is not spam. In a bayesian classification system, you need a method for the user to say whether or not a message is spam, to the backend, in a reasonable UI. A button is the only reasonable UI for doing so, that I have seen, or can think of. Moving things around manually and running sa-learn on the various mailboxes is very non-optimal. :) -- dobey
Attachment:
signature.asc
Description: This is a digitally signed message part
