MailMarshal

Version 4.2

Release Date: June 2001

Copyright 1994-2001 Marshal Software Limited

No part of this publication may be reproduced, transmitted, stored in a

retrieval system, nor translated into any human or computer language, in any
form or by any means, electronic, mechanical, magnetic, optical, chemical,
manual, or otherwise, without the prior written permission of the copyright
owner, Marshal Software Limited, 19 Lambie Drive, Manukau City, New
Zealand. Copyright infringement is a serious matter under the New Zealand
and foreign Copyright Laws.

Marshal Software and MailMarshal are registered trademarks of Marshal

Software Limited.
The Regular Expression Parser (Regex++) used in MailMarshal, and its documentation, are Copyright ©1998-
2000 Dr John Maddock. Permission to use, copy, modify, distribute and sell Regex++ and its documentation for
any purpose is hereby granted without fee, provided that the above copyright notice appears in all copies and that
both that copyright notice and this permission notice appear in supporting documentation. Dr John Maddock
makes no representations about the suitability of this software for any purpose. It is provided “as is” without
express or implied warranty.
 Licensing Agreement

The User License Agreement printed below is a copy for your information only of the actual agreement embedded in the
Marshal Software product which is displayed and accepted by the user during installation of the product. In the event of
any discrepancies between these versions, the copy embedded in the product shall apply.
IMPORTANT: Do not install this software unless you accept the following terms and conditions.
Marshal Software Limited (hereafter called “Marshal”) licenses this Marshal Software product (the “Software”) only on
the condition that you accept all of the terms contained in this software license (“License”). Please read slowly through
the terms of this License. Read it carefully before installing the Software. By installing or using the Software, you agree
to be bound by the terms of this Agreement.
1. The License
1.1. Marshal is the exclusive owner of the Software.
1.2. This License grants you the non-exclusive, non-transferable right to use one registered copy of the Software
strictly in accordance with the terms of this agreement. You may also make one copy for backup purposes
only.
1.3. You shall only use the Software on the computer (“Designated Computer”) for which Marshal has issued you
the key. If you wish to use the Software on another computer, you must obtain another key and pay the
relevant fees. However, with Marshal’s consent, you may replace or substitute a new computer for your
Designated Computer without incurring new license fees. Marshal shall not unreasonably withhold its
consent provided the Software is compatible with such replacement or substitute computer. In such case you
must cease running the software on the original designated computer and remove it from that machine as
soon as it is installed on the replacement or substitute computer.
1.4. Except as provided in §1.3, under no circumstance shall you install the Software, or make a copy thereof, for
use on any other computer. You shall not modify the Software for use on any other computer.
1.5. You shall not exceed the number of users for which your current key was authorized by Marshal. If you
wish to add more users, you must request a modification to your License and pay the relevant fees.
2. License Fee
2.1. To use the Software, you must have paid all applicable license fees. If you do not pay such license fees,
Marshal shall revoke this License in which case you shall forthwith stop using the Software and remove all
components of it from all computers.
3. Documentation
3.1. This Agreement extends to the Software documentation, whether in electronic or print format. The
documentation may not be copied, modified or used in any way not contemplated or expressly authorized by
this Agreement.
4. Your Obligations
4.1. You shall not: (i) Copy, reproduce, translate, adapt, vary or modify the Software without the express consent
of Marshal; (ii) disassemble, decompile or “unlock”, reverse translate, or in any manner decode the Software
for any reason whatsoever; (iii) provide or otherwise make available the Software in any form to any person
without the written consent of Marshal; (iv) rent, lend or lease the Software; (v) transfer the Software to any
other person under any circumstances without the written consent of Marshal; (vi) attempt to bypass or
circumvent the security procedures applicable to the Software; (vii) take any action that would cause injury
to Marshal’s intellectual property rights in the Software or that would deprive Marshal of the license fees to
which it is entitled.
4.2. You shall supervise and control the use of the Software in accordance with the terms of this Agreement. You
shall ensure your employees, subcontractors or agents who have authorised access to the Software are made
aware of the terms of this Agreement and comply therewith. You shall maintain safe custody of the
Software.
5. Limited Warranty
5.1. Marshal has used its best endeavors to develop a stable and reliable software product. Because there is such
a diverse range of computers, operating systems and applications, Marshal can not warrant that the Software
will be compatible in every operating environment. It is your responsibility to ascertain whether the
Software is compatible with your operating environment.
5.2. The Software is sold without warranties as to its performance or merchantability. To the extent allowed by
law, Marshal disclaims all liability, whether in contract or tort, for any loss or damage arising from your use
of the Software. Such disclaimer applies to direct, indirect, special and consequential damages including loss
of profit, business revenue, goodwill, loss of production, loss of product, losses resulting from downtime of
your domain or email system, losses resulting from system crashes, loss of data or emails, or failure to
achieve anticipated savings or production efficiencies.
5.3. Marshal does not warrant that the Software is free of “bugs”, errors or defects. Marshal shall not be

Licensing Agreement i
 responsible to you for costs or damages incurred as a result of any such “bugs”, errors or defects. Marshal
does not warrant that the Software is error free and the existence of such errors shall not constitute a breach
of this Agreement. Marshal does not warrant that the Software will meet your requirements. Marshal
excludes, and expressly disclaims, all express and implied warranties of merchantability or fitness for
purpose.
5.4. Notwithstanding the above, Marshal warrants that the Software media supplied directly by Marshal is free
from defects in manufacture. This warranty does not apply to Internet downloads.
5.5. Marshal will replace any defective media at no charge subject to notification of the said defect within
90 days of the date that you acquired the Software from Marshal or its authorized reseller.
5.6. If the Software fails to operate in accordance with this warranty, you may, as your sole and exclusive remedy,
return the Software media and related documentation, along with a dated proof of purchase, specifying the
problem. Marshal shall either replace the Software or give you a full refund, at Marshal’s discretion.
5.7. Except for the limited warranty described above there are no warranties, either expressed or implied, for the
Software or documentation, which are licensed to you, “as is”.
5.8. Marshal’s maximum liability to you shall not, under any circumstance, exceed the license fees that you paid
in respect to the Software.
5.9. Some jurisdictions do not allow the exclusion of certain implied warranties or conditions, so the above
exclusions may not apply to you. This Agreement does not exclude any implied warranties or conditions that
may not under applicable law be excluded. This Agreement gives you specific legal rights, and is in addition
to any other legal rights that you may have under the laws of your jurisdiction. This Agreement does not
affect your statutory rights.
6. Other Services Excluded
6.1. The license fees do not cover the cost of: (i) Installation services; (ii) Networking services; (iii) Software
configuration and preference setting; (iv) Technical support and troubleshooting; (v) Maintenance services;
(vi) Training; (vii) Software “fixes” and updates; and (viii) Software upgrades. Contact Marshal if you
require any of these services.
7. Copyright
7.1. You acknowledge that the Software and documentation are the subject of copyright. You shall not, during or
at any time after the expiry or termination of this License, permit any act that infringes that copyright. You
expressly agree that you shall not copy the Software except for back-up purposes pursuant to §1.2.
7.2. This is a License to use the Software. It is NOT an agreement for the sale of the Software. Marshal
continues to own the Software. Your rights to use the Software are specified in this Agreement, and Marshal
retains all rights not expressly granted to you in this Agreement.
8. Term of License
8.1. This Agreement commences the moment you click or press the “ACCEPT” button during installation of the
Software. It shall continue until terminated by either party. You may terminate this License upon 90 days
notice to Marshal Software. Marshal Software may terminate this License if you breach any clause thereof
and fail to cure such breach within 30 days after notice thereof.
8.2. Upon termination, you or your representatives shall destroy the Software and documentation or otherwise
return or dispose of such material in a manner directed by Marshal.
9. Verification of Compliance
9.1. You hereby grant Marshal the right to enter your premises and to operate any computers at your premises in
order to verify that: (a) you are complying with your obligations in relation to the operation of the Software
on Designated Computers (or any other computers approved by Marshal) in accordance with §1.3; (b) the
number of users does not exceed the number of registered users in accordance with §1.5; (c) you are not
otherwise in breach of your obligations under this Agreement. Marshal may, at its option, make use of
license authentication logic that sends information on licensing to Marshal for the sole purpose of protecting
the Software against unauthorized use.
10. Governing Law
10.1 Except as otherwise expressly mandated by the relevant law in your jurisdiction, this Agreement shall be
governed by, and construed in accordance with, the substantive laws of New Zealand whose courts shall have
jurisdiction over all disputes which may arise in respect to this Agreement.

Marshal Software Ltd. P.O. Box 97639, S.A.M.C., Auckland, New Zealand
Tel: 64-9-261 2110, Fax 64-9-261 2112

ii Licensing Agreement
 Disclaimer

Important!
Read this manual before attempting to install, operate or maintain the Software.
It contains important installation, operating, maintenance and back-up
instructions. The user must strictly comply with them.
The information contained in this manual is given in good faith and is believed
to be true and correct at the time of publication. However, Marshal accepts no
liability for any errors or omissions.
Any opinions, recommendations or suggestions given do not constitute a
guarantee or warranty. The information in this manual does not constitute a
warranty of any particular benefits that the user will derive from the Software.
Information in this manual shall not be deemed a warranty, representation or
guarantee concerning the Software’s suitability or fitness for a specific purpose.
It is the user’s responsibility to determine the suitability of the Software for its
own use. The user must make its own independent judgment and assessment
and should not rely upon any opinions, interpretations, statements, assurances
or representations contained in this Manual.
Marshal has endeavored to provide timely information. Future Software
developments may materially change the information. Marshal reserves the
right to change the specifications of the Software, or the information in this
manual, without necessarily giving its users notice thereof.
The information in this manual is intended to provide general guidance to the
user. For specific guidance or support, contact a Marshal Software reseller.
Unless otherwise noted, a reference to brand names, product names and
trademarks constitutes the intellectual property of the owner thereof and no
right of use is granted thereby.
This manual does not grant any license to use the Software. Use of the
Software is subject to the terms and conditions in the Marshal Software
License. Read carefully the Marshal Software License before using the

Disclaimer iii
 Software.
Marshal has made every effort to explain the operating procedures as clearly
and completely as possible. Nonetheless, it is not possible to anticipate, nor
address, every conceivable problem that might arise from the use of the
Software. This problem is compounded by the fact that no two operating
environments are exactly the same.
Therefore, Marshal is not able to guarantee that this manual will address every
issue or problem that might arise concerning the use of the Software.
Furthermore, Marshal cannot represent that the information in this manual is
complete.
Use of the Software shall constitute acceptance of the above conditions and
limitations.
The example companies, organizations, products, people, and events depicted in
this Manual are fictitious. No association with any real company, organization,
product, person, or event is intended or should be inferred.

iv Disclaimer
 Comments or Suggestions

Comments or suggestions regarding this document or the software should be

directed in writing to

Marshal Software Ltd

PO Box 97 639 S.A.M.C.
19 Lambie Drive
Manukau City
Auckland
NEW ZEALAND

Telephone: 64-9-261-2110
Facsimile: 64-9-261-2112
Email: support@marshalsoftware.com or
sales@marshalsoftware.com

Web Home Page: http://www.marshalsoftware.com

http://www.mailmarshal.com

Comments or Suggestions v
 Table of Contents

Licensing Agreement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii
Comments or Suggestions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v
Table of Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
1. Introducing MailMarshal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1
What Does MailMarshal Do? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1
Where is MailMarshal Installed? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1
How Does MailMarshal Work? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2
Virus Scanning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3
Encrypted Email . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3
Online Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-4

2. Pre-Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1
Installation Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1
Hardware Required for MailMarshal Server . . . . . . . . . . . . . . . . . . . 2-1
Software Required for MailMarshal Server . . . . . . . . . . . . . . . . . . . . 2-1
Software Required for Other Components . . . . . . . . . . . . . . . . . . . . . 2-2
Email Routing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2
How MailMarshal Routes Email . . . . . . . . . . . . . . . . . . . . . . . . . 2-3
Setting up Outbound Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3
Setting up Inbound Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3
When Installing MailMarshal on the Existing Email Server . . . . . . . 2-4
Installation Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-5
Gathering Information Before Installation . . . . . . . . . . . . . . . . . . . 2-7

3. Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1
Procedures to Install MailMarshal Server . . . . . . . . . . . . . . . . . . . . . . 3-1
Installation Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2
Configuring an Existing Email Server . . . . . . . . . . . . . . . . . . . . . . 3-11
MailMarshal and Microsoft Proxy Server 2.0 . . . . . . . . . . . . . . . . . 3-11
MailMarshal Console Installation . . . . . . . . . . . . . . . . . . . . . . . . . . 3-12

Table of Contents vii

 Console Security Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-13
MailMarshal Configurator Remote Installation . . . . . . . . . . . . . . . 3-13
Uninstalling MailMarshal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-14
Importing a MailMarshal Configuration . . . . . . . . . . . . . . . . . . . . . . 3-15

4. The Configurator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1

MailMarshal Configurator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2
Server Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2
Rulesets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3
User Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3
POP3 Accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3
Virus Scanners . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3
External Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-4
Folders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-4
Email Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-4
TextCensor Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-4
Logging Classifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-4
Message Stamps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-4
LDAP Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-5
News and Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-5

5. Rulesets and Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1

Best Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1
Viewing and Printing Rulesets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2
Creating a Ruleset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2
Editing a Ruleset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-4
To Copy or Move Rules Between Rulesets . . . . . . . . . . . . . . . . . . . . 5-5
To Enable or Disable a Ruleset . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-5
Order of Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-5
Adjusting the Order of Evaluation of Rulesets . . . . . . . . . . . . . . . . . 5-5
Adjusting the Order of Evaluation of Rules . . . . . . . . . . . . . . . . . . . 5-5
Creating a New Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-6
Copying a Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-7
Editing a Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-8
User Matching Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-8
Rule Conditions–Standard Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 5-10
Rule Actions–Standard Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-15
Rule Conditions–Receiver Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-19
Rule Actions–Receiver Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-19

viii Table of Contents

6. User Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1
To Create a New Standard User Group . . . . . . . . . . . . . . . . . . . . . . 6-1
To Add Members to a Standard User Group . . . . . . . . . . . . . . . . . . 6-1
To Add an LDAP User Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1
To Move and Copy User Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3

7. POP3 Accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1

To Set Up POP3 Accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1
POP3 Accounts for Relaying Authentication . . . . . . . . . . . . . . . . . . 7-2
To Edit POP3 Accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-3
To Delete POP3 Accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-3

8. Virus Scanners . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-1

Best Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-2
Configuring a New Virus Scanner . . . . . . . . . . . . . . . . . . . . . . . . . . 8-2
Viewing Virus Scanner Properties . . . . . . . . . . . . . . . . . . . . . . . . . . 8-3
Using Other Virus Scanners . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-5
Testing Virus Scanners . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-5
MailMarshal Directories and Resident Scanning . . . . . . . . . . . . . . . . 8-6

9. External Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-1

Uses of External Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-2

10. Folders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1

Creating a New Folder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1
Standard Folders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2
Parking Folders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2
Editing an Existing Folder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-3
Changing the Default Folder Location . . . . . . . . . . . . . . . . . . . . . . 10-3
Folder Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-4

11. Email Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-1

Creating an Email Template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-1
Duplicating an Email Template . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-3
Editing an Email Template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-3
Deleting an Email Template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-3

12. TextCensor Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-1

TextCensor Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-1
Weighting the Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-2
Adding a TextCensor Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-3
Editing a TextCensor Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-4

Table of Contents ix
 Duplicating a TextCensor Script . . . . . . . . . . . . . . . . . . . . . . . . . . 12-5
Importing a TextCensor Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-5
Exporting a TextCensor Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-6
Using TextCensor Effectively . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-6
Constructing TextCensor Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . 12-6
Decreasing Unwanted Triggering . . . . . . . . . . . . . . . . . . . . . . . . . 12-7

13. Logging Classifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-1

Creating a Logging Classification . . . . . . . . . . . . . . . . . . . . . . . . . . 13-1
Editing a Logging Classification . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-2
Duplicating a Logging Classification . . . . . . . . . . . . . . . . . . . . . . . 13-2
Deleting a Logging Classification . . . . . . . . . . . . . . . . . . . . . . . . . . 13-2
Logging Classification Usage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-2

14. Message Stamps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-1

Creating a New Message Stamp . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-1
Duplicating a Message Stamp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-2
Editing a Message Stamp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-2
Deleting a Message Stamp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-2

15. LDAP Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-1

What is LDAP? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-1
Adding a New LDAP Server Connection . . . . . . . . . . . . . . . . . . . . . 15-1
Editing an LDAP Server Connection . . . . . . . . . . . . . . . . . . . . . . . 15-5
Deleting an LDAP Server Connection . . . . . . . . . . . . . . . . . . . . . . 15-5

16. Server Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-1

General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-2
Delivery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-3
Dial-Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-4
Mail Batching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-5
Local Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-8
To Create a New Local Domain . . . . . . . . . . . . . . . . . . . . . . . . . 16-9
To Edit a Local Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-10
Wildcards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-10
Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-11
Anti-Relaying . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-12
License Info . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-14
Advanced . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-17
Change Folders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-17
Export Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-18

x Table of Contents
 Import Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-18
Server Threads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-19
Enable RTF Stamping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-20
Server Array . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-20
Blocked Hosts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-20
Host Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-21
MAPS Lookups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-22
DNS Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-23
Header Rewrite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-24
Field Matching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-26
Substitution Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-26
Substitution Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-27
Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-29
Regular Expression Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-29

17. Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-1

Installing MailMarshal Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-1
To Produce Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-2

18. The Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-1

Connecting to the MailMarshal Server . . . . . . . . . . . . . . . . . . . . . . 18-1
Console Security Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-2
The Main Console Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-3
The Services Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-4
Receiver State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-4
Sender State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-5
Sender Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-5
Domain Detail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-6
Message Folders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-6
Message Folder Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-7
Forwarding a Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-7
Deleting a Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-7
Processing a Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-8
Viewing a Message and Message Log . . . . . . . . . . . . . . . . . . . . . . 18-9
Interpreting Message Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-10
Mail History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-11
Alert History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-12
News and Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-12

19. MailMarshal Secure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-1

What is S/MIME? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-1

Table of Contents xi
 Options for Using MailMarshal Secure . . . . . . . . . . . . . . . . . . . . . . . 19-2
Installing MailMarshal Secure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-2
Setting Up S/MIME Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-4
Working with Domain Certificates . . . . . . . . . . . . . . . . . . . . . . . . 19-4
Backing Up Certificates and Keys . . . . . . . . . . . . . . . . . . . . . . . . 19-12
Protect the Certificates Folder . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-12
Exchanging Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-13
Checking Imported Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . 19-13
Basic Security Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-13
Rule Conditions–Security Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 19-15
Rule Actions–Security Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-17

20. Case Studies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-1

SmartCo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-1
Protecting Against Viruses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-2
Conserving Network Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-3
Ensuring Appropriate Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-4
Reducing Legal Liability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-4
Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-5
Company Name Change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-5
Encrypted Email . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-6
Multiple Gateway-to-Gateway Encryption Partners . . . . . . . . . . . . . 20-7
Gateway-to-Desktop Encryption Partners . . . . . . . . . . . . . . . . . . . 20-7
Blocking Spam. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-8
Email Aliases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-9

21. Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21-1

MailMarshal Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21-1
Windows NT Event Viewer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21-1
MailMarshal Working Directories . . . . . . . . . . . . . . . . . . . . . . . . . . 21-1
MailMarshal Message Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21-2
MailMarshal Log Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21-2
Running MailMarshal in Debug Mode . . . . . . . . . . . . . . . . . . . . . . 21-3
Some Common Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21-3
Error 2140 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21-3
Unable to Determine the Domain . . . . . . . . . . . . . . . . . . . . . . . . . 21-3
Moving MailMarshal to a New Server . . . . . . . . . . . . . . . . . . . . . 21-4
Further Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21-4

22. MailMarshal and the MMC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22-1

Configurator and Console in the Same MMC . . . . . . . . . . . . . . . . 22-1

xii Table of Contents

Appendix A: Other Email Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1
Configuring Microsoft Exchange 5.5 . . . . . . . . . . . . . . . . . . . . . . . . . A-2
Exchange 5.5 and MailMarshal on Separate Machines . . . . . . . . . . A-2
Exchange 5.5 and MailMarshal on The Same Machine . . . . . . . . . . A-3
Configuring Lotus Notes 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-4
Lotus Notes 4 and MailMarshal on Separate Machines . . . . . . . . . . A-4
Lotus Notes 4 and MailMarshal on The Same Machine . . . . . . . . . A-5
Configuring Lotus Domino R5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-6
Lotus Domino R5 and MailMarshal on Separate Machines . . . . . . . A-6
Lotus Domino R5 and MailMarshal on The Same Machine . . . . . . . A-6

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-1

Table of Contents xiii

 1. Introducing MailMarshal

MailMarshal is an Email Content Security application for organizations.

The purpose of MailMarshal is to enforce an organization’s Acceptable Use
Policy for email. Such a policy typically regulates what content can be sent in
and out of the organization by email. A policy may also call for disclaimers or
other official message stamps, archive copies of messages, and encryption of
sensitive email, as well as controls on the size or volume of email allowed.
Protection against email transmission of viruses and other harmful material is an
additional goal in most cases.

What Does MailMarshal Do?

MailMarshal scans the content of messages and attachments as they enter or
leave the organization. It can scan lexical content (such as subject lines, message
text and attached documents). It can also determine the structure and size of
messages and attachments. MailMarshal also allows scanning for viruses using
third-party virus scanners.
Based on the result of these scans, many actions may be performed. These
include blocking or quarantining of messages, making copies, stripping of
attachments, sending notifications, adding disclaimers, and many others.
An optional module, MailMarshal Secure, allows signing, encryption and
decryption of email messages using the S/MIME standard.

Where is MailMarshal Installed?

MailMarshal is a server-based SMTP (Simple Mail Transfer Protocol) email
content scanner that can be easily installed into a new or existing network with
other gateway applications. It complements, and is compatible with, traditional
Internet firewalls, SMTP mail servers, anti-virus and security applications. The
only pre-requisite is that MailMarshal must reside on a Windows NT 4.0 or
2000 Server. MailMarshal consists of several pieces of software–the Server,
Configurator, Console and Reporting Database.

Introducing MailMarshal 1-1

 The MailMarshal Server software is installed as the email gateway of an
organization. All email entering or exiting the organization passes through it.
Depending on local needs, MailMarshal may be installed on the same physical
machine as a corporate email server product (such as Microsoft Exchange), or
on a separate machine. It may also be installed as a standalone POP3 email
server for small to medium sized organizations.
The Configurator is installed on the same machine as the MailMarshal Server
software, and can also be run from a remote workstation. This module allows
setup of the basic connections required to use MailMarshal. It also allows
configuration of email processing rules and components, such as virus scanners
and TextCensor scripts.
The flow of email through MailMarshal is monitored using the Console, which
can be installed on the email administrator’s workstation. Through the Console
MailMarshal’s logs can be examined, and blocked items can be released if
necessary.
MailMarshal can log email activity to a SQL Server database, and use the
information to produce detailed reports. The reporting suite, using Microsoft
Access, can be installed on any workstation.

How Does MailMarshal Work?

MailMarshal is an SMTP gateway and is compatible with any SMTP email
server on any platform, eg. Microsoft Exchange, Sendmail, Novell Groupwise
or Lotus Notes. Where the existing email server software is a Windows NT
application, in most circumstances MailMarshal can reside on the same physical
server. Full details of installation scenarios are given in the chapter Pre-
Installation.
The MailMarshal Server consists of four major system services: the Receiver,
Engine, Sender, and Controller. All email entering or leaving an organization
enters the MailMarshal Server software via the Receiver, and is processed in the
Engine. The Engine unpacks each email message (unzipping archive or
compressed files if necessary) and splits the message into its individual
components. It then tests the whole message and each component against the
Rules that have been set up in the Configurator.
Rules are composed of three parts: User Matching, Conditions, and Actions.
Details of rule configuration are given in the chapter Rulesets and Rules.
User Matching criteria allow filtering of messages by the sender and recipients.

1-2 Introducing MailMarshal

Other Conditions may match based on the header information, text content of
the message and attachments, attached file types, message size, virus check by a
third-party virus scanner, and other criteria.
Based on the results of User Matching and Condition testing, the email
message is accepted, modified or quarantined. Accepted email is passed to the
MailMarshal Sender, which then forwards it to the appropriate recipients.
Messages may be stamped with a notice and/or stripped of objectionable
attachments. Quarantined messages are placed into one of several folders
defined for that purpose. They may be retrieved by the email administrator
(using the Console) for examination or re-processing.
Messages which cannot be unpacked or delivered are directed to special
DeadLetter folders.
Where MailMarshal takes action on a message, notifications or copies of the
original message may be sent as required. These messages can be customized;
see the chapter Email Templates.
All MailMarshal server activities are logged in detail to a text file. The relevant
log may be appended to a notification message.

Virus Scanning
MailMarshal invokes other vendors’ virus checking software to detect viruses. A
number of commercially available scanners have been tested and shown to
work with MailMarshal. For full virus protection, a licensed version of a virus
scanner should be installed and its virus definition files kept up to date.
MailMarshal can use multiple virus scanners to provide extra protection.
Information on virus scanner configuration appears in the chapter Virus
Scanners.
Because many email viruses are associated with known message text or file
types, MailMarshal can also block viruses using these criteria. Where best
security practices are followed to block suspicious files, MailMarshal can often
stop new viruses before scanner updates arrive.

Encrypted Email
MailMarshal Secure is an optional module of MailMarshal that provides for
server-based handling of encrypted messages. MailMarshal Secure uses the
S/MIME (Secure MIME) standard for Public Key Encryption. MailMarshal
Secure can communicate securely with any other encryption product that uses

Introducing MailMarshal 1-3

 the S/MIME standard; communication is not limited to MailMarshal sites.
Where MailMarshal Secure is not installed (or the appropriate encryption key is
not available), MailMarshal will recognize the message as encrypted but will be
unable to access the message contents. Such messages may be blocked or
passed through according to local policy.

Online Help
MailMarshal provides online help for assistance during installation and use of
the software. Help is accessed through the Help menu or by pressing the [F1]
key.
Extended up-to-the-minute support is available on the Marshal Software
website. The website at http://www.marshalsoftware.com features news, a
support Knowledge Base and Forum, and maintenance upgrades.

1-4 Introducing MailMarshal

 2. Pre-Installation

Installation Planning
MailMarshal consists of several components, which may be located on different
machines within an organization’s network. The components are:
• MailMarshal Server
• MailMarshal Configurator
• MailMarshal Console
• MailMarshal Reports
The MailMarshal Server software must be installed under Windows NT 4.0 or
Windows 2000. All other components may be installed under Windows 95 or
higher, or Windows NT/2000.

Hardware Required for MailMarshal Server

MailMarshal will run on almost any Pentium-class machine. Hardware
requirements naturally vary depending on the number of email users and the
amount of email traffic. The following minimum specifications are suggested
as a guideline:
• 250 users: Pentium 166, 1GB HD, 64MB RAM
• 5000 users: Pentium III 500, 10 GB HD, 128MB RAM
Sites with more than 5000 users may require enhanced hardware. MailMarshal
fully supports multi-processor computers for very high traffic sites. Please
contact Marshal Software for a recommended configuration.

Software Required for MailMarshal Server

Note
The following software can be installed during setup if necessary (if installing
from the CD-Rom). As this may require several restarts, installing the
prerequisite software before installing MailMarshal is recommended.
• Windows NT 4.0 Service Pack (SP) 4 or above–if not found, SP 6a will be

Pre-Installation 2-1
 installed (however, MailMarshal Secure requires 128 bit SP 6a, or Windows
2000 with the High Encryption pack–included in SP 2).
• Microsoft Management Console 1.2.
• Microsoft ActiveX Data Objects (ADO) 2.5.
• SQL Server 7.0–if not available, Microsoft Data Engine (MSDE) can be
installed. MSDE is a free runtime version of SQL Server. SQL 7.0 Service
Pack 2 is recommended for installation on either SQL Server or MSDE.
• Internet Explorer (IE) 5.01 or above (IE 5.5 is included on the MailMarshal
CD-Rom).
Note
MailMarshal must be installed on a NTFS partition. MailMarshal Secure
requires SQL 7.0 or MSDE to be available on the local system. Due to the
limitations on database size in MSDE, SQL Server is recommended for sites
over 500 users in size.

Software Required for Other Components

MailMarshal Configurator and MailMarshal Console may be run under
Windows 95 or above, or Windows NT/2000. They require the Microsoft
Management Console (MMC) 1.2, Microsoft Internet Explorer 5.01 or above,
and (if run on Windows 95/98) the Remote Registry Service.
MailMarshal Reports requires Microsoft Access 97 or 2000 (only on the
workstation where Reports will be run).

Email Routing
Internet email travels from server to server using SMTP (Simple Mail Transfer
Protocol). MailMarshal functions as a SMTP relay. Logically, MailMarshal is
situated on the local network so that email entering or leaving the organization
is routed through it. Physically, MailMarshal Server can be installed in several
scenarios. It may share a computer with other software or be run on a
dedicated computer. Before installing MailMarshal it is necessary to determine
which functions MailMarshal will serve and how it will handle incoming and
outgoing email.
In general, SMTP email servers may route email in four ways:

2-2 Pre-Installation
1. By delivering a message to a “local user” (another user on the same
server).
2. By sending email for a specific domain (eg. wellknown.com) to a fixed
address entered by the administrator.
3. By sending all outbound email to a specific server (email relay).
4. By performing a Domain Name Service (DNS) lookup to determine the
appropriate email server for a domain, and attempting to contact that
host directly.

How MailMarshal Routes Email

MailMarshal can use any of the four methods described above.
• If MailMarshal has been configured as a POP3 server, the POP3
mailboxes are “local” to it.
• MailMarshal uses the term “Local Domains” to name the specific domains for
which MailMarshal functions as the Internet email gateway. The local
domains should include all of the domains hosted by other email servers
within the organization (such as Exchange or Groupwise servers). Messages
for these domains will be delivered to fixed addresses.
• Where the address does not match any local domain, MailMarshal can be
configured to deliver it either using DNS or by relaying to a specific
downstream host for delivery.

Setting up Outbound Routing

Take note of how the existing email server sends email to the Internet. In
general MailMarshal should be configured to use the same process. For
instance, email may be delivered to a firewall or ISP (email relay), or directly
using DNS.
The existing email server must be reconfigured to forward all outbound
Internet email to MailMarshal.

Setting up Inbound Routing

Determine how inbound email is currently delivered to your server. If the
MailMarshal server retains the IP address and server name of the previous
email server (eg. if MailMarshal is installed on the same physical server as the
other email server software), then no change to inbound settings will be
required.

Pre-Installation 2-3
 If the MailMarshal server will have a different IP address and server name, in
most cases the route must be changed to ensure that inbound email messages
are sent to the MailMarshal server.
Before sending email messages to your organization, an email server on the
Internet performs a DNS lookup to see which server (IP address) accepts email
for your domain. The address returned may be that of your email server,
firewall, proxy server or a downstream email relay (eg. an ISP).
If email messages were formerly sent directly to your organization’s email
server (ie. the DNS MX lookup returned the email server’s IP address), then the
DNS MX record should be changed to the IP address of the new MailMarshal
machine. Firewall permissions may also require modification to permit SMTP
delivery to MailMarshal.
If the DNS lookup returns the address of the firewall, and the firewall employs
address translation, the translated address for incoming email must be changed
to the address of the MailMarshal machine. If the firewall acts as an email
relay, then the address to which it forwards inbound email must be changed to
that of the MailMarshal machine.
If the DNS lookup returns the address of an upstream email relay, then the
forwarding address setting used by that email relay should be changed to that of
the new MailMarshal machine.

When Installing MailMarshal on the Existing Email Server

When MailMarshal is installed on the same machine as the existing email server
software, normally no changes to the inbound routing are required. However,
as MailMarshal will take over the role of listening for SMTP traffic on port 25,
the existing email server must be configured to listen for SMTP traffic on
another port (port 97 is usually available, but any free TCP port will do).
MailMarshal should be configured, via its Local Domains information, to
forward all inbound email messages to the local machine on the new port. It is
recommended that you use the localhost IP address 127.0.0.1.
The existing email server should be configured to forward all outbound email
messages to the local machine (127.0.0.1) on port 25.

2-4 Pre-Installation
Installation Scenarios
MailMarshal can be installed in a variety of scenarios. More detailed
instructions and some examples are given in the chapter Installation.
1. On its own physical server, as an email relay within an organization (see
Figure 2.1). In this example, all email sent from within the organization
should be delivered to the email server. The email server forwards all
external messages to the MailMarshal server for processing and delivery.
The DNS MX record (or the firewall’s relay setting) is also set to deliver
all inbound email to the MailMarshal server.

Workstation
SMTP SMTP
Port 25 Port 25
Firewall

Internet

Workstation
MailMarshal Server Email Server

Workstation

Email Admin

Figure 2.1: Typical MailMarshal separate server installation

2. As a standalone POP3/SMTP server for a small organization (see Figure

2.2) In this example, all email sent from within the organization should
be sent to the MailMarshal server on port 25 for processing. Email for
internal addresses will be delivered to MailMarshal’s POP3 boxes for
collection by email clients. Email to and from external addresses is
delivered over a dial-up or other link to an ISP.

Pre-Installation 2-5
 Workstation
SMTP Port 25
Dialup
POP3 Port 110
connection

Internet

Workstation
MailMarshal
Server
ISP

Workstation

Email Admin

Figure 2.2: MailMarshal as a standalone POP3/SMTP server

3. On the same physical server as the organization’s email server software

(see Figure 2.3). All email sent from outside the organization should be
delivered to the email server computer on port 25. MailMarshal
forwards processed inbound email to the other server software using the
“localhost” IP address and port 97. The other server sends email for
outside delivery to MailMarshal at “localhost” port 25.

MailMarshal Workstation
Port 25
Firewall

Localhost
Localhost
Port 25
Internet Port 97

Other Email Port 97

Software Workstation

Email Server
Computer

Workstation

Email Admin

Figure 2.3: MailMarshal and another email server on the same computer

2-6 Pre-Installation
4. On a separate computer in a DMZ (see Figure 2.4). The advantage of
DMZ installation is that all messages must pass through the firewall
twice–there is no direct access through the firewall.
This is a variation on scenario #1. If the administrator Console is
required to communicate with the MailMarshal server from the internal
network, TCP port 19001 must be opened in the firewall. Use of the
logging/reporting function from the internal network will require TCP
port 1433 to be opened.
Note
Direct Configurator access through a firewall is not recommended since this
would require opening additional NetBios ports. If access through a firewall
is required, use of a remote access tool such as Microsoft Terminal Server is
recommended.

Workstation

Internet Firewall

TCP Workstation
Port
25
Port Email Server
19001

Workstation

MailMarshal Server
Email Admin

Figure 2.4: MailMarshal in a DMZ

Gathering Information Before Installation

Before beginning installation of MailMarshal, information about the
environment should be gathered. A basic list of required information is given
below. A more detailed MailMarshal Pre-Install Guide is available on the
Marshal Software website (http://www.marshalsoftware.com) under
Support|Documentation.

Pre-Installation 2-7
 • The organization’s Internet domain name (eg. ourcompany.com).
• Names of any other local domains for which MailMarshal will process email
(eg. oursubsidiaries.com).
• The IP address of the existing local email server.
• The administrator’s email address.
• The virus scanning software (with an appropriate license) to be used with
MailMarshal.
• The IP addresses of DNS servers.
• Who provides DNS? What is the lead time to alter settings, if necessary?
• Are all prerequisites present? (If not, system restart may be required to install
them.)
• Is a Firewall in use? If so, who administers it and what is the lead time to
change settings, if necessary?
• What is the outbound email delivery method now in use?
• What is the inbound email delivery method–will any changes be required?

2-8 Pre-Installation
 3. Installation

The MailMarshal Installation process consists of two parts: installation of the

software and any prerequisites onto the server, and configuration of the
software to send and receive email.
Installation optionally includes setting up the MailMarshal Reports database,
which stores usage information.
After installation and configuration, Rules must be customized to implement
the desired policies.
The MailMarshal Server, Configurator, Console, and Reports may be installed
on different computers. The Configurator and Console will always be installed
on the MailMarshal server computer, but may also be installed elsewhere.
This chapter assumes that decisions have been made as to where in the network
MailMarshal will be installed, and how email will be forwarded. Several typical
installation scenarios are presented in the chapter Pre-Installation.

Procedures to Install MailMarshal Server

Preliminary Steps:
1. Log on to the server as a user with administrative privilege. Insert the
MailMarshal disk into the server CD-Rom drive and select Install
MailMarshal 4.2. Or, run the downloaded MailMarshal Installer file.
2. Carefully read the information given on the screens Welcome to
MailMarshal Setup, Marshal Software License Agreement, and Important Pre-
Installation Information. By clicking Yes on the Software License screen, you
accept the terms of the License. (The License is printed in the front of
this manual for more convenient reading.)
3. In the Select MailMarshal Setup Type dialog, select the desired installation
option, then click Next. In the following dialogs, choose the destination
location and the program folder.

Installation 3-1
 Note
MailMarshal must be installed on a NTFS partition. MailMarshal Secure
requires SQL 7.0 or MSDE to be available on the local system.
4. Review the information in the Start Copying Files dialog. If it is correct,
click Next to start installation.
5. When the MailMarshal Setup Complete dialog appears, choose whether or
not to launch the Configurator. You must run the Configurator to
complete the installation.

Installation Wizard
When the MailMarshal Configurator is first run, MailMarshal launches a wizard
which requests the configuration information needed to complete installation.
For more information on configuration options, please refer to the chapter
Server Properties later in this manual. The Wizard process includes the following
steps:

1. License Key
Enter your company name in the first field (see Figure 3.1). Enter your
License Key, provided by Marshal Software or your local Marshal
Software reseller, in the second field. If you do not have a License Key,
click the URL link provided to connect to the Marshal Software web site.
Complete the MailMarshal Trial Key Request form; a trial key will
immediately be emailed to the address you specify.
Click Next. An information box will report the validity details of the key
you entered.

2. Local Domains
This dialog specifies the names of local domains for which MailMarshal
will accept inbound email (see Figure 3.2). The list should include all
(and only) the domains of email addresses your organization actually
uses through this gateway. (The Local Domains list should exactly match
the DNS MX records pointing at this server.)

3-2 Installation
 Figure 3.1: Installation Wizard–Key

Local domains may be of two types: Relay and POP3. Email for a relay
domain is sent on to another email server. Email for a POP3 domain is
delivered to a mailbox hosted by the MailMarshal server. Most often
there will be a single entry in this section for the local email server.
However, if the email server handles more than one domain, multiple
entries may be needed. Note that all relay servers defined here will also be
allowed to relay outbound email through MailMarshal.
Note
If POP3 service for a domain is already provided by other software (such as
Microsoft Exchange), that domain should be configured as a Relay domain in
MailMarshal.
Click New to start the New Local Domain Wizard. Choose whether
MailMarshal will host any POP3 mailboxes for the domain. In the final
screen, enter the domain name. Enter the IP address of the server to
which email should be relayed. Optionally enter a second email server
address (used only as a fail-over if the first server does not respond).

Installation 3-3
 If this is a POP3 domain, choose the action to be taken for
undeliverable messages.
Click Finish to return to the Local Domains dialog.

Figure 3.2: Installation Wizard–Local Domains

Multiple Relay local domains may be entered using wildcards (eg.

*.ourbusiness.com may be entered to direct email for all subdomains of
ourbusiness.com to a single address). See the section Wildcards in Server
Properties for a description of MailMarshal’s wildcard syntax.
Note
MailMarshal’s permanent License Keys are bound to the list of local domains
specified in this list. Each time the list of domain names changes, a new key
is required. Changes in IP addresses or ports, or between relay and POP3
domains, do not require a new key. See the section License Info in Server
Properties for information on requesting a new key.
Repeat the New Local Domain Wizard for each local domain required.
When all domains have been entered, adjust the order of matching by

3-4 Installation
 highlighting a domain from the list and using the up and down arrows.
Note
Ensure that local domains are matched in the correct order;
otherwise email may be misdirected. Eg. if the (incorrect) sequence is
*.example.com Relay 10.1.2.1:25
pop.example.com POP3 10.2.5.4:25
POP3 mailboxes will be ignored and all email will be delivered to the first
address, ie. 10.1.2.1 port 25, because *.example.com will match for messages
addressed to pop.example.com. In this example, to have the email correctly
delivered, pop.example.com should be the first domain in the sequence.

3. General
Administrative notifications (such as DeadLetter reports) will be sent to
the address specified in the first box (see Figure 3.3). This should be a
valid and appropriate mailbox or group alias. Administrative and user
notifications and other automated email from MailMarshal will be sent
“from” the address entered in the second box.

Figure 3.3: Installation Wizard–General

Installation 3-5
 4. Delivery

The primary DNS (Domain Name Server) address used by the

organization must be entered, and a secondary address is recommended
(see Figure 3.4). These servers should be located no further away than
the ISP.
By default MailMarshal will attempt to deliver outbound email directly,
using DNS resolution to determine the appropriate destination.
However, if all outbound email is forwarded to a firewall or a fixed relay
server (such as an ISP), then select the appropriate radio button and
enter the host name or IP address of the relay or firewall.

Figure 3.4: Installation Wizard–Delivery

3-6 Installation
5. Dial on Demand

See Figure 3.5. If outbound email is to be delivered over a dial-up

connection, check the box and fill in the appropriate information
(otherwise proceed to the next page). Select a RAS entry from the drop-
down list, or click on New Phonebook Entry to add the desired
information. Fill in other information as appropriate. The correct
settings should be obtainable from existing email server settings or from
your ISP.

Figure 3.5: Installation Wizard–Dial on Demand

6. Mail Batching

See Figure 3.6. MailMarshal supports batch receipt and delivery of email
messages where on-demand connection to the upstream email server is
not desired (eg. due to cost). If this feature is to be used, check the box
and fill in the appropriate information. The correct settings should be
obtainable from existing email server settings or from you ISP. For
detailed discussion of these settings see Mail Batching in Server Properties.

Installation 3-7
 Figure 3.6: Installation Wizard–Mail Batching

7. Reports

See Figure 3.7. MailMarshal can log details of the processing and
delivery status of messages to a database. When logging has been
enabled, the Mail History can be viewed in the Console and a wide
variety of reports run from MailMarshal Reports.
To enable logging, check the Enable Report Logging checkbox. Check the
Log Attachment Details checkbox to enable reporting on attachments
within email messages.

3-8 Installation
 Figure 3.7: Installation Wizard–Reports

Click Create/Select Database to choose the location of the SQL database

where the information will be stored. In the Create/Select Database dialog
(Figure 3.8), enter the name of the SQL Server (or MSDE) computer in
the first box. You can browse the network if necessary. Enter the name
of the database you wish to use, and the SQL user name and password.
(The default user “sa” does not normally require a password.) If you
believe that a MailMarshal database has previously been installed in the
given location and you wish to overwrite it, check the box to recreate the
database.
Note
The database password may be changed using SQL administration tools or
command-line SQL entry. However this procedure must be used with
caution if other applications may be using the database. For further
information please see Marshal Software Knowledge Base article KB203.

Installation 3-9
 Figure 3.8: Installation Wizard–Create/Select Database dialog

8. Finished

Basic configuration of the MailMarshal Server is now complete. The

MailMarshal Configurator starts automatically on completion of the
Wizard.
Changes to the configuration may be made through the Tools|Server
Properties menu in the Configurator. Several advanced selections are also
available in that menu. For complete information see the chapter Server
Properties.
Before MailMarshal can be put into production, the following steps
should be taken within the MailMarshal Configurator:
1. Configure virus scanners within MailMarshal, if desired. Most
installations use a virus scanner. See the chapter Virus Scanners.
2. Customize Rulesets and enable Rule processing. See the chapter Rules
and Rulesets.
3. Start MailMarshal Services.
The following additional steps may be required:
1. Configure an existing email server to pass email through MailMarshal.
2. Install and configure third party virus scanning software.

3-10 Installation
Configuring an Existing Email Server
Typically MailMarshal receives inbound email, processes it, then relays it to the
organization’s internal email server as specified in the Local Domains list.
Outbound email is passed from the internal email server to MailMarshal for
processing and external delivery. See the chapter Pre-Installation for a variety of
installation scenarios.
The internal email server software must be configured to send outgoing email
to MailMarshal for processing and delivery.
Where MailMarshal is installed on the same computer as the existing email
server software, the two applications must use different “ports” to receive email
In this case, the following steps are typically necessary:
• As the MailMarshal receiver is now accepting SMTP traffic on port 25, change
the SMTP port that the other email server uses for SMTP (port 97 is usually
available, although any free TCP port will do).
• Configure the other email server software to forward all Internet email to the
local machine (use the “localhost” IP address 127.0.0.1, port 25).
• Check that MailMarshal is configured, via its Local Domains information, to
forward all inbound email to the local machine on the alternative port (again,
use the localhost IP address and port, eg. 127.0.0.1:97).
Specific details for configuring Microsoft Exchange 5.5 and Lotus Notes 4 and
5 are given in Appendix A. For more detailed information, and to configure
other email server software, please refer to the product documentation for the
other software. The Marshal Software Knowledge Base also contains some
additional setup information.

MailMarshal and Microsoft Proxy Server 2.0

Where MailMarshal is installed in the same network as Microsoft Proxy Server
2.0, there are two possible scenarios:
• MS Proxy routes incoming connection requests through to the email server.
In this scenario the email server has Winsock proxy client installed on it and
there is a wspcfg.ini file in the MailMarshal install directory.
• MailMarshal (or an email relay or gateway to the MailMarshal server) is
installed on an MS Proxy Server.
Each scenario has a range of MailMarshal installation options.
MailMarshal can be installed on the same machine as Microsoft Proxy Server

Installation 3-11
 and could replace an existing email relay or gateway, or may be installed in
parallel. If WinSock Proxy Client was used by the email server it is no longer
needed, as MailMarshal will relay messages to and from the email server.
Alternatively, MailMarshal may be installed on a separate machine with two
network cards and be used to route email from the Internet to the email server.
In this case, email is no longer routed via Microsoft Proxy Server.
MailMarshal may also be installed on a machine “inside” the proxy server (on
the trusted network) when the proxy server has two network cards. This
scenario will require use of WinSock Proxy Client in order to communicate
with the Internet. Ensure that an appropriate wspcfg.ini is created in the
MailMarshal installation directory to bind the MailMarshal receiver to the
external interface of the proxy server. More information on MailMarshal and
MS Proxy 2.0 is available in Marshal Software Knowledge Base article KB31.
Note
Microsoft Proxy can be configured to implement security at user level.
Where this has been done, MailMarshal should initially be configured to run
under the same user account as your existing email server, email relay or
gateway.

MailMarshal Console Installation

The MailMarshal console provides day-to-day administrative access to the
MailMarshal server and email stream, including a real-time view of email
processing and management of rejected and quarantined messages. The
console is installed automatically on the MailMarshal Server when a server
install is performed. If the MailMarshal Console software is to be used on any
other machine it must also be installed on that machine. It may be installed
directly from the MailMarshal CD-ROM or from an install folder copied from
the CD-ROM. See the chapter Pre-Installation for a list of software prerequisites
for the Console.
To install the MailMarshal Console:
• Log in with sufficient access rights to install software onto the local machine
and to access the install folder for MailMarshal.
• Run the MailMarshal installation program or setup.exe to install the
MailMarshal Console software.
• Under Setup, choose Custom/Complete, then Console.
• Run the newly installed software.

3-12 Installation
• If the MailMarshal Server is not running on the same machine, a Change Server
dialog box will prompt for the IP Address or name of the MailMarshal Server
machine. This dialog box can be reached at any time by right-clicking on the
MailMarshal Console folder in the Console menu tree.
Configuration information for MailMarshal Console is stored in the client
machine registry.
Note
Whenever you update or upgrade the MailMarshal Server you must
also upgrade the Console on remote machines.

Console Security Issues

MailMarshal Console uses Windows NT’s secure RPC mechanism to
communicate (via TCP port 19001) with the MailMarshal Server. A console
user must have an account and password that can be validated by the
MailMarshal Server. If the MailMarshal machine is in a different domain you
can either set up a trust relationship or create local accounts on the
MailMarshal Server computer. If the Console and the Server are separated by a
firewall (eg. if the Server is located in a DMZ), port 19001 must be opened in
the firewall to allow remote Console access.
To view the messages in the quarantine folders the account in use must have
read access to the folders. If you wish to make changes to items (eg. forward
email, kill messages) the account will also need write access. Access to the
folders should be limited by using Windows NT security.
To implement access control for other features, edit the access permissions on
the MailMarshal.key file (in the MailMarshal folder on the server). Read access
to this file allows the user to view the service status, queued domains and mail
history. Write access to this file gives the ability to kill messages, dial now, retry
domains and reload services.
Note
For details on changing the Console communication to another port, contact
Marshal Software support.

MailMarshal Configurator Remote Installation

The MailMarshal Configurator software provides access to all setup functions
for MailMarshal, including server configuration and setup of Rules and Rule
elements. The Configurator is installed automatically on the MailMarshal

Installation 3-13
 Server when a server install is performed. If the MailMarshal Configurator
software is to be used on any other machine it must also be installed on that
machine. It may be installed directly from the MailMarshal CD-ROM or from
an install folder copied from the CD-ROM. See the chapter Pre-Installation for a
list of software prerequisites for the Configurator.
Note
It is not recommended to connect the Configurator to the MailMarshal
Server through a firewall, as additional NetBios ports must be opened to
make this possible. If access through a firewall is required, use of a remote
access tool such as Microsoft Terminal Server is recommended.
To install the MailMarshal Configurator:
• Log in with sufficient access rights to install software onto the local machine
and to access the install folder for MailMarshal.
• Run the MailMarshal installation program or setup.exe to install the
MailMarshal Configurator software.
• Under Setup, choose Custom/Complete, then Configurator.
• Run the newly installed software.
• If the MailMarshal Server is not running on the same machine, a Change Server
dialog box will prompt for the IP Address or name of the MailMarshal Server
machine. This dialog box can be reached at any time by right-clicking on the
MailMarshal Configurator element in the left pane of the Configurator.
Note
Whenever you update or upgrade the MailMarshal Server you must also
upgrade the Configurator on remote machines.

Uninstalling MailMarshal
Use the following steps to uninstall MailMarshal.
Before uninstalling, ensure that any settings changes made to the email system
(eg. the DNS MX records and email server settings) are revised to exclude
MailMarshal from email processing.
Log on to the MailMarshal Server computer with administrative rights. Stop
the MailMarshal Controller service using the Control Panel Services applet. This
should stop all other MailMarshal services.
Uninstall MailMarshal (and MailMarshal Reports, if installed) using the Control
Panel Add/Remove Programs applet. System restart may be suggested to remove

3-14 Installation
some files.
Uninstall the MailMarshal Configurator, Console and Reports software on
workstations.
If appropriate, drop the MailMarshal and MailMarshalCertStore databases using
SQL administration tools.

Importing a MailMarshal Configuration

Where MailMarshal is being reinstalled, or installed in a cluster environment, it
may be desirable to import configuration settings.
Warning
Incorrect use of this feature could damage your MailMarshal installation.
Always save current settings (using the export facility) before performing this
procedure.
The Merge with current configuration option must only be used with specially
constructed files supplied by Marshal Software.

Start the Configurator, choose Tools|Server Properties from the menu to see the
Server Properties dialog, and choose the Advanced tab.

To display the Import Configuration dialog box, click on the Import Configuration
button. Click on Browse to select the file to import. Select Overwrite current
configuration to replace your current configuration with the imported settings.
Click on OK.
User Group information is stored in the file UserGroups.txt within the
MailMarshal install folder. To import User Groups, copy this file to the
appropriate location.
Files with “known fingerprints” are stored in the folder ValidFingerprints
within the MailMarshal install folder. To preserve fingerprint information, copy
this folder to the appropriate location.

Installation 3-15
 4. The Configurator

The MailMarshal Configurator is used to set up and modify the Rules and rule
elements that control how email is processed by the MailMarshal Server. The
Configurator also allows advanced setup and modification of the Server
Properties, which determine how MailMarshal sends and receives email. The
Configurator is always installed on the MailMarshal Server computer during
initial setup. It may also be installed on any workstation–for installation
instructions, please see the chapter Installation.
The MailMarshal Configurator is implemented as a snap-in to the Microsoft
Management Console (MMC). For general information and tips about the
MMC, please see the chapter MailMarshal and the MMC. This manual assumes
that the MMC is displaying both the left (menu tree) and right (details) panes.

Figure 4.1: The MailMarshal Configurator

The Configurator 4-1

 To use the MailMarshal Configurator, ensure that the MailMarshal Configurator
folder is expanded. The left menu pane presents the top level functions of
MailMarshal. Detailed information is presented in the right pane.
Note
Only one instance of the MailMarshal Configurator may be active per
MailMarshal Server. Attempting to start a second Configurator results in the
notice “MailMarshal settings are locked.”

The following elements are available in the Configurator. Many of these

elements are covered in more detail in following chapters of this manual.

MailMarshal Configurator
When MailMarshal Configurator is selected in the left pane, the status of the
MailMarshal services is shown at the bottom of the right pane. These will
include the Engine, Receiver, and Sender. They may also include the POP3
service if this option has been configured, and the Encrypt and Decrypt
services if MailMarshal Secure is installed and enabled.

To start the MailMarshal services, click the Start icon in the toolbar. To
stop the services, click the Stop icon in the toolbar. An individual service
may also be started or stopped by selecting it then clicking the appropriate icon.
The start/stop status of these services persists through server restarts.
When changes to the Rules or rule elements have been made in the
Configurator but not yet reloaded on the Server, the caption MailMarshal
Configurator will be followed by a * (see Figure 4.1). To reload the Server, click
the Reload icon on the toolbar. Changes will take effect immediately.
Some configuration changes require the MailMarshal services to be restarted.
Where this is necessary the option to do so will be given. Restarting the
services takes only a few seconds and does not seriously affect email flow.

Server Properties
Click Tools|Server Properties in the menu to view the MailMarshal Server
Properties dialog. The various tabs of this dialog allow setup of MailMarshal’s
email delivery and receipt options, logging database, and Header Rewrite
function, as well as several minor options. Backup and restore of the

4-2 The Configurator

MailMarshal configuration is also available. Detailed information on this dialog
is available in the chapter Server Properties.

Rulesets
Select this item to view a list of MailMarshal’s Rulesets in the right pane.
Rulesets contain the Rules which determine how email messages are processed.
Rules may depend on recipient, message size, and other factors. Available
actions include content scanning, third-party virus scanning, message stamping,
and others. For detailed information on Rules and Rulesets, please see the
chapter Rulesets and Rules.
Note
When this item is selected, click the Print icon in the toolbar to view and
optionally print a list of all currently configured Rulesets and Rules.

User Groups
Select this item to view a list of MailMarshal’s User Groups. These Groups
may be used to apply different Rules to various email users–for instance, to
apply different message stamps to outbound email from various departments.
User Groups may be created within MailMarshal or imported via LDAP from
any available directory server. For detailed information please see the chapter
User Groups.

POP3 Accounts
Select this item to view a list of POP3 accounts which have been set up on the
MailMarshal server. MailMarshal is effective as a POP3 server for up to 300
users. POP3 accounts may also be used to provide relay access to
MailMarshal’s rule processing and SMTP sending abilities for remote users,
even if inbound email is not delivered to POP3 mailboxes. For detailed
information please see the chapter POP3 Accounts.

Virus Scanners
Select this item to view a list of third-party virus scanners which have been
configured for use by MailMarshal. Scanners in the list may be used to check
message content and attachments. For more information on configuring virus
scanners, please see the chapter Virus Scanners.

The Configurator 4-3

 External Commands
Select this item to view a list of external commands which MailMarshal can
invoke. Most command-line executable programs can be used in this way.
DLLs can also be invoked. External commands can be used either to test the
content of a message, or to perform an action as a result of a condition being
triggered by a message. For more information, please see the chapter External
Commands.

Folders
Select this item to view a list of folders into which MailMarshal can place email
items. Folders may be used to quarantine items based on content, to take
copies of selected items, and to park messages for later delivery. Folder names,
subfolders, and physical locations may be changed. For more information
please see the chapter Folders.

Email Templates
Select this item to view a list of templates which may be used when
MailMarshal sends an automated message. Templates may contain variables
and may have attachments. They can be created and modified to suit any need.
For more information please see the chapter Email Templates.

TextCensor Scripts
Select this item to view a list of MailMarshal’s TextCensor Scripts. These
Scripts are used within Rules to review the content of email messages and
attachments. A number of scripts are installed by default. They may be edited
and new scripts added. For more information, please see the chapter TextCensor
Scripts.

Logging Classifications
Select this item to view a list of classifications available when message traffic is
logged by MailMarshal. Classifications may be added and modified to suit local
need. For more information, please see the chapter Logging Classifications.

4-4 The Configurator

Message Stamps
Select this item to view a list of message stamps which may be appended by
MailMarshal. Stamps may be used for disclaimers, or to notify a recipient of
action taken by MailMarshal. Message stamps may be in HTML and plain text
format, and may be inserted at the top or bottom of an email message. For
more information please see the chapter Message Stamps.

LDAP Connections
Select this item to view a list of LDAP (Lightweight Directory Access Protocol)
server connections which have been configured in MailMarshal. LDAP allows
MailMarshal to populate User Groups from remote directory servers. LDAP is
also used by MailMarshal Secure to retrieve user Certificates from a remote
store. For more information on configuring LDAP connections, please see the
chapter LDAP Connections. Information on LDAP User Groups may be found
in the chapter User Groups; information on using LDAP certificate stores is
found in the chapter MailMarshal Secure.

News and Support

Select this item to view the Marshal Software website in the right pane. This
site features the latest support information, including Frequently Asked
Questions, a Knowledge Base, and a Support Forum. To access the full range
of resources, customers should log in to the site. Obtain login details, if
necessary, by contacting Marshal Software.

The Configurator 4-5

 5. Rulesets and Rules

Rules define how MailMarshal treats email messages. For convenience, all Rules
are defined within Rulesets (groups of Rules that share base User Matching
conditions). Conditions defined for a Ruleset must be satisfied before any Rule
in that Ruleset is evaluated.
An organization may have just a few Rulesets, or many. For example, one
Ruleset might apply to all messages outbound from the organization, and
another Ruleset apply to all inbound messages. Alternatively or in addition, an
organization may be divided into departments, with Rules governing email to
and from each department grouped into a separate Ruleset. While some default
Rulesets and Rules are provided with MailMarshal, changes and additions
should be made to meet local needs. A minimum of two Rulesets is
recommended: one for incoming email and one for outgoing email.
Each Rule has three parts: User Matching, Conditions, and Actions. The User
Matching and Conditions sections are used to evaluate each message. Messages
which meet the specified criteria are subjected to the specified Actions. Figure
5.1 displays an example Rule.

Best Practices
A wide variety of Rules may be created within MailMarshal. Marshal Software
recommends the following basic practices to ensure security and ease of
administration:
• Keep rules simple. Simple rules are easier to debug and often faster to run.
• Archive messages. Archiving gives an extra layer of backup in case of email
server or delivery problems, as well as being useful for rule testing.
• Block most attached files by default (both by file extension and by file type).
MailMarshal is shipped with example Rules to accomplish this.
• Block password protected attachments.
• Block encrypted attachments (eg. files of type ‘Encrypted Word Document’).
• Block encrypted messages which MailMarshal cannot decrypt (eg. PGP

Rulesets and Rules 5-1

 messages, and S/MIME messages if MailMarshal Secure is not installed).
• Subscribe to email notification lists for virus outbreaks (such lists are offered
by many anti-virus software companies). When an outbreak occurs, block the
offending messages by subject line or other identifying features.

Viewing and Printing Rulesets

To view and optionally print a list of all currently configured Rulesets and Rules
first select Rulesets in the left pane of the Configurator. Click the Print icon in
the toolbar to view the Ruleset and Rule definitions in a new window (see
Figure 5.1). To view an individual ruleset, select that ruleset in either pane and
click the Print icon.

Figure 5.1: Ruleset Print Preview window

Creating a Ruleset
To create a Ruleset, in the MailMarshal Configurator, select Rulesets in the left
pane. Then click the New Ruleset icon in the toolbar to start the New Ruleset
Wizard (see Figure 5.2).
Select the conditions under which the Ruleset should be used by checking

5-2 Rulesets and Rules

boxes in the upper pane. Scroll down to see the full list of conditions. The
conditions selected will be presented in the lower pane.
Where the matching condition requires specific information to be completed,
the incomplete information appears in the rule description as a red hyperlink.
Click on the hyperlink to bring up a dialog box allowing this information to be
entered. Where specific information has been entered the rule description
displays the specifics as a blue hyperlink; click on this link to edit them.

Figure 5.2: New Ruleset Wizard–Message Filtering

Clicking on the hyperlink People opens the Enter Users dialog (see Figure 5.3).
This dialog presents a list of MailMarshal User Groups. Expand any group in
the right pane of this dialog to see its members. Double-click on any user
group or individual address to add it to the list.
A new user may be added to the list by clicking the New User button. A new
User Group may be created by clicking the New User Group button. Once the
ruleset has been created the group should be populated using the functions
available in the User Groups item of the Configurator tree.

Rulesets and Rules 5-3

 Figure 5.3: Enter Users dialog

Delete a group or address from the list by clicking the Delete button. Close this
dialog and return to the New Ruleset Wizard by clicking OK.
In the final screen of the New Ruleset Wizard (Figure 5.4), give the Ruleset a
name. Choose whether to enable the ruleset, and whether to launch the New
Rule Wizard. A Ruleset must contain at least one Rule to have any effect.

Figure 5.4: New Ruleset Wizard–Finished

Editing a Ruleset
To edit a Ruleset, in the MailMarshal Configurator, select Rulesets in the left
pane. Right click the Ruleset to be edited in the right pane and select Properties
from the context menu. The Ruleset is presented in a dialog with two tabs,

5-4 Rulesets and Rules

“General” and “Filtering”, which allow all information in the Ruleset to be
modified.

To Copy or Move Rules Between Rulesets

To move a Rule between Rulesets, select the Rule’s parent Ruleset in the left
pane of the Configurator. Drag the desired rule from the list in the right pane
to a different Ruleset in the left pane.
To copy a Rule, hold down the <CTRL> key while dragging the Rule.

To Enable or Disable a Ruleset

To enable or disable a Ruleset, edit it then check or uncheck the box “enable
ruleset after next reload”. Alternatively, right click the Ruleset in the right pane
and select All Tasks|Enable or All Tasks|Disable from the popup menu.

Order of Evaluation
The order in which Rulesets and Rules are evaluated is significant. Certain Rule
actions are terminal (they stop further Rule processing). This is indicated in the
Rule description.
For instance, a virus scanning rule will normally be evaluated first, and if a
virus is found the message will be quarantined immediately–no further rules
will be evaluated.
Rulesets are evaluated in “top down” order as shown in the Configurator.

Adjusting the Order of Evaluation of Rulesets

To adjust the order of evaluation of Rulesets, select Rulesets in the menu pane.
Select a Ruleset in the right pane, and move it up or down using the arrows in
the toolbar. Click the Reload Server Rules icon to effect the change in order.

Adjusting the Order of Evaluation of Rules

To adjust the order of evaluation of Rules, expand a Ruleset. Select a Rule in
the right pane, and move it up or down using the arrows in the toolbar. Click
the Reload Server Rules icon to effect the change in order.
Note
A rule containing a “Goto” condition (Pass the message to rule) cannot be
moved below the rule it is set to go to. Attempting such a move raises a

Rulesets and Rules 5-5

 warning notice. See the section on rule conditions below for more
information.

Creating a New Rule

To create a new Rule, in the left pane of the Configurator, expand the Ruleset
that should contain the new Rule. Click the New Rule icon in the toolbar to
start the Rule Wizard.
In the first screen of the Rule Wizard, select the appropriate rule type.
Standard Rules are processed by the MailMarshal Engine and offer the full
range of Conditions and Actions. Most rules will be of this type.
Receiver Rules are processed by the MailMarshal Receiver before the receipt
of the message body. The only conditions available for Receiver Rules are
message size (this works only where the sending email server supports ESMTP)
and message source (User Matching and incoming/outgoing). The advantage
of Receiver Rules is that they may reduce traffic volume by refusing delivery of
messages completely before they are received.
Security Rules (available only when MailMarshal Secure is enabled) control the
encryption, decryption and signing of S/MIME messages. For information on
Security Rules, please see the chapter MailMarshal Secure.

Figure 5.5: Rule Wizard–User Matching

5-6 Rulesets and Rules

The next screen of the Rule Wizard, User Matching, specifies to whom the rule
will apply (see Figure 5.5). Check the appropriate boxes in the upper pane to
add matching conditions to the rule description. Scroll down to see the full list
of conditions.
Note
If no User Matching boxes are checked, the Rule will apply to all messages
(subject to the limitations imposed by the parent Ruleset). Matching
conditions determined by the parent Ruleset are displayed in grey text and
cannot be edited here. If these conditions must be changed, edit the
properties of the parent Ruleset.
Where the matching condition requires specific information to be completed,
the incomplete information appears in the rule description as a red hyperlink.
Click on the hyperlink to bring up a dialog box allowing this information to be
entered. Where specific information has been entered the rule description
displays the specifics as a blue hyperlink; click on this link to edit them.
The third screen of the Rule Wizard, Conditions, specifies other tests to be
performed on the message and its attachments. Choices are made as in the
previous screen. Detailed lists of Conditions are presented later in this chapter.
The fourth screen of the Rule Wizard, Actions, sets the actions to be taken if a
message meets the specified conditions. Choices are made as in the previous
screens. Detailed lists of Actions are presented later in this chapter.
The fifth and final screen of the Rule Wizard, Finish, presents the complete
Rule in the description pane where it may be edited (see Figure 5.6). The rule
must be named. By default the rule is “turned on” (used to process messages).
Note
New Rules and changes do not take effect until the Rules are reloaded (using
either the Reload Server Rules icon in the toolbar or the menu item Tools|Reload
Rules on Server).

Copying a Rule
To copy a Rule, right-click it in the Configurator. To make a copy in the current
Ruleset, choose Duplicate from the context menu. To make a copy in another
Ruleset, choose Copy from the context menu; then right-click the target Ruleset
and choose Paste.

Rulesets and Rules 5-7

 Editing a Rule
To edit a Rule, double click it in the right pane of the Configurator. The rule
will be presented in the Finish dialog of the Rule Wizard (see Figure 5.6).
Hyperlinked details may be edited from this pane. If more basic changes to
conditions or actions are required, use the Back button to view the User
Matching, Conditions, and Actions screens.

Figure 5.6: Rule Wizard–Finish

User Matching Criteria

When creating Rulesets and Standard and Receiver Rules, the following User
Matching criteria are available:

5-8 Rulesets and Rules

Where message is incoming
Action will be taken if the message is addressed to a domain within
MailMarshal’s Local Domains list.

Where message is outgoing

Action will be taken if the message is addressed to a domain outside
MailMarshal’s Local Domains list.

Where addressed to people

Action will be taken if a recipient of the message is found in the list of
addresses specified. See the section on Rulesets, above, for details on choosing
which “people” are included in these conditions.
Note
Whenever a list of “people” is required in a condition, the list may contain
individual email addresses, domains, and MailMarshal user groups (see Figure
5.3).

Where addressed from people

Action will be taken if the sender of the message is found in the list specified.

Where addressed either to or from people

Action will be taken if a recipient or sender of the message is found in the list
specified.

Where addressed both to and from people

Action will be taken if the sender of the message is found in the first list
specified, and the recipient of the message is found in the second list specified.

Except where addressed to people:

Action will not be taken if a recipient of the message is found in the list
specified.

Except where addressed from people

Action will not be taken if the sender of the message is found in the list
specified.

Except where addressed either to or from people

Action will not be taken if an recipient or sender of the message is found in

Rulesets and Rules 5-9

 the list specified.

Except where addressed both to and from people

Action will not be taken if the sender of the message is found in the first list
specified, and the recipient of the message is found in the second list specified.
Note
“Except” matching criteria are the key to creating exception based policies.
Rules which apply to all recipients with the exception of small specific groups
help to ensure that security policies are uniformly applied. For instance, a
rule may apply “Where the message is incoming except where addressed
to Managers”

Rule Conditions–Standard Rules

The following conditions are available for use in Standard Rules. They are
further explained below:
• Where message attachment is of type
• Where attachment parent is of type
• Where attachment fingerprint is/is not known
• Where message is of a particular size
• Where message attachment is of a particular size
• Where the estimated bandwidth required to deliver this message is
• Where message contains attachments of name
• Where message triggers text censor script(s)
• Where message contains a virus
• Where the external command is triggered
• Where number of recipients is count
• Where number of attachments is count
Note
If many conditions are specified in a single rule they must all be satisfied for
the Rule action to be taken. To match any of several single conditions, place
each one in its own Rule. It pays to keep rules simple and ensure they are
logical–it is possible to create nonsensical rules in MailMarshal!

Where message attachment is of type

MailMarshal checks the structure of all attached files to determine their type.
Over 80 types are recognized as of this writing. Selecting the hyperlink “file

5-10 Rulesets and Rules

types” opens a selection dialog including several categories of files (see Figure
5.7). Select an entire category by checking the associated box. Expand any
category to see the list of types included, and check the required boxes. When
satisfied click OK to return to the Rule Wizard.

Figure 5.7: File Attachment Types dialog

Where attachment parent is of type

This condition is intended to be used with the above condition (attachment of
type), and causes MailMarshal to consider the file type of the parent container as
well as that of the attachment (for instance, MS Word documents containing
images). Clicking the hyperlink “parent types” opens a selection dialog offering
all valid parent types. The dialog also allows the condition to be applied to
types in or out of the selected list (see Figure 5.8).
Note
This condition may be useful to exclude images and other inclusions within
MS Word documents from quarantine rules. Eg.
When a message arrives
Where message attachment is of type IMAGE
And where attachment parent is not of type: DOC

See also the next condition (attachment fingerprint).

Rulesets and Rules 5-11

 Figure 5.8: Parent Types dialog

Where attachment fingerprint is/is not known

The “fingerprint” identifies a specific file (such as a particular image). Click the
hyperlink and choose to base the condition on fingerprints which are known or
unknown. To add a file to the list of “known” files, use the “add to valid
fingerprints” rule action, or select Add Fingerprints while processing messages in
the Console (see the chapter The Console for further information). To delete a
file from the list of “known” files, delete the file from the ValidFingerprints
subfolder of the MailMarshal install folder then reload the MailMarshal
configuration.
Note
This condition may be useful to exclude certain images, such as corporate
logos or signatures, from triggering quarantine rules. Eg. to take action only
on unrecognized images, use the following conditions:
When a message arrives
Where message attachment is of type IMAGE
And where attachment fingerprint is not known

Note
Files may also be made known by placing them in the ValidFingerprints sub-
folder and restarting the Engine; however this must be done with care. See
the Marshal Software Knowledge Base for further information.

Where message is of a particular size

The size of the entire message, before unpacking, will be considered. Choose a

5-12 Rulesets and Rules

size and matching method using the Message Size dialog (see Figure 5.9)
Note
MailMarshal checks the size of the received message in its encoded format.
This is typically 33% larger than the size reported by an email client.

Figure 5.9: Message Size dialog

Where message attachment is of a particular size

The size of each attachment is evaluated after all unpacking, unzipping, etc. is
complete. An attachment size may be larger than the size of the original
message, due to decompression of archive files.

Where the estimated bandwidth required to deliver this message is

The bandwidth required to deliver a message is calculated by multiplying the
message size by the number of unique domains to which it is addressed. The
intended use of this criterion is to move high-bandwidth messages to a
“parking” folder for delivery outside peak hours. They could also be blocked
entirely.

Where message contains attachments of name

Enter a list of file names, separated by semi-colons. The * and ? wildcards are
supported (eg. *.SHS;*.VBS;*.DO?). This condition is particularly useful for
quickly blocking dangerous file types such as VBS, or known virus attachments
such as “creative.exe”. However, it checks only the file name and not the
internal type; use “Where message attachment is of type” to check files by
structure.

Where message triggers text censor script(s)

Choose a TextCensor script to be used in evaluating the message (see Figure
5.10). Depending on the settings of the individual script, various parts of the
message and its attachments may be scanned. Within the Select TextCensor Script

Rulesets and Rules 5-13

 dialog, select a script and click Edit Script to view or change it; click New Script
to create a new script which will be automatically selected when you return to
the dialog. See the chapter TextCensor Scripts for detailed information on
creating Scripts.
Note
More than one TextCensor script may be included in a rule. However, for
the rule to be triggered all included scripts must trigger.

Figure 5.10: Select TextCensor Script dialog

Where message contains a virus

All currently configured virus scanners will be used to scan all portions of the
message and attachments. See the chapter Virus Scanners for information on
choosing and configuring virus scanners within MailMarshal
Note
Where policy based choice of scanners or scanning actions is desired, virus
scanners may be defined as external commands (see the next rule condition
and the chapter External Commands for more information).

Where the external command is triggered

Select one or more external commands to be used to test the message. If more
than one command is specified, all commands must be triggered for this
condition to be triggered. External commands can be executable programs or
DLLs. See the chapter External Commands for more information.

5-14 Rulesets and Rules

Where number of recipients is count
This condition is typically used to block messages with large recipient lists as
suspected “Spam”.

Where number of attachments is count

This condition is typically used to block messages with large numbers of
attachments. The number of attachments may be counted using top level
attachments only, or top level attachments to email messages including any
attached messages, or all attachments at all levels (see Figure 5.11).
Note
“Top level attachments” are the files explicitly attached by name to an email
message. Other files, such as the contents of a zip archive or images within a
MS Word document, may be contained within the top-level attachments.

Figure 5.11: Number of Attachments dialog

Rule Actions–Standard Rules

The following actions are available for selection in Standard Rules. Details of
each action are given below.
• Copy the message
• BCC a copy of the message
• Run the external command
• Send a notification message
• Strip attachment

Rulesets and Rules 5-15

 • Write log message(s)
• Stamp message with text
• Add attachments to valid fingerprints list
• Move the message (terminal action)
• Park the message (terminal action)
• Delete the message (terminal action)
• Pass the message to rule
If a terminal action is performed, no further rules will be processed for the
affected message.
By default the following options are checked: send notification message, write
log message, move the message (to a folder).

Copy the message

Copy the email message file to the specified folder. To make the message
processing log available in the same folder, check the box at the bottom of the
dialog. The message log showing how the message was processed will then be
available in the Console. If a new folder is required, click the New Folder button
to bring up the New Folder Wizard (see the chapter Folders for more
information).

BCC a copy of the message

Send a blind copy of the message to one or more email addresses. These
should be entered as complete SMTP addresses (eg. user@domain.topdomain),
separated by semi-colons. The original message will not be modified in any way
by this action, so the original recipient would not know a copy had been taken.
Note
You can use this action in combination with “delete the message” to
effectively forward messages to a different recipient.

Run the external command

Choose one or more commands to be run from the list of pre-defined external
commands. See the chapter External Commands for information on defining
external commands. To run the same application with different parameters
under different conditions, use more than one external command definition.

5-16 Rulesets and Rules

Send a notification message
Send one or more email messages based on the templates checked in the
selection dialog. To view or edit the details of a particular template, select it
then click Edit Template. To create a new template, click New Template; the new
template will automatically be selected for use when you return to the template
selection dialog. For further information on templates, see the chapter Email
Templates.

Strip attachment
Where the rule conditions are triggered by a specific attachment, remove this
attachment from the message. This action would typically be used to remove
attachments of specific file types or file names.
Note
When an attachment is stripped, normally the original message should be
copied for later retrieval if necessary, and stamped to inform the recipient
that an attachment has been stripped.

Write log message(s)

Select one or more logging classifications from the list. Check the box to write
a logging classification for every component of the message (eg. a separate
record for each image file in a message). To view or edit the detailed
information in the classification, click Edit in the selection dialog. To create a
new classification, click New in the selection dialog. For details on
classifications, see the chapter Logging Classifications.

Stamp message with text

Choose one or more message stamps to be added to the message body. Stamps
will be at the top or bottom of the message as selected when they were created.
To view or edit the details of a particular message stamp, select it then click
Edit Stamp. To create a new stamp, click New Stamp; the new message stamp
will automatically be selected when you return to the stamp selection dialog.
See the chapter Message Stamps for details.

Add attachments to valid fingerprints list

Add the attachments to MailMarshal’s list of “valid fingerprints” (normally used
for images or other files which require special treatment, such as company
logos). Choose whether to add all attachments, or only images, to the list. See
the rule condition “where attachment fingerprint is/is not known” for more

Rulesets and Rules 5-17

 information.

Move the message

Move the email message file to the specified folder. To make the message
processing log available in the same folder, check the box at the bottom of the
dialog. The message log explaining how the message was processed will then
be available in the Console. If a new folder is required, click the New Folder
button to bring up the New Folder Wizard (see the chapter Folders for more
information). This is a terminal action–no further rules will be processed for a message if
this action is performed.

Park the message

Move the email message file to the specified parking folder for release
according to the schedule associated with that Folder. If a new folder with a
different schedule is required, click the New Folder button to bring up the New
Folder Wizard (see the chapter Folders for more information). This is a terminal
action–no further rules will be processed for a message if this action is performed.

Delete the message

Delete the email message file. Do not send the message to its original
destination. This is a terminal action–no further rules will be processed for a message if
this action is performed.

Pass the message to rule

If no “terminal” rule action has been taken, this action allows a choice of
which further rules to apply. Several choices are available (see Figure 5.12),
including

• Skip the next rule (do not apply it).

• Skip to the next ruleset (do not apply further rules in this ruleset).
• Skip all further rules (pass the message through to the intended recipients).
• Skip to a particular ruleset or rule.

Note
It is only possible to skip to a rule which is evaluated after the current rule.
(The order of evaluation may be changed; see Order of Evaluation earlier in
this chapter.)

5-18 Rulesets and Rules

 When skipping to a rule in a different ruleset, remember that the parent
ruleset conditions may prevent its having any effect. For instance, skipping
from MailMarshal’s default Inbound ruleset to the Outbound ruleset is
allowed, but rules in the Outbound ruleset will have no effect on inbound
messages.

Figure 5.12: Continue Processing dialog

Rule Conditions–Receiver Rules

The following condition is available for use in Receiver Rules. Note that
Receiver processing of this condition depends on an ESMTP connection from
the outside server. This condition should be repeated in a Standard Rule to
include messages received from non-ESMTP sources.

Where message is of a particular size:

This condition is normally used with a “block receipt” action to refuse large
messages. Choose the size criteria in the Message Size dialog (see Figure 5.9).

Rule Actions–Receiver Rules

The following actions are available for use in Receiver Rules.

Block receipt of message (default action):

MailMarshal will refuse the message based solely on the message headers. A
SMTP response refusing delivery will be transmitted to the sending server.

Rulesets and Rules 5-19

 This action is intended to be used in conjunction with a size-limiting condition
to conserve bandwidth, or to refuse messages from specific problem addresses
configured in the parent Ruleset.

Allow relaying
If selected, this condition permits receipt of the message by MailMarshal for
delivery subject to Standard Rules. Furthermore the message may be relayed to
an address outside MailMarshal’s local domains. This condition is intended to
be used in conjunction with a “from” User Match in the parent Ruleset, to
allow relaying by specific email users.
Relaying may also be allowed by authentication of the client. See the chapter
POP3 Accounts for details.
Note
The Allow Relaying action should not be combined with a size condition.

5-20 Rulesets and Rules

 6. User Groups

MailMarshal User Groups are used within Rulesets and Rules to specify to
whom the Rules apply. MailMarshal uses SMTP email addresses to perform
user matching. User Groups may be created and populated within MailMarshal
by entering email addresses manually (wildcards may be used). User Groups
may also be imported from an LDAP server (such as Microsoft Exchange or
Lotus Notes), in which case their membership is updated automatically on a
defined schedule.
To create and maintain User Groups, in the Configurator, expand the element
User Groups.

To Create a New Standard User Group

Click the New User Group icon in the toolbar to bring up the New User Group
dialog. Enter a name for the User Group.

To Add Members to a Standard User Group

Select the appropriate User Group from the right pane of the Configurator.
Click the New Member icon in the toolbar to see the Insert into User Group dialog.
Enter an individual SMTP address, a wildcarded address, or a domain name in
the box. (The available wildcards are the same as those used for local domain
names–see the Wildcards section of the chapter Server Properties for details.) Click
Add (or use the <Enter> key) to add the value. The dialog remains open and
additional values may be added. If an individual address was entered, the
domain name portion of the address is retained and only the new user name
need be entered.

To Add an LDAP User Group

LDAP user groups are used in the same way as standard MailMarshal user
groups. However, MailMarshal populates an LDAP group by retrieving a list of
members from an LDAP server, such as Lotus Notes. The membership of

User Groups 6-1

 LDAP groups is automatically updated on the schedule specified in the LDAP
connection dialog.
To work with LDAP User Groups, you must configure at least one LDAP User
Group Connection (see the chapter LDAP Connections).
Click on the Add LDAP User Group icon, or right-click on User Groups in the
tree then click on New, then on LDAP user group... to see the New LDAP User
Group dialog box (see Figure 6.1). Select the LDAP connection to be worked
with from the drop down menu and click OK. If no entries appear in the
menu, no LDAP user group connections have been configured.

Figure 6.1: New LDAP User Group dialog

MailMarshal will then query the server for a list of available user groups, and
display the results in a list (see Figure 6.2). (If MailMarshal is unable to
connect to the server no groups will be shown.) Select an LDAP group from
the list. This group will appear in the list of User Groups. The group name
will consist of the LDAP Connection name and the group name as retrieved
from the server. Repeat this action to add other user groups. When done, click
OK.
Initially, an LDAP group will be empty of users; it will be populated at the next
scheduled update. An LDAP user group can immediately be specified in any
MailMarshal rules; however, such rules should not be made effective (ie. the
server should not be reloaded) until the group has been populated.
Note
Although MailMarshal does not prohibit adding and deleting members from
LDAP groups, such changes will not be sent to the LDAP server, and they
will be lost during the next scheduled update from the LDAP server.
Any changes to membership of these groups must be made at the LDAP
server.

6-2 User Groups

 Figure 6.2: Available LDAP Groups

To Move and Copy User Groups

To copy a User Group, right-click it in the Configurator. To make a copy,
choose Duplicate from the context menu.
To move a User Group so that it is included within another User Group, drag it
over the target Group.
To copy a User Group so that it is included within another User Group, hold
down the <CTRL> key while dragging.

User Groups 6-3

 7. POP3 Accounts

MailMarshal can function as a POP3 server for local domains (as specified
during setup or in Server Properties). A POP3 login must be created for each
mailbox that will be hosted by MailMarshal.
If MailMarshal receives an email message addressed to the POP3 domain but
no matching account has been created, the message will be dealt with
(forwarded or refused) according to the options set up for the domain. See
Local Domains in the chapter Server Properties for more information on POP3
domains.
If a POP3 domain exists, MailMarshal automatically starts an additional service
to respond to POP3 requests. This POP3 service appears in the list of services
in the Configurator and Console.
POP3 accounts also permit email relaying. Since the MailMarshal server
functions as an email gateway, it is likely to be available from anywhere on the
Internet. Traveling email users who wish to send email from their business
address, using the scanning and stamping features of MailMarshal, can do so if
they have MailMarshal POP3 accounts. See POP3 Accounts for Relaying
Authentication below.
Note
The relaying authentication feature may be used regardless of where
MailMarshal delivers messages for an address, and without any POP3 local
domains being configured. See POP3 Accounts for Relaying Authentication below.

To Set Up POP3 Accounts

In the left pane of the Configurator, select POP3 Accounts. Click on the New
POP3 Account icon in the toolbar. Enter the details for the account holder and
authentication information in the New POP3 Account dialog (see Figure 7.1).
If the account will be used for email delivery (if MailMarshal is operating one
or more POP3 local domains), MailMarshal will automatically enter an
appropriate SMTP alias for email delivery to this account’s mailbox. Make any

POP3 Accounts 7-1

 desired changes to this alias, and enter any additional SMTP addresses for
which email should also be delivered to this account’s mailbox. (The domain
name of each alias address must be one for which MailMarshal is functioning
as a POP3 local domain server.)
If more than one POP3 account has the same SMTP alias, messages directed to
that alias will be delivered to all of the mailboxes.

Figure 7.1: New POP3 Accounts dialog

If the password fields are left blank, MailMarshal will use Windows NT
authentication to determine access for this account. In this case, ensure that
the account name matches the name of a valid Windows NT user account
permitting access to files on the MailMarshal server computer.
Click Add to add the account. When all accounts have been added, click Close.

POP3 Accounts for Relaying Authentication

A “POP3 account” may be used for relaying authentication only, and not for
message delivery. This feature may be useful, for instance, to traveling email
users who wish to send email from their business address, using the scanning
and stamping features of MailMarshal. In this case, enter an arbitrary value
(such as “none”) in the SMTP Address field. Delete any valid SMTP addresses

7-2 POP3 Accounts

which MailMarshal may have inserted automatically.
The users’ email client software must be configured to use authentication when
sending outbound messages. Consult the client software documentation for
further information on how to do this.

To Edit POP3 Accounts

To edit an existing POP3 account, select POP3 Accounts in the left pane of the
Configurator. Double-click the account to be edited. Change the password and
aliases as required, then click OK.

To Delete POP3 Accounts

To delete a POP3 account, select POP3 Accounts in the left pane of the
Configurator. Select the account to be deleted then click the Delete icon in the
toolbar.

POP3 Accounts 7-3

 8. Virus Scanners

MailMarshal is not a traditional virus scanner; however MailMarshal does

provide substantial proactive protection against viruses through file name and
file type checking, as well as TextCensor scanning for virus-related text and
harmful commands.
MailMarshal can also invoke third-party virus scanners to check email messages
and attachments for viruses. Nearly all MailMarshal installations use third-party
virus scanning.
MailMarshal allows one or more virus scanners to be used to check email for
viruses. Because virus scanners have differing architecture, some organizations
choose to use multiple scanners.
MailMarshal invokes the virus scanner after unpacking all elements of an email
message. MailMarshal then passes the elements to the scanner software for
analysis, and takes action based on the code returned from the scanner.
A sample virus scanning Rule is include in the MailMarshal default Rules. It
may be modified to suit local conditions. For details on configuring virus
scanning Rules, see the chapter Rulesets and Rules.
To work with MailMarshal, a virus scanner must have a command-line interface
or a special MailMarshal DLL. The scanner must return a documented
response indicating whether or not a virus is detected. Most commercially
available virus scanners meet these specifications.
Note
DLL based scanners are significantly faster than command line scanners,
because the scanner is always memory resident. Marshal Software
recommends the use of DLL scanners for sites with high message traffic.
The virus scanners listed below have been tested and validated for use with
MailMarshal as of this writing; contact Marshal Software for the latest list.
Appropriate parameters for these scanners are pre-coded in the Configurator,
ready for selection:

Virus Scanners 8-1

 • Sophos Anti-Virus (MMSAVI.DLL)
• Norman Virus Control (MMNORMAN.DLL)
• Network Associates Netshield and McAfee Command Line Scanner
• Vet Anti-Virus for NT Server
• InnoculateIT 6.x
Each virus scanner to be used should be installed on the MailMarshal Server
computer according to the manufacturer’s instructions.
Note
If resident or “on access” virus scanning is enabled, MailMarshal’s working
folders must be excluded from scanning. See the section MailMarshal
Directories and Resident Scanning later in this chapter.

Best Practices
Marshal Software recommends the following basic practices to ensure security
with respect to viruses and virus scanning:
• Block messages and attachments which MailMarshal cannot scan, such as
password protected attachments and encrypted attachments (eg. files of type
‘Encrypted Word Document’).
• Block encrypted messages which MailMarshal cannot decrypt, such as PGP
and S/MIME messages.
• Block executable and script files by type and name. This helps to ensure that
unknown viruses will not be passed through.
• Subscribe to email notification lists for virus outbreaks (such lists are offered
by many anti-virus software companies). When an outbreak occurs, block the
offending messages by subject line or other identifying features.

Configuring a New Virus Scanner

To configure a new virus scanner within MailMarshal, in the left pane of the
Configurator select Virus Scanners. Click the New Virus Scanner icon in the
toolbar to start the New Virus Scanner Wizard.
Select a pre-configured scanner from the list, or select “Custom Scanner” to
enter full information about a scanner not on the list of supported scanners.
In the next wizard screen, enter (or browse to) the location where the main
executable scanner file is located (eg. c:\McAfee\Scan.exe). DLL based
scanners do not require this information to be entered. If this is a custom

8-2 Virus Scanners

scanner, enter the other required information–see Viewing Virus Scanner
Properties, below, for information on the fields.
Note
If further information about a pre-configured scanner is required, click the
Vendors Web Site button to open the manufacturer’s web site in a web browser
window.
In the final screen, click Finish to add the virus scanner; it will appear in the
right pane of the Configurator. When at least one scanner is configured, virus
scanning rules may be enabled.

Viewing Virus Scanner Properties

Double click the name of any virus scanner in the right pane to review and
change MailMarshal’s configuration information for that scanner (see Figure
8.1).

Figure 8.1: Virus Scanner Properties

The Name is MailMarshal’s friendly name for this scanner. The Command Line
refers to the location of the executable or DLL file. The Parameters box allows
entry of any necessary additional command line parameters to ensure operation

Virus Scanners 8-3

 compatible with MailMarshal.
The Timeout values indicate how long MailMarshal will wait for the scanner to
complete its task. The default values are generous. If review of the
MailMarshal logs indicates that the virus scanner is timing out, these values may
be adjusted; however repeated timeouts probably indicate a need for greater
system resources.
The checkbox Single Thread indicates whether the scanner must operate on one
message at a time, or may be invoked multiple times. Non-DLL scanners will
generally have this box checked.
The two remaining fields are used to enter trigger values which specify the
meaning of the code returned from the virus scanner.
The field Command is triggered if return code is should include values used by the
virus scanner to indicate the presence of a virus or errors encountered scanning
the file. When one of these values is returned, the MailMarshal Rule condition
Where message contains a virus is triggered.
The field Command is not triggered if return code is should include values used by
the virus scanner to indicate the absence of a virus. When one of these values
is returned, the MailMarshal Rule condition Where message contains a virus is not
triggered.
If the code returned matches neither field, the associated email message is
moved to the “Undetermined” deadletter folder and an email notification is
sent to the MailMarshal administrator.
Entries in both fields may be exact numeric values, ranges of values (eg. 2-4),
greater than or less than values (eg. <5, >10). More than one expression may
be entered in each field, separated by commas (eg. 1-6,8,>10). Consult the
virus scanner documentation for details on return codes.
Note
Before entering new values for scanner parameters in MailMarshal, test the
scanner from the command line using the new parameters. If MailMarshal
invokes a scanner with invalid parameters, the result may cause all messages
to be treated as infected.

8-4 Virus Scanners

Using Other Virus Scanners
Most commercial virus scanners can be used with MailMarshal. Generally, the
following considerations apply when using an alternative virus scanner.
Verify that a Windows NT 4.0 (or Windows 2000) compatible version is
available. The product must have a command line interface and must be
capable of running silently in the background.
When entering the virus scanner information in the New Virus Scanner
Wizard, choose Custom Scanner. Enter the path to the executable file and the
parameters for silent operation. In the Parameters box, use the string
“%CmdFileName%” (including the quotation marks) to indicate to the scanner
software which folders it is to scan. Review the parameter syntax for a pre-
configured scanner to understand the use of this entry.

Testing Virus Scanners

Virus scanner setup may be tested using the VirusScannerCheck.exe application
found in the MailMarshal install folder. This application performs tests and
reports whether virus scanning is correctly integrated with MailMarshal.
If MailMarshal virus scanning rules are enabled, scanning can be checked by
sending a test virus in an email message. To create a test virus, open a new text
file and paste in the following string (without a line break):
X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-
FILE!$H+H*
Save the file as “eicar.com”. (A copy of this file may be found in the
MailMarshal install directory). Attach the file to an email message and send it
through MailMarshal to an external test email account. If the virus scanner and
scanning Rule are correctly configured to stop outbound viruses, your
MailMarshal installation should take action on the message. Alternatively, send
an email message to test@marshalsoftware.com to receive information on how
to receive a message containing the file eicar.com (this is an automated service).

Virus Scanners 8-5

 MailMarshal Directories and Resident Scanning
Network servers are usually protected by virus scanning packages to search disk
directories for contaminated files, particularly newly-created or imported files.
However, you must ensure that MailMarshal directories, their sub-directories,
and the Explode directory (located off the root directory, usually C:\MMExp)
and its sub-directories are excluded from any existing resident or “on-access”
anti-virus scanning. MailMarshal copies files to the Explode directory and
invokes virus scanners explicitly to check for viruses. If a resident virus
scanner found and cleaned a file here, MailMarshal’s virus scanning might then
determine the file to be clean. MailMarshal would then pass the original
message through with the virus still present.
MailMarshal checks for resident file scanning by placing the standard test virus
file eicar.com (not a real virus) in each of its working directories. If any of these
files are removed or cleaned by a resident scanner, or MailMarshal is denied
access to the files, the MailMarshal engine may not start and the email
administrator will be notified.
Please refer to the virus scanner manufacturer’s documentation for information
on excluding directories from on-access scanning (eg. in Networks Associates
NetShield, exclusions are set via the Exclusions tab in Scan Properties). If the
virus scanner does not have the facility to exclude the appropriate directories,
on-access scanning must be disabled completely.

8-6 Virus Scanners

 9. External Commands

An external command is a custom executable or batch file that can be run by

MailMarshal. The command can be used to check email messages for a
condition, or to perform an action when a message meets some other
condition. Some suggested uses are given at the end of this chapter.
In order for an external command to be used to check for a condition, the
command must return a standard return code.
External commands must be defined within MailMarshal before they can be
used in Rules. To create a new external command, in the left pane of the
Configurator select External Commands. Click the New External Command icon in
the toolbar to see the New External Command dialog (see Figure 9.1).

Figure 9.1: New External Command dialog

Enter a name for the external command. Type the path for the executable file
(or browse to it using the button provided). In the Parameters box, enter any

External Commands 9-1

 command line parameters necessary.
The Timeout and Timeout per MB values control how long MailMarshal will wait
for a response before ignoring the external command. The default values are
very generous.
The Single Thread setting indicates whether the scanner must operate on one
message at a time, or may be invoked multiple times. In most cases this
checkbox should be left checked. Certain executables and DLL applications
may be run multi-threaded.
The Only execute once for each message setting determines whether an external rule
condition command will be run for each component of a message, or only
once. Eg. if an external command definition is being used for policy-based
virus scanning, this box should be unchecked to ensure that each component of
each message is scanned.
Where the external command will be used as a Rule condition, set the trigger
return code information. This information should be specified in the
documentation of the executable.
Two fields are used to enter trigger values which further specify the meaning of
the code returned from the virus scanner.
If the code returned matches any value entered in the field Command is triggered
if return code is, MailMarshal will consider the condition to be satisfied.
If the code returned matches any value entered in the field Command is not
triggered if return code is, MailMarshal will consider the condition not to be
satisfied.
If the code returned matches neither field, the file is moved to the
Undetermined deadletter folder and an email notification is sent to the
MailMarshal administrator.
Entries in both fields may be exact numeric values, ranges of values (eg. 2-4),
greater than or less than values (eg. <5, >10). More than one expression may
be entered in each field, separated by commas (eg. 1,4,5,>10).

Uses of External Commands

Custom executables or batch files may be used with the Rule condition Where
message triggers an external command. For instance, fgrep.exe can be used for

9-2 External Commands

advanced expression matching.
Custom executables may also be used with the Rule action Run the external
command. For instance, a particular email subject line might invoke a batch file
to start or stop a system service, or to send a page or network notification to an
administrator.

External Commands 9-3

 10. Folders

MailMarshal uses folders for several purposes related to rule processing.

An email message which triggers a rule may be copied or moved to a folder.
This action is commonly taken for messages which are suspected of containing
viruses, but may also be used for archival or other purposes.
An outgoing email message may be “parked” to a folder for scheduled later
delivery.
An email message which cannot be processed (due to addressing or structure
problems) will be placed in a subfolder of the DeadLetter folder.
To work with folders, select Folders in the left pane of the Configurator.

Creating a New Folder

To create a new folder, click the New Folder icon in the toolbar to start the New
Folder Wizard. In the first screen of the Wizard, choose whether the folder is
to be a Standard or a Parking folder. In the next screen of the Wizard, give the
folder a name. Further options depend on whether the folder is a Standard or
a Parking folder.

Figure 10.1: New Folder Wizard–Standard Folder

Folders 10-1
 Standard Folders
See Figure 10.1. A time limit may be set for message retention in the folder.
This option is typically used for “quarantine” folders where the message may be
released on request to an administrator. Messages will be deleted automatically
after the set time.
Subdirectories may be created periodically within the folder This option is
typically used where a substantial volume of email is expected, so that messages
are easier to find.
Check the box “folder is used for message archiving” to create an Archive
folder. Within the MailMarshal Console, messages in Archive folders are
assumed to be “stored”: they may be viewed and forwarded but not deleted.
Messages in other Standard folders are assumed to be “in process” and they
may be reprocessed or deleted, among other actions. See the chapter The
Console for further information.
Click on OK to create the folder, or Cancel to lose any changes.

Parking Folders
When a Rule moves a message to this type of folder, it will be “parked” if the
time is within the blue schedule block and released (or sent immediately) when
the time is outside the blue schedule block (see Figure 10.2).
Use the checkbox Continue processing rules on release to determine what happens to
parked messages when they are released from this Folder for delivery. If the
box is checked, the message will be evaluated against all rules after the Rule
which placed the message in this Folder.
Alter the schedule block if desired:

• Drag using the left mouse button to add to the blue “parking” area.
• Drag using the right mouse button to erase from the blue “parking” area.
• To reset the schedule to the default time block, click on Set Default Schedule.
• Choose to “snap” the schedule times to the nearest full, half or quarter hour
using the drop down box.
Click on OK to create the folder, or Cancel to lose any changes.

10-2 Folders
Editing an Existing Folder
To edit the properties of an existing Folder, double-click its name in the right
hand pane of the configurator. Make any required changes, then click OK.

Figure 10.2: New Folder Wizard–Parking Folder Schedule

Changing the Default Folder Location

The default location for message folders is the Rulesets subfolder of the
MailMarshal install directory. The base physical path for all folders can be
changed to any location on a local drive. Please see the section Advanced in the
chapter Server Properties for details.
Note
If the folder physical path is changed, any messages in the old location must
be moved manually to the new location.

Folders 10-3
 Folder Security
Permission to use the MailMarshal Console (to view and take action on
messages in folders) is controlled by setting user permissions on the
MailMarshal.key file. See Console Security Issues in the chapter The Console for
details.
In some cases it may be desirable to set different access permissions for
different folders (for instance, if archived messages are to be available to the
users who sent them). Such permissions may be set using standard Windows
NT security procedures for the physical folder.

10-4 Folders
 11. Email Templates

Email Templates allow notification email messages to be sent based on the

outcome of Rule processing. This facility is most often used to notify
appropriate parties when a message is blocked.
Notifications are a very powerful tool to inform and modify user behavior.
When well thought out and constructed, they can save the administrator a lot of
time.
Notifications may also be used as a general autoresponder based on message
headers or content. For instance, a message to robot@ourcompany.com with
the subject “Send Catalog” might trigger a rule returning the product catalog to
the sender as an email attachment.
The same Rule outcome may send several notification messages. For instance,
if a virus is detected the email administrator, external sender, and intended
internal recipient of the message might each receive a different message.
Attachments to a notification may be made. Attachments may include the
original message, the MailMarshal processing log for the message, and any other
file (such as a virus scanner log file).
To work with Templates, select Email Templates in the left pane of the
Configurator.
MailMarshal is provided with numerous templates by default. These are a good
source of ideas for the creation of new templates.

Creating an Email Template

Click the New Template icon in the toolbar to see the New Email Template
dialog (see Figure 11.1). Give the Template a name.
MailMarshal allows variable information to be inserted into the message
headers and body from the original email (which triggered a Rule, invoking this
Template). Variables are marked by percent signs (%). To see a list of variables
available in any field, type % to bring up a context menu (see Figure 11.1).

Email Templates 11-1

 Enter appropriate information in the Header Details section. For instance, enter
the email address to which replies should be sent in the Return Path field.
To attach the original message, the MailMarshal message processing log, or
another file to the notification, check the appropriate box and enter the file
name if necessary.
Enter an appropriate message in the Message Body field. Variables marked with
% signs may be used.

Figure 11.1: Edit Email Template dialog

Note
When sending a notification to the original sender of an email message, use
the %ReturnPath% variable in the To: field to reduce the chance of looped
messages.

11-2 Email Templates

Duplicating an Email Template
To copy a Template, right-click it in the Configurator. Choose Duplicate from
the context menu. After duplicating the Template, make any required changes
to the copy.

Editing an Email Template

To edit a Template, double-click on its name in the right hand pane of the
Configurator. Make the required changes then click OK.

Deleting an Email Template

To delete a Template, select it in the right hand pane of the Configurator then
click the Delete icon in the toolbar.

Email Templates 11-3

 12. TextCensor Scripts

TextCensor scripts are used to check for the presence of particular lexical
content in an email message. The check may include all parts of the message,
including the message headers, message body, and any attachments that can be
lexically scanned. It may also be limited to one or more of these areas.
A script may include many conditions based on text combined with Boolean
and proximity operators. Triggering of the script is based on the weighted
result of all conditions.
TextCensor scripts are invoked by Standard Rules.
To work with TextCensor Scripts, select TextCensor Scripts in the left pane of the
Configurator.

TextCensor Syntax
TextCensor scripts contain one or more lines, each consisting of a word or
phrase.
• The wildcard character * may be used at the end of a word only (eg. “be*”
matches “being” and “behave”).
• Parentheses may be used to clarify the order of evaluation and for grouping.
• Each line may include Boolean and proximity operators. The operators must
be entered in capital letters. The six supported operators are:

TextCensor Scripts 12-1

 Operator Function Example
Matches when all terms are
AND dog AND cat
present
Matches when any term is dog OR cat
OR
present dog OR (cat AND rat)
Dog AND NOT cat
NOT Logical negation Dog FOLLOWEDBY
(NOT house)
Matches when two terms are
NEAR found within the specified Dog NEAR=2 bone
number of words of each other
Matches when a term is found
INSTANCES Dog INSTANCES=3
the specified number of times
Matches when one term
Dog FOLLOWEDBY=2
FOLLOWEDBY follows another within the
house
specified number of words

Default settings
INSTANCES has no default–a value must be specified.
If FOLLOWEDBY has no argument, the default is 5.
If NEAR has no argument, the default is 5.

Note
The INSTANCES operator is provided for compatibility with earlier
TextCensor scripts, but its use is discouraged. The use of appropriate
weighting (see below) will produce the same result with improved
performance.

Weighting the Script

Each script is given a trigger level, expressed as a number. If the total score of
the content being checked reaches or exceeds this level, the script is triggered.
The total score is determined by summing the scores resulting from evaluation
of the individual lines of the script.
Each line in a script must be given a weighting level and type. The type
determines how the weighting level of the line is figured into the total score of
the script. There are four weighting types:

12-2 TextCensor Scripts

 Standard Each match of the words or phrases will add
the weighting value to the total.
Decreasing Each match of the words or phrases will add a
decreasing (logarithmic) weighting value to the
total. Each additional match is less significant
than the first.
Increasing Each match of the words or phrases will add an
increasing (exponential) weighting value to the
total. Each additional match is more significant
than the first.
Once Only Only the first match of the words or phrases
will add the weighting value to the total.

Negative weighting levels and trigger levels can be used to allow for the number
of times a word may appear in an inoffensive message. For instance: if
“breast” is given a positive weighting in an “offensive words” script, “cancer”
could be assigned a negative weighting (since the presence of this word
suggests the use of “breast” is medical/descriptive).

Adding a TextCensor Script

Click on the New TextCensor Script icon in the toolbar to see the New TextCensor
Script dialog (Figure 12.2). Give the script a name. Check the various boxes to
select which portions of an email message will be scanned by this script.
By default only alphanumeric characters may be entered in TextCensor items.
If any non-alphanumeric characters are required, click on the checkbox to
enable matching for special characters and enter any special characters to be
matched. For instance, to match the HTML tag fragment “<script” you must
enter the < in this field.
Click on the New button to obtain the New TextCensor Item dialog (see Figure
12.1). Select a weighting level and type for this item (see Weighting the Script,
earlier in this chapter, for more information)
Enter the item, optionally using the operators described earlier in this section,
eg.
(Dog FOLLOWEDBY hous*) AND NOT cat
In this example the item weighting will be added to the script total if the
scanned text contains the words “dog house” (or “dog houses”, etc.) in order,

TextCensor Scripts 12-3

 and does not contain the word “cat”.

Figure 12.1: New/Edit TextCensor Item dialog

Note
TextCensor items are case insensitive by default. However, quoted content
is case sensitive. Eg. “textcensor” would not trigger on the caption of
Figure 12.1.
Click on Add (or press <Enter>) to add the item to this script. The dialog box
remains open and additional items may be created.
When all items have been entered, click on Close to return to the New TextCensor
Script dialog.
Select a Weighting Trigger Level. If the total score of the script reaches or
exceeds this level, the script will be triggered. The total score is determined by
evaluation of the individual lines of the script.

Editing a TextCensor Script

Double-click the script to be edited in the right pane to bring up the Edit
TextCensor Script dialog.
A line may be edited by double-clicking on it or deleted by selecting it then
clicking the Delete button.
The script name, parts of the message tested, special characters, and weighting
trigger level may be changed.

12-4 TextCensor Scripts

Click OK to accept changes or Cancel to revert to the stored script.

Duplicating a TextCensor Script

To copy a TextCensor Script, right-click it in the Configurator. Choose Duplicate
from the context menu. After duplicating the Script, make any required
changes to the copy.

Figure 12.2: New/Edit TextCensor Script dialog

Importing a TextCensor Script

TextCensor Scripts may be imported from CSV (comma separated) files.
Click on the New TextCensor Script icon in the toolbar. Click on the Import

TextCensor Scripts 12-5

 button.
Choose the file to be imported, and click Open. In the Edit TextCensor Script
dialog, click OK

Exporting a TextCensor Script

TextCensor Scripts may be exported to CSV (comma separated) files.
Double-click the script to be exported in the right pane to bring up the Edit
TextCensor Script dialog.
Click on the Export button. Enter the name of the file to which the script
should be exported, and click Save.
In the Edit TextCensor Script dialog, click OK.
Note
As of this writing, TextCensor Import and Export does not save the Weighting
Trigger Level, Special Characters, and Apply to following parts settings. This
information must be added manually after import.

Using TextCensor Effectively

The effective use of TextCensor scripts depends on understanding how the
Text Censor facility works and what it does.
Text censor rules are evaluated against text portions of messages (including
headers, message bodies, and attachment content).

Constructing TextCensor Scripts

The key to creating good TextCensor scripts is to enter exact words and
phrases that are not ambiguous. They must match the content to be blocked.
Also, if certain words and phrases are considered to be more undesirable than
others, those words and phrases should be given a higher weighting to reflect
the level of undesirability.
In creating TextCensor scripts, a balance must be struck between over-
generality and over-specificity. For instance, suppose a script is required to
check for sports-related messages. To enter the words “score” and “college”
alone would be ineffective in that those words could appear in many messages.
Hence the script would trigger too often, potentially blocking general email

12-6 TextCensor Scripts

content.
The same script (to find sports-related messages) would be better constructed
using the phrases “extreme sports”, “college sports” and “sports scores” as
these phrases are sport specific. However, using only a few very specific terms
may mean that the script does not trigger often enough.
Again using the sports example used above, the initials NBA and NFL, which
are very sports specific, should be given a suitably higher weighting (ie.
promoting earlier triggering) than, eg. “college sports”.

Decreasing Unwanted Triggering

TextCensor scripts may trigger on message content which is not obviously
related to the content types they are intended to match. The recommended
procedure to troubleshoot this problem is:
1. Use the problem script in a Rule which copies messages and their
processing logs to a folder (eg. “suspected sports sites”).
2. After using this rule for some time, check on the messages that have
triggered the script. Review the message logs to determine exactly which
words caused the script to trigger (see Interpreting Message Logs in the
chapter The Console).
3. Revise the script by changing the weighting, weighting type, or key
words, so as to trigger only on the intended messages.
4. When satisfied, modify the Rule so as to block messages that trigger the
script, and to notify the sender and/or the intended recipient.

TextCensor Scripts 12-7

 13. Logging Classifications

Log records are further categorized by Logging Classifications. These

Classifications are available within Standard Rule Actions.
To enable reporting on which Rules have triggered, each Rule should include a
logging action. MailMarshal’s default Rules include such actions.
Logging Classifications may be added and customized. To work with Logging
Classifications in the Configurator, select Logging Classifications from the left
hand menu tree.
Note
For general information on logging and reporting see the chapter Reports.

Creating a Logging Classification

Click the New Logging Classification icon in the toolbar to see the New Logging
Classifications dialog.

Figure 13.1: New/Edit Logging Classification dialog

Logging Classifications 13-1

 In the dialog box, enter a meaningful name for the classification.
Enter a number as the classification code for this classification. Reports can be
generated using these codes. By default the next available number in sequence
is used for a new classification; however, the same number may be used for
more than one classification.
Give a brief description of the classification and its purpose. This description
will be used in the Console and Reports, and may contain % variables as in the
Email Templates.
Click on OK to add the classification.

Editing a Logging Classification

To edit an existing logging classification, double-click it in the right pane of the
configurator to view its properties. Make any required changes then click OK.

Duplicating a Logging Classification

To copy an existing logging classification, right-click it in the Configurator.
Choose Duplicate from the context menu. After duplicating the classification,
make any required changes to the copy.

Deleting a Logging Classification

To delete a logging classification, select it in the right pane of the configurator,
then click the Delete icon in the toolbar.

Logging Classification Usage

Logging classifications are most commonly used to report on broad categories,
such as viruses or executable files quarantined. However they may also be used
to record very specific occurrences such as a specific file or size of file being
sent. Eg. the question “How many PDF files over 500K in size were sent by
Sales” could be answered by creating a Rule to log sending of such files.

13-2 Logging Classifications

 14. Message Stamps

Message stamps are short blocks of text which may be applied to the top or
bottom of an email message body. MailMarshal message stamps may include a
plain text and an HTML version. The appropriate stamp format will be applied
to the body text of the same type in the message.
Message stamps are typically used for corporate disclaimers or advertising on
outgoing email. Message stamps can also be used by MailMarshal to notify the
recipient that a message has been processed (eg. by having an offending
attachment stripped).
To work with message stamps in the Configurator, select Message Stamps in the
left pane. Message stamps may also be created and edited from the stamp
selection dialog during Rule creation.

Creating a New Message Stamp

In the Configurator, click the New Message Stamp icon to bring up the New
Message Stamp dialog (see Figure 14.1). Give the stamp a name and select
whether it is to appear at the top or the bottom of messages.
Enter a plain text version of the message stamp in the Plain Text tab. Then
enter an HTML version of the stamp, if desired, in the HTML tab. Various
formatting, including hyperlinks, may be applied to the HTML text using the
buttons provided.
To view the raw HTML, right-click in the HTML pane and select Edit Raw
HTML. Edit the HTML, or paste HTML source from another editor, then
click OK to return to the message stamp dialog.
Click OK to add the new stamp to the list of available message stamps.
Note
If RTF message stamping is enabled, the plain text message stamp will be
used with RTF messages. To enable RTF stamping, see the Advanced tab of
Server Properties.

Message Stamps 14-1

 Both plain text and HTML message stamps may include the same variables
available within email notification templates. See the example stamps provided
with MailMarshal, and the chapter Email Templates, for more information.

Figure 14.1: New/Edit Message Stamp Dialog

Duplicating a Message Stamp

To copy a Message Stamp, right-click it in the Configurator. Choose Duplicate
from the context menu. After duplicating the Message Stamp, make any
required changes to the copy. Remember to make changes to both the Plain
Text stamp and the HTML stamp.

Editing a Message Stamp

To edit a Message Stamp, double-click on its name in the right hand pane of
the Configurator. Make the required changes then click OK. Remember to
make changes to both the Plain Text stamp and the HTML stamp.

Deleting a Message Stamp

To delete a Message Stamp, select it in the right hand pane of the Configurator
then click the Delete icon in the toolbar.

14-2 Message Stamps

 15. LDAP Connections

What is LDAP?
LDAP (Lightweight Directory Access Protocol) is a system for retrieving
directory information, such as lists of users, from a remote source. The source
may be public (available for anonymous use) or private. Servers providing
LDAP support include:
• Lotus Notes
• Microsoft Exchange
• Microsoft Active Directory
• Novell GroupWise
• Many Sendmail systems
Within MailMarshal, LDAP connections are used to import user and group
information for User Groups. MailMarshal Secure can use LDAP to retrieve
Security Certificates for use in S/MIME encryption. See the appropriate
chapters of this manual for further information.
Before LDAP can be used to retrieve information, a connection to the remote
LDAP server must be established.

Adding a New LDAP Server Connection

Right-click on LDAP Connections in the menu tree, then click on New, then on
LDAP Connection... to see the New LDAP Connection wizard. In the first screen
of the Wizard, choose whether this connection will be used to retrieve User
Groups or Certificates.
Note
To retrieve both User Groups and Certificates from the same server, create
two connections.
In the LDAP Connection Wizard–Server dialog, enter the name of the server to be
queried into the LDAP Server field. This may be a fully qualified Internet server
name or simply the name of a server on the local LAN. Examples of LDAP
server names are:

LDAP Connections 15-1

 • ldap.netscape.com
• directory.baycorpid.co.nz
• IBMMAIL01
If desired use the browse button provided to select a server on the LAN.
The Port number field is used to enter the port on which the remote LDAP
server accepts queries. The default value is port 389. However this may be
changed where more than one LDAP server is hosted at the same IP address.
For example, when running Microsoft Exchange 5.5 on a Windows 2000 Active
Directory server, both Exchange and Active Directory provide LDAP services.
The network administrator will configure the servers to use different port
numbers.
Note
Server name, port, and login information should be obtained from the LDAP
server administrator.
Enter the logon name and password, if required, in the appropriate fields. If
using Windows integrated security, enter the logon domain as well.

Figure 15.1: The LDAP Connection Wizard–Server dialog

Select an LDAP Search Root, if necessary, in the next dialog. The Search Root

15-2 LDAP Connections

is used to limit the amount of information returned in LDAP queries, and
specifies the root container of the LDAP server to be searched. This field is
usually left blank; however, if the search does not work, ask the LDAP server
administrator for an entry. Typically the entry would be the base LDAP
Distinguished Name for the organization (eg. dc=ourcompany.com or
o=OurCompany Corporation).
Alternatively, if the LDAP server is a Microsoft Active Directory server, check
the box to populate the list of available search roots. Then select a root from
the list.
In the final dialog of the Wizard (see Figure 15.2), enter a name that will be
used to identify the LDAP connection (within MailMarshal only.)

Figure 15.2: The LDAP Connection Wizard–Finish dialog

If this is a User Groups connection, select an Update Interval. The default

period between updates is 240 minutes (4 hours). All groups derived from this
connection will be updated at the time specified. A shorter time may be
desirable if, for example, this option is used to synchronize user information
between MailMarshal and MS Exchange, and many new users are being added.
Conversely, if few users are ever added, setting a longer interval will reduce
overhead.
The field Next Update shows the time when the next update is due.
Note
If the Next Update time is reset, updates will occur at the time set and at
each Update Interval thereafter. Eg. if the Next Update field is changed to

LDAP Connections 15-3

 14:30 today and the Next Update field shows 240 minutes, the updates will
occur at 14:30, 18:30, and each 4 hours thereafter.
The Controller checks every 5 minutes to see if any LDAP user groups need
updating. If the Next Update field is used to schedule an immediate update,
this may not occur for up to 5 minutes.
Check the box Test the connection on finish then click Finish to test that the server
details are correct. If the connection type is User Groups, MailMarshal should
state that the connection has been made and some groups and members found
(see Figure 15.3).

Figure 15.3: Successful LDAP Groups Test

If the type is Certificates, MailMarshal will request an email address for which
to seek a certificate, and state whether one was found (see Figure 15.4).

Figure 15.4: Successful LDAP Certificates Test

Note
If you enter an email address for which the LDAP server holds no certificate,
MailMarshal will report that no certificate was found. However, this result
means that the server name, logon, password and port number are correct.
Other messages are less specific. The information given (eg. “no groups
found”) may not necessarily pinpoint the problem entry, so all information
entered must be checked. If necessary contact the LDAP server
administrator.

15-4 LDAP Connections

Note
A local network or LDAP server may be configured to allow access only from
certain machines or users. The Test button only tests the connection from the
Configurator. Because the MailMarshal Controller service may have different
security permissions, be sure to check that the Controller is updating LDAP
groups correctly. The Controller log file may show messages from the LDAP
action. The membership of the groups should change appropriately.
When all details are correct, click on the Finish button in the New LDAP
Connection dialog. The LDAP connection is ready to be used. See the chapters
User Groups and MailMarshal Secure for further details on using information
retrieved through LDAP.

Editing an LDAP Server Connection

To edit an existing LDAP connection, double-click it in the right pane of the
Configurator to restart the LDAP Connection Wizard.

Deleting an LDAP Server Connection

To delete an existing LDAP connection, select it in the right pane of the
Configurator then click the Delete icon in the toolbar.

LDAP Connections 15-5

 16. Server Properties

MailMarshal’s Server Properties include a variety of server setup information

and advanced options. During installation a wizard gathers enough of this
information to enable the product to function. To access the full range of
Server Properties for maintenance and reconfiguration purposes, choose
Tools|Server Properties from the Configurator menu to view the Server Properties
dialog. This dialog includes the following tabs, which are covered in detail in
the sections of this chapter:
General: Alter server email address information.
Delivery: Select how MailMarshal should deliver outbound email.
Dial-Up: Configure settings for Dial-Up connectivity.
Mail Batching: Configure settings for batched email sending.
Local Domains: Select how MailMarshal should deliver inbound email.
Reports: Choose whether, where, and how much information should
be logged.
Anti-Relaying: Choose which hosts if any may relay email through
MailMarshal.
License Info: Make Permanent Key request; see details of the current
license key and S/MIME certificate database (if enabled).
Advanced: Control configuration export/import, folder location, server
thread and logging array configuration.
Blocked Hosts: Select which hosts may not send email to local domains.
Host Validation: Enable DNS and MAPS list checking before accepting
email.
Header Rewrite: Set up rules to modify message headers, including email alias
support.
(The tabs General, Delivery, Dial-Up, Mail Batching, Local Domains, and
Reports are presented in the Installation Wizard when MailMarshal is installed.)

Server Properties 16-1

 General
Administrative notifications (such as DeadLetter reports) will be sent to the
address specified in the first box. This should be a valid and appropriate
mailbox or group alias, which is regularly monitored by the email administrator.
Administrative notifications and other automated email from MailMarshal will
be sent “from” the address entered in the second box (Template generated
messages may have a different “from” address). This address should also be a
valid SMTP address to allow for replies to notifications.

Figure 16.1: Server Properties–General tab

16-2 Server Properties

Delivery
The primary DNS (Domain Name Server) address used by the organization
must be entered in the first field of this tab, and a secondary address is
recommended. These servers should be in the local network if possible, but in
any case no further away than the ISP. They must be able to resolve domain
names outside your organization.

Figure 16.2: Server Properties–Delivery tab

Note
If MailMarshal must perform DNS lookups through a firewall, the firewall
must permit both TCP and UDP based lookups.
By default MailMarshal will attempt to deliver outbound email directly, using

Server Properties 16-3

 DNS resolution to determine the appropriate destination.
If all outbound email (not for local domains) is to be forwarded to a firewall or
a fixed relay server (such as an ISP), then select the appropriate radio button
and enter the host name or IP address of the relay or firewall in the
“Forwarding Host” box.

Dial-Up
If outbound email is to be delivered over a dial-up connection, check the box
and fill in the appropriate information. Select a RAS entry from the drop-down
list, or click on New Phonebook Entry to add the appropriate information. Fill in

Figure 16.3: Server Properties–Dial-Up tab

16-4 Server Properties

other information as appropriate. The correct settings should be obtainable
from existing email server settings or from the ISP.
Note
Test Dial-Up connections using Windows NT’s standard Dial-Up Networking
capabilities.

Mail Batching
MailMarshal supports batch receipt and sending of email messages where on-
demand connection to the downstream email server is not desired. Normally
this option will be used with a dial-up connection. It may also be used with

Figure 16.4: Server Properties–Mail Batching tab

Server Properties 16-5

 ADSL connections where the MailMarshal server does not have a fixed IP
address, or in situations where frequent connections incur high cost. Check the
box to enable the fields on this tab.
Click the Configure Schedule button to see the Delivery/Polling Schedule dialog (see
Figure 16.5). Alter the schedule block if desired:

• Drag using the left mouse button to add to the blue “business hours” area.
• Drag using the right mouse button to erase from the blue “business hours”
area.

• To reset the schedule to the default time block, click on Set Default Schedule.
• Choose to “snap” the schedule times to the nearest whole, half or quarter
hour using the drop down box.
• Select the frequency of connection for inbound and outbound email for
business and out-of-business hours.

Figure 16.5: Delivery/Polling Schedule

Note
When MailMarshal delivers outgoing email it will always poll the server for
inbound email unless the “Never” option is selected in the Check for incoming
mail every drop-down list.

16-6 Server Properties

 • Click on OK to return to the Mail Batching tab.
Note
Mail Batching can be overridden from the MailMarshal Console using the
Send/Receive Now button at the bottom of the Console window.
Next choose how email retrieval will be requested. If the downstream server
controls delivery click the Do Nothing radio button.
To send an ETRN command to a server, click on the radio button and enter
the host name or IP address of the downstream email server.
To collect email from a POP3 account, click on the appropriate radio button
then click on Modify... to obtain the POP3 Email Collection dialog box (see
Figure 16.6). Complete the fields in this box and click on OK. (POP3 can be
used for multiple addresses within a single account. The downstream server
will have a POP3 account containing an email alias for each user.)

Figure 16.6: POP3 Email Collection dialog

The list of POP3 recipient fields is used by MailMarshal to determine the

recipients for messages addressed to multiple users. Additions and deletions
should be made only if problems with delivery occur. Consult the ISP for
information on custom address headers which may be added.
To collect email using a custom executable command, click the radio button
Execute the following command, then enter (or browse to) the full path of the
executable application. For instance, some ISPs use the finger command, eg.

Server Properties 16-7

 c:\winnt\system32\finger example.com@mailhost.com. If a command is required, the
ISP or downstream server operator will provide instructions.

Local Domains
This tab specifies the names of local domains for which MailMarshal will
accept inbound email. The list should include all (and only) the domains of
email addresses your organization actually uses through this gateway. Each
entry in this list should be matched by DNS MX records (and firewall relay
settings, if necessary) so that email for these domains is passed to MailMarshal
for delivery.

Figure 16.7: Server Properties–Local Domains tab

16-8 Server Properties

Local domains may be of two types: Relay or POP3. Email for a relay domain
is sent on to another email server. Email for a POP3 domain is typically
delivered to a mailbox hosted by the MailMarshal server. Often there will be a
single entry in this section for the local email server. However, if the email
server handles more than one domain, multiple entries may be needed. Note
that by default all relay servers defined here will also be allowed to relay
outbound email through MailMarshal.

To Create a New Local Domain

Click New to start the New Local Domain Wizard. Choose the type of local
domain (relay to another server, or POP3). In the final screen, enter the
domain name.
Enter the IP address of the server to which email should be relayed.
Optionally enter a second email server address (used only if the first server is
unavailable). Multiple Relay local domains may be entered using wildcards (eg.
*.ourbusiness.com may be entered to direct email for all subdomains of
ourbusiness.com to a single address). See the section Wildcards below for a
description of MailMarshal’s wildcard syntax.
If this is a POP3 domain, choose the action to be taken for messages addressed
to non-existent mailboxes:
• Forward the message to the administrator account - The administrator email
address is entered in the installation wizard and may be changed on the
General tab of Server Properties.
• Reject the message - A non-delivery message will be returned to the sender
with a “Mailbox/User is unknown” reason code.
• Forward the message to the following Mail Server IP Address/Port - this allows
for messages not destined for POP3 accounts in MailMarshal to be
passed on to another email server for final delivery.
Click Finish to return to the Local Domains dialog.
Note
MailMarshal’s permanent License Keys are bound to the list of local domains
specified here. Each time the list of domain names changes, a new key is
required. Changes in IP addresses or ports, or between relay and POP3
domains, do not require a new key. See the section License Info, later in this
chapter, for information on requesting a new key.

Server Properties 16-9

 When invalidated because of a domain change, the key reverts to a fully
functional 14 day trial. This allows ample time to contact Marshal Software
for a new permanent key. There is no charge for the new key.
Repeat the New Local Domain Wizard for each local domain required. When
all domains have been entered, adjust the order of matching by highlighting a
domain from the list and using the up and down arrows.
Note
Ensure that local domains are matched in the correct order; otherwise email
may be misdirected. Eg. the following sequence is wrong:
*.example.com Forward 10.1.2.1:25
pop.example.com POP3 10.2.5.4:25
Here POP3 mailboxes will be ignored and all email will be delivered to the
first address, ie. 10.1.2.1 port 25, because both domains match
*.example.com. In this example, to have the email correctly delivered,
pop.example.com should be the first domain in the sequence.

To Edit a Local Domain

Select the domain to be edited from the list and click Edit to start the Local
Domain Wizard. Make any changes required, then click Finish.
Note
To change a domain from POP3 to Relay or vice versa, the entry must be
deleted and recreated.

Wildcards
Local domains may be entered using several wildcard characters. The same
characters are used in User and Group matching for standard and receiver rules.
The following syntax is supported:

* Matches any number of characters

? Matches any single character
[abc] Matches a single character from a b c
[!abc] or [^abc] Matches a single character except a b or c
[a!b^c] Matches a single character from a b c ! ^
[a-d] Matches a single character in the range from a to d inclusive
[^a-z] Matches a single character not in the range a to z inclusive

16-10 Server Properties

Examples
*.ourcompany.com matches
pop.ourcompany.com, hq.ourcompany.com, etc.
mail[0-9].ourcompany.com matches
mail5.ourcompany.com but not maila.ourcompany.com
mail[!0-9].ourcompany.com matches
mails.ourcompany.com but not mail3.ourcompany.com
Note
The !, -, and ^ are special characters only if they are inside [ ] brackets.
To be a negation operator, ! or ^ must be the first character within [ ].

Reports
See Figure 16.8. To enable logging of MailMarshal’s message processing, check
the box. When logging has been enabled, the Mail History can be viewed in
the Console and a wide variety of reports run from MailMarshal Reports. For
maximum detail, check the Log Attachment Details checkbox. Choose the period
for retention of data (the default is 100 days).
Click Create/Select Database to choose the location of the SQL database where
the information will be stored. In the Create/Select Database dialog, enter the
name of the SQL Server (or MSDE) computer in the first box. Browse the
network if necessary using the button provided. Enter the name of the
database to use, and the SQL user name and password. (The default user “sa”
does not normally require a password.)
The option Connect using TCP may be chosen where the database is behind a
firewall. TCP port 1433 must be opened through the firewall in this case.
If you believe that a MailMarshal database has previously been installed in the
given location and you do not wish to use it, check the box to recreate the
database.
Note
The database password may be changed using SQL administration tools or
command-line SQL entry. However this procedure must be used with
caution if other applications may be using the database. For further
information please see Marshal Software Knowledge Base article KB203.

Server Properties 16-11

 Figure 16.8: Server Properties–Reports tab

Anti-Relaying
This tab is used to control SMTP Relaying through MailMarshal. Relaying is
the passing of messages to another server for delivery. If an email server
allows open relaying, anyone (including bulk and spam senders) can use the
name and resources of that server. Best practices require relaying to be tightly
controlled.
MailMarshal relaying control may be configured in three locations and by three
different methods: POP3 accounts (see the chapter POP3 Accounts), Receiver

16-12 Server Properties

rules (see the chapter Rules and Rulesets), and this Server Properties tab.
By default MailMarshal is configured to stop all external domains relaying email
through it.
Note
The local domain email servers, entered in the Installation Wizard or the Local
Domains tab of Server Properties, are always allowed to relay through
MailMarshal.

Figure 16.9: Server Properties–Anti-Relaying tab

The list of “local network” addresses determines which additional computers

are allowed to relay email through MailMarshal. For instance, if email clients
such as Eudora send email directly to MailMarshal, their addresses (or the entire

Server Properties 16-13

 internal network) should be added.
To disable anti-relaying completely (not recommended), click to uncheck the
checkbox Prohibit Relaying.
To add the addresses of local servers or networks to the list permitted to relay,
click New to use the New Local Network dialog.
Enter the IP address of a computer or network in the dotted box.
Enter the network mask. A 32 bit mask defines a single address
(255.255.255.255); a 24 bit mask includes a class C network (255.255.255.0)
Select the appropriate radio button to choose whether this range of addresses is
to be included in the local network (permitted to relay) or excluded (forbidden
to relay).
Note
Since addresses not specifically permitted to relay will be forbidden,
exclusions here are only used for exceptions within a permitted group. For
instance, a university using POP3 email clients might include its entire private
net block as permitted to relay, but exclude the portion of the block assigned
to public access computers.
Click OK to add the address range to the list.
To edit an existing range, select it then click Edit. To delete a range, select it
then click Delete.

License Info
See Figure 16.10. This tab displays the details of the current Product License
Key. It also allows enabling of the MailMarshal Secure S/MIME module (if
this module is licensed) and allows configuration of the S/MIME certificate
database.
A new key must be requested if the local domain names are changed. A key
may also be requested to increase the licensed user count, or to purchase the
product (if it is running as a free trial).
To request a new key click the Request Key button. Enter the appropriate
contact information in the form (see Figure 16.11). MailMarshal automatically
appends the current local domain list and key details. Enter any additional

16-14 Server Properties

comments (such as the number of new user licenses desired) in the Additional
Information field. Click Send Request to email the data to Marshal Software.

Figure 16.10: Server Properties–License Info tab

Note
Changing or adding a local domain name will invalidate the license key.
When invalidated for this reason, the key reverts to a 14 day trial. This allows
ample time to contact Marshal Software for a new permanent key. There is
no charge for this service.
If the trial license expires, MailMarshal continues to operate as a SMTP relay
but no rules or limits will be applied. The administrator will be notified daily
by email if a key is due to expire or has expired.

Server Properties 16-15

 Figure 16.11: Request Permanent License Key dialog

To enter a key click the Enter Key button, type or paste the key provided by
Marshal Software, then click OK. An information box will report the validity
details of the key you entered.
To enable MailMarshal Secure S/MIME support, check the appropriate box.
This box will be grayed out if the license key does not support MailMarshal
Secure.
When MailMarshal Secure is enabled, the public Certificate database may be
selected (or created) using the Configure Database button. In the Create/Select
Database dialog, enter the location of the SQL Server or MSDE computer
where the database will reside. It is strongly recommended for speed and
security reasons that the database be created on the MailMarshal server.
The option Connect using TCP may be chosen if the database must be located
behind a firewall. TCP port 1433 must be opened through the firewall in this
case. However this configuration should be avoided.
If a database exists in the location selected, check recreate database to delete it.

16-16 Server Properties

Click OK to return to the Server Properties dialog.

Advanced
Several options are available on this tab.

Figure 16.12: Server Properties–Advanced tab

Change Folders
Locations of the folders used by MailMarshal may be altered. Stop all
MailMarshal services using the Configurator before changing locations.
Before changing folder locations here, the new locations should be planned.
MailMarshal will create the folders, if necessary, during the change process.

Server Properties 16-17

 Any data (such as message files) must be manually moved to the new folders.
Warning
Changing the directory paths may damage the MailMarshal installation if
performed incorrectly. Current settings and data should be backed up before
performing this procedure.
Folder locations are discussed in Marshal Software Knowledge Base article
KB84.
Click on Change Folders to see the MailMarshal Folders dialog box. Enter or
browse for the appropriate location for each folder.
When done, click on OK to close the dialog box and return to Server
Properties, or Cancel to discard any folder location changes.

Export Configuration
The MailMarshal configuration data, including server properties, Rulesets, and
Rule elements, is stored in the Windows Registry (with the exception of user
group information, which is found in the file UserGroups.txt in the
MailMarshal install folder, and files with known fingerprints, which are stored in
the subfolder ValidFingerprints of the MailMarshal install folder).
To export configuration data, click the Export Configuration button. Enter an
appropriate file name and location. To save User Group information, copy
UserGroups.txt. To save fingerprint information, copy the folder
ValidFingerprints and its contents.

Import Configuration
MailMarshal Registry information can be imported, either to restore a
previously created configuration or to merge a partial configuration.
Warning
Export configuration data safely before performing an import. The Merge
function requires a specially created file, and should be used only on advice
from Marshal Software Support.
To import configuration data, click the Import Configuration button. Enter or
browse to the appropriate file name. Choose to overwrite or merge
configurations using the radio buttons. Click OK to perform the import. If
User Group information is needed, copy UserGroups.txt to the MailMarshal
install folder. If attachment fingerprint information is needed, copy the

16-18 Server Properties

required files to the folder ValidFingerprints in the MailMarshal install folder.

Server Threads
Click on the button Server Threads to modify MailMarshal’s usage of processing
threads (see Figure 16.13).
Click on a radio button to select the appropriate size site. The thread settings
selected will be displayed, grayed out, in the spinner boxes.

Figure 16.13: Server Threads dialog

If a custom setup is required, click the appropriate radio button to enable the
spinner boxes. The four choices available for configuration are:
Total Sender Threads - the maximum number of simultaneous threads which
will be used by MailMarshal Sender to deliver messages.
Local Domain Threads - the maximum number of sender threads used to
deliver messages to local domains.
External Domain Threads - the maximum number of sender threads used to
deliver messages to any one non-local domain.
Total Receiver Threads - the maximum number of simultaneous connections
that will be accepted by the MailMarshal Receiver.
Click on OK to return to the Advanced tab.

Server Properties 16-19

 Enable RTF Stamping
Check this box to enable message stamping of messages generated in RTF
format by Microsoft Exchange.
Note
This option requires MAPI32.DLL (and its prerequisites) to be installed on
the MailMarshal Server. This DLL is installed as part of Outlook
97/98/2000 or the Exchange 5.x client. Please see the Marshal Software
Knowledge Base for more information.

Server Array
MailMarshal can be configured into an array of servers, typically for load
balancing purposes. All MailMarshal servers can log reporting information to
the same SQL database. To allow identification of the individual MailMarshal
server logs, each MailMarshal instance (up to 26) may be identified by a letter.
To enable array logging, click the checkbox MailMarshal is used in an array.
Choose an identifying letter from the drop-down box.

Blocked Hosts
This tab is used to enter the names or IP addresses of SMTP servers which are
not allowed to deliver email to MailMarshal. MailMarshal will refuse SMTP
connections from these servers.
To activate host blocking, click the checkbox then click the New button. Enter
a host name or IP address in the field provided. Wildcard entries are not
supported–each host name or address must be entered in full.
To edit an entry in the list, double-click to enable editing.
To delete an entry, select it then click the Delete button.

16-20 Server Properties

 Figure 16.14: Server Properties–Blocked Hosts tab

Host Validation
This tab is used to configure email blocking based on domain name
information. Messages may be blocked outright, or logged, if they come from
a host listed in a MAPS or MAPS compatible database. These databases list
open email relays and other Spam related hosts.
Messages may also be blocked based on reverse DNS lookups to confirm the
identity of the sending host.
Note
These features intentionally refuse email messages from sites that fail the

Server Properties 16-21

 validation criteria. MAPS compatible databases, in particular, are subject to
change without warning. Enable these features only after careful
consideration and monitor the results periodically.

Figure 16.15: Server Properties–Host Validation tab

MAPS Lookups
To enable checking of the MAPS database (and compatibles), check the
appropriate box. Individual databases must also be enabled using the Edit
process (below).
To add a new MAPS-compatible database for checking, click the New button to
see the New MAPS RBL Compatible Validator dialog (Figure 16.16).

16-22 Server Properties

 Figure 16.16: New/Edit MAPS RBL Compatible Validator dialog

The checkbox Enable this validator specifies whether the service will be used.
The checkbox Block email if address is listed specifies how the service is used. If
the box is not checked, email from hosts in the database will be logged to the
Windows NT event log, but not refused. This option is useful for “what if ”
testing purposes.
In the first text box, enter a name by which the service will be known within
MailMarshal.
In the second text box, enter the domain name of the service (eg.
blackholes.mail-abuse.org).
In the third text box, enter a message to return to the external SMTP server if
no message is returned by the MAPS service.
Click OK to return to the Host Validation tab.
To edit a MAPS-compatible database listing, select it and click the Edit button.
To delete a listing entirely, select it and click the Delete button.

DNS Validation
To validate hosts sending incoming email against DNS information, click on
the appropriate checkbox. MailMarshal will perform a reverse DNS lookup on
the IP address from which email is being sent.
Select an option using the radio buttons.

Server Properties 16-23

 Choose to Accept unknown hosts if hosts without appropriate DNS information
are to be allowed to send email, but logged to the Windows NT event log. This
option annotates the message header as “not validated”. It is usually used for
testing or debugging purposes.
Choose Host must have a PTR record to block messages from any host that does
not have a valid DNS PTR record.
Choose PTR Record must match the HELO connection string to block messages from
hosts whose PTR domain does not match the HELO identification sent by the
server. This is the most restrictive option.
Note
Valid email traffic may be blocked by DNS checking if the sending site does
not have PTR records or they are faulty.

Header Rewrite
MailMarshal can modify email header and envelope detail (eg. to allow email
aliasing). Modification is performed by the MailMarshal Receiver during email
message receipt and is controlled by a series of user-configurable header
rewriting rules that are created under the Header Rewrite tab (see Figure 16.17).
The rewriting rules use a regular expression engine to perform the matching
and substitution. Regular expressions are extremely powerful but somewhat
difficult to construct. Great care should be taken to ensure that the rules
perform only the changes required. Some examples of actions that can be
performed are
• Address modification - for example, changing user@host.domain.com to
user@domain.com.
• Field removal - for example, stripping out the received: lines from outbound
messages.
• Alias substitution - for example, replacing addresses via a lookup table, as
in user1@olddomain.com being replaced by user2@newdomain.com.
• Domain masquerading - for example, replacing all addresses in
thisdomain.com with identical addresses in thatdomain.com.
Note
Please note that this is an advanced option and most sites will not need to
use this facility. Test any rules thoroughly, as errors may cause all affected

16-24 Server Properties

 messages to be undeliverable.

Figure 16.17: Server Properties–Header Rewrite tab

Header rewriting rules are created using a wizard. To start the wizard, click
New. The screens in the wizard are as follows:
• An introduction screen that gives warning information.
• A field matching screen to select the header or envelope fields to be
rewritten, and the portion of the field to be modified.
• A substitution options screen where matching and substitution
expressions are entered.
• A naming and test screen for naming the rule and testing the
substitution options.

Server Properties 16-25

 In addition, the order of evaluation of header rewriting rules may be adjusted
using the arrows at the bottom of the Header Rewrite tab (see Figure 16.17).

Field Matching
Most standard email header fields can be rewritten. For instance, to modify the
appearance of internal email addresses to outside recipients you would select a
combination of the fields From:, Envelope return path and Reply-to:.

Consider the following To: header.

To: (A User) auser@domain.com, “Another user at domain2.com”
buser@domain2.com

The following table shows the field data that is passed to the substitution
engine for the various parsing methods.

Parsing method Data passed to the substitution engine

Entire line (A User) auser@domain.com, “Another user

at domain2.com” buser@domain2.com

Email address auser@domain.com

buser@domain2.com

Domain domain.com
domain2.com

When modifying address fields in the email header you would usually select the
field parsing method Email Address. Each email address in the field is then
passed to the substitution engine, while no other characters will be changed.

Substitution Options
An optional exclusion filter allows you to specify an expression that, if
matched, will prevent the field being substituted. This is provided since it can
be difficult to express exclusions in regular expressions.
The field search expression is a regular expression that is used to select the data
that will be substituted. For instance, the expression

16-26 Server Properties

(.+)@(.+)\.ourcompany\.com$
will match a sequence of 1 or more characters followed by an @ followed by
another sequence of 1 or more characters, followed by .ourcompany.com at the
end of the field. That is, it will match john@host.ourcompany.com and
john.smith@host.subdomain.ourcompany.com but not
peter@host.ourcompany.com.au

Figure 16.18: Header Rewrite Wizard–Substitution Options

Substitution Actions
Three actions are available to be taken on the data matched.
Substitute into field using expression allows the matched data to be replaced using a
sed or Perl-like syntax. Using the example given above, the substitution
expression

$1@$2.co.uk.eu

Server Properties 16-27

 would yield john@host.co.uk.eu, john.smith@host.subdomain.co.uk.eu and
peter@host.ourcompany.com.au respectively. The last address may be
somewhat surprising, but data that does not match part of the regular
expression is simply copied across.
Map using file allows a level of indirection in resolving what to substitute into the
field. A map file must be plain text; each line of the file must contain a key and
value pair separated by a comma–for example
john@domain.co.uk, john@domain2.co.uk
peter@domain.co.uk, peter@host1.domain.co.uk
The first entry in the line is a lookup key. The second value is the result to be
substituted in place of the original field when the key is matched. Eg. for a
search expression of
(.+)@domain\.co\.uk$
the above map file and a key expression of
$1@domain.co.uk
would, for the input string john@domain.co.uk, return john@domain2.co.uk.
If the key value is not found in the map file then it is returned unchanged as
the result.
Internal host information for outbound email could be removed using
substitution; the same information could be added to incoming email for
specific users by use of a map file.
Delete the field returns an empty string if the search expression matches. More
usefully, if Entire line is selected in the parsing options, Delete the field removes
the entire header line from the email.
A possible use may be to remove Received: lines from outbound email to hide
internal routing information from external recipients.
To achieve this effect, select the Received: field and a parsing method of Entire
line, then provide a search expression that will match the hosts you wish to hide
and select Delete field. For instance, your search expression might look like
from (secret.host | private.host).my.domain.com

16-28 Server Properties

Note
While such deletions give a higher level of security, they are not generally
recommended as they make tracing any email problems difficult.

Testing
The final dialog of the Header Rewrite Wizard (see figure 16.19) allows the new
rule to be named, and provides for a comment which should explain the
purpose of the rule. To test the rule, enter a sample string in the Source box
and click Test. If the result is not as expected, go back and modify the rule.
When satisfied, click Finish to return to the Header Rewrite tab. If several rules
are in use, adjust the order of evaluation using the arrows.

Figure 16.19: Header Rewrite Rule Wizard–Finish

Regular Expression Syntax

MailMarshal implements a full-featured regular expression syntax. Full

Server Properties 16-29

 documentation of this syntax is beyond the scope of this manual. Additional
documentation and links to further information may be found in Marshal
Software Knowledge Base article KB162.

A few basics are given below.

Reserved Characters
The following characters are reserved as operators:
*.?+(){}[]$\|^
To match any of these characters literally, precede it with \
To match marshalsoftware.com enter marshalsoftware\.com

Wildcard Character .
The dot character . matches any single character.

Repeat Operators * + ? {}
A repeat is an expression that occurs an arbitrary number of times.
An expression followed by * can be present any number of times, including
zero. An expression followed by + can be present any number of times, but
must occur at least once. An expression followed by ? may occur zero times or
once only. A precise range of repeated occurrences may be specified as a
comma-separated pair of numbers within {}. For instance,
ba* will match b, ba, baaa, etc.
ba+ will match ba or baaaa for example but not b.
ba? will match b or ba.
ba{2,4} will match baa, baaa and baaaa.

Parentheses ( )

Parentheses serve two purposes, to group items together into a sub-expression,

and to mark what generated the match.
For example, the expression
(ab)*

16-30 Server Properties

would match all of the string
ababab

Alternatives

Alternatives occur when the expression can match either one sub-expression or
another. In this case, each alternative is separated by a |. Each alternative is
the largest possible previous sub-expression (this is the opposite to repetition
operator behavior).
a(b|c) could match ab or ac
abc|def could match abc or def

Server Properties 16-31

 17. Reports

MailMarshal Reports allows generation of reports based on the information

logged by the MailMarshal Server. A wide range of reports is available
including overall summaries and per-user information.
In order for reports to be generated, logging must first be enabled, either in the
MailMarshal installation wizard or from the Reports tab of Server Properties.
MailMarshal Reports may be installed on any Windows (95 or higher)
workstation which can connect to the logging database. MailMarshal Reports is
implemented as a Microsoft Access 97 or 2000 database application. As such it
requires Microsoft Access and a printer driver to be installed as prerequisites.
The Reports application is available on the MailMarshal distribution CD-Rom,
or by separate download from the Marshal Software web site.

Installing MailMarshal Reports

Insert the MailMarshal CD-Rom and choose Install Reports from the autorun or
Setup Wizard application. Alternatively, run the downloaded MailMarshal
Reports installation file. Carefully read and accept the license information.
Choose a destination location and program folder.
Once installation is complete, run MailMarshal Reports from the Start menu.
When first run, the Reports database will raise the Select Data Source dialog to
configure an ODBC connection to the logging database.
Note
The MailMarshal logging database should be created from the Server (in
Server Properties or the Installation Wizard) before this procedure is
attempted.
If necessary, choose the Machine Data Source tab, then click New.
Choose to create a System data source, with the SQL Server driver. Click Next,
then Finish, to see the Create a New Data Source dialog.
Give the data source a friendly name and description, and select the source

Reports 17-1
 machine from the drop-down list (or enter its name or IP address if necessary).
Select the option SQL Server authentication. Check the box to require login. Use
the login and password configured when the database was created. For MSDE
and many SQL installations, the default login sa with no password will work.
The Client Configuration button is used to select a protocol for communication
with the database. If the logging database is on the other side of a firewall
from the Reports computer, use Client Configuration to choose TCP/IP
connection and port 1433, then click OK. Ensure that the firewall is configured
to allow traffic on this port.
Click Next to continue to the next screen. Check the box to change the default
database; select the MailMarshal database from the list. On the next screen,
click Finish.
In the Reports database, enter the appropriate data source name, user name,
and password if required, then click Connect to establish the connection. The
connection will be remembered when Reports is run again.

To Produce Reports
Run the Reports application from the Start menu.

Figure 17.1: MailMarshal Reports

17-2 Reports
To view the list of available reports, expand the various branches of the left
pane menu tree.
Select a report by clicking on it in the left pane. Information about the report
is shown in the lower right pane. Any options for the report type are given in
the upper right pane.
Choose the appropriate options. To choose an arbitrary range of dates, select
the “Other” radio button, then use the drop down menus to see a date picker.
When all options are chosen, click Preview to view the report on screen.
To print a report, use File|Print from the Access menu. To send the report via
email, use File|Send To and select an appropriate format, such as Rich Text.

Reports 17-3
 18. The Console

The MailMarshal Console is used for day-to-day administration of the

MailMarshal Server. Actions available from the Console include:
• Viewing the status of the MailMarshal services.
• Viewing information on queued outbound email messages.
• Reviewing messages that MailMarshal has moved or copied to folders.
• Releasing or reprocessing messages from folders if appropriate.
• Viewing a list of messages processed and their disposition.
• Viewing service alerts.
• Viewing the status of Mail Batching, if configured.
• Viewing news and support information from the Marshal Software web site.
The Console is installed on the MailMarshal Server computer and may also be
installed on any Windows 95 or higher workstation in the local network. See
the chapter Installation for prerequisites and detailed instructions.
The Console is implemented as a snap-in to the Microsoft Management
Console (MMC). For general information and tips on the MMC, please see the
chapter MailMarshal and the MMC. This manual assumes that the MMC is
displaying the left (menu tree) pane as well as the right (details) pane.

Connecting to the MailMarshal Server

When the Console is first run, or if one console is used to connect to more
than one Server, it is necessary to make a connection. Select Action|Connect to
Server from the menu.
Choose the name of the server from the drop-down list, or browse the network
using the button provided (see Figure 18.1). If the Server expects connections
on a port other than the default 19001, enter the correct value. (For
information on changing this value at the Server, please contact Marshal
Software Support.)
To connect as a user other than the current Windows user, select the
appropriate radio button then enter the user information.

The Console 18-1

 Click OK to attempt to connect.

Figure 18.1: Connect to Server dialog

Console Security Issues

MailMarshal Console uses Windows NT’s secure RPC mechanism to
communicate with the MailMarshal Server. A console user must have an
account and password that can be validated by the MailMarshal Server. If the
MailMarshal machine is in a different domain you can either set up a trust
relationship or create local accounts on the MailMarshal Server computer. If
the Console and the Server are separated by a firewall (eg. if the Server is
located in a DMZ), port 19001 must be opened in the firewall to allow remote
Console access.
To view the email in the quarantine folders the account in use must have read
access to the folders. If you wish to make changes to items (eg. forward email,
kill messages) the account will also need write access. Access to the folders
should be limited by using Windows NT security.
To implement access control for other features, edit the access permissions on
the MailMarshal.key file (in the MailMarshal folder on the server). Read access
to this file allows the user to view the service status, queued domains and mail
history. Write access to this file gives the ability to kill messages, dial now, retry
domains and reload services.

18-2 The Console

The Main Console Screen
In the left pane, expand the element MailMarshal Console to see the console
menu tree. Select MailMarshal Console to view the main Console screen in the
right pane. This screen provides summary information on MailMarshal
operation (see Figure 18.2).

Figure 18.2: The MailMarshal Console

The top section displays the status, version number, and number of messages
processed for each MailMarshal Service. Click the button View Detailed Status to
see details in the MailMarshal Services screen.
The middle section displays recent Service Alerts. Click the button View Alert
History to see a complete list in the Alert History screen.
The bottom section displays information on Remote Access (dial-up
connectivity) and Mail Batching, including the next scheduled send and polling
times. Click the button Send/Receive Now to initiate an immediate check and
dispatch of queued messages.

The Console 18-3

 Note
Messages processed today for each service will not generally be equal. Not all
messages received are delivered (eg. due to quarantine Rules), and
MailMarshal’s notification messages are delivered but not received.

The Services Screen

Select the item Services in the menu tree to view the Services screen in the right
pane (see Figure 18.3). The upper pane of this screen gives information about
the MailMarshal Receiver; the lower pane gives information about the
MailMarshal Sender.

Figure 18.3: The Console Services screen

Receiver State
The following information about the Receiver is available:
Internal Msgs: the number of messages, addressed to recipients in
MailMarshal’s local domains, which have been processed today.
External Msgs: the number of messages, addressed to recipients outside
MailMarshal’s local domains, which have been processed today.
Message details: a pane shows details of each message being processed by the

18-4 The Console

Receiver, and its status.
Active Threads: the number of messages currently being processed by the
Receiver service.
Licensed Users: the number of users recorded in the MailMarshal License
Key.
Current Users: the number of local email addresses from which email has
been received in the last 28 days.
Note
The Current Users value will be displayed in red if the value exceeds the
licensed number. However, rule processing and sending will continue as
normal. Please contact Marshal Software or your reseller to obtain additional
licenses.

Sender State
The following information about the Sender is available:
Internal Msgs: the number of messages, addressed to recipients in
MailMarshal’s local domains, which have been processed today.
External Msgs: the number of messages, addressed to recipients outside
MailMarshal’s local domains, which have been processed today.
Message details: a pane shows details of each message being processed by the
Sender, and its status.
Active Threads: the number of messages currently being processed by the
Sender service.
Msgs Queued: the number of messages waiting to be sent.
Domains Queued: the number of unique Internet domains to which messages
are waiting to be sent.

Sender Actions
A message visible in the detailed Sender list can be killed (deleted) by selecting
it and clicking the Kill Message button.
A detailed list of information about domains for which email is queued (waiting
to be sent) can be viewed by clicking the button View Domains (or the menu tree

The Console 18-5

 item Queued Domains). The listing also shows the number of messages queued,
number of sender threads dedicated to this domain, number of times delivery
has been attempted, and the next retry time.

Domain Detail
Double-click on a domain record in the Queued Domains screen to view details in
the Domain dialog (see Figure 18.4). The upper pane of this dialog shows a list
of MX records found for the domain. The lower pane shows details of each
message awaiting delivery to this domain.
Highlight one or more messages in the lower pane then click Kill Message to
delete the messages. Click the Retry Domain Now icon in the toolbar to force an
immediate attempt to deliver messages to this domain.
Note
These actions will be grayed out if the user does not have sufficient
permissions.

Figure 18.4: The Console Domain Dialog

Message Folders
To view a list of MailMarshal’s message folders, expand the menu item Mail
Folders. These Folders include the Archive, Parking and regular folders into

18-6 The Console

which messages are placed through Rule action, as well as the Dead Letter
folders used for messages which cannot be processed.
To view the contents of a folder, select it in the left pane. The contents will be
displayed in the right pane (see Figure 18.5). Folders may have subfolders
created periodically if this option has been set up in the Configurator. By
default no more than 1000 items will be retrieved for each folder. This number
may be adjusted by choosing Tools|Options from the menu.

Figure 18.5: The Console Folders view

Message Folder Actions

To search for a message by its MailMarshal message name, use the search icon
in the toolbar.
Messages in folders may be forwarded, deleted, processed, and viewed.
Note
Users who have read-only access to a folder cannot delete messages.
Messages in Archive folders cannot be deleted or processed.

Forwarding a Message
To forward a message, select it then click the Forward icon on the toolbar (or
open it then click the Forward icon on the message window toolbar). To forward
to multiple addresses, enter them separated by semi-colons (eg.
RichardN@example.com; GeraldF@example.com).

Deleting a Message
To delete a message, select it then click the Delete icon. This option deletes the

The Console 18-7

 message from the folder permanently.

Processing a Message
One or more messages may be selected for processing. Clicking the Process
Message(s) icon raises the Process Message dialog box (see Figure 18.6). The
following actions are available:

Figure 18.6: Process Message dialog

Continue processing the message: this option continues processing the

message after the Rule which placed it in the current folder. This action may
be used to release a message from quarantine while testing it for any further
violations of policy.
Reprocess the message: this option resubmits the message for processing by
the current set of MailMarshal Rules. This option may be useful when rules

18-8 The Console

 have been adjusted.
Pass the message through: this option allows the message to be queued for
delivery with no further evaluation.
If the checkbox Only apply this action to the following users is checked, the selected
option will be effective for one or more recipients of the message as selected
using the detail checkboxes..
The following additional options are available:
Delete the message after processing (selected by default): Once the selected
actions have been performed, the message is deleted from the folder.
Add attachment fingerprints: Attachments (including images embedded in
MS Word documents) will be saved in the folder ValidFingerprints (located in
the MailMarshal install folder). The unique “fingerprint” of each attachment
will be loaded by the MailMarshal Engine. These attachments can be the subject
of a Rule condition if they are found in the future. See the Standard Rule
condition “where attachment fingerprint is/is not known” for more details. All
attachments, or only images, may be “fingerprinted.”
Note
A file can be removed from the list of recognized fingerprints by deleting it
from the ValidFingerprints folder and reloading the configuration.
MailMarshal automatically deletes a fingerprint (and the associated file) if it
does not trigger a condition for six months.

Viewing a Message and Message Log

To view a message and its associated processing log (which indicates the reason
for its placement in the folder), double-click on it in a Message folder (see
Figure 18.7).
The message headers may be examined by clicking the View Message Header icon
in the message window toolbar.
Note
Processing logs are only available if copied by the Rule which placed the item
in the folder.

The Console 18-9

 Figure 18.7: Message and log display

Interpreting Message Logs

A message log includes information on the structure of the message, and
records any Rules which it triggered and the reasons for triggering.
Figure 18.6 shows a message which MailMarshal has identified as
B00000001.00000001.mml. The message contains a message header (MHDR),
a message body (MBODY), an attached ZIP archive (ZIP), and an executable
file (EXE) included within the archive (inclusion is indicated by the indentation
of the line in the log).
The message log also indicates which Rules were applied to the message, which
if any were triggered, and what action was taken. The log line for a triggered
Rule includes the notation “TRUE” and actions taken follow this line. In the
example, the executable triggered the rule “Block EXECUTABLE Files” in the
ruleset “Inbound Messages” (see the log excerpt below).
...
1452 15:44:57.576 1 user(s) match rule - Block EXECUTABLE Files
1452 15:44:57.576 Name=U1\B000000001.00000001.mml (MAIL,55320) False
1452 15:44:57.576 Name=U2\MsgHeader.txt (MHDR,602) False
1452 15:44:57.576 Name=U2\Plain (MBODY,14) False
1452 15:44:57.576 Name=U2\Fgrep.zip (ZIP,39657) False

18-10 The Console

1452 15:44:57.576 Name=U3\fgrep.exe (EXEW32,82944) TRUE Terminal
1452 15:44:57.576 Requesting Action <Inbound Messages:Block EXECUTABLE
Files:MailTemplate> be run
1452 15:44:57.746 Requesting Action <Inbound Messages:Block EXECUTABLE
Files:LogMessage> be run
1452 15:44:57.746 Requesting Action <Inbound Messages:Block EXECUTABLE
Files:MoveMessage> be run
1452 15:44:57.746 Action LogMessage for Component U3\fgrep.exe
1452 15:44:57.756 Action MoveMessage for Component U3\fgrep.exe
...

If a TextCensor script is triggered, the details of the script evaluation are

included in the log. In the following excerpt, two expressions in the Generic
Chain Letters script were triggered:
...
1452 16:02:24.551 1 user(s) match rule - Block Chain Letters
1452 16:02:24.551 TextCensor triggered: Script Generic Chain Letters Triggered
Expression: chain letter* Triggered 1 times weighting 5
Expression: send this FOLLOWEDBY=6 (many OR all OR friends OR anyone OR
others OR people OR every*) Triggered 1 times weighting 5

1452 16:02:24.551 Name=U1\B000000002.00000001.mml (MAIL,2998) TRUE

Terminal
...

Mail History
Mail History is a record of recent messages processed by MailMarshal. By
default no more than 1000 items will be retrieved. This number may be
adjusted by choosing Tools|Options from the menu.
This information is derived from the report logging database, so logging must
be enabled to view the history.
To view the history, select Mail History in the console tree.
Messages which were successfully sent display a yellow envelope icon and Sent
To: information in the Status column.
Messages which passed the Rule processing but could not be sent display an
icon with a red “x” and the failure reason in the Status column.
If a message triggers a rule which generates a logging classification, the icon
will be blue and the Status column will display the text associated with the
classification. In addition, the Class Code column shows the numerical logging

The Console 18-11

 classification code.

Alert History
To view a historical list of service alerts, select Alert History in the menu tree.

News and Support

Select this item to view the Marshal Software website in the right pane. This
site features the latest support information, including Frequently Asked
Questions, a Knowledge Base, and a Support Forum. To access the full range
of resources, customers should log in to the site. Obtain login details, if
necessary, by contacting Marshal Software.

18-12 The Console

 19. MailMarshal Secure

MailMarshal Secure is an additional module of MailMarshal which implements

the S/MIME (Secure MIME) standard for encryption and signing of email
messages using the Public Key Infrastructure.

What is S/MIME?
S/MIME is an industry standard method of protecting email privacy using the
Public Key Infrastructure (PKI). MailMarshal Secure interoperates with other
S/MIME aware products, whether server-based or workstation-based.
PKI begins with two digital Keys, known as the Public and Private Key. Public
Keys are made freely available, while Private Keys are kept secret and secure.
The Public Key is contained in a digital certificate. A Certificate may be
generated within MailMarshal, or issued by a trusted authority. The Keys are
known as an “asymmetric pair”; messages encrypted using the Public Key can
be read with the Private Key.
Public Certificates are maintained in a database such as MailMarshal’s
Certificate Database. A Certificate may be exported into a file which is made
available to sites with which S/MIME email will be exchanged.
PKI allows email to be processed in two ways, known as Encryption and
Signing. They are often used together–a message may be both encrypted and
signed.
Encryption is the “scrambling” of a message so that it is illegible until
decrypted. Typically email sent to a site will be encrypted with the recipient’s
Public Key (which any sender may have); such messages can only be decrypted
by the recipient using their Private Key.
Signing involves processing a message using a Private Key, to generate a unique
block of data known as the “signature”. The sender “signs” a message using
her Private Key. This signature is sent with the original message. The recipient
can determine that the message is unchanged and that it originated from the
sender, by testing it using the sender’s Public Key.

MailMarshal Secure 19-1

 Options for Using MailMarshal Secure
MailMarshal Secure can be used to encrypt messages from gateway to gateway,
desktop to desktop, or gateway to desktop. Brief explanations of these options
are given below. Details of the MailMarshal Rules required to implement these
options may be found elsewhere in this chapter.
1. Gateway to Gateway: All encryption and decryption of messages is
completed at the server. Internal networks are trusted for security
purposes. This mode is easy to set up and run, because all setup and
maintenance is done at the server. Users simply send and receive email.
MailMarshal can stamp incoming encrypted messages as valid, and can
also perform content checks on the messages. The default rules given in
the section Basic Security Rules, below, support this method.
2. Desktop to Desktop: Encryption and decryption takes place at the email
client (such as Microsoft Outlook). In this case, MailMarshal can still
perform content checks if the messages are also encrypted with a
certificate for which MailMarshal holds the private key. Messages for
which MailMarshal does not hold the key may be passed through
unscanned, or rejected, according to local policy.
3. Gateway to Desktop: MailMarshal can sign outbound messages with a
“proxy certificate” so that the receiving email client recognizes the
message as validly signed from the sending email address. MailMarshal
must hold public keys for all external addresses to which messages are to
be encrypted. This option is used where MailMarshal performs gateway
encryption, but the remote recipient uses desktop encryption software.

Installing MailMarshal Secure

MailMarshal Secure is available on the MailMarshal CD-Rom or in the
downloadable installation file. The product requires an S/MIME enabled
License Key, available from Marshal Software resellers and the Marshal
Software sales department (sales@marshalsoftware.com). Trial license keys
available from the Marshal Software website do not enable MailMarshal Secure.
MailMarshal Secure is installed with the Complete installation of MailMarshal.
MailMarshal Secure requires Windows NT SP 6a or Windows 2000 with 128 bit
encryption, and a MSDE or SQL server to host the Public Certificate Database.
If a minimal installation of MailMarshal was performed, rerun the MailMarshal
installation program and select the option “MailMarshal S/MIME Server.”

19-2 MailMarshal Secure

This may be done without affecting current settings. For full details of the
installation process, please see the chapter Installation.
Note
It is very strongly recommended, for speed, security, and availability reasons,
that the Certificate Database be installed on the MailMarshal Server
computer; therefore the installation program requires that SQL 7.0 or MSDE
be installed locally. In some cases (for instance, a cluster installation) the
Certificate Database can be created on a different server.
Once the S/MIME module is installed, select Tools|View License Details from the
Configurator menu bar to see the License Info tab of Server Properties (see
Figure 19.1)

Figure 19.1: The License Info tab of Server Properties

MailMarshal Secure 19-3

 Click Enter Key and enter the S/MIME enabled Key.
Check the box Enable Security. Click the button Create/Select Database to connect
to a Certificate Database.
In the Create/Select Database dialog, enter the location of the SQL Server or
MSDE computer where the database will reside. It is very strongly
recommended for speed, security, and availability reasons that this be the
MailMarshal server.
If a database exists in the location selected, check “recreate database” to delete
it.
Click OK to return to the License Info tab, and OK again to exit Server
Properties.

Setting Up S/MIME Features

Preparing MailMarshal Secure’s S/MIME features for use involves three steps:
1. Create a Domain Certificate (also known as a Server Certificate). The
same certificate may be used to process email for several domains using
Gateway-to-Gateway encryption. See the section Working with Certificates
below.
2. Exchange certificates with other sites. Since email messages will typically
be encrypted and signed in both directions between two or more
organizations, each must have the appropriate information to encrypt
for, and validate signatures from, the other. See the section Exchanging
Certificates below.
3. Configure Security Rules. A basic set of Security Rules is required to
ensure the security of encrypted links with other sites. See the section
Basic Security Rules and the detailed descriptions of Security Rule
Conditions and Actions below.

Working with Domain Certificates

Within MailMarshal, Certificates are created and managed using the Certificate
Manager. To access the Certificate Manager, choose Tools|S/MIME Certificate
Manager from the Configurator menu bar.
The Certificate Manager dialog offers five tabs:
Our Domains - used to create and manage Certificates for local domains.

19-4 MailMarshal Secure

Only certificates under this tab will have private keys associated with them.
Other People - used to import and manage Certificates for individual email
addresses (whether inside or outside the Local Domains). Domain Certificates
for external domains also appear on this tab, if they are generated by a
Certification Authority.
Intermediate Cert Authorities - used to import and manage Certificates
provided by external authorities which provide a certification link between a
Root Authority and the local Certificate.
Trusted Root Cert Authorities - used to import and manage Domain
Certificates from other Certification Authorities. These include other sites’ self-
signed certificates and certificates provided by Certification Authorities such as
VeriSign, BayCorpID, and Thawte.
CRLs - used to import and manage Certificate Revocation Lists, which are
provided by Certificate issuers to invalidate Certificates before their expiration
date. CRLs may be automatically updated from an Internet source.

Figure 19.2: MailMarshal Certificate Manager–Our Domains tab

Note
The Import button for Certificates is available on the first four tabs. It will
import the certificate to the appropriate location based on certificate type,
regardless of which tab is showing. Eg. a personal certificate will be placed in
the “other people” list even if import is invoked while the “our domains” tab

MailMarshal Secure 19-5

 is showing. A Domain Certificate provided by a Root CA may import as
many as three certificates.

Our Domains tab

This tab is used to create and manage Certificates for local domains (see Figure
19.2).
Create a New Certificate: Click on New to see the New Domain Certificate Details
dialog (see Figure 19.3). Enter the name of your organization and the domain
for which the certificate is to be used.

Figure 19.3: The New Domain Certificate Details dialog

Select a key strength using the radio buttons. Stronger keys are more secure but
require more processing time when used. 1024 bits is the standard key strength
in common use.
If desired, check the box to generate two certificates, one for signing and one
for encryption. The appropriate settings will be entered into the database for
each certificate.
Select a validity period using the radio buttons. Shorter validity periods require
more administration (as new certificates must be created and exchanged), but
may enhance security by becoming outdated more quickly.
Choose the source of the certificate using the radio buttons. Self-signed
certificates are typically adequate for encryption and signing between partner

19-6 MailMarshal Secure

sites which trust each other. A certificate from a CA (Certificate Authority)
may be desired where messages are to be signed to prove their origin publicly
(eg. to guarantee that information in a message comes from your company).
The CA undertakes that the certificates it issues were issued to the company
named in the certificate. There is no difference in the encryption strength
between self-signed and CA certificates.
Click OK. If the certificate is self-signed, it will be created and entered in the
“Our Domains” list ready for use.
If the certificate is to be requested from a CA, a certificate request string will
be provided in a new window. Copy this information into the certificate
request to the CA. A notice of the request will appear in the “Our Domains”
list. When the certificate is received from the CA, import it (see below) and
delete the request notice if necessary.
Import Certificate: Click on Import and choose the name of a certificate file to be
imported. MailMarshal recognizes several common certificate file types.
Note
PKCS12 certificates (.pfx files) may be imported into MailMarshal by first
importing them into the Microsoft Certificate Store then using the Import from
Win button (see below).
Delete Certificate: Select a Certificate from the list and click on Delete.
Warning
This action will permanently destroy the Certificate and the private key for
this domain. A new one can be created, but it will not allow decryption of
email sent using the old certificate. If no backup of the Certificate exists, it
will be necessary to create a new certificate and distribute it to everyone who
was using the old one.
Export Certificate: Select a Certificate from the list. Click on Export, then choose
the file format to be used. Enter the file name and location, and save the file.
This file may be sent to another site if appropriate for use in transmitting
encrypted email. (Only the Public Key is exported.)
View Details: Select a Certificate from the list, then click View Details to see the
information it contains including validity dates (see Figure 19.4). In the View
Certificate dialog, select the Certification Path tab to see the details of all
certifying authorities. MailMarshal Secure’s self-signed certificates will be signed
by “domain-confidentiality-authority” or “review-authority”.

MailMarshal Secure 19-7

 Figure 19.4: The View Certificate dialog–Details tab

Edit Settings: Select a Certificate from the list, then click Edit Settings to bring up
the Edit Certificate Details dialog (see Figure 19.5).

Figure 19.5: The Edit Certificate Details dialog

If this Certificate is to be used to process email to or from more than one

19-8 MailMarshal Secure

email domain, add the appropriate names to the list in the top pane. Eg. the
certificate created for marshalsoftware.com might also be used to decrypt
messages addressed to marshalsoftware.co.nz. External domains wishing to
send encrypted messages should be informed of this setting. Enter one
domain name per line. Wildcards are not allowed.
Check the appropriate boxes to indicate whether the certificate is preferred for
encryption and/or signing purposes.
Note
If the “preferred” certificate is not available (eg. because it is out of date),
another certificate for the same domain will be used, if available. This may
cause an encrypted message to be undecryptable if the recipient does not
have the appropriate key.
Choose whether to leave or remove a signature based on this key when it is
found on incoming email. Typically the signature will be removed in gateway to
gateway encryption situations (since MailMarshal has verified it). The signature
should be left in desktop to desktop encryption situations so it can be verified
by the client software.
Proxy Certificates: Select a certificate and click the Proxy Certificates button to
generate a Proxy Certificate for a specific user in the domain governed by the
certificate. See the information on Security Rule Actions later in this chapter
for uses of Proxy Certificates.
Note
MailMarshal Secure will generate Proxy Certificates on the fly and retain them
for future use. It is not normally necessary to create Proxy Certificates
manually. Proxy Certificates require a specific Domain Certificate for each
domain supported.
Import from Win: Click this button to import a Certificate (with its associated
Private Key if available) from the Windows Certificate Store on the local
computer.
Export to Win: Select a Certificate then click this button to export a Certificate
(with its associated Private Key) to the Windows Certificate Store on the local
computer.

Other People tab

(See Figure 19.6 for features typical of the next three tabs.) This tab is used to

MailMarshal Secure 19-9

 import and manage Certificates used for individual email addresses, whether
inside or outside the Local Domains, and Domain Certificates for external
domains which have been issued by CAs.

Figure 19.6 : The MailMarshal Certificate Manager dialog–Trusted Root CA tab

Import Certificate: Click on Import and choose the name of a certificate file to be
imported. MailMarshal recognizes several common certificate file types.
Delete Certificate: Select a Certificate from the list and click on Delete.
Export Certificate: Select a Certificate from the list. Click on Export, then choose
the file format to be used. Enter the file name and location, and save the file.
This file may be sent to another site if appropriate for use in transmitting
encrypted email.
View Details: Select a Certificate from the list, then click View Details to see the
information it contains including validity dates. In the Details dialog, select the
Certification Path tab to see the details of all certifying authorities.
Edit Settings: Select a Certificate from the list, then click Edit Settings to bring up
the Edit Certificate Details dialog (see Figure 19.5).
If this Certificate is to be used to process email to or from more than one
email domain, add the appropriate names to the list in the top pane. Ask the
certificate holder for a list of valid domains. Enter one domain name per line.
Wildcards are not allowed.
Choose the level of trust for the certificate. Explicitly Trust This Certificate, the
default, allows the certificate to be used. Explicitly Don’t Trust This Certificate will

19-10 MailMarshal Secure

cause messages related to this certificate to be rejected. Inherit Trust from Issuer
(only available for CA issued certificates) bases the trust level on the trust for
the root certificate to which this certificate is chained.
Choose whether to leave or remove a signature based on this key when it is
found on incoming email. The signature might be left if the end user may wish
to verify it.

Intermediate Cert Authorities tab

This tab is used to import and manage Certificates provided by external
authorities which provide a certification link between a Root Authority and the
local Certificate.
The available buttons and actions are the same as those for “Other People” (see
above). Note that the trust level for some individual and domain certificates
may depend on the level of trust granted to intermediate certificates.

Trusted Root Cert Authorities tab

This tab is used to import and manage Domain Certificates provided by other
sites, including self-signed and Root Authority certificates.
The available buttons and actions are the same as those for “Other People” (see
above). Note that the trust level for some individual, intermediate, and domain
certificates may depend on the level of trust granted to Root certificates.

CRLs tab
This tab is used to import and manage Certificate Revocation Lists, which are
issued by Certificate issuers to invalidate Certificates before their expiration
date.

Figure 19.7: The MailMarshal Certificate Manager dialog–CRLs tab

Import from File: Click this button and select a file containing the CRL to be

MailMarshal Secure 19-11

 imported. Information on the CRL will appear in the list.
View Details: Select a CRL from the list and click this button to view the details
of the CRL. The first tab shows a list of Certificate serial numbers which are
revoked. The second tab, Updating, allows entry of a URL from which the
CRL should be updated when it expires (see Figure 19.8).

Figure 19.8: The CRL Details dialog–Updating tab

Delete: Select a CRL from the list and click this button to delete it. MailMarshal
will no longer have access to the revocation information from this source.
Note
Automatic CRL updating requires MailMarshal to access remote websites.
The Internet connection and proxy settings should be configured within
Internet Explorer on the MailMarshal Server computer.

Backing Up Certificates and Keys

This is very important. Keep a copy of all Private Keys and the associated
Certificates. Each certificate in the Our Domains tab must be exported. A
simple way of doing this is to export the Certificates to Windows, then export
them from Windows in PKCS12 format (including Private Keys). The
exported information should be kept securely (eg. on a floppy disk in a safe).

Protect the Certificates Folder

This is very important. The Certificates folder is located in the MailMarshal
installation folder. Please control access to this folder very carefully as, if
anyone gains access to it, the security of your email may be compromised. If
someone has a copy of the files inside the directory, they would possibly be
able to decrypt and read your email and impersonate you.

19-12 MailMarshal Secure

Exchanging Certificates
To exchange encrypted email between sites, it is necessary for each site to
import the other’s certificates.
Export the domain certificates for local domains from the MailMarshal
Certificate Manager’s Our Domains tab. Email these certificates to the other
domain’s administrator. Alternatively if the other endpoint for encryption is a
client application that does not recognize domain certificates, it may be
necessary to create a proxy certificate for each user and export these.
Import the remote site’s certificates using the Import button in the MailMarshal
Certificate Manager.

Checking Imported Certificates

A certificate contains the encryption key for the related addresses. If the
wrong certificate is installed, encryption may not function correctly and security
may be broken.
To check that the correct certificate is installed, compare the “thumbprint” of
the certificate against the thumbprint of the certificate installed at the other
site. In the MailMarshal Certificate Manager, select the certificate to be checked
then click View Details. Two versions of the thumbprint, SHA1 and MD5, are
given if available. Confirm the thumbprint string with the administrator or user
at the other site. Perform this action for both sites’ certificates.

Basic Security Rules

MailMarshal controls S/MIME encryption and signing using Rules which are
maintained in the same way as content checking rules. When MailMarshal
Secure is installed and enabled, creation of Security rules is enabled in the Rule
Wizard.
Please refer to the chapter Rulesets and Rules for basic information on creating
and editing Rules.
The following Ruleset entitled “Encryption with OtherCompany” contains a
basic set of rules required to ensure that all email between the two sites is
encrypted, signed, and verified. More complex rules are possible, but this set
should be regarded as a minimum for secure communications.
The Ruleset is created with no common User Matching entries.

MailMarshal Secure 19-13

 1. The first two rules specify that outgoing messages are to be encrypted
and signed, and state what should happen if encryption cannot be
completed:
When a message arrives
Where addressed to othercompany.com
Sign message with an opaque domain certificate
and encrypt message with the domain certificate

When a message arrives

Where addressed to othercompany.com
Where message cannot be encrypted for one or more recipients
Send a Can’t Encrypt notification message
and move the message to Encrypt Problems

2. The next two rules check that incoming messages are validly encrypted
and signed, and warn the user (or other appropriate person) if they are
not. Warning could be by stamping or by email notification.
Note
A more restrictive option would be to quarantine such messages in a Folder.
When a message arrives
Where addressed from othercompany.com
Where message is not encrypted
Send a Not Encrypted notification message
and pass the message to the next rule for processing

When a message arrives

Where addressed from othercompany.com
Where message signature is Not Verified; Not Found
Stamp message with Message NOT signed
and pass the message to the next rule for processing

3. The next rule blocks any email that MailMarshal can’t decrypt. If
MailMarshal cannot decrypt the message it will be unable to check the
contents.
When a message arrives
Where addressed from othercompany.com
Where message is encrypted and cannot be decrypted
Send a Can’t Decrypt notification message
and move the message to Encrypt Problems

19-14 MailMarshal Secure

Rule Conditions–Security Rules
This section includes detailed information on the Rule Conditions available
within Security rules. User Matching conditions are the same as those available
in Standard Rules.

Where message is encrypted and cannot be decrypted

By default, MailMarshal attempts to decrypt all encrypted messages. Use this

condition to detect and block messages that MailMarshal cannot decrypt and
check. This condition triggers when both of the following are true:
• firstly, a message has been encrypted by someone else. In the case of an
incoming message that “someone else” may be another MailMarshal server.
In the case of an outgoing message it may be a user within your company,
possibly using the encryption features in an email client such as Microsoft
Outlook.
• secondly, MailMarshal cannot decrypt the message (this occurs when the
message was encrypted using a certificate for which MailMarshal does not
hold the Private Key). Typically, MailMarshal has private decryption keys only
for the site’s server certificates.
Note
If MailMarshal cannot decrypt a message, then it cannot scan it to check its
content. Most companies will want to block email that cannot be decrypted
by the MailMarshal server.

Where message is encrypted and can be decrypted

This condition can be used in conjunction with the previous condition (eg.
when the site wants to stamp incoming encrypted email to indicate its secure
status). The condition will trigger when
• a message has been encrypted using the S/MIME protocol, and
• MailMarshal has a private key for the message and can read it.

Where message is not encrypted

This condition is often used to double-check that all email from another site is
secure. For example, the administrator should be informed if another site
accidentally stops encrypting the email that it is sending.
The condition will trigger when a message is plain text without encryption.

MailMarshal Secure 19-15

 Where message signature is
This condition will trigger when the signature in the message matches the
options set in the Signature dialog box (see Figure 19.9).

Figure 19.9: The Signature dialog

A number of sub-conditions are available within this condition. More than one
Rule could be implemented to inform administrators and recipients about the
various outcomes.
Message was signed and verified: The message has a valid signature. This
option might be used to stamp validly signed messages to assure the user of
this fact.
Not signed: The message has no signature. This option is used to check that
email is signed.
Signing certificate has expired: The message has no valid signature–either
the signing certificate, or a certificate in the chain of trust, has expired.
Signing certificate is not trusted: The certificate, or a certificate in the chain
of trust, has been marked as distrusted by the administrator (using the
MailMarshal Certificate Manager).
Signing certificate could not be verified: MailMarshal has been unable to
check the trust of the certificate (eg. the certificate or its root are not in the
database, or the email address for the sender does not match the address set up
for the certificate).

19-16 MailMarshal Secure

Signing certificate has been revoked: The certificate issuer has revoked the
certificate (included it in a Certificate Revocation List). This means that the
certificate is not to be used because (eg.) it has been lost or stolen.
Message has been altered: The content of the message has been changed
since it was signed. (This may have occurred intentionally or accidentally.)

Where message cannot be encrypted for one or more recipients:

This condition triggers when
• the rules state that the message should be encrypted, and
• MailMarshal cannot find a certificate to use for encryption.
In this case, MailMarshal would have to encrypt the message for some
recipients, but send a plain readable message to the others. This would
compromise the security of the message. The recommended action in this case
is to move the message to a folder and notify the sender and/or administrator.
Note
The Rule containing this Condition should be evaluated after any other
encryption Rules. This condition overrides MailMarshal’s default behavior
which is to move the message to the Encryption DeadLetter folder and notify
the administrator.

Rule Actions–Security Rules

Sign message with certificate
Domain Certificate: Uses the certificate for the domain from which the
message originates.
Note
MailMarshal follows the latest Internet protocols but many applications
(Microsoft Outlook, for example) will not work correctly with domain
signatures. These applications will read and display the email, but erroneously
warn the user that the signature is invalid. If sending signed email which will
be verified by a desktop client, use Proxy certificates.
Proxy Certificate: Use this option when communicating with applications that
do not accept domain signatures. Proxy certificates contain the same
information as domain certificates but have an email address for an individual
user.

MailMarshal Secure 19-17

 MailMarshal creates these certificates automatically on the fly. For example, if
the rules tell MailMarshal to sign a message from “auser@ourcompany.com”
with a proxy certificate, MailMarshal will generate a new certificate for the user
and will keep it in the database for later use. It is not necessary to give the
certificate to the end user.

Figure 19.10: The Sign Message dialog

Attach signature as follows: if set to “Opaque,” the signature will be

combined with the message in one block of data so that the format is unlikely
to be changed accidentally when being transmitted via the Internet.
If set to “Detached,” the signature will be saved into the message separately
from the content. Therefore anyone can read the message–even if their email
system does not support S/MIME. (Use this option if there are compatibility
problems with another site.)
Calculate the signature with the following algorithm: Select the algorithm
to use from the drop down box. Two algorithms are in common use, SHA1
and MD5. Both provide adequate security protection but SHA1 may be
preferred. (Use this option if there are compatibility problems with another
site.)
Annotate the message as domain signed: This option adds a flag to the
signature. When email is received from another site the flag is used to tell
whether the signature was created by the server software or by the end user.
(Uncheck this option only if compatibility problems are reported, which is
unlikely.)

19-18 MailMarshal Secure

Encrypt message with certificate
Use this action to encrypt messages so that they can only be read by the
intended recipient. There are several encryption options (see Figure 19.11).

Figure 19.11: The Encrypt Message dialog

Encrypt using the recipient’s certificate: This option is used when a

recipient is using S/MIME at desktop level. MailMarshal will look in the
database for a certificate with an address that matches the “To:” address. It will
not use a domain certificate.
Encrypt using the recipient’s domain certificate: This option is used when
a recipient’s site is using Email Gateway software such as MailMarshal.
MailMarshal will look in the database for a domain certificate set up for anyone
in that domain.

MailMarshal Secure 19-19

 Encryption for recipient and domain: This option is a combination of the
two previous options. MailMarshal will encrypt using both certificates. Both
the recipient’s Email Gateway software and the recipient will be able to decrypt
and read the message.
This option would be used if message protection is required to the recipient
level but the recipient’s company email gateway software blocks messages that it
cannot read.
None of the above: MailMarshal will not encrypt with either the recipient’s
individual certificate or their domain certificate, it will only use the escrow
certificate.
Additional email addresses (for escrow): MailMarshal will use a certificate
that matches the email addresses specified in this box. This option is used in
situations where a third party may decrypt and read the messages (eg. secure
archive, proof of sending, auditing).
Encrypt with sender’s certificate: MailMarshal will also encrypt using the
certificate for the sender so that the sender can reopen sent email.
Encryption algorithm: MailMarshal can encrypt using several algorithms. It is
recommended that you use the strongest, Triple DES. However, another
setting may be used to allow for recipients who are running incompatible
software.
Search for certs on these LDAP servers: If no valid certificate is found in
MailMarshal’s Certificate Store, MailMarshal can try to retrieve a certificate
from the LDAP servers specified in the list. LDAP can only be used for
individual recipient certificates (domain certificates do not have a commonly
used format).

Click the Add button beside the LDAP servers list. Select an LDAP connection
to be added to the list. If more than one connection is specified, MailMarshal
will query the servers in order from top to bottom. To configure LDAP
connections for certificates, see the chapter LDAP Connections.
Note
Use this feature only as a backup, or where certificates are known to be
available for the addresses affected–for example, where a company stores
certificates for all employees on the LDAP server. If a certificate is not
available, the email message will be deadlettered (unless a Rule overrides this
behavior–see the condition Where message cannot be encrypted).

19-20 MailMarshal Secure

Do not decrypt message

MailMarshal decrypts all messages received (for which it holds an appropriate

Certificate) so that content Rules may be applied before delivery. If this action
is specified MailMarshal will deliver the original encrypted version to the
recipient. This action is used when email must be protected all the way to a
desktop.

MailMarshal Secure 19-21

 20. Case Studies

When using MailMarshal in an organization, the various features must be

configured to work effectively with each other and with the network
environment. This chapter provides several simple examples and suggestions
of how to put MailMarshal to work:
• Implementing an Acceptable Use Policy (SmartCo).
• Safeguarding a company’s name change.
• Encrypting email.
• Blocking SPAM.
• Implementing email aliasing.

SmartCo
SmartCo is a merchandise marketing company with about 200 employees.
These employees use email for a number of different business-related purposes.
SmartCo has deployed MailMarshal to support its Acceptable Email Use Policy.
The Policy has several goals:
1. to protect the company’s systems against virus infection.
2. to ensure the efficient use of network resources (bandwidth and file
storage).
3. to ensure that internet email is used in ways appropriate to employees’
responsibilities.
4. to address legal liability and intellectual property issues.
To implement its Acceptable Use Policy, SmartCo has implemented several of
the Rulesets which are provided with MailMarshal. Most of the elements have
simply been “turned on”, although some have been customized slightly. Policy
compliance is monitored using MailMarshal Reports to report on triggered
rules.
All of the Rules discussed below are found in three MailMarshal Rulesets which

Case Studies 20-1

 are turned on by default: Inbound Messages, Outbound Messages, and Bothways.
Many of these Rules also use default notification templates and write logging
classifications to the reports database.

Protecting Against Viruses

Protection against virus infection (inbound and outbound) is provided in three
ways.
• Traditional virus scanning is implemented using the Block Virus Rule. Before
this Rule can be turned on, a virus scanner must be installed and configured
(see Figure 20.1).

Figure 20.1: SmartCo’s Virus Scanners setup

• Script-based viruses and viruses associated with known message text are
blocked using using three Rules: Block VBScript, Block JavaScript, and Block
Known Worms. These Rules invoke TextCensor scripts to scan the content of
the messages and attachments.
• Viruses and other malicious code are further limited by two additional Rules,
Block Dangerous Attachments and Block Executable Files. These rules check the
actual file extensions and the internal file types of attached files. Because the

20-2 Case Studies

 Information Technology department commonly receives executable files by
email, these rules have been modified to allow receipt of the required files
(see Figure 20.2).

Figure 20.2: Block Attachments Rule Exception

Conserving Network Resources

The goal of conserving network resources is achieved in several ways.
• Oversized messages are stopped by two rules in the Bothways ruleset. The
Receiver rule Globally deny over 30MB refuses delivery of very large messages
where ESMTP information is available. The Standard rule Globally quarantine
over 30MB stops large messages when ESMTP is not available. Together these
rules stop very large messages from being delivered.
• Hoaxes and chain letters are limited by the Block Hoax Messages Rule, which
invokes a TextCensor script. The TextCensor script has been modified to test
for an additional hoax message (see figure 20.3).

Case Studies 20-3

 Figure 20.3: Custom TextCensor item

• Messages from known junk mail sites are blocked using the Block Junk Mailers
Rule. To support this Rule, a list of problem addresses has been added to the
user group JunkMailers.
• Outbound mass mailings are deferred until after business hours using the Park
large files Rule. This helps to maximize the network bandwidth available
during the day.

Ensuring Appropriate Usage

“Appropriate usage” is defined in terms of the content of email messages.
• Appropriate textual content of messages is checked with the Block Unacceptable
Language rules in the Inbound and Outbound Rulesets. A TextCensor script
checks the body and attachments of messages.
• The blocking of executable attachments also contributes to this goal as users
cannot receive or send joke executables.

Reducing Legal Liability

Legal liability issues can arise due to inappropriate content of messages, and
also due to questions about the ownership of messages.
• Intellectual Property and liability issues are addressed with a custom message
stamp which asserts SmartCo’s ownership of messages (see Figure 20.4).
• The Unacceptable Language filter also helps to address liability issues by
limiting problematic content.

20-4 Case Studies

 Figure 20.4: SmartCo’s Custom Message Stamp

Reports
SmartCo tracks compliance with its Acceptable Use Policy using the
MailMarshal Reports. The primary report used is the detailed report Logging
Rule by Local Domain. This report shows the number and size of messages
which triggered each Rule, by user name.
The graphical bandwidth usage report is also used for planning purposes.

Company Name Change

In an actual case, MailMarshal was configured to prevent premature release of a
company’s name change. This application required the addition of a Rule for
outgoing email, which invoked a TextCensor script to monitor messages for the
new company name. Offending messages were blocked, and the sender and
administrator were notified.
The following Rule and TextCensor script could be used, in conjunction with
standard templates and classifications, to implement this function.

Standard Rule: Name Change Secret

Forbids sending of the new company name outside the company
When a message arrives

Case Studies 20-5

 Where message is outgoing
Where message triggers text censor script(s) Name Change
Send a Sensitive Mail to Internet notification message
And write log message(s) with Message Sensitive Material
And move the message to Suspect

Figure 20.5: Custom TextCensor Script–Name Change

Encrypted Email
The Basic Security Rules section in the chapter MailMarshal Secure contains a set of
rules which implements encrypted email from gateway to gateway.
Two enhancements to this ruleset are suggested to cover additional cases:
multiple gateway-to-gateway partners, and gateway-to-desktop encryption for

20-6 Case Studies

external recipients who use a desktop encryption client such as Microsoft
Outlook.
Note
In all cases described here, users within the MailMarshal site do not need to
take any special action to encrypt email. They simply send messages, and
MailMarshal does the rest.

Multiple Gateway-to-Gateway Encryption Partners

Create a User Group called Gateway Encryption Partners. Change the rule
conditions Where addressed to: and Where addressed from: so that they refer to this
User Group rather than a particular domain.
To implement message encryption to an additional domain, first import the
appropriate Certificate for the domain into MailMarshal’s Certificate Store; then
add the domain name to the User Group Gateway Encryption Partners.

Gateway-to-Desktop Encryption Partners

Create a User Group called Desktop Encryption Partners. Use this group to
collect all individual email addresses for which gateway-to-desktop encryption is
enabled.
To implement message encryption to an address, first import the remote user’s
Certificate into MailMarshal’s Certificate Store; then add the SMTP address to
the User Group Desktop Encryption Partners.
A ruleset implementing these features will appear as follows:
1. The first three rules specify that outgoing messages are to be encrypted
and signed, and state what should happen if encryption cannot be
completed. Gateway and Desktop recipients are treated separately:
When a message arrives
Where addressed to Gateway Encryption Partners
Sign message with an opaque domain certificate
and encrypt message with the domain certificate

When a message arrives

Where addressed to Desktop Encryption Partners
Sign message with a detached proxy certificate
and encrypt message with the recipient certificate

When a message arrives

Case Studies 20-7

 Where addressed to Gateway Encryption Partners; Desktop
Encryption Partners
Where message cannot be encrypted for one or more recipients
Send a Can’t Encrypt notification message
and move the message to Encrypt Problems

2. The next two rules check that incoming messages are validly encrypted
and signed, and warn the user (or other appropriate person) if they are
not. Warning could be by stamping or by email notification.
When a message arrives
Where addressed from Gateway Encryption Partners; Desktop
Encryption Partners
Where message is not encrypted
Send a Not Encrypted notification message
and pass the message to the next rule for processing

When a message arrives

Where addressed from Gateway Encryption Partners; Desktop
Encryption Partners
Where message signature is Not Verified; Not Found
Stamp message with Message NOT signed
and pass the message to the next rule for processing

3. The next rule blocks any email that MailMarshal can’t decrypt. If
MailMarshal cannot decrypt the message it will be unable to check the
contents.
When a message arrives
Where addressed from Gateway Encryption Partners; Desktop
Encryption Partners
Where message is encrypted and cannot be decrypted
Send a Can’t Decrypt notification message
and move the message to Encrypt Problems

Blocking Spam
MailMarshal provides several resources for blocking Unsolicited Commercial
Email and other forms of Spam.
Two anti-Spam Rules are present in the default Inbound ruleset and should be
enabled.
• Block Junk Mailers checks for email addresses associated with unwanted
email. The addresses are contained in the User Group Junk Mailers, which

20-8 Case Studies

 must be edited by hand.
• Spam Filter uses a TextCensor script to check message contents.
Additional anti-Spam measures may be taken in Server Properties, using the
features found on the Host Validation and Blocked Hosts tabs. These features
allow messages from particular sources to be rejected absolutely before delivery
is completed. See the appropriate sections of the chapter Server Properties for
details.
Note
The host blocking features do not log their actions to the MailMarshal logs
(only to the Windows NT application log). Further, they cannot be adjusted
as finely as MailMarshal’s Rules.
They should be used with caution.

Email Aliasing
MailMarshal’s Header Rewrite facility can be used to allow email aliases for an
organization. Aliasing may be useful where internal email is addressed to many
servers but outside users use a single domain name for all recipients.
An example of rewriting of outbound message headers (to control the visibility
of internal servers and addresses) is provided in the Header Rewrite section of
the chapter Server Properties.
An example of rewriting of incoming message envelope details (to direct each
recipient’s messages to the appropriate internal server) may be found in the
Knowledge Base on the Marshal Software website.

Case Studies 20-9

 21. Troubleshooting

A number of problems may arise when using email systems that can interfere
with MailMarshal operation. Therefore, if a problem occurs it may be that
MailMarshal is reflecting an external or internal email or network problem.
When analyzing problems, the following resources may be useful.

MailMarshal Console
Check to see that the MailMarshal services are running. The Alert History
shows stop and start information for each service. If necessary, restart the
services using the Configurator.
Note
If the MailMarshal Controller service is stopped, the other services cannot
continue and the Console and Configurator will indicate “Failed to Connect”.
Restart the MailMarshal Controller using the Windows Control Panel Services
applet.
Check the Console Services screen to see whether email is being processed.
Check the Mail History screen to see whether email has being sent, and any
errors that the Sender may have encountered. If there are many “Failed to
connect” or “Unable to resolve domain” messages this usually indicates a
downstream network, SMTP, or DNS problem.

Windows NT Event Viewer

If there are difficulties when starting any of the MailMarshal services, or there
are any pop-up error messages, start the Windows NT Event Viewer and check
the application log.

MailMarshal Working Directories

Check the MailMarshal sub-directories to see where email messages are trapped.
The normal flow of email is as follows: The MailMarshal Receiver accepts
SMTP connections for all email (both inbound and outbound). Receiver Rules

Troubleshooting 21-1
 control the rejection of messages at this point. The Receiver places each
accepted message in a file in the Incoming directory. The Engine then retrieves
each message file from the Incoming directory, unpacks it and processes it
according to the Standard Rules. A message which is not blocked or moved by a
Rule is placed into the ProcessedOK directory. The Sender then takes the message
file from that directory and places it in the Sending directory for delivery.
Note
If MailMarshal Secure is installed and Security Rules are in use, files from the
Incoming folder are processed by the MMDecrypt service which places the
files in the Decryption folder for the Engine. Messages to be sent are placed in
the Encryption folder for processing by MMEncrypt.
Email queued in the Incoming directory indicates a problem with the Engine
service–either the engine has stopped or the rules are incorrectly configured.
Email queued in the Sending directory points to a problem with the sender
service.

MailMarshal Message Names

MailMarshal assigns a name to each message it processes or generates. These
names are used as the file names for message files and the associated log files;
they are also used to identify the messages in log files.
Message names beginning with “B” are SMTP messages which MailMarshal
receives and processes. Notifications generated by the MailMarshal Sender have
names beginning with “C”. Notifications generated by the MailMarshal Engine
have names beginning with “D”. Notifications generated by the MailMarshal
Controller have names beginning with “E”.
In addition to MailMarshal’s message names, the SMTP Message ID of each
message is retained throughout processing and recorded in the processing logs.

MailMarshal Log Files

Each MailMarshal service creates its own daily log file. Routine processing and
problems encountered are all recorded in these log files. The most recent
information is at the end of the log file. The files are found in the MailMarshal
Logging Directory. By default the last 5 days of log files are kept.

21-2 Troubleshooting
Running MailMarshal in Debug Mode
MailMarshal services can also be run in debug mode from a command prompt.
Using this facility, the user can see the results of the system logging in real
time–which is particularly useful for resolving problems, testing new rules, or
determining why a service fails to start.
To use this facility, ensure that the service(s) to be debugged are stopped. Then
go to the MailMarshal directory and enter one or more of the following:
mmengine -debug
mmreceiver -debug
mmsender -debug

For example, to test the passage of a particular email message, run the Receiver
and Engine services in debug mode. Use an email client (such as Outlook
Express) to send email and monitor its progress through the Receiver and
Engine.

Some Common Issues

Error 2140
This message is a generic Windows NT error message meaning that one or
more of the services were unable to start. The error may be related to invalid
TextCensor scripts or other setting problems.
To determine the specific cause of the error, first check the Windows NT event
viewer (application log), or the MailMarshal logs. If necessary start the
MailMarshal services in debug mode.

Unable to Determine the Domain

The following message may appear in the NT Event Log: “Unable to determine
the domain this machine belongs to. Check the TCP/IP protocol properties
for a valid domain name.”
MailMarshal requires a domain to be specified. The Primary DNS suffix of the
computer should be set to the email domain name of the MailMarshal Server
(eg. ourcompany.com)
In Windows 2000, this information should be entered as a Primary DNS setting

Troubleshooting 21-3
 (in the Control Panel under System|Network Identification|Properties|More).
In Windows NT, this information should be entered as a Domain (in the
Control Panel under Network|Protocols|TCP/IP Protocol properties, DNS
tab).

Moving MailMarshal to a New Server

When moving the MailMarshal Server to a new computer, the following steps
are required:
1. Export the MailMarshal configuration from the old server (using the
Advanced tab of Server Properties)
2. Import the configuration to the new server.
3. Copy the file UserGroups.txt and the contents of the subdirectory
ValidFingerprints from the old MailMarshal install directory to the new
one.
4. To continue logging to the existing MailMarshal database, copy the file
SequenceFile from the old MailMarshal install directory to the new one.
Failure to do this will corrupt the database.
5. Ensure that email routing is adjusted to use the new server (both
inbound and outbound).
For additional information on MailMarshal Server and database migration
please see Marshal Software Knowledge Base article KB71.

Further Help
For any problems not listed here, please see the FAQs, Knowledge Base and
Forum on the Marshal Software website. If these resources do not resolve the
issue please contact your Marshal Software Distributor or Marshal’s support
desk.

Web Home Page: http://www.marshalsoftware.com

Email: support@marshalsoftware.com

21-4 Troubleshooting
 22. MailMarshal and
the MMC
The MailMarshal Configurator and Console are implemented as snap-ins to the
Microsoft Management Console (MMC). Users of other MMC applications
(such as WebMarshal 2.x Console and Microsoft SQL Server) will be familiar
with this interface.
By default, the MMC features a tool bar, a menu, and two main panes. The left
pane contains a menu tree, while detailed information appears in the right pane.
• To expand an element (branch) of the menu tree, click on the associated +
symbol. This will show the elements contained within this branch.
• To select an item in either pane, click on it to highlight it.
• Selecting an item in the left pane will display the associated detail information
in the right pane.
• To collapse an expanded menu element click on the associated - symbol.
• If the left pane is not visible, click the Show/Hide Console Tree icon in the
toolbar. It should appear “pushed in.”
Note
The tool bar and menu bar of MMC are context dependent. The available
icons and choices depend on which item is selected in the main panes. If an
icon referred to is not visible, ensure that the appropriate item is selected.
For instance, the arrow icons, which allow rules to be moved up or down in
order of evaluation, are only visible when a rule is selected in the right pane.
While this manual usually refers to choices from the tool bar, in many cases the
MMC also provides equivalent choices from pop-up context menus, which are
made available by right-clicking on the selected item.

Configurator and Console in the Same MMC

Where more than one MMC snap-in (such as the MailMarshal Configurator,
MailMarshal Console, and WebMarshal Console) is to be used from the same

MailMarshal and the MMC 22-1

 machine, a new MMC Console can be created which contains all the required
snap-ins.
To create a custom MMC Console, run mmc.exe from a command prompt.
Choose Console|Add/Remove Snap-in from the main menu. In the Add/Remove
Snap-in dialog, click Add to see a list of available snap-ins. Double-click each
desired snap-in to add it to the list. When done, click Close, then OK.
To save the custom Console, choose Console|Save from the main menu. Select a
location for the .msc file.
Double-click this file to run the custom console.
Note
Only one instance of the MailMarshal Configurator may be active per
MailMarshal Server. Attempting to start a second Configurator results in the
notice “MailMarshal settings are locked.”

22-2 MailMarshal and the MMC

 Appendix A:
Other Email Servers
Typically MailMarshal receives inbound email, processes it, then relays it to the
organization’s internal email server as specified in the Local Domains list.
Outbound email is passed from the internal email server to MailMarshal for
processing and external delivery. See the chapters Pre-Installation and Installation.
Once MailMarshal has been installed, the internal email server software must be
configured to send outgoing email to MailMarshal for processing and delivery.
Where MailMarshal is installed on the same computer as the existing email
server software, the two applications must use different “ports” to receive email
In this case, the following steps are typically necessary:
• As the MailMarshal receiver is now accepting SMTP traffic on port 25, change
the SMTP port that the other email server uses for SMTP (port 97 is usually
available, although any free TCP port will do).
• Configure the other email server software to forward all Internet email to the
local machine (use the “localhost” IP address 127.0.0.1, port 25).
• Check that MailMarshal is configured, via its Local Domains information, to
forward all inbound email to the local machine on the alternative port (again,
use the localhost IP address and port, eg. 127.0.0.1:97). Specific details for
configuring Microsoft Exchange 5.5, Lotus Notes 4, and Lotus Domino R5
are given below. For more detailed information, and to configure other email
server software, please refer to the product documentation for the other
software. The Marshal Software Knowledge Base also contains some
additional setup information.
Note
The following integration examples assume SMTP connectivity has been set
up and is running properly–all that is required here is the introduction of
MailMarshal to an already operating environment.

Appendix A: Other Email Servers A-1

 Configuring Microsoft Exchange 5.5
Exchange 5.5 and MailMarshal on Separate Machines
On the Microsoft Exchange Server, run Microsoft Exchange Administrator. Under
the Configuration container, select Connections, then select Internet Mail Service (see
Figure A.1).
Under the Connections tab, change the Message Delivery option from DNS to
Forward all messages to host, and enter the MailMarshal server IP address, eg.
“10.1.1.1”. This will ensure that outgoing messages are passed to the
MailMarshal machine. Click on OK.

Figure A.1: MS Exchange 5.5 Internet Mail Service properties

Stop and start the Microsoft Exchange Internet Mail Service from the Services
Control Panel applet.

A-2 Appendix A: Other Email Servers

Exchange 5.5 and MailMarshal on the Same Machine
On the Microsoft Exchange Server, run the Microsoft Exchange Administrator.
Under Configuration, select Connections, then select Internet Mail Service (see Figure
A.1).
Under the Connections tab, change the Message Delivery option from DNS to
Forward all messages to host, and enter “127.0.0.1” to identify the local machine.
This will ensure that out-going messages are passed to MailMarshal on the
same machine as MS Exchange.
Because MailMarshal is installed on the same machine, Microsoft Exchange
must be configured to listen for SMTP traffic on a different port to the SMTP
default of 25.
Microsoft Exchange uses the Windows NT services file to determine which
port to listen on for inbound SMTP messages. It is necessary to edit the
services file to change the default SMTP port for Microsoft Exchange to a new
value, for example 97.
The Windows NT services file is located in the folder
%systemroot%\system32\drivers\etc (where %systemroot% is usually C:\WINNT)
In this folder, edit the file named Services using Notepad. Add an explanation
and the new port details.
Locate the text
smtp 25/tcp mail

Comment out the line by prefixing it with the “#” character, and add the new
material:
# smtp 25/tcp mail
# Change default smtp port to 97 to allow both Microsoft
# Exchange and MailMarshal to exist on same machine
smtp 97/tcp mail

Save the Services file and close Notepad. Stop and start the Microsoft Exchange
Internet Mail Service from the Services Control Panel applet.
Note
This example uses port 97, but any available port number may be chosen as
long as it does not conflict with any other service on the same machine.

Appendix A: Other Email Servers A-3

 Configuring Lotus Notes 4
Lotus Notes 4 and MailMarshal on Separate Machines
On the Lotus Notes Server, shut down SMTPMTA from the Notes console.
Open the Public Address Book. Expand the Server section, and select the
Connections view. Open the Internet Hosts Document (see Figure A.2).

Figure A.2: The Lotus Notes 4 Internet Hosts Document

Change the Relay host field to the IP address of the MailMarshal machine, eg.
“192.168.2.218”. This will ensure that out-going messages are passed to the
MailMarshal machine.
Restart the SMTPMTA.

A-4 Appendix A: Other Email Servers

Lotus Notes 4 and MailMarshal on the Same Machine
On the Lotus Notes Server, shutdown SMTPMTA from the Notes console.
Open the Public Address Book, expand the Server section, and select the
Connections view. Open the Internet Hosts Document (see Figure A.2).
Change the Relay Host field to “127.0.0.1” to identify the local machine. This
will ensure that out-going messages are passed to MailMarshal on the same
machine as Lotus Notes.
Because MailMarshal is installed on the same machine as Lotus Notes, the
SMTP component must be configured to listen to a different port to the SMTP
default of 25.
Lotus Notes uses the Notes.INI file to determine which port to listen to for
inbound SMTP messages. The file must be edited to change the default SMTP
port for Lotus Notes, eg. “97”.
The Notes.INI file is located in the WINNT folder (eg. C:\Winnt).
Using Notepad, edit the Notes.INI file and add the following item at the end of
the file.
SMTPMTA_IPPORT=
Then specify the port number on which MailMarshal was configured and to
which internal email is to be forwarded, eg.
; Changed default smtp port to 97 to allow both
; Lotus Notes and MailMarshal to exist on same
; machine
SMTPMTA_IPPORT=97

Restart the SMTPMTA.

Appendix A: Other Email Servers A-5

 Configuring Lotus Domino R5
All changes must be made through Domino Server Administrator, and not by
editing files or using the Notes Client.

Lotus Domino R5 and MailMarshal on Separate Machines

Configure Domino to forward outgoing SMTP traffic to MailMarshal

1. Select the Domino Server for which the mail relay setting must be
changed.
2. Click on the Configuration Tab.
3. Select Messaging, Messaging Settings.
4. On the Basics Tab find the entry for Relay hosts leaving the local
Internet Domain; enter the IP address of the MailMarshal server, eg.
10.2.1.7.
From the server console or a remote session from the Domino Administrator
type the following
>Tell SMTP quit

Once the message that the SMTP service has stopped has appeared on screen
type the following
>load SMTP

The new settings should now be active. The SMTP listening ports can be
checked by typing
>sh tasks

Lotus Domino R5 and MailMarshal on the Same Machine

Change the SMTP Inbound port from port 25 to port 97
As MailMarshal will take over the role of listening for SMTP traffic on port 25,
the port that Domino listens on must be changed. You can use any unused
port (Port 97 is usually free).
1. Select the Domino Server for which the SMTP listening port must be
changed.
2. Click on the Configuration Tab.
3. Select Server, Current Server Document.

A-6 Appendix A: Other Email Servers

4. Click on the Ports Tab, then Internet Ports Tab, then Mail Tab.
5. Change the Mail SMTP Inbound setting from 25 to 97.

Configure Domino to forward outgoing SMTP traffic to MailMarshal

1. Select the Domino Server for which the mail relay setting must be
changed.
2. Click on the Configuration Tab.
3. Select Messaging, Messaging Settings.
4. On the Basics Tab find the entry for Relay hosts leaving the local
Internet Domain; enter 127.0.0.1.
From the server console or a remote session from the Domino Administrator
type the following
>Tell SMTP quit

Once the message that the SMTP service has stopped has appeared on screen
type the following
>load SMTP

The new settings should now be active. The SMTP listening ports can be
checked by typing
>sh tasks

Appendix A: Other Email Servers A-7


A Configurator, 4-1 to 4-5
Acceptable Use Policy, 1-1, 20-1, 20-5
Accounts (POP3), 7-1, 16-7, 16-9
Actions, see Rule Actions
Active Directory Server, 15-2, 15-3
Administrator email addresses, 3-5,
16-2
Advanced Options, 16-17 to 16-20
Aliases, email, 16-24, 20-9
Alert History, 18-12
Anti-Relaying, 16-12 to 16-13
Archiving, 5-1, 10-2, 10-3, 18-6, 18-7
Attachment details, logging, 3-8, 5-17
Attachment fingerprints, 5-12, 5-17,
16-18, 18-8
Attachment parent, 5-11
Attachments, 5-10 to 5-13, 12-3
Stripping, 5-17
B Dial-Up, 3-7, 16-4
Backing up
Configuration, 16-18
S/MIME Certificates, 19-12
Batching (email delivery), 3-7, 16-5
Best Practices, 5-1, 8-2
Block Receipt, 5-19
Blocked Hosts, 16-20
C Email servers, 3-11, A-1 to A-7
Certificate Manager (S/MIME), 19-4
to 19-12
Certificates (S/MIME), 19-4 to 19-13
Classifications, see Logging
Classifications
Conditions, see Rule Conditions
Configuration, import and export,
12-5, 12-6, 16-18
Index
Console, 18-1 to 18-12, 21-1
Contact Information, v
Controller, MailMarshal, 3-14, 15-4,
15-5, 21-1, 21-2
CRLs, 19-5, 19-11 to 19-12
D
Database
Certificate, 19-3, 19-4, 19-12
Logging, 3-8, 3-9, 17-1 to 17-3
Dead Letter, 8-4, 9-2, 10-1, 18-7, 19-7
Debug mode, 21-3
Decryption, S/MIME, 19-15, 19-21,
20-6 to 20-8
Delivery, email, 2-2 to 2-4, 3-6, 16-3,
16-6
Desktop-to Desktop encryption, 19-2,
19-9, 19-17, 19-19, 19-21
DMZ, 2-7, 18-2
DNS, 2-3, 3-2, 3-6, 3-14, 16-3, 16-23,
16-24
DSN, 17-1
Domains, 2-3, 2-8, 3-13, 16-3
See also Local Domains
E
Email Templates, see Templates
Encryption, S/MIME, 19-1, 19-15,
19-18, 20-6 to 20-8
Engine, MailMarshal, 1-2, 5-6, 21-1,
21-2
Error 2140, 21-3
ESMTP, 5-6, 5-19, 20-3
ETRN, 16-7
Index I-1
 Exchange, see Microsoft Exchange L
Exporting configuration, 12-6, 16-18 LDAP, 6-1, 15-1 to 15-5, 19-19
External Commands, 5-14, 5-16, 9-1 License Key, see Keys
Licensing, 16-14 to 16-17
F Licensing Agreement, i
Filtering, 1-2, 5-3, 16-26 Local Domains, 2-3, 3-2 to 3-5, 3-11,
Fingerprints, see Valid Fingerprints 5-9, 5-20, 16-8 to 16-10
Firewall, 2-3, 2-4, 2-8, 3-6, 3-13, 3-14, Localhost, 2-4, 3-11, A-1
16-3, 16-11, 17-2 Logging, 3-8, 4-2, 16-11, 17-2, 18-11,
Folder Actions, Console, 18-7 21-2
Folders, 10-1 to 10-4, 16-17, 18-6 to Logging Classifications, 13-1, 13-2
18-7 Logs (message), 18-8 to 18-10
Archive, 18-7 Lotus Notes, A-4 to A-7
DeadLetter, 8-4, 9-2
Parking, 10-2 M
Standard, 10-2 Mail, see also Email
Batching, 3-7, 16-5 to 16-8
G History, 3-8, 18-11, 21-1
Gateway-to-Gateway encryption, 19-2, MAPS, 16-22, 16-23
19-4, 19-20, 20-6 Message Folders, see Folders
Goto action, 5-5, 5-18 Message log, 12-7, 18-9 to 18-11
Message names, 18-7, 21-2
H Message parking, 10-2, 5-18, 18-6
Hardware requirements, 2-1 Message Stamp, 5-17, 14-1, 14-2,
Header Rewrite, 16-24 to 16-31 16-20, 19-2
Help, 1-4 Microsoft Active Directory Server,
History, see Alert History, Mail History 15-2, 15-3
Host Validation, 16-21 to 16-24 Microsoft Management Console
(MMC), 22-1
I Microsoft Exchange, A-1 to A-3
Importing configuration, 12-5, 16-18 Microsoft Proxy Server 2.0, 3-11
Importing Certificates, 19-7, 19-9 Moving MailMarshal, 21-4
Installation, 3-1 to 3-15, 17-1, 19-2 MSDE, 2-2, 3-2, 19-2
Internet Explorer, 2-2, 19-12 MX record, 2-4, 3-2, 3-14, 16-8, 18-6
ISP, 2-3 to 2-5, 3-6, 16-3, 16-7
N
K News and Support, 4-5
Keys, MailMarshal license, 3-2, 3-4, Notes, see Lotus Notes
16-15, 16-16, 19-2 Notifications, 3-5, 5-17, 8-4, 9-2, 11-1,
S/MIME enabled, 16-16, 19-2 16-2, 21-2
Keys, PKI, 19-1 to 19-15
Knowledge Base, 1-4 O
ODBC, 17-1
Online Help, 1-4

I-2 Index
Order of Evaluation, 5-5, 5-18, 12-1,
16-10, 16-26
P Header Rewrite, 16-24 to 16-31
Pass message to rule, 5-5, 5-18
Permanent Key, 16-14 to 16-16
POP3, 2-3, 3-3, 7-1, 16-7, 16-9
Ports, see TCP ports
Prerequisites, 2-1, 16-20, 17-1, 19-2
Process message, 18-8
Proxy Certificate, 19-2, 19-9, 19-13,
19-17
Proxy server, 3-11
Proxy settings, HTTP, 19-12
Q Server Array, 16-20
Quarantine folders, see Folders
Quarantined messages, 10-2, 18-2,
18-8
Queued Domains, 18-2, 18-5, 18-6
Queues, message, 18-5, 18-6, 21-2
R S/MIME, 19-1
RAS, 16-4
Receiver, MailMarshal, 1-2, 3-11, 5-6,
16-19, 18-4, 21-1, 21-3
Regular Expressions, 16-24 to 16-31
Relay Domains, 3-3, 16-9
Relaying, 2-3, 5-20, 7-2, 16-12
See also Anti-Relaying
POP3 Authentication, 7-2
Release message, 18-8
Reload Rules, 4-2
Reports, 3-8, 16-11, 17-1 to 17-3
Restoring configuration, 12-5, 16-18
Routing, email, 2-2, 2-3, 21-4
RTF message stamping, 14-1, 16-20
Rule Actions
Receiver, 5-19, 5-20
Security, 19-17 to 19-21
Standard, 5-15 to 5-19
Rule Conditions
Receiver, 5-19
Security, 19-15 to 19-17
Standard, 5-10 to 5-15
Rule User Matching, 5-8 to 5-10
Rules, 5-5 to 5-19, 19-13 to 19-21
Rulesets, 5-1 to 5-6
Enabling, 5-4
Printing, 5-2
S
Scanners, see Virus scanners
Schedules, 5-18, 6-2, 10-3, 15-4, 16-6,
18-3
Security issues, 10-4, 15-5, 16-16, 18-2
Sender, MailMarshal, 1-2, 16-19, 18-5,
21-1 to 21-3
Server Properties, 16-1 to 16-31
Server Threads, 16-19
Service Alerts, 18-3, 18-12
Services, MailMarshal, 1-2, 4-2, 16-7,
18-4, 21-1
Signing, message, 19-1, 19-15, 19-17
SMTP, 2-2, 2-4, 3-11
Software requirements, 2-1, 2-2, 16-20,
17-1, 19-2
Spam, 5-15, 16-12, 16-21, 20-8
SQL Server 7.0, 2-2, 16-11, 17-2
Subject line, 12-3, 12-5
Support, 21-4
T
TCP ports
110, 2-6
1433, 2-7, 16-11, 16-16, 17-2
19001, 2-7, 18-1, 18-2
25, 2-4 to 2-7, 3-11, A-1
97, 2-4, 2-6, 3-11, A-1
Templates (email notification), 5-17,
11-1 to 11-3
TextCensor Scripts, 12-1 to 12-7
Troubleshooting, 21-1 to 21-4
U
Uninstalling MailMarshal, 3-14
Index I-3
 User Groups, 5-3, 6-1 to 6-3, 15-1,
16-8
User Matching, see Rule User Matching

V
Valid fingerprints, 5-2, 5-17, 16-18,
18-9, 21-4
Virus Scanners, 5-14, 8-1 to 8-6, 9-2

W
Website, Marshal Software, 1-4
Wildcards, 16-10, 16-11
Working directories, 21-2

I-4 Index