This is an issue that everyone who configures filter policies must deal with.

My filter policies look a lot like yours. While there are ways to reduce the number of components on the workbench, for example by using a single Message Block service, it becomes very difficult to see how everything is linked together and therefore almost impossible to verify that the filter policy is configured correctly.

Given the current workbench diagramming capabilities, the approach you have diagramed is probably the best compromise we can hope for but it is far from ideal especially when the scan filter configuration contains a couple of dozen components (or more).

The issue of providing more details about why a message has been quarantined can be addressed by defining more granular filters and naming them appropriately. For example, if we want to block certain attachments we can list them all in a Fingerprint filter but then the digest will simply show the filter name. The other approach is to make the filter more specific: we can define one Fingerprint filter for PDFs and another one for AVIs and name them accordingly. This approach will identify the specific attachment type that caused the message to be quarantined but it will greatly increase the complexity of the scan filter configuration.

When I'm working on a complex scan filter configuration, I almost always focus on a section of related components and not the whole configuration. It would be much easier to create and manage a complex scan filter configuration if we could:

• Select and name a group of related components. (This does not imply the use of a Filter Group.)
• See an overview of the scan filter configuration that shows all the groups that have been created.
• Select a specific group to edit/manage such that the workbench would only show the components and relationships in that group creating much needed additional space on the workbench.

This is an issue that everyone who configures filter policies must deal with.

My filter policies look a lot like yours. While there are ways to reduce the number of components on the workbench, for example by using a single Message Block service, it becomes very difficult to see how everything is linked together and therefore almost impossible to verify that the filter policy is configured correctly.

Given the current workbench diagramming capabilities, the approach you have diagramed is probably the best compromise we can hope for but it is far from ideal especially when the scan filter configuration contains a couple of dozen components (or more).

The issue of providing more details about why a message has been quarantined can be addressed by defining more granular filters and naming them appropriately. For example, if we want to block certain attachments we can list them all in a Fingerprint filter but then the digest will simply show the filter name. The other approach is to make the filter more specific: we can define one Fingerprint filter for PDFs and another one for AVIs and name them accordingly. This approach will identify the specific attachment type that caused the message to be quarantined but it will greatly increase the complexity of the scan filter configuration.

When I'm working on a complex scan filter configuration, I almost always focus on a section of related components and not the whole configuration. It would be much easier to create and manage a complex scan filter configuration if we could:

• Select and name a group of related components. (This does not imply the use of a Filter Group.)
• See an overview of the scan filter configuration that shows all the groups that have been created.
• Select a specific group to edit/manage such that the workbench would only show the components and relationships in that group creating much needed additional space on the workbench.