One idea (probably the most work) is to create a web interface to SA for end users. I could change both black and white lists. To handle the training, perhaps I could set Eudora to leave mail on the server for a day or two, and SA could show these to allow me to mark them - black, white, or spam. Or perhaps SA could copy (and maybe compact/excerpt) all incoming mail, store for a short time, so that when I copy an email with its limited headers from Eudora into the web page, there is enough information to identify the original mail with full information for filter training.
Aye, that's the most work.. but unlike your other option, it would actually work.
Another scheme would be to let me forward email to SA (a special account), with some instructions to tell SA that this piece of mail is to be white listed, black listed, or is spam.
Not possible. Your MUA (Eudora) mangles mail as it receives it in a manner which cannot be repaired or reconstructed.. in particular Eudora strips out mime boundaries as it yanks off attachments. It also tends to completely discard any plain-text alternatives to a HTML part. It actually does this as it stores the email in the .mbx file, so even if you directly take it out of Eudora's mailbox without other changes from things like forwarding, some of the message is lost. I know.. I use Eudora, see the headers of this message.
The reason this mangling is a problem is that Bayes is pretty sensitive to subtle changes. It also does header based learning, so forwarding won't work, as it will quickly learn things like "all mail that is a forward from eudora is spam".
Not being an engineer, I'm don't want to solve the problem. But it IS a PROBLEM. Spam seems to be getting smarter by the day, with more and more emails marked 3.9, or 4.5, just getting through the SA filter.
And I have no convenient way to use the more sophisticated features of SA.
I wouldn't say it's a PROBLEM, but it is a limitation.
However, bear in mind that
1) there's a limited amount of time that the sadev team has to work on SA, and they are swamped keeping the core featureset up and well maintained.
2) The target user for SA is an advanced unix-based mail systems admin. In the hands of an such an admin, the above issue isn't much of an issue.
Now of course, SA is open to everyone, and I'm sure the SA devs would love to make it easy to use for everyone.. but given the limited development resources, they seem to be making the sensible compromise of making a good product that skilled sysadmins can use, instead of a shoddy product that's easy enough for everyone to use.
I wouldn't say that the sa-devel team is purposely snubbing the "average joe", but to put time into developing simpler interfaces also involves taking time away from some other aspect of SA's development. At that level it becomes a matter of priorities.
------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 _______________________________________________ Spamassassin-talk mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
