Annette, > ...Now I configure a new machine for mail service, that isnt supported by > MMSMTP and I decided to change to a dual sendmail approach with amavis for > the virus scans.
Why not try with Postfix, while you are at it. > Bypass Virus scans is not an option in our environment. > Studying amavis docs I read about the features of also checking spam with > amavis calling dspam and/or SA, so I try to configure and test a > centralized spam checking. I think, 90 % of my users dont interested in the > details of spam checking, they only dont want spam and a centralized > solution would be a nice idea. But the remaining very specialized users > want to define spam checks by theirself. So bypass SA spam checks was > allowed until now. If SA is called via procmail the user simply decided not > to write the > corresponding lines in .procmailrc :). For example specialized users > decided not to use SA but to wrote their own procmail antispam rules etc., > so of course they dont want to "waste time" in processing their mails also > via a centralized spam checks. My original posting aimed at a solution for > this constellation. Letting users themselves control their spam settings at a central content filter is best done like Chris Hastie suggested: | The other approach is to use MySQL lookups to decide on what policy | applies to what user, and write an interface for users to select their | preferred policies. You need to provide a simple web application to let users change their spam flags or levels in a SQL database. You don't need a full fledged SQL server, the SQLite is probably sufficient if web server and mail are located on the same host. Only those recipients that need a non-default treatment need to have their entries in a database. Alternatively, just letting amavisd-new flag spam with a header field or by adding an address extension lets user's decide what to do with mail in their mailboxes. See also: http://www.ijs.si/software/amavisd/amavisd-new-docs.html#addrext > Furthermore: setting spam_lovers is not the thing I need, I understand > after reading the answers in the thread, because I set final_spam_destiny > to D_PASS. Indeed, final_spam_destiny=D_PASS is equivalent to having all recipients marked as spam lovers. > - I want a behaviour of amavis like SA do the thing: amavis > should mark scanned mails if they seem to be spam and let it trough to > recipients in every case. The recipient has to decided what to do with > "possibly spam" mails - not amavis and not an admin. You already have it implemented like this, as far as I understand it. > I would prefer a spam quarantine (like dspam does) if there was an amavis > variable warnspamrecip like warnvirusrecip (This is =1 in my amavisd.conf). > But such an variable dont exist. warnvirusrecip does not exist because replacing a junk mail with an even less informative notification is not particularly useful. It doesn't save any work in deleting a message, and adds the burden of having to check on original mail once in a while. Letting spam through but having it tagged in some obvious way (in header or by an address extension) achieves the same purpose. > Spam or virus mails should not go to a quarantine without any notice > to receiver(s). (You know I come from germany with a law that say: You are > not allowed to suspend some mail for a receiver). So don't quarantine (keep kill level very high or just disable quarantine), just mark the spam (at tag2_level) and deliver it all. Depending on what method you use (tagging by adding header field, or by appending an address extension, e.g. '+spam'), your procmail rules or even LDA by itself can store received mail in a dedicated spam subfolder in user's mailbox. It effectively provides an equivalent of a spam quarantine in recipient's own mailbox, no laws violated. (viruses may independently still be blocked before reaching a mailbox). > If I think about dual sendmail and amavis sitting in the middle of the two > sendmails, so I understand the configuration, that my virtual domains are > expanded from the first sendmail, but the sendmail alias lists and > majordomo mailing lists are expanded from the second sendmail AFTER amavis. Yes, this is usually the case (having mailing lists expanded after a content filter). > So it seems to be not possible to guarantee no spam checks for a single > user of a group alias or majordomo list because of course the (list) alias > should not be listed in a bypass_spam_check_map. If this is an issue, mailing lists may be expanded by the first MTA, before content filtering. Since amavisd-new is able to cache check results for the same contents mail, and checks each message only once regardless of the number or recipients, expanding mailing lists before content filtering is not too bad performance-wise, yet gives you control on a by-recipient basis to selectively filter or not filter. This is much more efficient (for mailing lists) than calling SA once for each recipient at local delivery time. > Meanwhile I think: Maybe amavis spam checks strategically are not the right > solution for my situation. I think about bypassing all spam checks for my > domain(s) via amavis and let SA do the job via procmail for single users as > before. It's your call. It is a tradeoff between throughput and full flexibility. I believe the amavisd-new can provide for your needs, as long as you do not need different per-recipient SA pattern matching and network tests rules. And even if you do need these for a handful of users, letting them call SA or dspam by themselves at delivery time and catering for the majority at a central server covers that too. Mark ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ 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/
