administration guide

Addendum

Administration Guide

for IronMail 6.5.4

Copyright© 2008 Secure Computing Corporation. All Rights Reserved. No part of this publication may be reproduced, transmitted, transcribed, stored in a retrieval system, or translated into any language in any form or by any means without the written permission of Secure Computing Corporation.

TrademarksSecure Computing, SafeWord, Sidewinder, Sidewinder G2, Sidewinder G2 Firewall, SmartFilter, Type Enforcement, CipherTrust, IronMail, IronIM, SofToken, Enterprise Strong, Mobile Pass, G2 Firewall, PremierAccess, SecureSupport, SecureOS, Bess, Cyberguard, SnapGear, Total Stream Protection, Webwasher, Strikeback and Web Inspector are trademarks of Secure Computing Corporation, registered in the U.S. Patent and Trademark Office and in other countries. G2 Enterprise Manager, SmartReporter, SecurityReporter, Application Defenses, Central Management Control, RemoteAccess, SecureWire, TrustedSource, On-Box, Securing connections between people, applications and networks and Access Begins with Identity are trademarks of Secure Computing Corporation.

Software license agreementCAREFULLY READ THE FOLLOWING TERMS AND CONDITIONS BEFORE LOADING THE SOFTWARE. THIS AGREEMENT GOVERNS THE USE OF THE SOFTWARE (AS DEFINED BELOW). BY CLICKING “I ACCEPT” BELOW, OR BY INSTALLING, COPYING, OR OTHERWISE USING THE SOFTWARE, YOU ARE SIGNING THIS AGREEMENT, THEREBY BECOMING BOUND BY ITS TERMS. BY INDICATING YOUR AGREEMENT, YOU ALSO REPRESENT AND WARRANT THAT YOU ARE A DULY AUTHORIZED REPRESENTATIVE OF THE ENTITY THAT HAS PURCHASED THE SOFTWARE AND THAT YOU HAVE THE RIGHT AND AUTHORITY TO ENTER INTO THIS AGREEMENT ON THE ENTITY’S BEHALF. IF YOU DO NOT AGREE WITH THIS AGREEMENT, THEN CLICK “I DO NOT ACCEPT” BELOW OR DO NOT USE THE SOFTWARE AND RETURN ALL COPIES OF THE SOFTWARE AND DOCUMENTATION TO SECURE COMPUTING CORPORATION (“SECURE COMPUTING”) OR THE RESELLER FROM WHOM YOU OBTAINED THE SOFTWARE. 1. DEFINITIONS. “Documentation” means the published user manuals and documentation that are made available for the Software. “Secure Computing Software” means the machine-readable object-code versions of certain Secure Computing messaging gateway software applications (for example, without limitation, IronMail, IronIM, IronNet and Secure Computing Edge) as indicated on your invoice and any updates or revisions of the Secure Computing Software that you may receive. “Software Module” shall mean software applications that Secure Computing licenses to its customers in addition to the Secure Computing Software (for example, without limitation, anti-virus software) as indicated on your invoice and any updates or revisions of the Software Module that you may receive. “Software” shall mean collectively the Secure Computing Software and, if purchased by you, the Software Module(s). 2. GRANT OF LICENSE. Secure Computing grants to you, and you accept, (a) a non-exclusive, and non-transferable license to use the Secure Computing Software solely on and in conjunction with the Secure Computing appliance on which the Secure Computing Software is installed, and, if purchased by you, (b) a non-exclusive, non-transferable license to use the Software Module(s) for a specific period of time and for the specific number of licensed users as each is indicated on your invoice solely on and in conjunction with the Secure Computing appliance on which the Software Module is installed. Under no circumstances will you receive any source code of the Software. Secure Computing also grants to you, and you accept, a non-exclusive, and non-transferable license to use the Documentation solely in conjunction with the Software. 3. LIMITATION OF USE. You may not: 1) copy, except to make one copy of the Software solely for back-up or archival purposes; 2) transfer, distribute, rent, lease or sublicense all or any portion of the Software or Documentation to any third party; 3) translate, modify, adapt, decompile, disassemble, or reverse engineer any Software in whole or in part; 4) modify or prepare derivative works of the Software or the Documentation; or 5) use the Software to process the data of a third party. You agree to keep confidential and use your best efforts to prevent and protect the contents of the Software and Documentation from unauthorized disclosure or use. Secure Computing reserves all rights that are not expressly granted to you. 4. DISCLAIMER OF WARRANTIES. Secure Computing does not warrant that the functions contained in the Software will meet your requirements or that operation of the program will be uninterrupted or error-free. The entire risk as to the results and performance of the Software is assumed by you. THE SOFTWARE IS FURNISHED, “AS IS” WITHOUT ANY WARRANTY OF ANY KIND, AND SECURE COMPUTING AND ITS LICENSORS HEREBY DISCLAIM ALL WARRANTIES, EXPRESS, IMPLIED OR STATUTORY IN RESPECT OF THE SOFTWARE INCLUDING, WITHOUT LIMITATION, ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, AND ANY WARRANTIES AS TO NON-INFRINGEMENT. SOME STATES AND COUNTRIES DO NOT ALLOW THE EXCLUSION OF IMPLIED WARRANTIES, SO THE ABOVE EXCLUSION MAY NOT APPLY TO YOU. THIS WARRANTY GIVES YOU SPECIFIC LEGAL RIGHTS. YOU MAY HAVE OTHER RIGHTS WHICH VARY BY STATE OR COUNTRY. 5. LIMITATION OF REMEDIES. SECURE COMPUTING’S AND ITS LICENSORS ENTIRE LIABILITY UNDER, FOR BREACH OF, OR ARISING OUT OF THIS AGREEMENT, IS LIMITED TO A REFUND OF THE PURCHASE PRICE OF THE PRODUCT OR SERVICE THAT GAVE RISE TO THE CLAIM. IN NO EVENT SHALL SECURE COMPUTING OR ITS LICENSORS BE LIABLE FOR YOUR COST OF PROCURING SUBSTITUTE GOODS. IN NO EVENT WILL SECURE COMPUTING OR ITS LICENSORS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, INCIDENTAL, EXEMPLARY, OR OTHER DAMAGES WHETHER OR NOT SECURE COMPUTING HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH LOSS OR DAMAGE. 6. TERM AND TERMINATION. This license is effective until terminated. You may terminate it at any time by destroying the Software, including all computer programs and Documentation, and erasing any copies residing on computer equipment. This Agreement also will automatically terminate if you do not comply with any terms or conditions of this Agreement. Upon such termination you agree to destroy the Software and Documentation and erase all copies of the Software residing on computer equipment. Notwithstanding the foregoing, each license to use a Software Module will automatically terminate on expiration of its applicable term (as set forth on your invoice) unless it is renewed prior to such termination. 7. PROTECTION OF CONFIDENTIAL INFORMATION. The Software and Documentation are delivered to you on a confidential basis and you are responsible for employing reasonable measures to prevent the unauthorized disclosure or use thereof, which measures shall not be less than those measures employed by you in protecting your own proprietary information. You may disclose the Software or Documentation to your employees as necessary for the use permitted under this Agreement. You shall not remove any trademark, trade name, copyright notice or other proprietary notice from the Software or Documentation.8. OWNERSHIP. The Software and Documentation are licensed (not sold) to you. All intellectual property rights including trademarks, service marks, patents, copyrights, trade secrets, and other proprietary rights in or related to the Software and Documentation are and will remain the property of Secure Computing or its licensors, whether or not specifically recognized or protected under local law. You will not remove any product identification, copyright notices, or other legends set forth on the Software or Documentation.

i

9. EXPORT RESTRICTIONS. You agree to comply with all applicable United States export control laws, and regulations, as from time to time amended, including without limitation, the laws and regulations administered by the United States Department of Commerce and the United States Department of State. You have been advised that the Software is subject to the U.S. Export Administration Regulations. You shall not export, import or transfer Software contrary to U.S. or other applicable laws, whether directly or indirectly, and will not cause, approve or otherwise facilitate others such as agents or any third parties in doing so. You represent and agree that neither the United States Department of Commerce nor any other federal agency has suspended, revoked or denied your export privileges. You agree not to use or transfer the Software for end use relating to any nuclear, chemical or biological weapons, or missile technology unless authorized by the U.S. Government by regulation or specific license. 10. U.S. GOVERNMENT RIGHTS. Any Software or Documentation acquired by or on behalf of a unit or agency of the United States Government is “commercial computer software” or “commercial computer software documentation” and, absent a written agreement to the contrary, the Government’s rights with respect to such Software or Documentation are limited by the terms of this Agreement, pursuant to FAR § 12.212(a) and its successor regulations and/or DFARS § 227.7202-1(a) and its successor regulations, as applicable. 11. ENTIRE AGREEMENT. This Agreement is our offer to license the Software and Documentation to you exclusively on the terms set forth in this Agreement, and is subject to the condition that you accept these terms in their entirety. If you have submitted (or hereafter submit) different, additional, or other alternative terms to Secure Computing or any reseller or authorized dealer, whether through a purchase order or otherwise, we object to and reject those terms. Without limiting the generality of the foregoing, to the extent that you have submitted a purchase order for the Software, any shipment to you of the Software is not an acceptance of your purchase order, but rather is a counteroffer subject to your acceptance of this Agreement without any objections or modifications by you. To the extent that we are deemed to have formed a contract with you related to the Software prior to your acceptance of this Agreement, this Agreement shall govern and shall be deemed to be a modification of any prior terms in their entirety. 12. GENERAL. Any waiver of or modification to the terms of this Agreement will not be effective unless executed in writing and signed by Secure Computing. If any provision of this Agreement is held to be unenforceable, in whole or in part, such holding shall not affect the validity of the other provisions of this Agreement. You may not assign this License Agreement or any associated transactions without the written consent of Secure Computing. This License Agreement shall be governed by and construed in accordance with the laws of California, without regard to its conflicts of laws provisions.

Technical support informationSecure Computing works closely with our reseller partners to offer the best worldwide Technical Support services. Your Secure Computing reseller is the first line of support when you have questions about our products and services; however, if you require additional assistance, contact us directly.• To contact Secure Computing Technical Support directly, telephone +1.800.700.8328 or +1.651.628.1500.• To inquire about obtaining a support contract, refer to our “Contact Secure” Web page for the latest information at

www.securecomputing.com.• To use our web support site, point your browser to: support.securecomputing.com. This site allows you to submit support issues, and to

monitor, edit, and set the severity of issues 24 hours a day.• To use the Secure KnowledgeBase, go to www.securecomputing.com/goto/kb. Enter your company ID.

Customer Advocate informationTo suggest enhancements in a product or service, or to request assistance in resolving a problem, please contact a Customer Advocate at +1.877.851.9080. If you prefer, send an e-mail to [email protected] you have comments or suggestions you would like to make regarding this document or any other Secure Computing document, please send an e-mail to [email protected].

Publication history

Date Part number Software release

January 2008 86-0948263-A IronMail 6.5.4

ii

www.securecomputing.com/goto/KB

http://www.securecomputing.com

CONTENTS

Before You Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .vWho should read this addendum . . . . . . . . . . . . . . . . . . . . . . . . . . . . vHow this addendum is organized . . . . . . . . . . . . . . . . . . . . . . . . . . . . vHow to use this addendum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vConventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viUser interface bookmarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viYour first log-in . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vi

CHAPTER 1 Anti-Spam Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1TrustedSource features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2

TrustedSource whitelisting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2TrustedSource queries for LDAP rejections . . . . . . . . . . . . . . . . . .3

Bayesian retraining . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4Ham retraining . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4Administrator-released messages . . . . . . . . . . . . . . . . . . . . . . . . . .5Improved Bayesian tokenization . . . . . . . . . . . . . . . . . . . . . . . . . . .5

Classifying spam . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6Image Spam Classifier (ISC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6Dynamic Spam Classifier (DSC) . . . . . . . . . . . . . . . . . . . . . . . . . . .7

Connection Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9LDAP connection control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9Connection control deny list improvement . . . . . . . . . . . . . . . . . . .9

Backscatter Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9DSN Bounce Verification Protection . . . . . . . . . . . . . . . . . . . . . . . .9

Other features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11End User Quarantine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11RBL hop count . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13Non-ASCII characters for “Add Header” options . . . . . . . . . . . . . .14Subject re-write changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14

CHAPTER 2 IntrusionDefender Features . . . . . . . . . . . . . . . . . . . . . . . . . .15LDAP features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16

Secure LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16LDAP variable User Identification . . . . . . . . . . . . . . . . . . . . . . . . .17

SMTP on custom TCP ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17

CHAPTER 3 Queue Manager Features . . . . . . . . . . . . . . . . . . . . . . . . . . . .19Dynamic Quarantine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20

Enabling and disabling Dynamic Quarantine from the UI . . . . . . .20TrustedSource score variable in Dynamic Quarantine . . . . . . . . .20Automatic shut-off . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20

CHAPTER 4 Compliance Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21Whitelisting features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22

Integrating TrustedSource into whitelisting rules . . . . . . . . . . . . . .22Whitelisting include/exclude option . . . . . . . . . . . . . . . . . . . . . . . .22

iii

Table of Contents

Automated Administrator whitelist expiration . . . . . . . . . . . . . . . .23Content Analysis Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25

Using the pre-defined regular expressions . . . . . . . . . . . . . . . . . .25Using the validation algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . .29

Message stamping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32

CHAPTER 5 Reporting Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35Message Blocking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36

Configuring the Message Blocking Report . . . . . . . . . . . . . . . . . .36A sample report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37

SNMP polling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38SNMP polling configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38Public SNMP variables for IronMail . . . . . . . . . . . . . . . . . . . . . . . .40

Syslog additions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41

CHAPTER 6 System Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43Improved TRUSign update process . . . . . . . . . . . . . . . . . . . . . . . . .44

Downloading and installing updates . . . . . . . . . . . . . . . . . . . . . . .44Locking your current configuration settings . . . . . . . . . . . . . . . . . .44Special configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .45

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

iv

BEFORE YOU BEGIN

Who should read this addendum

You should read this addendum if you are responsible for configuring and managing one or more IronMail® appliances. The addendum assumes you are familiar with networks and network terminology. You should also be familiar with the internet and its associated terms and applications. Please take a few minutes to become acquainted with the documentation.

How this addendum is organized

This addendum provides current information about features and functions that have been added to IronMail or enhanced since the publication of the IronMail 6.5.1 Administration Guide. The addendum is comprised of chapters that correspond to major program areas in IronMail, as identified by the tabs at the top of IronMail’s main window, and to the corresponding sections of the Administration Guide.

How to use this addendum

This addendum should have been delivered to you in PDF format. You can navigate through the addendum by clicking a line in the Table of Contents (each line is a hyperlink to the page it references).

Figure 1: TOC navigation

Figure 2: Indexnavigation

The listings in the Index are also clickable. There, the pages numbers are links to the locations in the text. You can navigate with a simple click of your mouse.

Figure 3: Chapternavigation

You will also be able to navigate within the text of the PDF version, using the following aids:

In each chapter, the topics introduced by “In this chapter” are links that allow you to navigate to your selected topic.When you navigate to a page or topic, you will also find a “back” arrow at the bottom of the page; the arrow will return you to your prior location.

v

Before You Begin

Conventions Names of buttons, tabs, keys, etc., or other items that receive an action from the window will appear in boldface type. Examples: Submit - Next - Reset.

User interface bookmarks

Within IronMail itself, you will find the ability to set bookmarks. These markers will allow you to navigate quickly to screens you visit frequently. Using these bookmarks permits easy access to specific screens.

Figure 4: Adding abookmark

Most IronMail screens include the bookmark capability. Available bookmarks (those that have not already been set) are indicated by a bookmark icon a the top of the window near the window title. If you click the icon, IronMail creates a link for that window on the Bookmarks list.

Figure 5: Bookmark list When you click the Bookmarks link at the upper right of the IronMail window, the Bookmarks list opens. All bookmarks you have added are listed. The window also includes commands for saving bookmarks and for clearing all the bookmarks on the list.

When you place the cursor over a listed bookmark, the bookmark will become bold. Clicking the bookmark will take you directly to the indicated window.

Your first log-in IronMail provides a window that appears the first time a user logs into the Web Administration interface.

Figure 6: First-timeopening window

The primary section of this window is entitled “What’s New?” Here you will find a list of new features included in IronMail version 6.5.4. When you click on any item in the list, it expands to offer a brief explanation of that feature.

vi

1CHAPTER Anti-Spam Features

In this chapter...

TrustedSource features..................................................................................... 2TrustedSource whitelisting............................................................................ 2TrustedSource queries for LDAP rejections ................................................. 3

Bayesian retraining............................................................................................ 4Ham retraining .............................................................................................. 4Administrator-released messages ................................................................ 5Improved Bayesian tokenization................................................................... 5

Classifying spam ............................................................................................... 6Image Spam Classifier (ISC) ........................................................................ 6Dynamic Spam Classifier (DSC)................................................................... 7

Connection Control............................................................................................ 9LDAP connection control .............................................................................. 9Connection control deny list improvement.................................................... 9

Backscatter Protection ...................................................................................... 9DSN Bounce Verification Protection ............................................................. 9

Other features ..................................................................................................11End User Quarantine...................................................................................11RBL hop count............................................................................................ 13Non-ASCII characters for “Add Header” options ........................................ 14Subject re-write changes ............................................................................ 14

1

Chapter 1: Anti-Spam FeaturesTrustedSource features

TrustedSource features

IronMail includes significant features to TrustedSource functionality since IronMail 6.5.1. The new functionality includes the following:

• TrustedSource whitelisting, and

• TrustedSource queries for LDAP rejections.

The information that follows refers to new functionality. Further information about TrustedSource may be found in Chapter 15 of the IronMail 6.5.1 Administration Guide.

TrustedSource whitelistingIronMail provides the capability to whitelist IP addresses from TrustedSource reputation queries. The details surrounding this capability follow.

TS whitelist rules• The Administrator must be able to add an IP address using the existing whitelisting window

and set TrustedSource as the sub-feature to be whitelisted.

• Anti-Spam and TrustedSource must be the only selections in such a rule.

• SMTPProxy will read IP based rules which have a bypass list value of Anti-Spam/TrustedSource, and use them when it perfrorms the TrustedSource lookup.

• The Administratore must create a policy including the rules that need to be evaluated. Policy attributes are not evaluated, so the policy could be global, user based, etc. The policy indicates explicitly the rules to be used. This allows the Administrator to create certain rules that may not be used immediately, and helps extend this feature to VIPs in the future.

• IronMail will not use whitelist rules created on filters other than IP address, and will ignore the direction (inbound/outbound) in the whitelist rule.

• Just before TrustedSource lookup is initiated, SMTP proxy will look up the address in memory. If it is present, it will send TrustedSource a special parameter to let it know that this message should not be flagged.

• IronMail will log the result of TrustedSource lookup, but will not evauate it for further action.

• IronMail will continue processing as if the TrustedSource lookup reports the IP address as neutral.

Configuring a TrustedSouce whitelist rule

To create a TrustedSource whitelist rule, navigate to the Whitelist - Manage Rules window (Compliance > Whitelist > Create).

Figure 7: Creating aTrustedSource rule

2

Chapter 1: Anti-Spam FeaturesTrustedSource features

When you have finished entering the required information, click Submit. The rule will be created, and will appear on the Whitelist - View Rules window (Compliance > Whitelist > View).

Figure 8: Viewing theWhitelist rule

You may apply the TrustedSource whitelist rule just as you would any other.

TrustedSource queries for LDAP rejectionsIronMail includes a field in the TrustedSource query it sends, which allows TrustedSource to capture partial LDAP rejections. The query will return proper information about an IP address if one or more recipients on the email are rejected. Such emails are likely to be malicious.

Since the LDAP query occurs before TrustedSource, the message will be dropped if all recipients are rejected. No TrustedSource query will be required.

Table 1: Creating a TS Whitelist rule

Field Description

Who Select from the drop down list the type of entity to be whitelisted by this rule. For a TS rule, the only allowable option is IP Address.

Data In this field, enter the data that defines the particular entity you have chosen to whitelist. For a TS rule, an IP address is required.

File If you wish, you may import a list of whitelist entries from a file, if the entries are in the proper format. For format information, see Appendix 5 in the IronMail 6.5.1 Administration Guide.

Export (hyperlink) If you wish, you may export this file (listing your whitelist entries) to save it as a backup, etc. Click the Export hyperlink.

Direction Click the appropriate radio button to determine the message direction for which the rule will apply.

• Inbound• Outbound• Both

Queue Select Anti-Spam as the queue for which you want to select processes to be bypassed.

Bypass When you select queue(s), the processes managed by that queue will appear in the Bypass list. Select TrustedSource as the rule to bypass.

3

Chapter 1: Anti-Spam FeaturesBayesian retraining

Bayesian retraining

IronMail improvements involve Bayesian analysis and retraining. They include:

• Better token utilization and management, and

• Improved training, including the handling of smaller datasets.

Specific features are explained below. The information that follows refers to new functionality. Further information about Bayesian analysis and training may be found in Chapter 17 of the IronMail 6.5.1 Administration Guide.

Ham retrainingAs part of Secure Computing’s ongoing efforts to improve Bayesian training and effectiveness, Bayesian training is being enhanced to include training on outbound messages. Bayesian functionality will be trained using all messages being sent outbound from the enterprise, so long as each message has multiple recipients. Messages destined to a single recipient will not be used for training.

IronMail also allows you to send “ham,” or legitimate email, to a special email account. This mail will be used for retraining the Bayesian classifier, similar to the way spam messages have been supplied in the past.

To configure this feature, enter the ham notification address in the data field on the User Spam Reporting - Configure window.

Figure 9: User SpamReporting window with

ham email address field

If a message is sent to the ham address and that message contains an embedded image, or if it has an image attached, the image will be added to the list of whitelisted images for the specific IronMail’s Image Spam Classifier.

Note: Image Spam Classifier requires that SuperQueue be manually restarted before it will recognize whitelisted items.

IronMail includes a provision to allow you to enable training on outgoing messages (as ham). As Figure 11 reveals, the Bayesian - Configure window includes a checkbox that allows the Administrator to enable or disable training. This option may be used to alleviate overemphasis on spam messages for Bayesian training.

4

Chapter 1: Anti-Spam FeaturesBayesian retraining

Administrator-released messagesIronMail provides the ability to specify messages that will be used for Bayesian training, much as the way EUQ released messages are used.

To specify messages for training, select the messages on the Quarantine Queue Message List window, then click the button at the top of the window, as indicated in Figure 10. Any messages you have selected will be used for Bayesian and ISC training.

Figure 10: QuarantinedMessages List window

Improved Bayesian tokenizationSecure Computing’s Research group continually tests additional tokenization methods that may be useful in Bayesian analysis. You may select the desired method from the drop down list on the Bayesian - Configure window. Only one method may be selected at a time, and “Split on white space” remains the default method.

Bayesian training can be done for additional tokenization methods; Secure Computing can apply added methods if customers have issues with those available in the GUI.

Figure 11: Bayesianconfiguration window

The content of the drop down list will be managed by the Research group, so that all effective methods are available to the Administrator. If you encounter spam effectiveness issues and Support determines that a different Bayes method would help, additional methods can be made available to you.

5

Chapter 1: Anti-Spam FeaturesClassifying spam

Classifying spam Two additional spam classification engines are now included in IronMail:

• Image Spam Classifier, and

• Dynamic Spam Classifier

The information that follows refers to new functionality that you may access in SpamProflier. Further information about SpamProflier may be found in Chapter 14 of the IronMail 6.5.1 Administration Guide.

Image Spam Classifier (ISC)This enhancement adds a new feature, the Image Spam Classifier (ISC), to IronMail. The Image Spam Classifier is a solution for identifying image spam. Image spam incorporates text content into common graphic encodings, such as GIF, JPEG and PNG, using graphic features such as animation and transparency to obscure the text from detection.

Note: This feature is not related to the Image Analysis feature already in IronMail. That feature is primarily concerned with pornographic or objectionable material.

The Image Spam Classifier includes two additional features:

• It includes a whitelist designed to improve performance by quickly recognizing and bypassing customer-supplied images that may appear in messages, such as corporate logos, signature embellishments, etc.

• It also includes a blacklist designed to improve effectiveness by catching images similar to those known to evade detection by ISC.

Images may be added to the whitelist and blacklist by informing Support and allowing them to be added. The lists are not user-configurable, and will be maintained by Secure Computing.

The only user-configurable option for ISC is the ability to enable or disable it from the Spam Profiler configuration window. ISC is disabled by default.

How Image Spam Classifier works

The high-level process for the ISC is as follows:

1 The ISC sorts the images it detects in a message and selects the three largest (the number of images processed is configurable upon request by Support).

2 It checks the whitelist to look for a match. If it finds a match, it skips the image.

3 The ISC checks size heuristics. If the image is too large or too small, ISC skips it.

4 The Support Vector Machine (SVM) applies algorithms to determine the likelihood that the image is spam.

5 The ISC checks the blacklist to see if the image matches known spam images.

6 The ISC returns a raw score for the image to the Spam Profiler. By default, the score will be 0 if the image is determined not to be spam, and 50 points if it is spam. A confidence value will be applied to the raw score.

Default scores for the Spam Profiler may be reconfigured by Support upon request.

Important notes about the ISC

The Image Spam Classifier reduces throughput when processing e-mail messages with images.

If a message is greater than 100 KB in size, a setting in Spam Queue Properties will cause it to bypass spam queue and therefore bypass the ISC. The setting is configurable by the

6


Administrator, via the anti-spam bypass feature.

Dynamic Spam Classifier (DSC)Because spammers change techniques more quickly than specific solutions can be provided to the field, Secure Computing is providing a method for delivering increased spam protection that is not contingent upon a new release of IronMail. Dynamic Spam Classifier (DSC) is a technology that can implement new spam detection techniques within IronMail in a timely manner.

DSC is a framework for delivery of fast-reaction detection methods to IronMail to fight spam outbreaks. The benefits are:

• Flexibility and timeliness in delivering spam updates independently of IronMail release cycles;

• Deliverability using ThreatResponse Signature updates methods;

• Ability to tailor methods for specific outbreaks, and to retire methods that are no longer needed; and,

• No dependence upon existing spam features in IronMail.

Note: DSC is implemented to deliver better protection from the latest spam outbreaks. It does not replace TRU, Spam Queue, or any other detection method on IronMail.

How DSC works

DSC will deliver a series of methods that will look at specific heuristics of a file. Whenever DSC is updated, it will replace or override the previous one, which allows for retirement of methods no longer necessary. In addition, if a certain method continues to be used, it can become a candidate for inclusion as an IronMail feature.

DSC runs as the last feature when Spam Queue runs. Spam Queue will pass messages to the DSC, where they will be compared to the current methods. DSC will then hand the message back with an associated score to contribute to the Spam Profile score. Every message that goes through Spam Queue will be sent to DSC. The only exceptions are:

• Messages larger than a preconfigured size, which can vary as necessary for the method;

• Messages that have received TrustedSource scores greater than 100 points or less than -100 points;

• Messages that have been whitelisted for DSC, as discussed below.

The individual scores from each DSC module will be visible in the X-header of the message, and in the message log files.

How to configure DSC

You can enable or disable the DSC on the SpamProfiler - Configure window. It is listed as a potential contributor to the Spam Profile along with other spam detection features. To enable it, select the Enable check box. You do not need to supply a threshold or confidence value. It is disabled by default.

7


Figure 12: Anti-Spam >SpamProfiler > Configure

Updating DSC

The frequency of DSC updates will be based on research and evaluation of new spam threats. The updates will be delivered as ThreatResponse Signatures, which can be delivered as frequently as every twenty minutes. The delivery method will be the same as for any other ThreatResponse Signature update.

If you have DSC enabled and have configured to allow automatic TRU updates at System > Updates > Configure Auto Updates, updated DSC files will be installed automatically.

Whitelisting

If you so choose, you can whitelist messages from DSC. You must select Anti-Spam from the Queue list, then you can select Dynamic Spam Classifier from the Bypass list.

Figure 13: Compliance >Whitelist > Create

Reporting

The message count stopped by DSC will be included on any report that reports overall spam (Executive Summary, Domain Executive Summary, Spam Action Summary) or in the totals for any report that shows messages blocked by SpamProfiler (Overall Spam Summary, Top Spam Lists).

8

Chapter 1: Anti-Spam FeaturesConnection Control

Connection Control

IronMail’s connection control functionality has been improved by including LDAP rejections in the TrustedSource query, and by enabling a TrustedSource query on IP addresses before they are added to the deny list.

The information that follows refers to new functionality. Further information about Connection Control may be found in Chapter 15 of the IronMail 6.5.1 Administration Guide.

LDAP connection controlLDAP rejections for any IP address that meets or exceeds a defined threshold will be subjected to a TrustedSource query. If the query produces a reputation score greater than zero, the IP address will be added to the Connection Control deny list.

Important: If you wish to use LDAP connection control, and the IronMail appliance is protected by an Edge appliance, you must add the Edge appliance to the connection control exclude list.

Connection control deny list improvementAs a method for reducing false positives, all IP addresses will be checked by TrustedSource before they are added to the Connection Control deny list. The query is performed after Spam Profiler determines the address qualifies for the deny list, but before it is actually added to the list.

Important: For connection control functionality requiring TrustedSource information, you must have TrustedSource enabled, and the IP address being checked must not be whiltelisted for TrustedSource.

Backscatter Protection

When hackers create spam or phishing messages using forged (spoofed) source addresses belonging to a company’s domain, that company can experience denial of service attacks under certain conditions. Where the fraudulent email’s recipient address doesn’t exist, the spoofed company can be flooded with email bounces. In the worst cases, a mail loop occurs when the message is bounced to a non-existent sender address.

The information that follows refers to new functionality. Further information about phishing threats may be found in Chapter 15 of the IronMail 6.5.1 Administration Guide.

Bounced Address Tag Validation (BATV) is a method for determining whether the return address specified in a bounced email is valid. The goal is to reject bounced messages to forged return addresses.

DSN Bounce Verification ProtectionThe BATV feature in IronMail is DSN Bounce Verification Protection. The feature allows the Administrator to configure a text key that is included in all recipient addresses supported by IronMail appliances.

The following conditions apply:

• DSN Bounce Verification will not work if IronMail or a BATV-compatible device with matching Address Tagging key is not used for outbound mail delivery.

• If there are multiple IronMails on site, they must share the same hash code.

• Recipients of outgoing messages will not be able to see the header code.

• You should allow a delay time to allow the DSNs to filter through your system.

9

Chapter 1: Anti-Spam FeaturesBackscatter Protection

Configuring DSN Bounce Verification

To configure this feature, navigate to the DSN Bounce Verification Protection - Configure window (Anti-Spam > Anti-Spam Advanced > DSN Bounce Verification Protection).

Figure 14: Configurationwindow

When the configuration options have been properly set, click Submit.

How DSN Bounce Verification Protection works

The feature solves the BATV issue by generating a unique hash (the tagging key) and including it in the header of all outgoing email messages. If a bounced email doesn’t include this header code, IronMail takes the configured action on that message (log only, or log and drop).

DSN Verification processing is performed in SMTPProxy. When the feature is enabled, IronMail will check to see if the “Mail From” header is empty. If it is NOT empty, then BATV will be bypassed. If the header is empty, IronMail will check the “Receipt To” header to see if the tagging key is present. If it is not present, IronMail will take the configured action.

Table 2: Configuring DSN Bounce Verification Protection

Field Description

Enable DSN Verification Protection

Select the check box to enable DSN Verification Protection on this IronMail.

The protection is disabled by default.

Select Action Select the proper radio button to configure the action IronMail should take when a message fails bounce protection. Options are:

• Log verification failure - IronMail creates a log entry for the failed message, but the message will still be received.

• Log and block verification failure - IronMail creates a log entry for the failure and drops the message.

Address Tagging Key

Enter the text for the tagging key (in plain text) that will be included in the mail recipient addresses that are supported by this IronMail. A minimum of four characters is required; the maximum number allowed is fourteen characters.

Note: If multiple BATV-capable devices exist on site, they must all have the same key.

Incoming DSNs are considered expired after __ days

Specify the number of days before incoming DSNs are considered expired, even if otherwise valid, by selecting the number of days from the drop down list.

10

Chapter 1: Anti-Spam FeaturesOther features

Other features IronMail includes other significant improvements.

End User QuarantineThe information that follows refers to new functionality. Further information about End User Quarantine may be found in Chapter 16 of the IronMail 6.5.1 Administration Guide.

IronMail allows users to have a unique (controlled expiration) link for accessing their quarantined messages, rather than receiving a new link each time they get EUQ notices. The Administrator can control the expiration frequency of the links for security purposes, and can refresh them at any time should the need arise.

To configure the expiration of these links or to refresh them for other reasons, navigate to the End User Quarantine - Configure window (Anti-Spam > Advanced > End User Quarantine > Configure).

Figure 15: ConfiguringEUQ link expiration

Configuration of the new functionality requires populating new fields at the bottom of the window. The rest of the configuration process is unchanged.

Table 3: Configuring EUQ link expiration

Field Description

EUQ Link Expiration Choose the correct radio button to determine the expiration rule you prefer. Options are:

• Always - the EUQ links will expire immediately (no persistent links)• Never - the links will never expire, but will remain available

permanently unless refreshed by the Administrator• A specific number of days - enter the length of time you want the links

to stay active unless they are refreshed by the Administrator.

More...

11


Configuring the notification

The notices users are to receive can be configured in the Mail Notification windows. IronMail is delivered with a default EUQ Link Notification that cannot be edited or deleted. To view the notice, navigate to the Mail Notification - Manage window (Compliance > Advanced Compliance > Mail Notification).

Figure 16: MailNotification window

showing EUQ linkexpiration notice

You may also add your own custom notice by clicking Add New at the bottom of the screen.

Figure 17: Adding a newnotification

EUQ Link Notification

From the drop down list, select the particular notification to be sent to users when the links expire or when they are refreshed.

Note: When the information in these two fields is correctly entered, click Submit to establish the expiration cycle.

EUQ Link Refresh If you wish to refresh the EUQ links, select the correct radio button to identify the specific links to be affected. Options are:

• Refresh for All Users - selecting this option will refresh all unique links associated with this IronMail appliance

• Refresh for Specific Users - selecting this option requires you to enter one or more complete email addresses in the data field. Multiple addresses must be entered as a comma-separated list.

Note: When you have determined which links are to be refreshed, click Refresh.

Table 3: Configuring EUQ link expiration

Field Description

12


Select the type of notification you want to create, then enter the required information, just as you would for any other type of mail notification. More information about configuring mail notifications may be found in Chapter 13 of the IronMail 6.5.1 Administration Guide.

RBL hop countThe information that follows refers to new functionality. Further information about Realtime Blackhole Lists may be found in Chapter 17 of the IronMail 6.5.1 Administration Guide.

The dynamic hop count feature allows you to specify the hop count of messages, identifying the entities that are to be reported by TrustedSource. The feature is important for companies that have complex networks, such as multiple paths to their email systems. It tells TrustedSource what to check and in what position it should occur when reporting a reputation score.

Dynamic hop count is configured on the Realtime Blackhole List window. The newly-added segment from the bottom of that window appears in Figure 18.

Figure 18: Configuringdynamic hop count

Configuration is based on combinations of the following pieces of information:

• The connecting IP address;

• Received headers (the header string to be matched); and,

• Position of the received header string (header position).

IronMail supports the following configuration combinations:

• Connecting IP, header string and header position - all conditions must be met;

• Connecting IP only - set the hop count for the specified IP; or,

• Header string and header position - set the hop count for matches on the header string and position, for all IPs. The received header is checked to see if the header string occurs in the specified header position.

The following basic rules apply:

• You must always specify the header string and header position together. You must have both.

• You cannot specify a header string with a position of 0, which implies the header string is NULL (matching is done for the connecting IP only).

The actual processing using dynamic hop count occurs in smtpproxy, where the TrustedSource lookup happens.

Extending Dynamic Hop Count functions

IronMail has extended the Dynamic Hop Count functions to additional anti-spam features, including SenderID, Reverse DNS and System Defined Header Analysis. Settings that were formerly limited to RBL now apply globally to these features, to ensure they analyze the correct IP address.

13


Non-ASCII characters for “Add Header” optionsThe information that follows refers to new functionality accessible through SpamProfiler. Further information about SpamProfiler may be found in Chapter 14 of the IronMail 6.5.1 Administration Guide.

IronMail allows you to enter non-ASCII characters as input for the “add header” action in Spam Profiler. Users whose languages do not support ASCII can take advantage of this action. To add a header to a message that has been identified as spam, navigate to the Spam Profiler - Configure window. Select the check box, then enter the name you want to appear as the added header.

Figure 19: Add Headeroption

Subject re-write changesWhen IronMail inserts a character string as a subject re-write parameter, IronMail will not automatically convert that string to UTF-8. Instead, it will use the character set that already exists in the subject line. If a subject line has multiple character sets, IronMail will use the first detected character set.

If the subject line is written in a character set that IronMail does not support, it will be converted to UTF-8.

Further information about IronMail actions and action values may be found in Appendix 8 of the IronMail 6.5.1 Administration Guide.

14

2CHAPTER IntrusionDefender Features

In this chapter...

LDAP features ................................................................................................. 16Secure LDAP.............................................................................................. 16LDAP variable User Identification............................................................... 17

SMTP on custom TCP ports............................................................................ 17

15

Chapter 2: IntrusionDefender FeaturesLDAP features

LDAP features IronMail’s LDAP functionality has been enhanced to allow secure communication with the LDAP server, and to allow support for an additional user attribute, User Identification (UID).

The information that follows refers to new functionality. Further information about LDAP may be found in Chapter 23 of the IronMail 6.5.1 Administration Guide.

Secure LDAPThis feature provides the capability for IronMail to communicate with the LDAP server over a secure tunnel. Three radio buttons on the LDAP Profile - Add Definition window allow you to select the mode and set the appropriate port. Three modes are possible:

• Non-secure communication - this is the default mode;

• Secure LDAP over SSL - this mode enables communication over a secure port using encrypted text; and,

• Secure LDAP and TLS - the query to the LDAP server will be done securely via a TLS session.

For Microsoft Active Directory, the port for non-secure communication and for the TLS mode is 3268; the port for SSL communication is 3269. For other platforms, the non-secure/TLS port is 389, and the SSL port is 636.

The proper default port for the selected platform will populate the Port field when you select the mode.

Figure 20: Selectingsecure communication

Note: The Administrator can change the port by simply typing over the default.

16

Chapter 2: IntrusionDefender FeaturesSMTP on custom TCP ports

LDAP variable User IdentificationThe feature adds support for the use of an attribute called User Identification (UID) as an alternative or alias for the email user.

Figure 21: LDAP querybrowser with UID

Some LDAP platforms, such as Domino, e-Directory and OpenLDAP support the variable. The UID replaces the user name to the left of the @ sign in the email address. IronMail supports the variable within the search filter when it queries the LDAP server.

SMTP on custom TCP ports

Since some companies have a need for their mail servers to listen for SMTP traffic on ports other than port 25, IronMail allows the Administrator to define the destination SMTP ports for mail delivery on the Domain Routing - Add Mapping window. The option is available only for inbound static and outbound static routes.

The information that follows refers to new functionality. Further information about Domain Routing may be found in Chapter 22 of the IronMail 6.5.1 Administration Guide.

The process for adding a new static route remains much as it has been, with one change to the window. The Port field has been added, where you may enter a valid port ID to specify the custom port you desire.

Figure 22: Adding adomain routing

When the configuration has been entered properly, click Submit. The Domain Routing Mapping - Manage window will update to show the newly-designated port.

17

Chapter 2: IntrusionDefender FeaturesSMTP on custom TCP ports

Figure 23: Domainrouting updated

18

3CHAPTER Queue Manager Features

In this chapter...

Dynamic Quarantine........................................................................................ 20Enabling and disabling Dynamic Quarantine from the UI........................... 20TrustedSource score variable in Dynamic Quarantine ............................... 20Automatic shut-off....................................................................................... 20

19

Chapter 3: Queue Manager FeaturesDynamic Quarantine

Dynamic Quarantine

The information that follows refers to new functionality. Further information about Dynamic Quarantine may be found in Chapter 5 of the IronMail 6.5.1 Administration Guide.

IronMail includes enhancements to Dynamic Quarantine, allowing better Administrative control and the ability to add rules based on TrustedSource scores. Details are shown below.

Enabling and disabling Dynamic Quarantine from the UIIronMail includes the ability to enable or disable Dynamic Quarantine from the UI. Customers have the capability to opt out of the feature if they so choose by simply selecting or de-selecting a checkbox on the TrustedSource - Configure window.

Dynamic Quarantine is disabled by default.

Figure 24: EnablingDynamic Quarantine

TrustedSource score variable in Dynamic QuarantineThere are two methods for sending a message to Dynamic Quarantine:

• through a TrustedSource lookup that returns a score within a preconfigured range; or,

• using rules that have been deployed as part of a TRUSign package.

IronMail provides the ability to add rules based on a TrustedSource score variable to the TRUSign rules, in addition to rules based on subject, attachment name, attachment format, and message size.

Automatic shut-offDynamic Quarantine will automatically disable itself if available disk space falls below 30% of the system’s capacity. This feature is intended to prevent performance degradation or other problems that may result from inadequate disk space.

20

4CHAPTER Compliance Features

In this chapter...

Whitelisting features ........................................................................................ 22Integrating TrustedSource into whitelisting rules ........................................ 22Whitelisting include/exclude option............................................................. 22Automated Administrator whitelist expiration.............................................. 23

Content Analysis Features .............................................................................. 25Using the pre-defined regular expressions................................................. 25Using the validation algorithms................................................................... 29

Message stamping .......................................................................................... 32

21

Chapter 4: Compliance FeaturesWhitelisting features

Whitelisting features

The information that follows refers to new functionality. Further information about whitelisting may be found in Chapter 12 of the IronMail 6.5.1 Administration Guide.

IronMail’s whitelisting capabilities have received three refinements, allowing increased capabilities and expanded administrative options:

• Integrating TrustedSource into whitelisting,

• Whitelisting include/exclude option, and

• Automated whitelist expiration.

Integrating TrustedSource into whitelisting rulesThis feature provides the ability to whitelist an IP address, exempting it from TrustedSource queries. You can select TrustedSource as a sub-feature to be bypassed like any other sub-feature.

TrustedSource is an allowed selection only when IP Address is the selected “Who” parameter.

Figure 25: Whitelistrules window

Whitelisting include/exclude optionIn prior versions of IronMail, whitelisting was implemented as an inclusive function. If IronMail received a message with more than one recipient, and one of the recipients was whitelisted, then all recipients were treated as if they were whitelisted. The current feature permits an exclusive mode of operation that you may select. The default setting is “inclusive.”

If the Exclusive check box is selected, when IronMail receives a message with multiple recipients and one of the recipients is whitelisted, but the others are not, the message will be processed as if no one is whitelisted. The other recipients must also be explicitly whitelisted in order for the message to bypass processing.

22


Figure 26: Whitelistexclusive mode

Automated Administrator whitelist expirationIf whitelist rules continue to accumulate on an IronMail appliance, they may eventually degrade performance. IronMail allows the Administrator to configure automatic expiration and deletion of whitelist rules that are no longer in use.

Creating the whitelist entry

Whitelist entries are created on the Whitelist - Manage Rule window. The only change to the creation process comes with the addition of one check box, labeled Don’t Expire. If the Administrator selects this check box, the entry will remain until it is manually deleted by the Administrator.

Figure 27: Configuringwhitelist expiration

When the whitelist entry is configured properly, click Submit. The Whitelist - View Rules window will refresh to include the new entry.

23


Figure 28: Viewingwhitelist rules

As Figure 28 illustrates, the Administrator’s expiration preference shows on this window. If Don’t Expire is checked for an entry, the only way to delete it is to check the Delete box and then click Submit. If, however, the option is unchecked, the Administrator can navigate to the Cleanup Schedule feature and create cleanup/expiration rules that automatically delete unused whitelist entries.

Setting automatic cleanup for whitelist entries

On the Cleanup Schedule - Configure window (Administration > Cleanup Schedule), the Administrator sets the schedule for deletion of unused rules. The deletion occurs based on the length of time that has expired since the entry was last used. The last hit date appears on the View Rules window, as shown in Figure 28.

Figure 29: Settingautomatic whitelist

expiration

Table 4: Configuring whitelist rule removal

Field Description

File Type: Choose the Whitelist rules file type from the drop down list. Then click Select. The window will refresh to appear as it does in the screen shot above.

Admin Whitelist Cleanup Interval

Enter the length of time in hours that must expire since an Administrator-created rule was last hit. When a rule’s last use is beyond this number of hours, the rule is set for cleanup.

EUQ Whitelist Cleanup Interval

Enter the length of time in hours that must expire since an End User Quarantine-created rule was last hit. When a rule’s last use is beyond this number of hours, the rule is set for cleanup.

More...

24

Chapter 4: Compliance FeaturesContent Analysis Features

When the cleanup schedule is correctly configured, click Submit.

Content Analysis Features

The information that follows refers to new functionality. Further information about Content Analysis may be found in Chapter 8 of the IronMail 6.5.1 Administration Guide.

Two new features have been added to Content Analysis Dictionaries:

• Use of pre-defined regular expressions, and

• Support for validation algorithms.

Both additions are related to the use of regular expressions.

Using the pre-defined regular expressionsThe two pre-defined regular expressions are specifically intended to identify US Social Security Numbers and Canadian Social Insurance Numbers.

You may use the pre-defined regular expressions two ways,

• Add them to an existing compliance dictionary

• Create a new compliance dictionary that contains the pre-defined regular expressions.

After logging into your IronMail appliance, click on the Compliance tab. In the left column menu, expand Content Analysis, then click Dictionaries.

Frequency Schedule

Clicking this button enables creation of a fixed-interval schedule for the Cleanup cycle. The Administrator may select an interval in hours (1 hour to 72 hours) between cycles.

Note: You must choose either Frequency Schedule or Detailed Schedule. Enabling one disables the other.

Detailed Schedule This option allows creation of a specifically detailed schedule for the Cleanup cycle. The schedule is configured in two steps:

• The left side of the window displays a list of days of the week. Select the day during which the cleanup cycle is to run. You may select only one day at a time. However, after you submit the detailed schedule for one day, you can do it again for another day and the system will accumulate the daily schedules. It is therefore possible to create individual detailed schedules for all seven days per week.

• The right side of the window contains check boxes for each of the 24 hours in a day. Clicking a check box enables IronMail to run Auto Cleanup at that time on the designated day. You may select from 0 to 24 cleanup times per day.

Table 4: Configuring whitelist rule removal

Field Description

25


Figure 30: Dictionarieswindow

In this example, we will add a new dictionary that will contain the use of the pre-defined regular expressions.

1 Click Add New.

Figure 31: Adding adictionary

2 Enter a name for the new dictionary. In this example, we will simply name it “regex_test.”

3 Accept the default settings for the remaining fields, then click Submit.

Figure 32: Dictionariesupdated

The new dictionary will appear in the dictionary list.

4 Click the name of the dictionary you just created.

26


Figure 33: Dictionarycontent window

5 Click Add New.

Figure 34: Selecting thecontent type

6 From the Content Type pulldown menu, select Regular Expressions. The window will change and display the following options.

27


Figure 35: Selecting theRegEx type

7 From the Enter Regular Expression field pulldown menu, select the type you want to use.

Figure 36: Predefinedheaders

In this example, we use the U.S. Social Security Number.

Figure 37: Dictionarycontent with pre-defined

RegEx selection

Upon selection, several changes will occur on the window.• The Search Type will reset to “substring” and cannot be changed.• The Enter Regular Expression field will automatically populate with the pre-defined

regular expression selected. It may NOT be edited.• The Validation Algorithm is not editable.• The Side Note is not editable.

28


8 Click Submit to save your information.

Using the validation algorithmsIronMail includes three validation algorithms for use when validating regular expressions.

You may use the validation algorithms two ways,

• Add them to an existing compliance dictionary• Create a new compliance dictionary that contains the pre-defined regular expressions.

1 After logging into your IronMail appliance, click on the Compliance tab. In the left column menu, expand Content Analysis, then click Dictionaries.

Figure 38: The ManageDictionaries window

In this example, we will add a new dictionary that will contain the use of the regular expres-sions along with the validation algorithms.

2 Click Add New.

Figure 39: Adding a newdictionary

3 Enter a name for the new dictionary. In this example, we will simply name it “regex_validation.”

4 Accept the default settings for the remaining fields, then click Submit.

29


Figure 40: Dictionarieswindow updated

The new dictionary will appear in the dictionary list.

5 Click the name of the dictionary you just created.

Figure 41: ManageDictionary Content

window

6 Click Add New.

30


Figure 42: Selecting thecontent type

7 From the Content Type pulldown menu, select Regular Expressions. The window will change and display the following options.

Figure 43: Selecting thevalidation algorithm

Enter your configuration according to the table below.

Field Description

Search Type Select “substring.”

Enter Regular Expression

Select “Custom” then type the regular expression you want to use.

Regular Expression Flags

Select an appropriate flag, if desired. (Not required.)

More...

31

Chapter 4: Compliance FeaturesMessage stamping

8 Click Submit.

Message stamping

The information that follows refers to new functionality. Further information about Message Stamping may be found in Chapter 13 of the IronMail 6.5.1 Administration Guide.

The following character sets have been added to IronMail, to be used for Message Stamping only:

• Arabic (Windows) win-1256

• Baltic (ISO) 1o-8859-4

• Baltic (Windows) win-1257

• Central Euro (Windows) win-1250

• Chinese Simplified (HZ) hz-gb-2312

• Cyrillic (KOI8-U) koi8-u

• Estonian (ISO) iso-8859-13

• Greek (ISO) iso-8859-7

• Green (Windows) win-1253

• Hebrew (Windows) win-1255

Validation Algorithm From the pulldown menu, select the validation algorithm to use for validating your regular expression. Choices are:

• Mod 10 - also known as the Luhn algorithm, a simple checknumber formula used to validate various ID numbers, including credit card numbers and Canadian Social Insurance Numbers.

• CUSIP - a 9-character alphanumeric identifier for North American securities, created by the Committee on Uniform Security Identification.

• ISIN - international security identifying number, used to identify securities such as bonds, commercial paper, equities and warrants.

Test Value Enter a value to test against if you wish to test your regular expression.

Weight Enter a value to represent the score contribution for one instance of this entry.

Include Click the checkbox to include this entry in the dictionary's message scans.

Scan Area Select one or more parts of the message that should be included in the dictionary's scan for this entry.

Contribution Type Click the radio button to determine whether the entry will be counted only once per message, no matter how many times it appears, or will contribute the amount configured as Maximum Contribution.

Note: For the contribution value, enter a number to represent the maximum contribution per message for this entry. The count will accumulate multiples of the entry's weight each time the entry appears, until the maximum is reached. If the count is set at zero and Maximum Contribution was selected above, the count will be the weight of the entry multiplied by the actual number of times it appears in the message.

Side Note Enter any explanatory or identifying text you wish to associate with this entry.

Field Description

32


• Korean ks_c_5601-1987– An alternative alias character set my be used - CP949

• Latin9 (ISO) iso-8859-15

• Thai (Windows) win-874

• Turkish (OSO) iso-8859-9

• Turkish (Windows) win-1254

• Unicode (utf7) utf-7

33


34

5CHAPTER Reporting Features

In this chapter...

Message Blocking ........................................................................................... 36SNMP polling................................................................................................... 38

SNMP polling configuration ........................................................................ 38Public SNMP variables for IronMail ............................................................ 40

Syslog additions .............................................................................................. 41

35

Chapter 5: Reporting FeaturesMessage Blocking

Message Blocking

The information that follows refers to new functionality. Further information about IronMail Reports may be found in Chapter 31 of the IronMail 6.5.1 Administration Guide.

A Message Blocking report has been added to the list of available reports from IronMail. It is a PDF report, accessible from the Reports window, as shown in Figure 44.

Figure 44: The ReportsWindow

Clicking on the link for the Message Blocking report will take you to a window where you can see the most recent report and where you can access others by clicking the appropriate links.

Configuring the Message Blocking ReportYou can configure the report on the Reports - Configure window, just as you would any other IronMail report. The Message Blocking Report appears in the lower list of reports, as shown in Figure 45.

Figure 45: Configuringthe report

36

Chapter 5: Reporting FeaturesMessage Blocking

In the upper section of the window, you can configure the archiving and transfer method for the report just as you would for any other. Of particular interest for the Message Blocking Report, you must also specify the Connection to Message ratio by selecting Industry Standard or Admin Defined ratio. If you select the Admin Defined setting, you will also specify the maximum number of messages allowed per connection by entering a number from 1 to100 in the data field.

You may elect to disable the report, create the report, or create and email it by selecting the desired options associated with the report name as shown.

A sample reportFigure 46 shows a current day’s report as it appears in IronMail. The Reports window allows you to determine the period of time the report should represent. It provides a simple Total Messages Summary for quick review, followed by a detailed report that shows messages blocked by each IronMail feature.

Figure 46: MessageBlocking Report

The Detail section tracks both connections and messages blocked by IronMail. Information for the current day is presented graphically and numerically, including trends over time. The two numerical tables represent connection-layer blocking and application-layer blocking, respectively. Connection-layer blocking (the table to the left) is concerned with the

37

Chapter 5: Reporting FeaturesSNMP polling

connections blocked and the associated messages that were not allowed into IronMail. Application-layer blocking (the table to the right) shows messages blocked as a result of IronMail’s actions on messages it processed.

The lower portion of the current report lists available reports for today and the recent past. If you click View for any available report, you will be allowed to open or save that day’s report in PDF format, as illustrated in Figure 47.

Figure 47: PDF MessageBlocking report

SNMP polling IronMail includes an SNMP polling feature that provides the capability for a polling station or package to collect data from the IronMail appliance via the SNMP protocol. This feature is helpful in mapping alert events to SNMP traps. The IronMail appliance publishes a MIB view that allows “read only” access to data to be used in processing a variety of queries. There is NO “write” access permitted, so the data remains secure. The feature allows the Administrator to set the polling interval.

IronMail’s SNMP polling supports SNMP v1 and SNMP v2.

SNMP polling configurationThe SNMP polling feature may be accessed from the Reporting tab (Reporting > SNMP Polling).

Figure 48: ConfiguringSNMP Polling

38


If you click the service name, the following window will appear.

Figure 49: Configuringthe collection interval

On this window, you can set the polling interval by entering a time in seconds. The allowable range is from 60 to 3600 seconds. This interval defines the wait time between SNMP polling occurrences.

Table 5: SNMP Polling

Field Description

Service This field contains the service name. In this case, the name is Internal-snmpd2, the name of the SNMP polling service.

Click the name to configure the polling time interval.

Auto-Start A red X or green check icon indicates whether or not the service is set to start automatically when the IronMail appliance is rebooted. If an icon is green, the service will begin running when IronMail restarts. In addition, if the icon is green, IronMail’s Health Monitor will restart any service except SMTPO that has stopped for any reason when it performs its tests on all appliance subsystems. If an icon is red, the service will not start on reboot, nor when Health Monitor runs its system tests.

Note: A service can continue to run after its auto-start setting is turned off.

The red and green light icons are hyperlinks. Clicking the icon/hyperlink toggles the auto-start option on and off.

Running A red or green light icon indicates whether or not the service is currently running.

In some situations, the Running icon may not refresh when clicked, i.e. change from green to red. If the icon does not toggle as expected, click the Mail Services - Configure hyperlink in the left navigation frame of the Web Administration interface to refresh the page, rather than clicking the Running icon a second time.

Service Uptime This column indicates (in days, hours, minutes, and seconds) how long a service has been running since it was last restarted.

If the “uptime” appears less than expected, it may indicate that the service was manually stopped and restarted by an administrator, or was stopped by an administrator and was restarted automatically by IronMail’s Health Monitor.

39


Public SNMP variables for IronMailThe following variables are provided to the SNMP polling station from the IronMail SNMP daemon.

Table 6: SNMP Variables

S # Variable Name Description

1 ctCPUSystem Current system-space CPU utilization

2 ctCPUIdle Current idle CPU

3 ctCPUUser Current user-space CPU utilization

4 ctMemoryFree Currently free memory (in bytes)

5 ctMemoryActive Currently active memory (in bytes)

6 ctMemoryInactive Currently inactive memory (in bytes)

7 ctMemorySwap Current swap space in use (in bytes)

8 ctDiskIOtps Disk I/O transactions per second

9 ctDiskIOmbps Disk I/O in megabytes per second

10 ctDiskFSct Current percentage of the ct partition used

11 ctDiskFSvar Current percentage of the var partition used

12 ctDiskFStmp Current percentage of the tmp partition used

13 ctNetworkIOin Current rate of data into the physical network interface (bits/sec)

14 ctNetworkIOout Current rate of data out of the physical network interface (bits/sec)

15 ctServiceSmtpo Status of smtpo service (0 = not running, 1 = running)

16 ctServiceSmtpproxy Status of smtpproxy service (0 = not running, 1 = running)

17 ctQueueLevel Number of messages currently being processed by queues

18 ctQueueProcessedAVQ Number of messages processed by AVQ since local midnight

19 ctQueueActionAVQ Number of messages processed by AVQ since local midnight that required action

20 ctQueueProcessedCFQ Number of messages processed by CFQ since local midnight

21 ctQueueActionCFQ Number of messages processed by CFQ since local midnight that required action

22 ctQueueProcessedMMQ Number of messages processed by MMQ since local midnight

23 ctQueueActionMMQ Number of messages processed by MMQ since local midnight that required action

24 ctQueueProcessedSMTPO Number of messages processed by SMTPO since local midnight

More...

40

Chapter 5: Reporting FeaturesSyslog additions

Before IronMail’s SNMP traps can provide all the available information to the SNMP service, you must compile the appropriate IronMail MIB file within your SNMP application. You can download the MIB you will need for SNMP polling from the Support KnowledgeBase, article 7220. The file you need to download is CT-SNMP-PUBLIC-MIB.txt.

Syslog additions Three new parameters have been added to Syslog:

• ESP score and message hash;

• LDAP message drops; and,

• SMTPI full throttle/sleep information.

25 ctQueueActionSMTPO Number of messages processed by SMTPO since local midnight that required action

26 ctQueueProcessedRIPQ Number of messages processed by RIPQ since local midnight

27 ctQueueActionRIPQ Number of messages processed by RIPQ since local midnight that required action

28 ctQueueProcessedJOINQ Number of messages processed by JOINQ since local midnight

29 ctQueueActionJOINQ Number of messages processed by JOINQ since local midnight that required action

30 ctQueueProcessedSPAMQ Number of messages processed by SPAMQ since local midnight

31 ctQueueActionSPAMQ Number of messages processed by SPAMQ since local midnight that required action

32 ctQueueProcessedSUPERQ Number of messages processed by SUPERQ since local midnight

33 ctQueueActionSUPERQ Number of messages processed by SUPERQ since local midnight that required action

34 ctQueueProcessedCCQ Number of messages processed by CCQ since local midnight

35 ctQueueActionCCQ Number of messages processed by CCQ since local midnight that required action

Table 6: SNMP Variables

S # Variable Name Description

41

Chapter 5: Reporting FeaturesSyslog additions

42

6CHAPTER System Feature

In this chapter...

Improved TRUSign update process ................................................................ 44Downloading and installing updates ........................................................... 44Locking your current configuration settings ................................................ 44Special configurations................................................................................. 45

43

Chapter 6: System FeatureImproved TRUSign update process

Improved TRUSign update process

The information that follows refers to new functionality. Further information about ThreatResponse updates may be found in Chapter 35 of the IronMail 6.5.1 Administration Guide.

ThreatResponse updates are a critical asset that enable Administrators to ensure they have the best and latest protection configuration settings for their IronMail appliance. However, there are situations wherein specific settings should not be overwritten when a new ThreatResponse Signature (TRUSign) update is installed. For example, a custom Content Analysis dictionary may have been created to meet the unique needs of the organization. IronMail provides the capability to block changes to feature configuration when new updates are installed.

Administrators can lock current configuration settings to be kept as they are, either individually or as a group.

Important: If you want to protect any of the existing configuration settings in your system, you must lock those settings prior to installing new TRUSign updates.

Downloading and installing updatesThe basic downloading and installation process for TRUSign updates remains essentially unchanged. Available updates are downloaded and installed from the ThreatResponse Signatures - Updates window. Figure 50 illustrates a listing of updates that have been installed. You can refresh the window at any time to view recent updates that have become available.

Figure 50: TRUSignature Updates

Prior to installing any updates, you have the option of locking current settings.

Locking your current configuration settingsYou can lock your current settings by either of two methods. You can navigate to the Configure Auto Updates window and lock all existing configurations by clicking the Locked check box associated with the ThreatResponse Updates service, as indicated in Figure 51.

44


Figure 51: Locking allfeatures

If you select this option, all your existing rules will remain as they are. None will be overwritten.

Note: Selecting the Locked option on the Auto Updates window overrides the Locked check boxes on the SpamProfiler - Configure window. Choose one method or the other for locking your configuration.

You may also lock the current settings for specific features by navigating to the SpamProfiler - Configure window. As the screen shot shows, most features that appear in SpamProfiler have a checkbox that allows you to lock them. If you select the check box next to a feature, the current settings will be maintained, while those for unchecked features will be overwritten.

Figure 52: Lockingindividual features

Special configurationsAs Figure 52 illustrates, some features do not offer the locking option on the SpamProfiler window. Realtime Blackhole Lists, System Defined Header Analysis and User Defined Header Analysis require their own configuration methods.

Note: Selecting the locking option on the AutoUpdates window will protect the settings for these features, just as it does for all the others.

As shown in Figure 53, you can configure each zone you add to your RBL as you add it. Checking the Locked check box causes the entry to be protected when new TRUSign updates are added.

45


Figure 53: RealtimeBlackhole List locking

For SDHA and UDHA, each filter has its own checkbox by which you can protect the current configuration. You can select the individual filters from the lists, as you can see in Figure 54.

Figure 54: SDHA locking

46

INDEX

AAdd Header options

Non-ASCII characters 14

BBackscatter Protection (BATV) 9Bayesian 4

Admin-released messages 5Ham retraining 4

CConnection Control 9

Deny list 9LDAP 9

Content Analysis 25Pre-defined RegEx 25Validation algorithms 29

DDSN Bounce Verification 9

Configuration 10How DSN Bounce Protection works 10

Dynamic Quarantine 20Enabling from the UI 20TrustedSource variable 20

Dynamic Spam Classifier 7Configuring DSC 7How DSC Works 7Reporting 8Updating DSC 8Whitelisting 8

EEnd User Quarantine 11

IImage Spam Analysis 6

How ISC works 6

LLDAP 16

Secure LDAP 16

User ID variable 17

MMessage actions

subject re-write 14Message Blocking 36

Configure report 36Sample report 37

Message stamping 32

RRBL Hop Count 13

SSMTP

Custom Ports 17SNMP Polling 38

Configuration 38IronMail variables 40

Syslog 41

TTRUSign Updates 44

Installing 44Locking current settings 44Special locking configurations 45

TrustedSource 2LDAP Rejections 3Whitelisting 2

WWhitelisting 22

Automated expiration 23Include option 22

47

Index

48

administration guide

Documents

secure computing software

software modules

secure computing appliance

secure computing grants

secure computing licenses

secure computing edge

antivirus software

trademarkssecure computing