File level exclusions for a E2K7 (SP3) mail server

Hi,

Always a tough one.  The way I see it, every application developer can't test with every other application developers product, especially not the latest versions of each.

In this case, the AV products can't test with all environments where third party applications are installed, e.g. Exchange, Sharepoint, etc.. Likewise MS can't test/support/know enough implementation detail to guarantee an AV product is "safe" to use. Standards like VSAPI emerge to solve this problem in part but it really only focuses on a single point of interaction.

So with this very limited testing, there will always be gaps in coverage. This leaves a bit of an unknown and the safest advice (on both sides) is to exclude because it seems less risky. I suppose it's not too dissimilar to electrical devices on aeroplanes, the airlines can't guarantee all electrical devices ever made are safe, so it's less risky to exclude them.

So it comes down to risk, a few being:

• The AV product corrupts mail files. This is only really likely when actions are being taken on an event such as a virus being found. So if the action in the AV product is to do nothing (the default) there isn't much risk there.
• Performance - it's going to depend on how much left over resources are available for a file level scanner to scan the files that Exchanged and in this case the store process touches. Mail files can sometimes become quite complex, think objects wrapped in objects, encoded in a variety of ways. Size of mail flow is also a consideration.
• Do you need to scan the files in their current state? If all the mail was scanned at the edge for example before getting to Exchange, then maybe again at the SMTP level going into exchange, is there any sense in scanning the "internal" files of Exchange again when at this "state" they're not really going to be "executed", can anyone get at the files to tamper with them?

The other point being that a process exclusion is really a shortcut to multiple file exclusions, If a process only accesses files in one directory it's as easy to exclude that directory.  It's only these larger applications, such as AD, Exchange that touch files in multiple locations, so again it's seen as safer to just exclude the process to ensure all the files it touches are covered.  You can also exclude the process file, e.g. store.exe if you feel the risk is that the AV product might classify store.exe as a virus and take action.

With all that being said, I would suggest that if the options in the AV product are set to no action being taken (for any type of scan, E.g. on-access, scheduled, on-demand), the computer has enough resources and the mail flow isn't extreme with thousands of users it should be fine. The word "should" being the key here.

I hope that helps.

Regards,

Jak 

Hi,

Always a tough one.  The way I see it, every application developer can't test with every other application developers product, especially not the latest versions of each.

In this case, the AV products can't test with all environments where third party applications are installed, e.g. Exchange, Sharepoint, etc.. Likewise MS can't test/support/know enough implementation detail to guarantee an AV product is "safe" to use. Standards like VSAPI emerge to solve this problem in part but it really only focuses on a single point of interaction.

So with this very limited testing, there will always be gaps in coverage. This leaves a bit of an unknown and the safest advice (on both sides) is to exclude because it seems less risky. I suppose it's not too dissimilar to electrical devices on aeroplanes, the airlines can't guarantee all electrical devices ever made are safe, so it's less risky to exclude them.

So it comes down to risk, a few being:

• The AV product corrupts mail files. This is only really likely when actions are being taken on an event such as a virus being found. So if the action in the AV product is to do nothing (the default) there isn't much risk there.
• Performance - it's going to depend on how much left over resources are available for a file level scanner to scan the files that Exchanged and in this case the store process touches. Mail files can sometimes become quite complex, think objects wrapped in objects, encoded in a variety of ways. Size of mail flow is also a consideration.
• Do you need to scan the files in their current state? If all the mail was scanned at the edge for example before getting to Exchange, then maybe again at the SMTP level going into exchange, is there any sense in scanning the "internal" files of Exchange again when at this "state" they're not really going to be "executed", can anyone get at the files to tamper with them?

The other point being that a process exclusion is really a shortcut to multiple file exclusions, If a process only accesses files in one directory it's as easy to exclude that directory.  It's only these larger applications, such as AD, Exchange that touch files in multiple locations, so again it's seen as safer to just exclude the process to ensure all the files it touches are covered.  You can also exclude the process file, e.g. store.exe if you feel the risk is that the AV product might classify store.exe as a virus and take action.

With all that being said, I would suggest that if the options in the AV product are set to no action being taken (for any type of scan, E.g. on-access, scheduled, on-demand), the computer has enough resources and the mail flow isn't extreme with thousands of users it should be fine. The word "should" being the key here.

I hope that helps.

Regards,

Jak