This help section explains the test settings available under
in the Administration Tool.A brief description of each test is displayed when the name of the test or the down arrow icon is clicked. ORF tests could be enabled or disabled on this page globally, and the filtering point assignments of enabled test can be also managed here: tests could run at the Before Arrival, the On Arrival or both filtering points. For more information, see the Filtering Points Concept section.
The right filtering point for tests depends on your email delivery setup and intentions. There are many things to consider. Please see the Filtering Point Selectionsection for detailed information.
Click the ON / OFF button next to the name of the test to enable or disable it. When a test is disabled, ORF skips performing the given test.
Enable or disable the selected test at the Before Arrival, On Arrival or both filtering points by clicking the and symbols (the latter means the test is enabled for the filtering point). Filtering point assignments can be edited only when the test is enabled. Some tests, such as the Keyword blacklist and Attachment filtering work at On Arrival only, so they cannot be assigned to the Before Arrival filtering point.
Click Settings to jump to the configuration page of the test.
See the Whitelist Test Exceptions topic.
Basically, there are two setup elements that affect the filtering point selection: perimeter servers and secondary MXs (also called "backup email servers"). These are called Intermediate Hosts in ORF.
The front-end is a host which receives the email before ORF would filter the email. The front-end is not necessarily a separate box, it may be e.g., an anti-virus proxy on the same server where ORF runs.
The secondary MX or backup email server is another server which receives emails for your domain when your server (the primary MX) is down. Spammers often send to the secondary MX directly to bypass spam filtering software, which typically runs on the primary MX only and trusts the secondary MX.
The following table summarizes the effective filtering selections for the various email delivery setups.
Case | Setup | Before Arrival | On Arrival | Both |
---|---|---|---|---|
A | Direct Delivery (no front-end or secondary MX) | Yes | Yes | Yes |
B | No front-end, but there is a secondary MX | No | Yes | Yes |
C | Front-end | No | Yes | No |
The above is a good starting point if you want to reject all blacklisted emails as soon as possible. However, if you want to accept and tag or redirect them (because you want to allow users to review blacklisted emails) assign all tests to On Arrival instead. See the On Arrival Action Settings section for more information.
The below table shows an optimal filtering point selection for the following case:
Test | Before Arrival | On Arrival | Both |
---|---|---|---|
DNS Whitelist | |||
Automatic Sender Whitelist | |||
Reverse DNS | |||
DNS blacklists | |||
HELO domain blacklist | |||
SPF test | |||
IP blacklist | |||
Sender blacklist | |||
Recipient blacklist | |||
Recipient validation | |||
DHA protection test | |||
Honeypot test |
The below table shows an optimal filtering point selection for the following case:
Test | Before Arrival | On Arrival | Both |
---|---|---|---|
DNS Whitelist | |||
Automatic Sender Whitelist | |||
Reverse DNS | |||
DNS blacklists | |||
HELO domain blacklist | |||
SPF test | |||
IP blacklist | |||
Sender blacklist | |||
Recipient blacklist | |||
Recipient validation | |||
DHA protection test | |||
Honeypot test |
The below table shows an optimal filtering point selection for the following case:
Test | Before Arrival | On Arrival | Both |
---|---|---|---|
DNS Whitelist | |||
Automatic Sender Whitelist | |||
Reverse DNS | |||
DNS blacklists | |||
HELO domain blacklist | |||
SPF test | |||
IP blacklist | |||
Sender blacklist | |||
Recipient blacklist | |||
Recipient validation | |||
DHA protection test | |||
Honeypot test |
If you have a front-end and all tests are assigned to On Arrival, make sure Tarpit delay is disabled for that filtering point, otherwise you will "punish" your front-end only when delaying SMTP responses.