Sven wrote:
> Hi Mark, > thanks for your reply, > On Fri, Aug 12, 2005 at 12:16:53PM +0200, Mark Martinec told us: >> 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. >> >> If there is no effect, then it is irrelevant whether a mail was checked or >> not >> (except for wasted time). > that is what I meant: see this from the point of the person(s) running > a busy mail server. With respect to spam scanning there are three > kind of people: > 1. People who want spam scanning and want the spam to be discarded/ > quarantined/whatever. bypass lover 0 0 useful, check and block malware > 2. People who want spam scanning but who want to receive all mails to > act based on the spam scanning headers, e.g. in their MUA (those > would be the ones for spam_lovers). Those people probably also > want to define a threshold for marking mail as spam so they can > filter on the "X-Spam-Status: Yes" header. bypass lover 0 1 useful, check but deliver tagged > 3. People who want no spam scanning and don't want to pay for it. Those > people can be put in bypass_spam_checks, no work will be wasted > in spam scanning their mail, thus more resources on your mail > server for scanning other people's mails. bypass lover 1 1 useful, no checks if possible, and no effects You have not mentioned a use for the fourth scenario which is the one that could no longer be configured if the change were made. bypass lover 1 0 not too useful, free riding > 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... Mark, are you saying you want to automatically assign all *lovers to bypass*? Then how would you accomplish this?: bypass lover 0 1 useful, check but deliver tagged I don't find it confusing. I'm would favor flexibility. At first, I did not understand what *lovers did exactly. Bypass seemed obvious. I think that a note that including a recipient in a @*_lovers_maps is functionally equivalent to setting $final_*_destiny = D_PASS; for that recipient helps explain it (at least is does for me). I think it would be more confusing if you told people, "If you want to bypass spam checks for a recipient, put then in a spam_lovers map." I think that you can only do something like: @spam_lovers_maps = @bypass_spam_checks_maps; (or) @bypass_spam_checks_maps = @spam_lovers_maps; under certain circumstances, not all. I think a note explaining under which circumstances these could be used would be appropriate. Gary V ------------------------------------------------------- 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/
