Stan, Hi Thanks for your detailed response. Actually, the main reason which drove us toward performing virus scanning as an offline process was performance. As we deal with large amounts of e-mails, we found the way amavisd-new or other filtering management tools performing filtering too slow. We intended to somehow decrease the amount of load which amavisd-new or similar tools impose on the architecture.
Kind Regards Ali Majdzadeh Kohbanani 2009/11/30 Stan Hoeppner <s...@hardwarefreak.com> > Ali Majdzadeh put forth on 11/30/2009 12:28 AM: > > Hello all, > > I do not know whether here is the right place to ask this question or > > not, but I would like to know if it is a good idea to perform offline > > e-mail virus scanning. By offline, I mean a scenario in which e-mail > > filtering management tools (like amavisd-new) do not hand out received > > e-mails to virus scanners (like clamav), instead, virus scanning is > > performed on mailboxes as regular files on the file system. Does anyone > > have any experiences regarding this scenario? Is at all this scenario > > sane or applicable? > > Why would you ever want to write a virus to a user mailbox and then scan > it later? Unless you have a flawless realtime virus scanner daemon that > checks every file as it's written to the file system, you open up the > possibility that a user will open that mail file containing the virus > before the system quarantines or deletes it. > > Why would you not want to identify a viral payload as soon as it hits > your MTA, and delete it immediately? This is analogous to waiting until > the home invaders have entered your childrens' bedroom to call the > police, instead of calling the police when you heard the front door > being kicked down. > > Back in the day (maybe still) virus scanner plugins for Microsoft > Exchange worked in a similar fashion. And on occasion, disaster struck > as a result of it, with a user's Outlook client pulling the viral email > before the A/V plugin was able to scan it. IIRC, the reason for this > was two fold: First, Microsoft had no interface to allow third party > scanners to look at queue files directly, because doing so would > literally break Exchange. Second, because Exchange stores all mail > files in a database instead of as individual files, A/V vendors were > required to write SQL like queries to scan the records within the > database. Exchange is anything but a realtime database. Because of > this architecture, and the potentially large time delays created by a > loaded system, it was impossible to guarantee anything close to realtime > scanning of inbound mail. I believe MS has since changed the > architecture to allow A/V scanning of mail whilst it's in the inbound > queue. It's been a long time since I dealt with Exchange, the above > architectural short sightedness being one of the reasons for that. > > In summary, scan the mail as it enters the edge MTA, and deal with viri > at that point in time. There may be extreme border cases for very large > orgs where a tiered mail delivery approach and downstream A/V scanning > is desirable, but I'm guessing your org doesn't fit in such a case. > > -- > Stan >
