The appliance enforces your organization’s policies for messages sent to and from your users through the use of mail policies. These are sets of rules that specify the types of suspect, sensitive, or malicious content that your organization may not want entering or leaving your network. This content may include:

• spam
• legitimate marketing messages
• graymail
• viruses
• phishing and other targeted mail attacks
• confidential corporate data
• personally identifiable information

You can create multiple policies that satisfy the disparate security needs of the different user groups within your organization. The appliance uses the rules defined in these policies to scan each message and, if necessary, perform an action to protect your user. For example, policies can prevent the delivery of suspected spam messages to executives while allowing their delivery to IT staff but with a modified subject to warn them of the content, or drop dangerous executable attachments for all users except those in the System Administrator group.

The appliance uses two different sets of mail policies for message content security:

• Incoming mail policies for messages are messages received from connections that match an ACCEPT HAT policy in any listener.
• Outgoing mail policies for messages are messages from connections that match a RELAY HAT policy in any listener. This includes any connection that was authenticated with SMTP AUTH.

Having separate sets of policies allow you to define different security rules for messages sent to your users and messages sent from your users. You manage these policies using the Mail Policies > Incoming Mail Policies or Outgoing Mail Policies pages in the GUI, or the policyconfig command in the CLI.

Note

Some features can be applied only to incoming or to outgoing mail policies. For example, Data Loss Prevention scanning can only be performed on outgoing messages. Advanced Malware Protection (File Reputation scanning and File Analysis) is available in Incoming Mail Policies and Outgoing Mail Policies. In certain installations, “internal” mail being routed through the Cisco appliance may be considered outgoing , even if all the recipients are addressed to internal addresses. For example, by default for C170 and C190 appliances, the system setup wizard will configure only one physical Ethernet port with one listener for receiving inbound email and relaying outbound email.

As messages are received by the appliance , the appliance attempts to match each message recipient and sender to a mail policy in the Incoming or Outgoing Mail Policies table, depending on whether it is an incoming or outgoing message.

Matches are based on the recipient’s address, the sender’s address, or both:

• Recipient address matches the Envelope Recipient address

  When matching recipient addresses, the recipient addresses entered are the final addresses after processing by preceding parts of the email pipeline. For example, if enabled, the default domain, LDAP routing or masquerading, alias table, domain map, and message filters features can rewrite the Envelope Recipient address and may affect whether the message matches a mail policy.

• Sender address matches:
  • Envelope Sender (RFC821 MAIL FROM address)
  • Address found in the RFC822 From: header
  • Address found in the RFC822 Reply-To: header

Addresses may be matched on either a full email address, user, domain, or partial domain, and addresses may also match LDAP group membership.

Intelligent message splintering is the mechanism that allows for differing recipient-based content security rules to be applied independently to message with multiple recipients.

Each recipient is evaluated for each policy in the appropriate mail policy table (Incoming or Outgoing) in a top-down fashion.

Each policy that matches a message creates a new message with those recipients. This process is defined as message splintering :

• If some recipients match different policies, the recipients are grouped according to the policies they matched, the message is split into a number of messages equal to the number of policies that matched, and the recipients are set to each appropriate “splinter.”
• If all recipients match the same policy, the message is not splintered. Conversely, a maximum splintering scenario would be one in which a single message is splintered for each message recipient.
• Each message splinter is then processed by anti-spam, anti-virus, Advanced Malware Protection (incoming messages only), DLP scanning (outgoing messages only), Outbreak Filters, and content filters independently in the email pipeline.

The following table illustrates the point at which messages are splintered in the email pipeline.

Note	New MIDs (message IDs) are created for each message splinter (for example, MID 1 becomes MID 2 and MID 3). For more information, see the “Logging” chapter. In addition, the trace function shows which policies cause a message to be split.

Policy matching and message splintering in Email Security Manager policies obviously affect how you manage the message processing available on the appliance .

Mail policies map different user groups to specific security settings, such as Anti-Spam or Anti-Virus.