This article applies to:

• MailMarshal (SEG)
• MailMarshal ECM/MailMarshal Exchange 7.X

Question:

• What are some common pitfalls encountered when configuring MailMarshal?
• Are there any gotchas when configuring MailMarshal?

Information:

This article lists some of the most common pitfalls encountered in typical MailMarshal administration activities. 

Spam, viruses or other mail getting through rules:

• Combining multiple conditions in one rule
  • If you combine two conditions in one rule, then both conditions have to be met for the rule to trigger. For instance, if you use two TextCensor scripts in one rule, "Offensive Language" and "Specific Spam", it would trigger when the message contained both offensive language and the specific Spam phrases in your script. The same applies to using multiple conditions of "Where Message is categorized as 'Spam' and 'URLCensor Blacklisted" - in this example the message would have to trigger both the SpamCensor and the URLCensor.
  • In MailMarshal (SEG) 10.0 and above TextCensor conditions and Category conditions allow you to select a Boolean "OR" as well as the default "AND"
• Installing new components, like virus scanners, without enabling a rule
  • When you install a new virus scanner, or a Category Script XML file, you must create or enable a MailMarshal rule which uses the new component. Otherwise the new component will remain unused. It is useful to think of it this way: if the rule does not exist, nothing is going to happen.
• Overactive "Pass message to rule" action
  • If you use a rule to skip over all Spam rules, determine exactly when the rule should trigger. Confirm that the user matching is configured correctly (See below - Errors in user matching). Ensure that you are not using all-encompassing wildcard entries in your user groups that would match against more addresses than you might expect (See below - Global Blacklist blocking legitimate email).

Legitimate mail getting blocked, Spam or viruses getting through:

• Errors in user matching - Where addressed from, Except where addressed from etc
  • Mistakes in user matching configuration are a very common cause of unexpected behavior in MailMarshal rules. Be extremely careful to correctly choose between the various user matching options. For example, mistakes can cause rule exclusions not to work and legitimate mail to get blocked. Double check your rules and note the following user matching settings that are often accidentally interchanged.
    • Where addressed from / Except where addressed from
    • Where addressed from / Where addressed to
      
• Global Blacklist blocking legitimate email
  • When using wildcards in MailMarshal user groups, such as the Global Blacklist, be careful to avoid all-encompassing wildcard usage. For example, *@*mail.com would block all email from Hotmail.com.

Database, History and Node issues:

• Duplicate logging entries in MailMarshal History
  • MailMarshal logs all Move the message to folder actions as logging classifications. If a rule includes both an action of Write log message(s)with and Move the message to folder then two separate logging classifications are written to the database. This causes duplicate entries to appear in the Console History, and it is also a waste of database space and resources. We recommend that you remove the Logging Classification actions from your terminal rules unless you have a specific and understood need for these classifications in your MailMarshal Reports.

This article was previously published as:

NETIQKB45697