Mail flow is very slow or stops entirely when a content filtering rule for Symantec Mail Security for Exchange with a user condition is enabled.
search cancel

Mail flow is very slow or stops entirely when a content filtering rule for Symantec Mail Security for Exchange with a user condition is enabled.

book

Article ID: 177198

calendar_today

Updated On:

Products

Mail Security for Microsoft Exchange

Issue/Introduction

After enabling a content filtering rule with a user condition specified in Symantec Mail Security for Microsoft Exchange (SMSMSE), mail flow stops or slows considerably.

Symptoms

  • In a cluster environment you may experience multiple failovers.
  • In some cases mail flow may stop entirely.
  • In the Windows Application Event log you may see the following Events:

 

Source: Symantec Mail Security Microsoft Exchange
Event ID 327
Description: The process SAVFMSESp.exe was forcibly terminated. Reason: SAVFMSECtrl process failed to communicate with SAVFMSESp process.
Source: Symantec Mail Security for Microsoft Exchange
Event ID 168
Description: The process SAVFMSESp.exe was restarted

 

  • In some cases you may see unscannable file events in the Windows Event Viewer Application log similar to this:   

 

Source: Symantec Mail Security for Microsoft Exchange
Event ID 218
Description: Includes a reference to a message that Symantec Mail Security for Microsoft Exchange determined a message was unscannable.

  

  • If you collect DebugView log (as specified in the "Technical Information" section of this document) you will see entries similar to the following:

 

SAVFMSESp(2090)[1F74] 2010-04-22 20:14:54 0035ms:
..\..\..\src\Server\SAVFMSESHARED\SMSMSEMailStoreClientCDO.cpp(220) :
CheckName for /O=/OU=/CN=/CN= is UnResolved
SAVFMSESp(2090)[1F74] 2010-04-22 20:14:54 0035ms:
..\..\..\src\Server\SAVFMSESHARED\MailStoreClient.cpp(441) :
Debug Trace: HRESULT=0x80004005 - Unspecified error
 

Cause

SMSMSE is receiving X.400 addresses instead of SMTP addresses for email routing from the Microsoft VSAPI interface. X.400 addresses may map to more than one SMTP address inside Active Directory.  When content filtering rules are configured SMSMSE issues a query to Active Directory using LDAP to determine the SMTP address associated with the X.400. If the query fails, the content filtering rule is skipped.  If the query returns more than one SMTP address  SMSMSE initiates a resource intensive search of the Exchange information store to narrow the list of SMTP addresses down to one SMTP address.

If either the LDAP query or the search in the Exchange information store takes a long time then mail flow backs up.  This can eventually result in a system down situation where mail is not flowing or flowing very slowly.

Resolution

Upgrade to 6.5.2 or later.  For details on the changes see the KB article Details about the User Address caching feature of Symantec Mail Security for Microsoft Exchange (SMSMSE).

If you are still seeing issues with SMSMSE 6.5.2 or later see the Workaround section or contact Symantec Technical Support.

Workaround

6.5.2 and later

If you are running 6.5.2 or later and are still seeing this problem, implement one of the following workarounds, based on the condition that is causing the issue.

Condition: If one or more content filtering rules contains a user condition in wild card or  regular expression format (for example: *@<domain>.com or \s*) on an Exchange Mailbox role server you may still see this issue after upgrading.

Workaround: Configure these rules only on Exchange Edge or Hub transport role servers. During transport scanning, SMSMSE gets SMTP addresses of senders and recipients of mail items to be scanned, allowing it to evaluate this type of content filtering rules without the need to issue an LDAP query.

 

Condition: If one or more content filtering rules contains a user condition that specifies an Active Directory group on an Exchange Mailbox role server you may still see this issue after upgrading.
 

Workaround:

a) Configure these rules only on Exchange Edge or Hub transport role servers. During transport scanning, SMSMSE gets SMTP addresses of senders and recipients of mail items to be scanned, allowing it to evaluate this type of content filtering rules without the need to issue an LDAP query

or

b) Instead of defining an Active Directory group as the user condition, explicitly define each SMTP address in the list. This will cause SMSMSE to use the User Address caching feature for evaluation of the rule; otherwise, it will revert to the previous behavior of issuing an LDAP query for each message evaluated.


6.5.1 and earlier

* Reduce the number of internal domains.

This result in faster timeouts for the query reducing the likelihood of a mailflow disruption:

1. Open the SMSMSE console.
2. Click on Admin > System settings.
3. In the List of internal domains remove all listed except the main or top level domain hosted on this Exchange server.
4. Click Deploy Changes.

* Remove user specific content filtering rules.

1. Open the SMSMSE console.
2. Click Policies > Content Filtering Rules.
3. Make note of all enabled content filtering rules.
4. For each content filtering rule, complete the following:

a. On the Users tab check for the presence of SMTP addresses / Active Directory groups.
b. If SMTP addressesActive Directory groups exist, remove them from the rule.
c. Click Ok.

5. Click Deploy Changes.

* Disable user based content filtering rules for real time scanning, and enable them only for scheduled scans.

Note: This process means content filtering no longer applies to real time scanning.  Content filtering violations may be read by the user if they are accessed before the next scan is scheduled.

1. Open the SMSMSE console.
2. Click Policies > Content Filtering Rules.
3. Make note of all enabled content filtering rules.
4. For each content filtering rule, complete the following:

a. On the Users tab check for the presence of SMTP addresses / Active Directory groups.
b. Make note of the rule name.
c. Click Ok.
d. Disable the rule by clicking the Enabled drop down and changing it to Disabled.

5. Navigate to Scans > Scheduled Scans.
6. Under Tasks click New scan....
7. Give the scan a descriptive name, in this case something like "Content enforcement" would be appropriate.
8. Choose how long you'd like the scan to run before it will stop scanning, and select options for which messages to process.  (Note: Selecting "Only scan items modified since last scan" causes these scans to run much faster, but prevents the content rules from stripping some older items) and then click Next.
9. Choose the mailboxes you would like to scan, or which you would like to exclude from the scan, and click Next .
10. Enable all the rules you added to the list in step 4b and click Next .
11. Select the scheduled time for your scan.  Symantec recommends selecting off hours such as evenings or weekends to avoid the possibility of overtaxing the Exchange server with scheduled scan processing and causing service outages.  Click Finish.

Content filtering violations will now be detected only during these scheduled scans, and will not affect mail flow during normal operations.

Technical Information

If none of these workarounds resolves the problem it is recommended obtain additional debug logging information about the LDAP queries.  This is most easily done with 6.5.1 or higher as described in this article: Troubleshooting LDAP query issues with Symantec Mail Security for Microsoft Exchange 6.5.1 and later.