A new version of this guide is available
You are viewing a guide written for an earlier ORF version. To view the latest version, click Other Versions below and select the latest version.
Introduction
This guide helps deploying ORF seamlessly to your network. The intended audience of this document are system administrators.
Table of Contents
A Brief Introduction to ORF
This guide assumes that this is your first ORF deployment and you are not yet familiar with some basic concepts of our product. Skip to the next section if you already experienced with ORF.
The rest of this section briefly explains a few basic ORF technical concepts. These will gain significance later in the guide.
Email filtering basics
ORF filters your email traffic in real time, while emails are being transmitted using the SMTP protocol. This low-level monitoring of email flow enables ORF to stop spam right on its tracks, offering a number of benefits such as SMTP-level email rejection.
Exchange integration
By hooking into Microsoft® Exchange or IIS SMTP using the integration interfaces provided by Microsoft, ORF monitors your email traffic without introducing another hop in the email delivery chain.
The Filtering Points of ORF
The integration with Exchange/IIS is event-based: ORF gets notified of certain events that occur during the SMTP email transmission and also gets a chance to intervene in the delivery. ORF calls these events Filtering Points and there are two of them.
The Before Arrival Filtering Point occurs when the sending server just specified the recipient email address
(RCPT TO
command) and waits for your server to acknowledge. At this point, the email contents are not transmitted yet,
but ORF is already very capable of making decisions about the email: for instance, if the sending server is known to distribute
spam, ORF can turn down the offer.
A little later in the delivery process comes the On Arrival Filtering Point, when the sender server transmits the email and waits for acknowledgment. As the email contents are now available, ORF can perform a more in-depth analysis of the email and also carry out more actions than at Before Arrival, such as redirecting the email or moving it the Junk Email folder of the end-users.
From the above description it might appear to you that On Arrival is sort of "better", but in fact both filtering points have their merits.
Choosing Deployment Location
Deployment on the network perimeter
ORF is best deployed on the network perimeter, on your primary mail exchanger servers (primary MX) and optionally on all of the secondary MXs.
-
Deployment with Microsoft® Exchange 2010 or 2007
Install ORF on the server with Edge Transport role. If you do not use edge servers, install on the Hub Transport role server.
Installing ORF on a Hub Transport role server in an Edge Transport-Hub Transport setup will work as well.
-
Deployment with Microsoft® Exchange 2003, Exchange 2000 and IIS
When possible, install ORF on the network perimeter servers (other locations are supported).
Deployment behind the network perimeter
ORF will also work behind the network perimeter, e.g. behind SMTP front-ends, non-transparent firewalls, anti-virus proxies or cloud email filtering services. However, ORF may take more time to set up and maintain in such setup. Find a summary of limitations below.
-
Increased Intermediate Host List (IHL) maintenance cost
This list of ORF contains the IP addresses of the servers between your network perimeter and your ORF server. IHL is crucial for ORF to work reliably.
Compiling and maintaining this list could be challenging if your network is complex or if your network perimeter is provided by a third-party (e.g. your ISP or a cloud email filtering service).
-
Before Arrival filtering will not work
The On Arrival filtering point will work without any limitations, though. Lack of Before Arrival filtering will result in the following limitations:
- The Greylisting feature will not be available: Greylisting is a rarely used, rather aggressive spam filtering technique, so it is no big loss unless you specifically want to use this feature.
- Backscattering: Spam is usually sent in the name of innocent third-parties. In this setup, rejecting spam at On Arrival will cause your perimeter servers to generate bounce reports (also known as NDRs or DSNs) and bomb the innocent party with them. This phenomenon is called backscattering. To avoid this, we recommended using email tagging instead of rejection in this setup.
- No bounce on invalid recipients: When using the Recipient Validation Test of ORF to bounce emails sent to non-existent local recipients, ORF will be unable to trigger a bounce report in certain cases—that is, the sender might not get notified about the failed delivery. This is due to a technical limitation of the SMTP protocol.
Before choosing to deploy ORF behind the perimeter, make sure the above limitations are acceptable for you.
Deployment with secondary MXs
Secondary mail exchangers (MXs) are ironically the primary targets of spammers—often they will skip the primary MX and turn to the secondary MXs directly. Make sure that emails from your secondary MXs are relayed through your ORF server so that it can filter them.
Ideally, ORF should be deployed on all of the secondary MXs as well as the primary MX. If this is not possible, you will be facing the same challenges as outlined in the previous section, but the limitations will apply only to the emails arriving via the secondary MXs.
Outbound email traffic
The Auto Sender Whitelist of ORF is a self-learning feature that automatically builds a list of your trusted email partners by monitoring your outbound email traffic. This feature greatly reduces the administration costs and significantly decreases the chance for mistaking legitimate emails as spam.
If possible, route your outbound emails via your ORF server. This will allow ORF to populate data for the Auto Sender Whitelist.
Deployment on multiple servers
ORF features Configuration Synchronization, a service which allows distributing configuration changes in a "publisher-subscriber" model. The administration typically appoints a central repository server (publisher) and carries out any change on that server which then get automatically distributed to subscriber servers.
This feature should be used alongside with the External Databases feature for data sharing between ORF instances.
Please consult the Multi-Server Usage Guide on setting up and using ORF on multiple servers.
System requirements
The minimum system requirements for ORF servers are the following:
Requirements | |
---|---|
Operating System |
Microsoft® Windows® Server 2008 R2 Microsoft® Windows® Server 2008 Microsoft® Windows® 2003 Server SP1 Microsoft® Windows® 2000 Server SP3 Windows® Small Business Server 2011 Standard) [1] Windows® Small Business Server 2008 (latest Service Pack required) [1] Windows® Small Business Server 2003 R2 (latest Service Pack required) [1] Windows® Small Business Server 2003 (latest Service Pack required) [1] Microsoft® Small Business Server 2000 (latest Service Pack required) [1] |
Email Server |
Microsoft® Exchange 2010 Microsoft® Exchange 2007 (64-bit release version only [2]) Microsoft® Exchange 2003 Microsoft® Exchange 2000 Microsoft® IIS SMTP Service 6 Microsoft® IIS SMTP Service 5 |
Platform | Both 32-bit and 64-bit [2] OS platforms are supported |
Internet Explorer® | Microsoft® Internet Explorer® 6 or later |
CPU | As required by the operating system |
Storage | Varies, at least 100Mb |
RAM | Varies, at least 50Mb |
[1] ORF Fusion for SBS will run on Small Business Server only. ORF Fusion will run on both SBS and the regular Windows® Server platforms.
[2] Microsoft has released a 32-bit version of Exchange 2007 for lab testing only. ORF is not compatible with this version.
Microsoft® Exchange 2013 is not supported by the latest ORF 5.0 version. We will address the compatibility issues in ORF version 5.1.
The recommended system configuration is that of Microsoft® Exchange. In overall, introducing ORF to a system that is already capable of running Exchange or IIS SMTP smoothly does not add significant further load to the system. However, estimating the load generated by ORF is very difficult, because it depends much on the features and configuration used.
ORF requires considerable disk space for logs, about 500 bytes per log entry on average. This results in the following average disk space requirements:
Email Traffic | Logs for 1 day | Logs for 30 days |
---|---|---|
1,000 / day | 488 kB | 14 Mb |
10,000 / day | 4.5 Mb | 143 Mb |
50,000 / day | 24 Mb | 715 Mb |
100,000 / day | 48 Mb | 1.4 Gb |
500,000 / day | 238 Mb | 7 Gb |
Log retention can be configured in ORF (defaults to 30 days).
Performance and sizing
ORF is not particularly resource-intensive software: even under heavy stress testing, an average setup will use negligible or low amount of memory and CPU due its design and optimizations.
The heavy reliance of DNS-based information of ORF limits its throughput, however. The major factors influencing throughput are your settings and DNS response time. Unfortunately, both factors vary greatly, which makes it hard to come up with estimations that fit all sizes and setups.
By our experience, the average ORF configuration that sticks to our Best Practices recommendations can process 250,000 emails per day per server without any issues and ORF installations with up to 750,000-1,000,000 emails per day per server have been reported.
As a general rule of thumb, if your network processes less than 100,000 emails per day per server, performance is not likely to require extra attention. For 100,000 or more emails, we recommend the following:
- Use only one, local DNS server with ORF
- Keep the DNS timeout low (no more than 5 seconds)
- Gradually enable DNS-based ORF tests and watch for the number of concurrent SMTP connections in Exchange (it should stay below 10)
- Review DNSBL/SURBL usage restrictions: DNS zone transfers or using premium services may be required if your traffic exceeds a certain level
Preparation for Deployment
Compiling the Intermediate Host List
The Intermediate Host List contains the IP addresses of the servers between your network perimeter and your ORF server. ORF uses this list to "look behind" any intermediate delivery hops in the email delivery history to find the original IP that connected to your network. This list is crucial for ORF to work reliably.
This list will be empty if you deploy ORF on the perimeter and you have no secondary MXs. However, if you have secondary MXs, or ORF is deployed behind other servers, you need to compile this list.
Checking DNS compliance
ORF relies on DNS in many ways. We have the following requirements and recommendations for DNS servers used with ORF:
- The server must support recursion (enabled by default in Microsoft® DNS)
- The server should be on the local network or on the ORF computer. Using ISP DNS servers and third-party DNS resolution services (such as OpenDNS or Google Public DNS) is discouraged.
- The server should not use forwarders (e.g. ISP DNS servers)
- The server should not be the same DNS server that supports your Active Directory
The easiest way to comply with the above is to install Microsoft® DNS Server on the computer where ORF is deployed. This software is part of Windows® Server and can be added as a server role.
Network security setup
ORF requires the ports below to be opened for communication.
Port | Description |
---|---|
UDP/53 and TCP/53 | DNS communication with the DNS server(s) configured in ORF. |
TCP/6242 | Default port for remote ORF management and configuration synchronization between your ORF servers. Optional (if Remote Access is disabled in ORF). |
TCP/80 | HTTP communication between ORF management tools and our servers (HTTP proxies are supported). |
TCP/389 or TCP/3268 | Default ports for Active Directory LDAP or GC communication if the Recipient Validation Test is enabled in ORF with the Active Directory source. Optional (if the above test is disabled). |
(Varies) | Communication with External Databases (e.g. Microsoft® SQL Server) if ORF is configured to use these. Please consult the database manual for port information. |
The Remote Access feature of ORF can be secured further by employing VPN or similar solutions.
Setting up External Databases
Certain features, such as the Auto Sender Whitelist and the Directory Harvest Attack Protection Test store their data in databases. These databases can be either Private Local Databases (an embedded, no-setup solution in ORF) or External Databases (e.g. Microsoft® SQL Server). Setting up External Databases is required if:
- ...your email traffic reaches or exceeds 50,000 email per day
- ...if you are setting up multiple ORF servers (allows sharing data between servers)
A broad range of database solutions are supported by ORF, please check the Database Guides page for the complete list and database setup instructions.
Preparing for service outages
When planning deployment, consider that under Microsoft® Exchange 2010 and 2007 the ORF Setup has to restart the MSExchangeTransport service to finalize the installation. SMTP email transmission will be down while the MSExchangeTransport service is restarting. This usually takes less than a minute (differences may occur). It is recommended to schedule the installation to a time when the service outage causes the least problems.
There is no service outage under Microsoft® Exchange 2003, Exchange 2000 and IIS SMTP.
Next Step: Installing ORF
Please follow the instructions in the Installation Guide to install ORF on your network.