Giampaolo wrote: >> I believe you can send banned files and still have spam checks >> performed by bypassing banned checks (but it's still a good idea to >> include the recipients as lovers if you want to insure delivery) but >> then you would not have the benefit of defanging.
> Yes, you're right. >> The meaning of a >> lover is to insure delivery. If a message is not blocked by previous >> tests (in this case virus checks) then the message will be delivered. > Right, but the banned_file_lover setting was the only way I found to alert my > user > on a possible hazard without completely stopping delivery. After all, if I > want to > receive these silly .exe games from a friend of mine or the update of a > product from > my software house, I would like to be able to. And if those silly games or updates are also spam or have a bad header? Then what you are proposing may not pass this desired mail. Then we would complain that we desired the current behavior. >> It might be a nice feature however to allow processing to continue on to >> spam checks when the recipient is a banned lover. This would have to be >> customizable as not everyone would desire this behavior. The next question >> is about virus lovers - would you want tests to continue on to banned >> checks and spam checks too? That does not seem to make sense. Both >> cases dilute the meaning of being a lover. In general would you have >> all checks performed and then have a lower priority test block mail even >> if a person was a lover of a higher priority test? The recipients must be >> aware that if they choose to receive banned files (and they want them >> defanged) then they run the risk of receiving undetected viruses. > The problem is that amavisd-new has rules to enforce delivery and stops the > check > chain too early. I mean, if you are a banned_file_lover but you want not to > receive spam, > you shouldn't receive spammy banneds or, at least, these should follow also > the spam rules. > I think actually the check chain is bad header -> virus content -> banned > content -> spam content. It's virus content -> banned content -> spam content -> bad header http://www.ijs.si/software/amavisd/amavisd-new-docs.html#checks "For the purpose of deciding on these actions, a mail is classified based on all available checks results. It is quite possible that more than one check results would be positive (e.g. virus and banned and bad header, or spam and bad header, or virus and spam), yet a mail is considered to be only in one category. The logic is currently hard-wired into the program and can not be influenced by configuration variables. The following order is used, the first condition met decides the outcome: 1) a virus is detected: mail is considered infected; 2) contains banned name or type: mail is considered banned; 3) spam level is above kill level for at least one recipient or a sender is blacklisted: mail is considered spam; 4) bad (invalid) headers: mail is considered as having a bad header." > For each of these checks there is a _lover and even a _defang setting, as > well as final-destiny > of this stuff. > If I say, in example, that I am not a virus_lover, while I am a > banned_file_lover, it can't > simply mean that viruses have to be passed to me just because they've got > also banned content. Right, that would not be desirable. This is one reason virus checking occurs first. You probably are not a virus lover, and you probably don't let recipients receive viruses. > The reasoning should be: > 1) check if the message would have to stop and stop if this is the case; > 2) defang the message if any rule requires it; > 3) deliver to the destinating mailbox. > I don't see any problem with this, regardless of the case. The message gets > stoppend or > defanged whether at least one rule requires it. If I'm a banned_file_lover > wouldn't mean > I'm also a spam one. > The only problem may eventually be at point 3), where more rules may demand > for different > destinating mailboxes. But this can easily be prioritized (if a virus, use > the virus dest. > Else if a banned use the banned dest etc etc). > However, you're probably right: if one wants to be a something_lover he/she > may want to > receive every and each sample of his/her love. Ok, fine. Why not define a new > set of > setting (i.e.: bad_header_affine, banned_file_affine, spam_affine etc.) which > enforce > my way of ruling. banned_files_casual_lovers_maps ;) > At the end the reasoning could be: > 1a) check if any _lover setting would demand for delivery, and skip next > point if this is the case; > 2b) check if any _affine setting would demand for NO delivery, and stop it if > this is the case; > 2) defang the message if any _defang message requires it; > 3) deliver to the destinating mailbox (with prioritized destinations). The only problem is, what you are really looking for is to receive some banned messages and not others. You want stuff from your friends even if it may be spam but you don't want undetected viruses that are spam. With your proposal there is still no protection from undetected viruses if they are not spam. The solution for me is to block banned files and allow only certain senders to bypass banned files checks via policy banks. http://www200.pair.com/mecham/spam/bypassing.html#7 Even this does not guarantee those senders will not send me undetected viruses. It's always great when software does what we want but in this case really what we want is that it works one way one time and another way another time. Pretty tough for the program to discern the difference. > Thoughts? > Thanks Gary for repling. > Giampaolo Gary V ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ AMaViS-user mailing list AMaViS-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amavis-user AMaViS-FAQ:http://www.amavis.org/amavis-faq.php3 AMaViS-HowTos:http://www.amavis.org/howto/
