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).

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.

ORF is best deployed on the network perimeter, on your primary mail exchanger servers (primary MX) and optionally on all secondary MXs (if there are any). On Exchange 2007 and above, install ORF on the server with Edge Transport role. If you do not use edge servers, install on the Hub Transport role server.

After obtaining the installer of the registered build, you should simply install the registered version 鈥渙n top鈥?of the trial: the previous configuration will be preserved. It is also recommended to create a backup of your current configuration before the conversion: 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: in fact, a separate edition is available especially for SBS users with per server licensing. The regular ORF version (with per user licensing) also supports SBS.

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 Test 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 2010 and 2007, the installer restarts the MSExchangeTransport service. SMTP email transmission will be down while the MSExchangeTransport service is restarting. This usually takes less than a minute (your mileage may vary). 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.

First of all, we recommend reading the ORF 101 guide, which describes how ORF operates. 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鈥檛. 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鈥檛 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 Best Practices Guide (Efficient Spam Filtering / Tests: A Starter Plan section).

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

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

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

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).

Attachment filtering can be configured to replace blacklisted email attachments with a removal notice, or to drop the entire email: currently it is not possible to quarantine removed attachments for retrieval.

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 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 phenomena 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.

If you run Exchange 2007 and later, please see this KB article for detailed instructions. For Exchange 2003, please consult our Exchange 2003-specific documentation.

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.

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.

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.

Please consult the Best Practices Guide and make sure ORF is configured accordingly and you have the recommended DNS Blacklists and SURBLs enabled. 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).

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 鈥減olluted鈥? 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.

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.

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 standard 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.

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 media, 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.

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 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.

The issue is typically caused by the ISP DNS servers, so we recommend using local DNS servers. You should consider that ISP DNS servers are out of your control and their configuration may change without prior notice.

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.

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.

If the error message is A referral was returned from the server, 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: 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 "...": 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 2010/2007/2003/2000. Synchronization with a regular Active Directory without these schema extensions is not supported.

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.

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
   

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.

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.

Under Microsoft庐 Exchange 2010 and 2007, the installer restarts the MSExchangeTransport service during the upgrade process. SMTP email transmission will be down while the MSExchangeTransport service is 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.

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.

SMAs (Software Maintenance Agreements) allow you to download and use any ORF version released within their validity period. ORF licenses are bundled with SMAs valid for a year, so you are guaranteed to access all versions released within a year after your initial purchase with no further costs.

SMAs can be renewed (currently for an additional year only) within 60 days prior or within one year after expiration. The expiration does not affect your current ORF installation in any way (it will continue to function), and you are also eligible for technical support even after expiration. However, if you intend to upgrade to a more recent ORF version which your latest SMAs do not cover, you should either renew or (if your SMAs expired more than a year ago) purchase new licenses.

You will need to purchase as many SMAs as many users or servers you currently have (depending on your license type). This also applies if you have an ORF Enterprise Edition SMA and you are upgrading to Fusion or Fusion for SBS licensing.

If you need less licenses than you purchased earlier, you should simply purchase less SMAs (e.g., if you purchased ORF Fusion licenses for 100 users initially, but now your company has only 80 employees.)

However, if you want to extend licensing for more users/servers than you currently have, you will need renew all your current SMAs, then purchase extra seats/licenses.

Your current ORF installation will continue to function without any restrictions, you will be able to download the installer of the last version your SMA covered any time from our website, and you will also be eligible for technical support. However, you will not be able to download and install any new ORF versions released after the SMA expiration date.

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 ask no questions (but will probably thank you for giving ORF a shot), just initiate the refund process immediately so you will get your money back in full as soon as possible.

Request a trial extension from our Customer Service.

If you have one or more ORF Enterprise Edition SMAs which expired in the last 365 days, you can upgrade to the new licensing program buy purchasing Fusion or Fusion for SBS SMAs. We provide roughly 30% discount from the list prices for such upgrades. If your ORF Enterprise Edition SMA expired more than a year ago, new license(s) should be purchased in order to upgrade.

Currently, purchasing SMAs for more than a single year is not possible.

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 SMA. Most competitors require you to go through lengthy identification processes and charge a hefty price for help if your SMA has expired.
• No Hidden Charge: You can let your SMA expire and renew it later with no penalties.
• Return Policy: We offer a 90 day, no questions asked money-back guarantee for ORF Fusion and Fusion for SBS licenses.

ORF has been split into two products: ORF Fusion and ORF Fusion for SBS. Both products offer the same, full range of features and services. They are different in their licensing model: ORF Fusion is licensed per user (with unlimited servers). ORF Fusion for SBS is licensed per server and will run on Windows Small Business Server only.

For more complete information, please see the ORF 5 Changes page.

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.