<quote who="Theo Julienne"> > No, not Amavis. Amavis is just the middle-man. I'm talking about the > virus scanners. Amavis does indeed run as a daemon - but it still runs > command-line scanners ( kavscanner, etc ) which load the virus database > each time - Kaspersky even recommends this daemonised approach for their > AV software ( and really, they have made a _great_ piece of software ).
As I said previously, it does both. In some cases, it talks directly to the AV daemon, in some cases it executes a tiny client that talks to the daemon, in some cases it runs a command line only scanner executable. It does the lot. > Why should Amavis be here extracting the files, when good virus programs > like KAV can do it for you? Why do we have Amavis there acting as a > middle-man, when we could be going directly? Fine, MTAs don't support it > out of the box, but really, it's a much simpler and more efficiant > solution than having a perl script daemon running there in the middle! Unpacking is not the only thing that Amavis does, but it provides it because some scanners don't do that. The ones I use generally do it themselves, but I didn't choose them solely based on that. Again, Amavis is there for policy (such as figuring out what should be scanned, how to deal with responses, if we want spam detection as well, user preferences, etc.) and protocol. > >You haven't addressed the mid-DATA problems at all, though. > > It's not mid-data, it's post-data. But > pre-telling-the-remote-mta-that-its-sent-perfectly ( eg DATA ends with > "." -- after that, according to the SMTP protocol the mail server must, > if the mail was sent correctly, send a "250 OK" message back -- simply, > rather than sending the OK message, we send back error and say "don't > send me viruses" or whatever -- most MTAs send this string back to the > user that sent it ). Ah, so you don't even get the bandwidth benefit, because your tool can't handle streaming detection. So, what benefits are you actually getting at all? It's not like you're optimising and simplifying for the common case. :-) > > Yes - it's viciously unreliable. > > Providing everything is configured correctly - it's not unreliable. If the > daemon turns off - mail is indeed rejected - but the sender is told that > it's a temporary local problem and to try again. HOWEVER - this should > _never_ happen! Uhhh-huh. And you're only describing one point of failure, but you've built a whole pile. But problems should never happen! ;-) Any mail that gets through my MTA is bound for a valid user (the MTA does that), and is ON DISK immediately and queued for action. It is *safe*. Once it's there, I can futz with it as much as I want, delay it, discard it, run it though policy systems, yada yada yada, but anything that goes wrong is 100% my fault after that (very safe and secure) point. Some people are even crazy enough to scan their MTA queues directly. While it's insane, at least they've got the mails there on disk, and are doing stupid things with them after that point. The MTA is a great big queue manager, and if anything does bugger up, it's okay - *my* MTA, the one I trust, is dealing with it in its queues. The responsibility does not fall to some other machine. So, the point is, minimise your points of failure as much as possible, and optimising for the common case will generally help with that. In this case, we're going to accept or discard the mail in total, very specifically *not* rejecting it - if it's valid, it'll be delivered; if it's crap, we'll just drop it into /dev/null - so there's no reason to perform all of the higher level scanning business during the SMTP transaction. It provides no benefit. The best thing to do, is let any mail that passes our MTA policies into the queue, where it is safe, and figure out where it should go next. Oh, plus you can split all of this crap off onto another machine, rather than doing it all on your SMTP frontend (or single mail server). :-) - Jeff -- GVADEC 2004: Kristiansand, Norway http://2004.guadec.org/ "The ability to procrastinate is what separates us from the machines." - Chris Gregory, Desktop Magazine -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
