From: Giampaolo T. <Giampaolo@Tomassoni.biz> - 2007-01-21 20:36:34
|
From: ama...@li... >=20 > Giampaolo wrote: >=20 > >> 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. >=20 > > Yes, you're right. >=20 > >> 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. >=20 > > Right, but the banned_file_lover setting was the only way I=20 > found to alert my user > > on a possible hazard without completely stopping delivery.=20 > After all, if I want to > > receive these silly .exe games from a friend of mine or the=20 > update of a product from > > my software house, I would like to be able to. >=20 > And if those silly games or updates are also spam or have a bad=20 > header? Then > what you are proposing may not pass this desired mail. Then we=20 > would complain > that we desired the current behavior. >=20 > >> It might be a nice feature however to allow processing to=20 > 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=20 > 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=20 > mail even > >> if a person was a lover of a higher priority test? The=20 > 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. >=20 > > The problem is that amavisd-new has rules to enforce delivery=20 > and stops the check > > chain too early. I mean, if you are a banned_file_lover but you=20 > want not to receive spam, > > you shouldn't receive spammy banneds or, at least, these should=20 > follow also the spam rules. >=20 > > I think actually the check chain is bad header -> virus content=20 > -> banned content -> spam content. >=20 > It's > virus content -> banned content -> spam content -> bad header Ah, ok. > http://www.ijs.si/software/amavisd/amavisd-new-docs.html#checks >=20 > "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=20 > the program > and can not be influenced by configuration variables. The following = order > is used, the first condition met decides the outcome: >=20 > 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=20 > sender is > blacklisted: mail is considered spam; > 4) bad (invalid) headers: mail is considered as having a bad header." >=20 > > For each of these checks there is a _lover and even a _defang=20 > setting, as well as final-destiny > > of this stuff. >=20 > > If I say, in example, that I am not a virus_lover, while I am a=20 > banned_file_lover, it can't > > simply mean that viruses have to be passed to me just because=20 > they've got also banned content. >=20 > Right, that would not be desirable. This is one reason virus=20 > checking occurs first. You > probably are not a virus lover, and you probably don't let=20 > recipients receive viruses. >=20 > > The reasoning should be: >=20 > > 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. >=20 > > I don't see any problem with this, regardless of the case. The=20 > message gets stoppend or > > defanged whether at least one rule requires it. If I'm a=20 > banned_file_lover wouldn't mean > > I'm also a spam one. >=20 > > The only problem may eventually be at point 3), where more=20 > rules may demand for different > > destinating mailboxes. But this can easily be prioritized (if a=20 > virus, use the virus dest. > > Else if a banned use the banned dest etc etc). >=20 > > However, you're probably right: if one wants to be a=20 > something_lover he/she may want to > > receive every and each sample of his/her love. Ok, fine. Why=20 > not define a new set of > > setting (i.e.: bad_header_affine, banned_file_affine,=20 > spam_affine etc.) which enforce > > my way of ruling. >=20 > banned_files_casual_lovers_maps ;) >=20 > > At the end the reasoning could be: >=20 > > 1a) check if any _lover setting would demand for delivery, and=20 > skip next point if this is the case; > > 2b) check if any _affine setting would demand for NO delivery,=20 > 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). >=20 > 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 Nonono. I don't want banned messages which are also spam. Messages from = friends of mine which are spam gets blocked. Period. > Even this does not guarantee those senders will not send me undetected > viruses. >=20 > 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=20 > another time. > Pretty tough for the program to discern the difference. It's just a matter of design. Many of the amavisd-new features seems to = be put in place thanks to some glue and wire, probably because their = need went up later, by users requests. Please note I say this keeping well in my mind that the people which = contributed to its design and development deserve all my respect. But = I'm also shure that now it would probably be designed in another way. I = think I would do it more or less how firewall ruling works: a set of = rules ordered by priority. Whichever gets matched first wins. By = carefully specifing these rules both lover's and affine's needs would = get satisfied. The _affine settings I would like to propose are mean just to cover some = otherwise uncovered setups (like when you want a banned_file mail to = follow really the same path that a non-virus, non-banned mail would = follow before reaching delivery), while still preserving = upward-compatibility. Or do I miss something? What if I put PASS as the final destiny of = banned content? Is the banned content checked against SA *and* defanged = (in this order) before delivery? Cheers, Giampaolo > > Thoughts? > > Thanks Gary for repling. > > Giampaolo >=20 > Gary V >=20 >=20 > = -------------------------------------------------------------------------= > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to=20 > share your > opinions on IT & business topics through brief surveys - and earn cash > = http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D= DEVDEV > _______________________________________________ > AMaViS-user mailing list > AMa...@li... > https://lists.sourceforge.net/lists/listinfo/amavis-user > AMaViS-FAQ:http://www.amavis.org/amavis-faq.php3 > AMaViS-HowTos:http://www.amavis.org/howto/ |