> 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?
> 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? // Steve -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger !DSPAM:1011,4869fcab150921685713960!
