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
