No, ORF was designed to filter SMTP traffic. POP3 filtering is only supported if the POP3 downloader re-submits all emails via SMTP. For instance, the Microsoft Small Business Server POP Connector is known to use the Pickup folder for resubmission instead of SMTP, so ORF is unable to monitor such traffic. A possible workaround is using a third-party POP3 downloader which is known to use SMTP for email resubmission (like POPcon), but please note that Before Arrival filtering cannot be used in such setups.

Please consult our Deployment Guide for detailed information on deployment.

Converting an evaluation installation into a fully licensed one takes entering your license key into the License Manager of the ORF Administration Tool. Step-by-step instructions can be found in our Trial Conversion Guide.

Yes, there should be no interference. The only thing to consider is the filtering order: ORF will probably have lower priority by default, so it will filter the emails after the other software. You can change this by changing the priorities.

Yes, it does: ORF Fusion supports both Server Essentials and Small Business Server installations.

Yes, ORF can be installed to Exchange clusters. The configuration of multiple ORF instances (installed to each cluster node) can be synchronized automatically in a publisher-subscriber model. For detailed instructions, read our Multi-Server Usage Guide.

No, it does not, at least not directly. "Exchangeless" Microsoft IIS SMTP Servers are supported, but other servers with their own SMTP engine (MailEnable, Xmail) are not. ORF can be used in such setups with a perimeter IIS SMTP server only, which receives all emails first, then relays filtered emails to the non-Exchange server running at the back-end (see our KB article for detailed instructions).

Yes: ORF can run in Demo mode, in which it only monitors the incoming email flow and records what it would have done in Live mode without actually rejecting any emails. Alternatively, you can configure it to tag or redirect blacklisted emails instead of rejecting them. See our Testing Guide for detailed instructions.

Under Microsoft® Exchange, the installer restarts the MSExchangeTransport service (Exchange 2016, 2013 Edge and Mailbox server roles, 2010, 2007) and/or the MSExchangeFrontendTransport service (2016 Mailbox server role, Exchange 2013 Client Access server role standalone or hybrid setup) during the installation process. SMTP email transmission will be down while these services are restarting. This usually takes less than a minute (your mileage may vary). It is recommended to schedule the upgrade 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.

First of all, we recommend reading the ORF 101 guide, which describes how ORF works. Once you learned the ropes, consult our Best Practices Guide to maximize the filtering efficiency.

It really depends on your preferences and setup: for instance, the Greylisting test has an excellent catch rate, but it can be utilized only if ORF runs on a perimeter server. It also causes about 15 minutes of delay in the delivery of legitimate emails: some find this acceptable, others don’t. The tests enabled by default are safe to use in any setup, the rest should be enabled only after you made sure it is suitable for your setup and all configuration prerequisites have been made (e.g., enabling the Honeypot test alone won’t do anything, you will need to compile a list of spam trap addresses first). For starters, make sure you read our recommendations.

It depends on your setup: if emails are received directly by ORF (running at the network perimeter), use Before Arrival. If there is another host in front of ORF and emails are received through that, add this host to the Intermediate Host List and use On Arrival. If ORF runs at the perimeter but you also have a secondary MX relaying emails to ORF, add it to the Intermediate Host List and use Both filtering points. For more information, see our Best Practices Guide.

See the list of recommended DNSBLs in our Knowledge Base article and in our Best Practices Guide (Efficient Spam Filtering / Tests: A Starter Plan section).

See the list of recommended SURBLs in our Knowledge Base article and in our Best Practices Guide (Efficient Spam Filtering / Tests: A Starter Plan section).

The minimum system requirements for ORF servers are the following:

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:

Log retention can be configured in ORF (defaults to 30 days).

Microsoft® Exchange 2013 Service Pack 1 was shipped with a defect that needs to be fixed before ORF can be used with SP1.

You can download and install the hotfix from Microsoft Knowledge Base article KB2938053.

Compatibility with Exchange Roles

ORF 5.3 and later versions support all three roles available on Exchange 2013 (Edge Transport Server, Client Access Server and Mailbox Server roles). Please see our Knowledge Base article regarding Exchange 2013 deployment scenarios and limitations.

When do I apply the fix?

Apply the fix after Service Pack 1 is installed.

Can I keep ORF installed while upgrading to SP1?

You can keep ORF installed while upgrading to Exchange 2013 SP1, but please be aware that you will not be able to start the Exchange Front-End Transport Service and/or the Exchange Transport Service until the hotfix is installed.

Microsoft® Exchange 2013 Service Pack 1 was shipped with a defect that prevents third-party Transport Agents like ORF from loading. As a side effect, you may also experience problems with starting the Exchange Front-End Transport Service and/or the Exchange Transport Service.

You may also find errors similar to the one below in the Windows Event Log:

Microsoft has released a fix for this issue. Please see our related KB article for more information.

Please consult our Multi-Server Usage Guide for detailed instructions.

Yes, it is called the Best Practices Guide. We also recommend reading the ORF 101 Guide, which covers the basics of ORF.

You have been directed to this page because ORF has detected that you have upgraded to Microsoft® Exchange 2007 while ORF was installed on your computer. Because ORF connects to Exchange 2007 using a different technology than for IIS, Exchange 2000 or Exchange 2003, now you need to connect ORF to Exchange 2007.

Please follow the steps below to connect ORF to Exchange 2007:

1. Stop the MSExchangeTransport service
   

   You can do this from the Services MMC, from command-line using

   net stop MSExchangeTransport
   

   or from PowerShell using

   stop-service MSExchangeTransport
   
2. Remove ORF connections from IIS
   

   Open a command prompt and enter to the ORF program directory (\Program Files\ORF Enterprise Edition by default). Run

   orfinsthelper -uninstallconnector
   

This will uninstall any remains of the components that bind ORF to IIS. This step is successfull if you get no error messages.

3. Install the ORF Transport Agents
   

   From the same command prompt, run

   orfainst -install
   

   This will install and enable the ORF Transport Agents that bind ORF to your Exchange 2007 Server.

4. Configuring ORF for Exchange 2007
   

   Start the ORF Administration Tool and open the Configuration / Global / Microsoft® Exchange page. Click the Detect to automatically detect the Exchange Replay Directory path. Press CTRL-S to save the configuration, then press F11 to start the ORF Service.

5. Start the MSExchangeTransport service
   

   You can do this from the Services MMC, from command-line using

   net start MSExchangeTransport
   

   or from PowerShell using

   start-service MSExchangeTransport
   

You have been directed to this page because ORF has detected that you have uninstalled Microsoft® Exchange 2007 while ORF was installed on your computer. If you want to keep using ORF with IIS, Exchange 2000 or 2003, please follow the instructions below to connect ORF to IIS.

1. Install the ORF SMTP Module
   

   Open a command prompt and enter to the ORF program directory (\Program Files (x86)\ORF Enterprise Edition by default). Run

   orfsmtpinst -install
   

   This will install the ORF SMTP Module.

2. Bind the ORF SMTP Module to IIS
   

   Start the ORF Administration Tool and select the Configuration / Global / Server Bindings page. Bind ORF SMTP Module to the SMTP Virtual Servers.

   If the ORF Service is already running, press CTRL-U to save the binding changes and to restart the ORF Service.

   If the ORF Service is down, press CTRL-S to save the configuration changes and start the ORF Service by pressing F11.

Please consult this KB article for detailed information about deploying ORF 5.2 and 5.1 on Exchange 2013 servers.

ORF records the final status of the email in its logs. To check this information, start the ORF Log Viewer tool, load the related log files, search/filter the related entries and check the last, Message column. For detailed usage instructions, please consult the related KB article and the related ORF Help topic.

Rejected emails cannot be retrieved: they have never arrived. If configured properly, ORF will not blacklist any legitimate emails, so this is usually not a problem, but if you are concerned about false positives and want to review blacklisted emails, you should configure ORF to tag and/or redirect the email to a specified address upon blacklisting instead of rejecting them. If you have Exchange 2003 SP2 or later, you can also configure Exchange to put emails tagged by ORF to the Junk mail folder of target recipient (see our KB article for instructions).

Enable the Attachment Quarantine feature of ORF to place blacklisted email attachments in a file system quarantine. Learn more about this feature from this ORF help topic.

Note that this feature was first introduced in version 5.2. In earlier versions, there was no way to retrieve blacklisted attachments.

Rely on automated tests as much as possible (instead of adding entries manually to the Sender and IP Blacklists). Use only the recommended DNSBLs and SURBLs (see our Knowledge Base article and our best practices guide). Use the Auto Sender Whitelist feature to ensure emails sent by clients and partners (whom your users often correspond with) are excluded from filtering.

Read our Best Practices Guide for the recommended settings.

Read our article for possible solutions: How to blacklist self-spam?

This phenomenon is called email backscatter: a spammer is spoofing the email address of your user, so when the target server returns a bounce message, it will land in the inbox of your user. Read our article How to stop backscatter? for possible solutions.

Emails have two type of sender addresses: the first is called the SMTP envelope sender address, which is submitted by the sender server in the MAIL FROM: command during the SMTP transport – this is what ORF works with and logs. The other is called the MIME sender address, which is stored in the email header and this is what your email client (e.g., Outlook) shows.

These two addresses match in most cases, but not necessarily: it is absolutely legal to use different SMTP and MIME address information. The Bcc: addressing, mailing lists, CRM software and other systems with automatic bounce-handling often take advantage of this.

Spammers also tend to use different SMTP and MIME sender addresses to confuse the recipient, for example using the recipients own address as the MIME sender address, so it seems the user received the spam from his own address. To blacklist such spam, you should use a Keyword Blacklist expression which checks the MIME header instead of the Sender Blacklist. For detailed instructions, read the Other campaigns: MIME sender spoofing section of our related article).

We recommend using regular expressions: for detailed instructions, read our related KB article.

In general, whitelists always take precedence over blacklists. In other words, if an email is whitelisted by any tests, it will be excluded from further testing and will be allowed through filtering. The Auto Sender Whitelist test monitors your outgoing email flow and records the addresses to which your users send emails, so when a reply arrives, it will be excluded from filtering. In some cases, the database might get "polluted", e.g., when a user accidentally replies to a spammer. To fix this, the whitelisted address should be added to the exclusion list: see our KB article for detailed instructions.

See our related KB article for detailed instructions.

First, an external SQL database should be set up (see our related guides for detailed instructions), then all records should be migrated from the Private Local Database files to the SQL database using our Database Converter tool.

ORF uses the PCRE engine (Perl-Compatible Regular Expressions), which implements (almost) the same syntax and semantics as Perl 5. Note that it is not the same engine used by Perl, Java or the .NET Framework. Complete documentation is available at http://www.pcre.org/pcre.txt.

Before Arrival filtering is performed when the sender server specifies the recipient(s) in the RCPT TO: command(s) during SMTP transport (see the Filtering Points Concept Help topic for more information). Each RCPT TO: command specifies a recipient and each time the Before Arrival tests run, so Before Arrival tests may be performed multiple times on a single email. When a blacklisting is triggered, ORF rejects the recipient specified by the sender in the given RCPT TO: command. The sender either specifies another recipient and the Before Arrival tests are performed again, or gives up and terminates the connection.

Due to the above process, ORF could log the email was blacklisted at Before Arrival only if all recipients were blacklisted, but it makes more sense to log the results of each Before Arrival tests per recipient (the way they are performed), instead of logging a message like At Before Arrival, the email was whitelisted for John because the sender is in the Auto Sender Whitelist database, blacklisted for Brian due to a Recipient Blacklist hit, and passed all checks for Mary and Sue for each email.

Consult the following articles, depending on your Exchange version:

• Exchange 2016/2019 instructions
• Exchange 2013 instructions
• Exchange 2010/2007 instructions

The .opg files are the so-called ORF PowerLog files: the ORF Service pre-processes these files and generates .ppr files. The latter files are required for the reporting feature of ORF. Once you have their matching .ppr file, the .opg files can be safely deleted. You can also configure ORF to automatically delete them after their pre-processing is finished (Administration Tool: System / Log, ORF PowerLogs - Configure button, Delete PowerLogs after preprocessing).

You can safely delete the .ppr files as well if you do not use the reporting feature of ORF (or disable PowerLogs entirely, Administration Tool: System / Log, ORF PowerLogs - Configure button, uncheck Enable PowerLogs), though these are relatively small files, so might want to keep them in case you need to create reports in the future.

See the list of recommended DNSBLs in our Knowledge Base article and in our Best Practices Guide (Efficient Spam Filtering / Tests: A Starter Plan section).

See the list of recommended SURBLs in our Knowledge Base article and in our Best Practices Guide (Efficient Spam Filtering / Tests: A Starter Plan section).

Microsoft® Exchange 2013 Service Pack 1 was shipped with a defect that prevents third-party Transport Agents like ORF from loading. As a side effect, you may also experience problems with starting the Exchange Front-End Transport Service and/or the Exchange Transport Service.

You may also find errors similar to the one below in the Windows Event Log:

Microsoft has released a fix for this issue. Please see our related KB article for more information.

The following Active Directory-related errors may be logged by ORF:

A referral was returned from the server

Solution: make sure that you have a valid LDAP path configured for ORF (Administration Tool: Blacklists / Recipient Validation, Configure selected). Note that LDAP, GC, DC, ORG, etc. has to be written uppercase and no spaces are allowed between the commas.

The authentication mechanism is unknown

Solution: make sure that you have proper authentication information defined, both the user name and password is correct. Note that your server may require the user name in format DOMAIN\username or username@DOMAIN.

Could not bind to path "..."

Solution: check the LDAP path. Note that LDAP, GC, DC, ORG, etc. has to be written uppercase and no spaces are allowed between the commas.

If the above does not help, try the synchronization with and without authentication (also with authentication with blank user information). ORF AD synchronization queries AD-specific properties, so it also requires the AD schema extension by Microsoft Exchange 2019/2016/2013/2010. Synchronization with a regular Active Directory without these schema extensions is not supported.

Introduction

This article provides possible solutions to DNS-related problems causing DNS lookups to fail with error message SERVFAIL, RCODE2, which means Server failure - The name server was unable to process this query due to a problem with the name server, which leads to poor filtering performance.

Is my system affected?

Occasional DNS lookup failures are considered normal, because DNS is an unreliable transport. If you see such errors logged only occasionally for the Reverse DNS and SPF tests, but the majority of DNS lookups are successful, there is nothing to worry about.

However, if you see this error logged for DNS Blacklist and SURBL lookups frequently, we recommend giving the below solutions a try:

1. Use the built-in DNS resolver (ORF 5.4 and newer only)

Starting from version 5.4, ORF can access DNS using a built-in recursive DNS resolver, which is not affected by local DNS server problems. Consider switching to this resolver. Find more information on this in the related ORF help topic.

2. Make sure you are using a local DNS server with no public forwarders

In most cases, the problem is caused by public DNS servers (Google DNS servers, OpenDNS servers, ISP DNS servers, etc.) which are used for the queries (either directly, or by forwarding the query through them from the local DNS server). Most online blacklist services (such as Spamhaus) do not accept queries from such public DNS servers (i.e., they return NXDOMAIN to all queries, or refuse to reply and the query times out eventually).

Make sure the DNS server configured in ORF meets all requirements.

3. Try disabling EDNS probes

If the local DNS server uses EDNS, the size of the packets may exceed the limit configured on your firewall. A possible solution is disabling EDNS probes using the following command:

For more information, please consult the related Microsoft TechNet article.

4. Increase the TTL value

When name resolution is provided by root hints, Windows Server 2008 DNS and Windows Server 2008 R2 DNS Servers may fail to resolve queries for names in certain top-level domains. When this happens, the problem will continue until the DNS Server cache is cleared or the DNS Server service is restarted. Setting the TTL to 2 days or higher and flushing the DNS cache may solve the problem.

For more information, please consult the related Microsoft Knowledge Base article.

5. Install a hotfix to eliminate a bug in the Microsoft DNS Server service

Some Microsoft DNS Server service versions are affected by a bug: they cannot correctly handle expired/removed glue records, causing SERVFAIL RCODE2 errors. Installing a hotfix may solve the problem.

We also strongly recommend flushing the DNS cache after applying the above solutions.

6. Verify IPv6 connectivity

If your DNS server thinks it has Internet access over IPv6 when it has none, name resolution may fail with timeout, which results in SERVFAIL errors. This typically affects specific DNS zones and a telltale symptom is name resolution working for a while, then suddenly ceasing to work until the DNS cache is cleared. This can be caused by a combination of the false IPv6 connectivity and a DNS zone which has a different Time-To-Live (TTL) configured for IPv4 (DNS A) and IPv6 (AAAA) authoritative name server data. As Microsoft DNS Server prefers IPv4 over IPv6, lookups work initially, but as IPv4 TTLs expire and Microsoft DNS falls back to the still valid IPv6, the lack of actual IPv6 connectivity will manifest itself as a SERVFAIL error.

If you are seeing this, we recommend investigating why the server believes it has IPv6 connectivity and fix the problem as per the result of your investigation.

This error indicates a problem with the Active Directory connection between ORF and the LDAP server (this is required for the AD-based Recipient Validation test of ORF). By default, ORF tries to find the LDAP root (root DSE) automatically, this works in most cases if that the system where ORF runs is in the domain. This error is logged if this automatic detection fails for some reason. To solve this, you may want to manually specify the root DSE (LDAP path) for ORF in the Administration Tool: Blacklists / Recipient Validation, Configure selected, Directory tab > Use the LDAP root below.

It is also possible that your server requires authentication: please try with user name and password specified for LDAP authentication ( Administration Tool: Blacklists / Recipient Validation, Configure selected, Authentication tab). Note that the user name format required may depend on your AD settings, for example, it can be DOMAIN\user, domain@user or user. Please also try with blank user name and password fields and with authentication disabled.

To repair a corrupted database file, follow the steps below:

1. Start the Administration Tool and connect to the local or remote ORF instance
2. Navigate to the page of the related test (Whitelists / Auto Sender Whitelist, or Blacklists / Greylisting, or Blacklists / Honeypot Test, or Blacklists / DHA Protection Test)
3. Click the Database button, then Manage
4. Attempt to Repair the database

If the above does not help and you still receiving database related error messages, delete the related .abs file from the ORF directory (Program Files (x86)\ORF Fusion by default). Note that this requires the ORF Service to be stopped first, as it locks the database file. The embedded database engine will recreate the database file when the first entry needs to be added to it.

To solve the problem permanently, it is strongly recommended to switch to an External SQL database: setup instructions can be found in our guides. Once the SQL database is set up, you can migrate all data from the Private Local Database files using the Database Converter Tool.

This Knowledge Base article describes a known bug with ORF 5.0.

Description

Due to a bug in ORF, email notifications sent by ORF may trigger further email notifications, eventually resulting in an email loop. This may happen if ORF receives a copy of the email notification by SMTP transmission. In this specific case, the mechanism that should prevent filtering these notifications fails with an error.

Workaround

Configure ORF to submit emails using the Pickup/Replay directory (system default).

• Start the Administration Tool and connect to the ORF installation
• Select System / Log in the navigation pane
• Click the Configure button in the Email Notifications box
• Select the Settings tab
• Select the "Default Pickup/Relay folder (recommended)" radio button
• Click OK
• Press CTRL - S to save your configuration

Fix

A patch has been released for version 5.0 on September 17, 2012 (orf-5.0-ntlp-patch.zip). To install the patch, follow the instructions of readme.txt from the package.

This bug was fixed in ORF 5.1. ORF 5.1 and later versions are not affected.

Issue Details

Affected Products

ORF Fusion 5.0
ORF Fusion for SBS 5.0

Severity

Minor

Published

Issue published on September 17, 2012.

You probably have the Whitelist Delivery Status Notifications option enabled (Administration Tool: Whitelists / Sender Whitelist page) in your configuration. Disabling it and saving the configuration should solve the problem.

ORF has this option because it is an RFC standards requirement that every SMTP server must accept Delivery Status Notifications. These emails are sent with blank sender address. To keep your server compatible with the Internet standards, ORF could exclude incoming Delivery Status Notifications (e.g., Non-Delivery Reports) from filtering.

Unfortunately, spammers often try to exploit this requirement by sending spam with blank addresses to avoid filtering, so we strongly suggest not having this option enabled.

This is most likely an issue with the DNS servers specified for ORF. They must be able to resolve external domains recursively (i.e., to return the requested DNS record in a single step instead of redirecting the DNS client to the root DNS servers). Please make sure that all DNS servers configured for ORF satisfy these requirements. To test your DNS server's status, start the ORF Administration Tool, expand System / DNS and click the Health Check button.

Starting from ORF 5.4, you can also use the built-in DNS resolver, which is not affected by DNS server configuration issues.

Whitelists take precedence over the Keyword Blacklist test, so first of all, make sure the email was not whitelisted by checking the logs using the Log Viewer. If it was not, check your filter expression: are you absolutely sure it matches the string in the email body? There are a few other things to consider:

When ORF filters HTML emails, the HTML contents are decoded to simple text. As HTML is a rich visualisation medium, built by complex HTML elements, the decoding may produce some unexpected results on occasion. For example, spammers often use white text on white background to confuse the filters which treat the invisible text as actual content, though you do not see it in the mail client. You may filter for the expression No prior prescription required, which has hidden text inside, so the decoded text may look like NoFpriorQprescription33required. Spammers also use HTML tables, images instead of text and other techniques to bypass content filtering.

Also, ORF does not filter embedded emails (such as emails attached to Delivery Status Notifications), so these will not trigger keyword filtering.

This issue is caused by a memory leak bug in the Microsoft DNS Server. You can find more information about the problem in our blog. If you experience this issue, please read Microsoft Knowledge Base Article 946565 regarding the fix.

You have been directed to this page because ORF has detected that you have upgraded to Microsoft® Exchange 2007 while ORF was installed on your computer. Because ORF connects to Exchange 2007 using a different technology than for IIS, Exchange 2000 or Exchange 2003, now you need to connect ORF to Exchange 2007.

Please follow the steps below to connect ORF to Exchange 2007:

1. Stop the MSExchangeTransport service
   

   You can do this from the Services MMC, from command-line using

   net stop MSExchangeTransport
   

   or from PowerShell using

   stop-service MSExchangeTransport
   
2. Remove ORF connections from IIS
   

   Open a command prompt and enter to the ORF program directory (\Program Files\ORF Enterprise Edition by default). Run

   orfinsthelper -uninstallconnector
   

This will uninstall any remains of the components that bind ORF to IIS. This step is successfull if you get no error messages.

3. Install the ORF Transport Agents
   

   From the same command prompt, run

   orfainst -install
   

   This will install and enable the ORF Transport Agents that bind ORF to your Exchange 2007 Server.

4. Configuring ORF for Exchange 2007
   

   Start the ORF Administration Tool and open the Configuration / Global / Microsoft® Exchange page. Click the Detect to automatically detect the Exchange Replay Directory path. Press CTRL-S to save the configuration, then press F11 to start the ORF Service.

5. Start the MSExchangeTransport service
   

   You can do this from the Services MMC, from command-line using

   net start MSExchangeTransport
   

   or from PowerShell using

   start-service MSExchangeTransport
   

You have been directed to this page because ORF has detected that you have uninstalled Microsoft® Exchange 2007 while ORF was installed on your computer. If you want to keep using ORF with IIS, Exchange 2000 or 2003, please follow the instructions below to connect ORF to IIS.

1. Install the ORF SMTP Module
   

   Open a command prompt and enter to the ORF program directory (\Program Files (x86)\ORF Enterprise Edition by default). Run

   orfsmtpinst -install
   

   This will install the ORF SMTP Module.

2. Bind the ORF SMTP Module to IIS
   

   Start the ORF Administration Tool and select the Configuration / Global / Server Bindings page. Bind ORF SMTP Module to the SMTP Virtual Servers.

   If the ORF Service is already running, press CTRL-U to save the binding changes and to restart the ORF Service.

   If the ORF Service is down, press CTRL-S to save the configuration changes and start the ORF Service by pressing F11.

Please consult the Best Practices Guide and make sure ORF is configured accordingly. If that does not help, use the Log Viewer to check the log entries of spam getting through: it is possible they are accidentally whitelisted (excluded from filtering) either by a manually added whitelist entry, or by the accidental pollution of the Auto Sender Whitelist database (to solve the latter problem, read the related KB article).

You can also contact our Customer Service anytime (be sure to check the "A few tips to get things fixed faster..." link on that page to get an idea what we will need to help you).

Most likely your database file got corrupted (see this article regarding the fix). Such problem may occur if too many emails are flowing through your server (e.g., sending out huge amounts of newsletters), which the embedded database engine of ORF cannot handle (see Which database is best for me? in the related Help topic for more information).

To solve the problem permanently, it is strongly recommended to switch to an External SQL database: setup instructions can be found in our guides. Once the SQL database is set up, you can migrate all data from the Private Local Database files using the Database Converter Tool.

The most common mistake is forgetting to "escape" special characters or anchoring the expression, so make sure you test your regex before adding it to your active configuration.

For example, you intend to filter attachments with .exe extension and come up with something like .*.exe. This works nice in the test box, but will also catch the file called monthly executive summary.doc. Why?

In regular expressions, the dot character acts as a wildcard (it matches any character). Accordingly, .*.exe translates to any characters, any number of repetitions, followed by exactly one arbitrary character, followed by the character sequence "exe". The anchor is also missing, so any characters are allowed after the exe character sequence, including cutive summary.doc. The proper regular expression is .*\.exe$, with the "escaped" dot character and with a trailing anchor ($ matches the end of string).

Another typical problem is with the keyword filter expression concepts. Regular expressions in ORF are evaluated on the entire content (not on every single word separately) so the regex cialis may not do anything (except if you want filter emails beginning with this word). The common mistake is adding wildcards improperly, like .*cialis.*. This expression will catch any emails containing the word specialist, because the wildcard will ignore word boundries. Adding \b to both sides of the expression like .*\bcialis\b.* will correct this, so the expression will match the exact word only.

Emails have two type of sender addresses: the first is called the SMTP envelope sender address, which is submitted by the sender server in the MAIL FROM: command during the SMTP transport – this is what ORF works with and logs. The other is called the MIME sender address, which is stored in the email header and this is what your email client (e.g., Outlook) shows.

These two addresses match in most cases, but not necessarily: it is absolutely legal to use different SMTP and MIME address information. The Bcc: addressing, mailing lists, CRM software and other systems with automatic bounce-handling often take advantage of this.

Spammers also tend to use different SMTP and MIME sender addresses to confuse the recipient, for example using the recipients own address as the MIME sender address, so it seems the user received the spam from his own address. To blacklist such spam, you should use a Keyword Blacklist expression which checks the MIME header instead of the Sender Blacklist. For detailed instructions, read the Other campaigns: MIME sender spoofing section of our related article).

If the above does not explain the problem, check whether the email was whitelisted using the Log Viewer. If it was not, make sure your Sender Blacklist expression matches the SMTP sender address ORF logged for this particular email.

This status does not indicate a problem, it only reports that the SMTP Module has not been loaded by the IIS Administration Service yet. The SMTP Module is loaded first time when an email arrives to the IIS SMTP virtual server you bound the SMTP ORF Module to.

If emails are flowing through the given SMTP virtual server, but the status is still "inactive", open the command prompt, enter to the ORF directory (\Program Files (x86)\ORF Fusion by default) to fix the SMTP Module registration.

For version 4.0 and later, run

For a pre-4.0 version, run

When ORF tags the email subject, the encoding of the subject is changed to UTF-8, regardless the original subject encoding. ORF does this because the language of the subject tag and the subject is not guaranteed to be the same (Cyrillic subject tag and Hebrew subject), thus the new subject must be encoded with an encoding that supports mixing various languages and writing systems, like the UTF-8 encoding.

This change made by ORF is correct by the email standards, but Microsoft Exchange Server 2003 has a bug that causes these emails to be displayed garbled in Microsoft Outlook when the message body contains non-English characters.

Microsoft provides a patch and detailed information about this bug in Microsoft Knowledge Base Article 900087 The body of an e-mail message is garbled when the header field and body field are set to different character sets in Exchange Server 2003. If this patch does not solve the problem, try Microsoft Knowledge Base Article 916299 The body of an e-mail message is garbled when the message is viewed in Outlook in an Exchange Server 2003 organization.

In case your Forefront / ISA server is configured to forward requests to Exchange with the option Requests appear to come from the Forefront TMG / ISA Server Computer (SMTP Rules), Forefront / ISA will delete the Received: header lines from the email, removing the email delivery path history. This causes ORF to think the email came directly from the ISA server, as it will not find the original sender (see Header Analysis in the ORF Help).

Change this setting to Requests appear to come from original clients in order to preserve the original headers.

Check the ORF logs: it is possible that you have accidentally started to whitelist spam, either by adding a manual whitelist entry, or the Auto Sender Whitelist database got “polluted”. See our KB article for solutions to the latter problem.

This problem is usually caused by recently added manual blacklist entries. Check the logs to find out which test classifies legitimate emails as spam and modify your configuration accordingly.

Check the related entries in the ORF logs using the Log Viewer to verify that ORF is causing the delivery issue. If the issue is not related directly to the delivery of emails (e.g., high CPU usage), stop the ORF Service temporary to see if the problem goes away. It is also recommended to check the Windows Event Log entries from the time period you experienced the problem. If none of the above helps, contact us: we are happy to assist in the investigation.

Start by checking the ORF logs using the Log Viewer to verify the email was blocked by ORF. If not (i.e., no blacklisting is logged), check the SMTP transport logs, the incoming queue and the Junk folder of the recipient. If the email has passed checks (or was whitelisted) at the On Arrival filtering point according to the ORF logs, that means it was allowed through ORF and the problem lies elsewhere. Note that even if ORF allows the email through, that alone does not guarantee its delivery: other software or Exchange itself may still block, alter or divert it.

Most likely a service pack or update of Exchange overwrote/broke a CDO registration, which ORF fixed before during installation (read our blog post regarding this). To fix the CDO registration:

1. Start a 32bit command prompt (Click Start, click Run, type c:\windows\syswow64\cmd.exe, and then click OK)

2. Run the following command:

   regsvr32 c:\windows\syswow64\cdosys.dll
   

   If the above does not help, unregister Cdoex.dll and cdosys.dll first:

   regsvr32 /u c:\windows\syswow64\cdoex.dll regsvr32 /u c:\windows\syswow64\cdosys.dll
   

   Then re-register Cdosys:

   regsvr32 c:\windows\syswow64\cdosys.dll
   

Under Microsoft® Exchange, the installer restarts the MSExchangeTransport service (Exchange 2016, 2013 Edge and Mailbox server roles, 2010, 2007) and/or the MSExchangeFrontendTransport service (2016 Mailbox server role, Exchange 2013 Client Access server role standalone or hybrid setup) during the upgrade process. SMTP email transmission will be down while these services are restarting. This usually takes less than a minute (your mileage may vary).

Under Microsoft® Exchange 2003, Exchange 2000 and IIS SMTP, the installer will shut down the IIS Administration Service and all dependent services while uninstalling the previous version of ORF.

It is recommended to schedule the upgrade to a time when the service outage causes the least problems.

Unlike anti-virus software, ORF does not require downloading any definition updates on a regular basis: the online blacklist databases it uses to identify spam (such as SpamCop and Spamhaus ZEN) are maintained centrally and queried via DNS in real time. This ensures ORF always works with the most up-to-date information available.

The update process of the ORF software itself (when a new version is available) has to be performed manually: no automatic upgrade is available currently. We also suggest updating the DNS blacklist and SURBL definitions after the upgrade as described in our KB article.

Yes, ORF is fully backward compatible and will update any earlier release. The configuration will be left intact, but it is recommended to create a backup before starting the upgrade process. For detailed instructions, consult our Upgrade Guide. It is also recommended to update your DNS and SURBL definitions after the upgrade and to make sure ORF is configured as per our recommendations described in the Best Practices Guide.

An annual license lets you use and update ORF Fusion for a defined period.

Once your license has expired, you will be given a 14-day grace period to renew your license, during which time ORF will remain fully functional. Once the grace period is up, you will be able to use ORF in demo mode with limited functionality. Test results can still be monitored using the Log Viewer and the Reporting Tool, but no filtering actions will be actually performed.

To resume filtering, you have to renew your license.

ORF Fusion is licensed per user, thus you can use it on any number of servers that belong to your organization, including subsidiaries. For example, a 10,000-user license will allow the use of ORF Fusion on just one server or 10 servers, as long as they all belong to your organization.

ORF was always the best value product on the market and that did not change. We formulated our pricing and licensing policy to directly beat competitor pricing and to eliminate the annoying (and expensive) hidden charges found elsewhere. Here is a breakdown on how we do it better:

• Pricing: ORF licenses and Software Maintenance Agreements cost less than any of the major competing product licenses.
• Performance: No other product achieved 0% false positive rate 5 times in the VBSpam test series - ORF did that with an excellent spam catch rate and with a rather basic configuration (that we barely touched during the testing).
• TCO: When configuration does have to be touched, ORF goes into great lengths to help the administrator. The intuitive UI of ORF saves administration time and thus money.
• No Hidden Charge: Fusion's 'per-user' license is per actual person benefiting ORF. Most competing products are licensed per mailbox or define 'users' otherwise.
• No Hidden Charge: Fusion can be installed on any number of servers. Competitors usually require additional licenses for multiple servers.
• No Hidden Charge: Our technical support is available even with an expired subscription. Most competitors require you to go through lengthy identification processes and charge a hefty price for help if your subscription has expired.
• Return Policy: We offer a 90 day, no questions asked money-back guarantee for ORF Fusion licenses.

You can renew your ORF Fusion license any time, before or after expiration, without any penalty. The renewal can be performed on the Client Portal.

Yes, discounts are available for educational/academic institutions and non-profit organizations. Please contact us with your proof of educational/non-profit status (e.g., 501(c) designation letter) to see if you qualify.

If you are not satisfied with ORF and want a refund, please contact our Customer Service within 90 days following your purchase. We will start the refund process immediately, so you will get your money back in full as soon as possible (usually a couple of days, depending on the payment method).

Request a trial extension from our Customer Service.

Unfortunately, you cannot. The Fusion for SBS edition of ORF has been discontinued with the release of ORF version 6.0, which supports both Small Business Server (SBS) and Windows Server Essentials installations as well.

Currently, we do not offer multi-year licenses.

ORF Enterprise Edition has been discontinued in 2012. You should purchase an ORF Fusion license in order to upgrade.

Registered ORF Enterprise Edition users have their Customer ID (a six-digit identifier) as their password assigned to their registered email addresses by default and will be prompted to change it to something secure upon their first login to our new website. If you forgot your Client Portal password, you can reset it by clicking the Forgot your password? link on the Client Portal login page.

Log in to the Client Portal, navigate to the My Client Portal: Profile page using the right-side menu and disable email notifications you no longer wish to receive under News & Notifications.