Sven, > > If I knew how much confusion the semantics of bypass_* vs. *_lovers > > is causing, I would have provide only _lovers, and derive bypass_ > > automatically from it. Perhaps some day... > > what if on a big mail server hosting many users some don't want spam > checking at all,
As long as the effects of spam checking for such recipients are not visible (e.g. in headers or in paying the cost of additional service), they wouldn't know the difference nor care. This is why I'm saying that bypass* could in principle be derived from *lovers. The bypass* is just an optimization mechanism. > but some want spam checking but no action taken > based on the result of spam checking, If there is no effect, then it is irrelevant whether a mail was checked or not (except for wasted time). > and some others don't want to receive mails which are definitely spam > (e.g. the spam score is over a certain threshold)?? > I think this is where the differentiation between bypass_* and *_lovers > comes in very handy, or is there another way of doing this?? Yes it comes handy at times, which is why it was introduced. But the only useful reason that I can think of in setting bypass=1 and lovers kept at FALSE for a recipient is connected with cost. It is saying: I don't want to be billed for virus/spam filtering, but I don't mind if you block a virus or high score spam as long as I don't have to pay for this service (free ride on already performed checks on behalf of other recipients). bypass lover 0 0 useful, check and block malware 0 1 useful, check but deliver tagged 1 0 not too useful, free riding 1 1 useful, no checks if possible, and no effects Mark ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ AMaViS-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/amavis-user AMaViS-FAQ:http://www.amavis.org/amavis-faq.php3 AMaViS-HowTos:http://www.amavis.org/howto/
