> > Why not, but I don't understand why you say this is less accurate. > > DSPAM will continu to compute tokens as it was done before, and at > > the end it will check if email address is in the whitelist and tag > > the mail with "X-DSPAM-Result: Whitelisted". > > > That's not the way DSPAM works. Normally it checks at the beginning > of the processing if a message is whitelisted or not. Not at the end. > It would be less accurate if we would replace the current algorithm > (using the whole From line) with a less accurate one (just using the > "From" + "*" + "the email in lower case"). Maybe it would be wise to > leave the current algorithm the way it is and introduce a new one > (the fuzzy one) with own counters for when to tag a message as > whitelisted?
Yes, this is what I meant. (Sorry for my bad english, I'm french ;) > > > > It is the same way of present whitelist, but management could be > > done by the end-user. > > > Well... using the same way as the current one would work but the > managing part would be hart. This is because DSPAM computes a token > out of the entry it want's to whitelist. This token is easy > calculated but the computing from a token to a whitelist entry (in > clear text) is the hard part. Adding would work very easy but > deleting/changing would be the hard part since finding what token > represents what whitelist entry would be +/- a unpractical task. > > So from my viewpoint it can/(should) not be using the same algorithm > as the current whitelist method. Probably more suited would be to add > the user driven whitelisting in the same technique as the blocklist > (flat ASCII text file). However... flat files are not known to be > fast. > > > > I talke about a manual intervention by the user. > > I have 3 DSPAM servers running with Qmail, whitelisting on the MTA > > level is not impossible, but with a centralized DSPAM database, > > this is much more simple and clean. > > > This is what I talk about. Using a central storage (database, file on > a share, etc) would be a possibility. The reason why I think it is > more wise to implement that outside of DSPAM is an economical > viewpoint. It is more economical (less computing) to not start the > content filter if you know at the beginning of the processing that > you don't need to start the content filter. The only reason why I > could think that implementing this in DSPAM could be beneficial is if > you would train the content filter automatically with whitelisted > messages. For example: 1) Message is from a whitelisted sender > (well... can be faked but that's another story) 2) Message would be > flagged as spam by the content filter if you would instruct the > content filter to not look at the whitelist. > > If this would be the case, then forcing the content filter to learn > such a message as innocent would be beneficial to the whole filtering > experience of the user. And then I would see a benefit in > implementing the user driven whitelisting in the content filter. But > if you just want to deliver a message and not pass it over the > content filter, then it is more economical to implement that outside > of the content filter. Why bothering in starting another instance of > the filtering process when you anyway know that the message is > whitelisted? Do you know what I mean? > That's right, but in my case this is difficult to share data between my different Qmail (simscan is using to run DSPAM). > > // Steve !DSPAM:1011,486a291a150926918273860!
