Policy Components

Every ZixGateway policy consists of three components: Label, Matching Criteria, Send Options and Action.

• Label - the label is the unique identifier for this policy.
• Matching Criteria - a policy matching criteria specifies the kind of messages to which the policy should apply.
  A pattern consists of five divisions. Administrators can use values in any of these five divisions to create the matching criteria.
  • The To and From fields allow you to restrict the policy to a sender or receiver who matches a defined email address. The To and From fields can be added by selecting the drop-down arrow next to the field and adding one or more patterns in the Add From or Add To field. Alternately, you can select Enable All Patterns to choose all senders or receivers.
    
    ZixCorp recommends that you set up eGroups using LDAP if you intend to have more than 25 individual email addresses in any policy. See Appendix F. Configuring eGroups to use LDAP for additional information.
  • The Subject, Body and Attachments fields allow you to restrict the policy to content patterns that are matched in the subject, body and/or attachments of the message.
    • The patterns are defined in Glossary entries. Each policy can have more than one glossary entry that is either ANDed or ORed together.
    • Each glossary entry consists of one or more terms that are ANDed or ORed together. Each term can define a search pattern (Expression), use a lexicon as a search pattern (Lexicon) or use an existing glossary entry (Existing Entry).
    • Because of the possible complexity of the pattern, the pattern is defined in the “Glossary and Bindings” screen. See “Using the Glossary and Bindings Screen” on page 5-6 for information on defining patterns.
  • The File Type field allows you to set up a policy based upon the email attachment’s file extension type. You can enter one or more file extensions, separated by commas. For example: .exe, jpg, tiff
  • The Send Options restricts the policy based on the button the sender used to send the message. The default send option is Send.
    • Administrators can deploy the ZixSelect option, comprised of the send options of ZixSelect Encrypt & Send and ZixSelect Send Unencrypted buttons, to the tool bar of end users’ email client. By default, these buttons take precedence over the Send button, permitting the end user to make the final decision on whether a message is to be sent plaintext or encrypted.
    • When the user selects a ZixSelect button, the email message matches one of two default encryption policies. These policies determine whether the email is encrypted based on the button selected by the user. See Encryption Default Policies for a description of these policies.
    • The ZixDirect Reply & Forward option is matched when a user sends a reply or forwards a ZixDirect message. You can encrypt, route, brand or audit/log these messages before they are forwarded or returned to the original sender.
  • Policy Trigger - Select the options of Outbound, Plaintext Inbound, or Encrypted Inbound to trigger a match for Branding and Routing policies. The parameter provides a simple way to distinguish between policies for outbound and inbound messages.
    
    Plaintext Inbound email messages are any inbound messages except Zix encrypted messages. Encrypted Inbound email messages are ZixVPM S/MIME, ZixVPM, ZixMail, TLS, ZixDirect and ZixPort encrypted messages.
• Action - An action is applied to the message whenever a message matches that policy’s criteria. Each policy type has a different type of action.
  • Encryption policies have encryption actions, delivery methods, that specify how a message is sent.
  • Branding policies have branding actions that detail what headers or footers are attached to a message body.
  • Routing policies have actions that send messages to additional recipients such as administrators, auditors and the original sender. Routing can also be used to block delivery of a message to the original recipient.
  • Content policies have actions that request that a log record be written whenever a message matches (or does not match) the policy pattern.

Main Topic

Structuring Policies