Frequently Asked Questions

The latest 4.3 version of ORF supports Microsoft® Exchange 2010 by a patch. Learn more and get the patch from the Vamsoft Insider blog.

Yes, ORF 4.3 supports Windows Server 2008 R2 with Exchange 2007. However, IIS SMTP-only installations (without Exchange 2007) are not supported. This will change in the next ORF release, which will support IIS SMTP on both Windows Server 2008 and 2008 R2 (both 32-bit and 64-bit).

Yes, ORF 4.2 and newer versions support both Windows Server 2008 and SBS 2008 with Exchange 2007. However, IIS SMTP-only installations (without Exchange 2007) are not supported neither on Windows Server 2008 nor on SBS 2008.

In ORF 4.2, elevation is required for the ORF Administration Tool: the easiest way to archive this is to update the Admin Tool shortcut with setting the "Run as Administrator" checkbox. Without elevation, you may not be able to start/stop the ORF Service from the Admin Tool and also statistics will not be available. This step is not required in version 4.3 and above.

ORF 5 will fully support IIS SMTP-only installations both on Windows Server 2008 and 2008 R2 (both 32-bit and 64-bit).

Yes, it does, with a few restrictions.

It supports standalone IIS SMTP installations without Exchange on Windows 2000 and 2003 (including SBS). On Windows 2008 and 2008 R2, IIS SMTP-only installations are not supported as of now. The next version will support IIS SMTP without Exchange on these platforms as well, see Q: Does ORF support Windows Server 2008 R2? and Q: Does ORF support Windows Server 2008 (or SBS 2008)?

You can also use ORF with other mail server products (such as SmarterMail, Ipswitch IMail, Lotus Domino, etc.) as well in a forwarding setup with ORF filtering the mail flow first using IIS SMTP. IIS SMTP is included in every Windows Server (and even XP) releases, so this can be done even on a single server. The only limitation here is that the Active Directory-based recipient validation of ORF will not work. This can be worked around by using the SQL and text file-based fallback options (e.g. exporting addresses from the servers LDAP directory into a text file or SQL database upon changes or periodically, so ORF can always work with up-to-date recipient addresses).

Usually, it cannot, as ORF was designed to filter SMTP traffic. POP3 filtering is only supported if the POP3 downloader re-submits the POP-downloaded emails using SMTP. So ORF may filter the resubmitted emails, but even in that case there is a tradeoff: you would lose the ability to use the Before Arrival filtering point of ORF, so you could not use the Greylisting test, for instance.

To test this, download the trial version, install it, assign all tests to the On Arrival filtering point in Configuration / Tests / Test in the ORF Administration Tool, switch it to Test Mode (so no actual filtering will be applied) in Configuration / Global / Miscellaneous, save your new settings (Ctrl+S in the Administration Tool) and start the ORF Service (F11). If the POP connector resubmits these emails via SMTP, they should appear in the logs (you can monitor the logs of ORF using the ORF Log Viewer Tool). If not, that means that the POP3 connector does not resubmit the emails using SMTP, so unfortunately ORF will not be able to filter them.

The Microsoft Small Business Server POP Connector is known to use the Pickup folder for resubmission, so ORF will not see that incoming traffic unfortunately.

Yes, ORF can work in Exchange clusters, but as it is not cluster-aware, you have to install it to both cluster servers and synchronize the configuration manually. Alternatively, you can install ORF to a front-end server.

We are not aware of any issues with any anti-virus software.

However, if the anti-virus software works as an SMTP proxy, the Before Filtering point might not work (see Q: Before Arrival filtering does not seem to work, any ideas?). On Arrival filtering is not affected by this, so if you experience the issue above, you can choose to use On Arrival filtering only or to install ORF to a front-end server.

Yes, ORF can work behind firewalls, but the Before Arrival filtering may be unusable in this scenario.

Some firewalls behave like a proxy, first they receive the SMTP data and forward that to the server where ORF is running. Before email arrival, the email header is not available, so ORF identifies the sender server as the incoming SMTP connection remote peer.

When ORF is running on the primary MX and receives emails directly from the Internet (or via a transparent firewall), this address above is the IP address of the sender server. When a proxy or proxy-like firewall forwards the SMTP data, the connection is coming from the proxy and so the address is the IP of the proxy. As many ORF tests use the sender IP address, these tests may not work and the efficiency of ORF decreases significantly.

See Q: Before Arrival filtering does not seem to work, any ideas? regarding this.

It is suggested to deploy ORF to the network perimeter whenever it is possible (directly to the MX), so it can stop spam in the earliest stage. ORF can work well on back-ends as well, but you might not be able to use the Before Arrival filtering point of ORF, and therefore the Greylisting feature for instance (see Q: Before Arrival filtering does not seem to work, any ideas?).

If you have Exchange 2007 Edge and Hub servers, we recommend deploying ORF to the Edge server, but please consider that the Active Directory-based Recipient validation of ORF is not available on Edge servers, so some tests which rely on Recipient Validation might not work (e.g. Honeypot). This can be worked around by disabling the Recipient Validation feature of Exchange, and using the SQL and text file-based Recipient Validation of ORF instead (e.g. exporting addresses from the servers LDAP directory into a text file or SQL database upon changes or periodically, so ORF can always work with up-to-date recipient addresses).

See the Conversion Guide (55Kb PDF).

There is no need to download any updates or definitions on a regular basis: as DNS and URL Blacklists are stored online and queried via DNS in real time, ORF always works on up-to-date information. It is suggested to update ORF itself if a new version becomes available though, since we continuously add new features, improve existing ones, fix known bugs and update DNS and URL Blacklist definition sets. If your licensing covers the access to the new version, you can obtain the installer from the Customers Area. Upgrade instructions can be found in the Upgrade Guide (58Kb PDF).

In short: backup your configuration, uninstall ORF from the first server, install ORF to the new server, and import your configuration. For detailed instructions, see the Configuration Export/Import Guide (70Kb PDF).

Yes, ORF versions are always backward-compatible, so you can upgrade even from 1.x versions to the latest in one step. See the Upgrade Guide for instructions (58Kb PDF). It is also suggested to read the latest best practices guide (135 Kb PDF) and update your DNS and URL blacklist definition sets according to our recommendations if necessary (Selecting the best DNS Blacklists section).

ORF logs everything it does to your emails, including rejections and redirections among other things. Use the Log Viewer tool (shipped with ORF) to search, filter, sort, entries with a few clicks: you can find any information easily.

ORF logs everything it does to your emails, including rejections and redirections among other things. Use the Log Viewer tool (shipped with ORF) to search, filter, sort, entries with a few clicks: you can find any information easily.

By default, you cannot: if the email was rejected by ORF, it cannot be retrieved, as actually it has never arrived. If you would like to review all emails blacklisted by ORF, you should assign all tests to the On Arrival Filtering point (Administration Tool: Configuration / Tests / Tests), then you can configure ORF to tag or redirect blacklisted emails instead of dropping them (Configuration / Filtering - On Arrival / Actions).

Moreover, if you have Exchange 2003 or above, you can redirect blacklisted emails to the recipient's Junk folder for further review (see our guide and our blog post regarding this).

In the current version, you cannot: attachments can be either replaced by a removal notice or the entire email is dropped. In any case, the blacklisted attachment cannot be retrieved: you should ask the sender to resend it after making sure the next attempt will be delivered.

That depends on your system and intentions. Each test works differently and have different purposes: you should read the description of each in the ORF Help (F1) and our best practices guide and decide yourself, there is no ultimate test set which will work for anyone equally. For example Greylisting has an excellent spam catch rate, but if your ORF installation runs on the back-end, it makes no sense to enable it. For others, the delay in legitimate email delivery is unacceptable, so they keep it disabled on the front-end as well.

Yes, it is called the Getting the most out of ORF Guide (135 Kb PDF).

If you are not sure, we recommend choosing the On Arrival filtering point. It is suitable for most of the ORF users.

If ORF runs on the front-end, and you have no secondary MXs, assign all tests possible to Before Arrival.

If ORF runs on the front-end, but you have a secondary (backup) MX server, you should add the secondary MX to the Intermediate Host List and assign all tests possible to Both filtering points.

If ORF runs on the back-end and there is a front-end before it, you should add the front-end to the Intermediate Host List and assign all tests to On Arrival (Greylisting won't work).

You can read more about the recommended test assignments in our best practices guide (135 Kb PDF).

It really depends on your intentions. Some DNS blacklists are more effective than others, but may have a higher false positive rate. Our current recommendations are listed in the Selecting the best DNS Blacklists section of our best practices guide (135 Kb PDF). You might also want to take a look at the DNS blacklist usage and effectiveness statistics or you can also ask for other users' opinion on the ORF newsgroups.

The best to start with is uribl.com and the SURBL: Combined SURBL list. The latter includes all other SURBL lists. If you feel that one of the lists contained by the combined list generates too many false positive hits, you can select the SURBL's separately, excluding the SURBL that you do not want. Our current recommendations are listed in the Selecting the best URL Blacklists section of our best practices guide (135 Kb PDF).

Add your business partner's email address, domain or outbound email server IP address to the sender or the IP whitelist of ORF.

We recommend using the sender whitelist which is easier to configure. If your business partner's email address looks like john@company.com, you can add john@company.com to the sender whitelist or whitelist the whole company domain using the mail mask *@company.com.

Because ORF works with SMTP Envelope addresses, while your email client shows the MIME From: address (see Q: Why ORF does not block foo@bar when it is on the Sender Blacklist?)

If you are not sure what you are doing, set the header check depth to 1. This is the recommended and default value for the header check depth. This value also could be right for your if you have a secondary MX (which is added to the Intermediate Host List).

By setting the header check depth higher than 1, you can increase in the spam blocking effectiveness, but most likely the number of false positives will also increase.

If you use a Private Local Database, you should simply add the sender to the exception list of the Auto Sender Whitelist database, so it will not be whitelisted anymore (ORF Administration Tool: Configuration / Tests / Auto Sender Whitelist / Settings / Check exceptions) In pre-4.2 versions, you can edit the private local database file contents using the Auto Sender Whitelist Browser (note that in 4.0-4.2 versions the ORF Service should be stopped first in order to edit the database).

If you use an SQL database, you can delete the record using any tool of your choice (e.g. SQL Server Enterprise Manager, Query Analyzer, SQL Server Management Studio etc.)

If you use a Private Local Database, you should simply add the sender to the exception list of the Auto Sender Whitelist database, so it will not be whitelisted anymore (ORF Administration Tool: Configuration / Tests / Auto Sender Whitelist / Settings / Check exceptions).

If you use an SQL database, you can delete the record using any tool of your choice (e.g. SQL Server Enterprise Manager, Query Analyzer, SQL Server Management Studio etc.)

Use the ORF Database Converter Tool.

ORF uses PCRE engine (Perl-Compatible Regular Expressions), which implements (almost) the same syntax and semantics as Perl 5 (see http://www.pcre.org and http://www.pcre.org/pcre.txt [warning! large file] for documentation). Note that it is not the same engine used by Perl, Java or the .NET Framework.

We suggest using regular expressions: Start the ORF Administration Tool, select Configuration / Filtering – On Arrival / Attachment filtering. Click New and set the Filter by attachment name checkbox. Select Regular expression (Perl-compatible) and enter the filtering expression (see below). Select what should ORF do with the attachment (Filter Properties tab), optionally assign a comment to the filter and click Ok.

To block ZIP attachments, simply add

.*\.zip$

This will block all attached files ending with ".zip". You can also specify more than one extensions by a single expression. If you wish to block ZIP, EXE, COM and VBS attachments, enter an expression like

.*\.(zip|exe|com|vbs)$

There are same common mistakes of novice regular expression users, make sure you tested your filter correctly.

The most common mistake is to forget "escaping" the special characters or anchoring the expression, Example: The novice user wants to filter attachments with ".exe" extension and he come up something like ".*.exe". This works nice in the test box, but will also catch "monthly executive summary.doc". Why? First, the dot character is a special character which means "any arbitrary character". Thus, when you write ".*", it translates to "zero or more arbitrary characters, 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.

Another typical problem is with the keyword filter expression concepts. You should know that the regular expression is evaluated on the entire content, not on every single word separately, so a regular expression filter like "cialis" may not do anything (except if you want filter emails beginning with this word). The common mistake is to use a filter like ".*cialis.*". For this first look, it appears to be correct, but there is a significant problem with it: the expression will catch any emails containing the word "specialist", because you did not tell the regular expression engine anything about the boundaries. So, just add \b to both sides of the expression (".*\bcialis\b.*") and only those emails will be caught be the filter expression which contain the word "cialis" and a word delimiter on both side of the word.

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 whitelists (skips test for) the incoming Delivery Status Notifications (DSN's—a subtype of DSN's is the Non-Delivery Report, also called NDR).

There may be certain situations when it is useful to disable this auto-whitelist feature. Start ORF Administration Tool, select Configuration | Global | Miscellaneous and set the Allow filtering Delivery Status Notifications checkbox. When this checkbox is set, ORF will treat emails with blank sender as regular emails. Note that this does not result in rejecting all DSN’s, only that these emails are tested and maybe blocked just as the other emails.

First check your logs for the status of the given email, it may have been whitelisted. If it was not, check your filter expression: shall it really catch the email?

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.

First, please check the ORF logs regarding this given sender, it may have been whitelisted. It is also possible that you do not find the sender in the logs and you can match the email by the recipient and the arrival time only. Why? Because ORF identifies the sender and recipient as the SMTP envelope sender and recipient.

Emails are similar to the real life postal mails. You put your letter into an envelope and write the sender and the recipient to the envelope. The post office delivers your mail to the recipient on the envelope, they do not open your envelope and check who is the sender and recipient on the letter paper. Emails also have envelope sender and recipient (they are called SMTP envelope sender and recipient) and letter sender and recipient (called MIME sender and recipient). Your email client, like Outlook displays the MIME sender and recipient only. Actually, the envelope sender and recipient is not stored in the email anywhere. *

The SMTP envelope and MIME envelope information matches in most cases, but spammers often use different SMTP and MIME information to confuse the recipient. 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 also often take advantage of this.

* We offer a free script on our website that inserts the SMTP envelope information to the mail header, see the Scripts & Tools section of our website.

See Q: "Why "Reject recipient" event is logged when it was a sender rejection?"

This is specific to the Before Arrival filtering point. ORF builds into the SMTP connections (the transfer protocol of emails) and monitors specific protocol events. The Before Arrival filtering is performed when the sender server tries to specify the recipient(s). On this event, ORF performs the tests assigned to the Before Arrival filtering point and if the incoming email fails on the tests (e.g. the sender email address, the connection IP address or the recipient is blacklisted), it rejects the email recipient. So it is not actually the email rejected, it is the recipient. The On Arrival filtering point actually deals with the email, so it uses the "email" terminology.

An email may have multiple recipients, so the rejection of a single recipient may not result in rejecting the entire email.

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 (Configuration / Global / Log and events / 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 in Configuration / Global / Log and events / ORF PowerLogs - Configure button), though these are relatively small files, so might want to keep them in case you need to create reports in the future.

Spammers often forge the recipient address as the sender address to confuse the recipient. Please read our article for solutions.

The problem is called email backscatter: the spammer spoofs your domain name and sends spam to somebody. When the target server detects the spam, it generates a Non Delivery Report (NDR, bounce) and sends it to the sender address, but since it was forged, your users will receive the NDRs instead of the spammer. To prevent this, you should make sure ORF filters NDR messages (Configuration / Global / Miscellaneous / Allow Filtering Delivery Status Notifications) and import our Backscatter Protection External Agent. It is also suggested to publish an SPF record to stop email forgery in the name of your domain and to enable the SPF test of ORF.

To prevent your server to send such NDR floods to innocent parties, it is recommended to run ORF on the front-end server and reject spam as early as possible: if the email is rejected at Before Arrival, only an SMTP response is sent to the sender server, which from it generates the NDR to the actual sender address (in other words, the responsibility of NDR generation shifts to the sender server).

There are some scenarios when the Before Arrival filtering cannot be used effectively, typical examples are:

• incoming emails are filtered by an anti-virus/mail filtering proxy running in front of ORF
• incoming emails are forwarded by a front-end server
• incoming emails are received using a POP3 forwarder
• incoming emails arrive via a secondary MX

These scenarios can be recognized easily, check the ORF logs and if you find that all incoming emails are from the same IP address at the Before Arrival filtering point, most likely you experience the problem above.

Before email arrival, the email delivery path is not known, so ORF identifies the sender as the incoming connection remote peer. In the scenarios above, these peers are not the actual sender servers, but the forwarders (proxy, front-end, etc.) so IP-based tests (including DNSBL tests) does not work, the emails may be whitelisted (due to the source intranet address).

In this case, assign all tests to the On Arrival filtering point (ORF Administration Tool, Configuration | Tests | Tests).

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, open the Configuration / Global / DNS and Lookups page and click button Test DNS.

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 there are emails flowing thru the given SMTP virtual server, but the status is still "inactive", open the command prompt, enter to the ORF directory (\Program Files\ORF Enterprise Edition by default) to fix the SMTP Module registration.
For version 4.0 and later, run "orfsmtpinst -install". For a pre-4.0 version, run "regsvr32 orfesmtp.dll"

You should simply add the sender's email address, domain or IP address to the Greylisting exceptions (ORF Administration Tool: Configuration / Filtering - Before Arrival / Greylisting) and save your settings to apply the changes (Ctrl + S).

First of all, it is suggested to check the ORF logs using the Log Viewer. If the sender was rejected once by Greylisting and never re-attempted the delivery, that indicates a problem on the sender's side: according to RFC standards, email servers should always re-try the delivery of an email which was rejected temporary by the recipient. You should contact the sender so he/she can investigate this problem. Until this is fixed, you can add the sender to the Greylisting exception list, so future delivery attempts will not be greylisted by ORF.

It is also possible that the sender has multiple servers, and each delivery attempt came from a different IP address. You can reduce this problem by enabling the "Accept delivery retries from the same /24 subnet" and/or by adding the sender to the Greylisting exception list.

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 ISA is configured to forward requests to Exchange with the option Requests appear to come from the ISA Server Computer (SMTP Rules), 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 (see Header Analysis in the ORF Help).

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

Most likely, you private local database file has been corrupted. It is advised to perform a repair on the affected database (under the settings of the test, click Database > Manage) and to migrate the database to SQL (visit the database guide page for instructions).

If the error message is "A referral was returned from the server", make sure that you have a valid LDAP path configured for ORF. 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 2000/2003/2007. 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 Configuration / Test / Recipient Validation / Active Directory (Configure selected) / Use the LDAP root below on the Directory tab in ORF Administration Tool.

It is also possible that your server requires authentication: please try with user name and password specified for LDAP authentication (Configuration / Tests / Recipient Validation / Active Directory - 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.

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

Most likely a service pack or update of Exchange 2007 overwrote and broke a CDO registration, which ORF fixed before (read our blog post regarding this). Please try to fix the CDO registration as follows:

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:

1) Unregister Cdoex.dll and cdosys.dll first:

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

2) Then re-register Cdosys:

regsvr32 c:\windows\syswow64\cdosys.dll

It is not possible to extend the 30-days trial period, but you can you can "downgrade" to the trial version of the previous release after the trial of the latest version expires to gain additional 30 days (as the trial limitation is per version). You should simply backup your configuration, uninstall the trial, install the trial of the previous version and restore the configuration (see our Export/import guide for detailed instructions).

Discounts from the full ORF license price are available both for educational/academic institutions and non-profit organizations. Please contact us with your proof of educational/non-profit status to see if you qualify.

Basically, yes, but of course this also depends on your intentions. If you renew the SMA, you will get all updates for one more year. If you are satisfied with the last version and you do not need updates, you do not have to buy the SMA and you can still use the last version you have as long as you want.

However, you should consider that when a new version is released, you will have to buy a new license again in order to obtain it (if you have no valid SMA(s)).

If your SMA has expired and you did not renew it, you cannot download ORF releases published after the SMA expiration date. The SMA cannot be renewed once it has expired, so if you want a newer release, you have to buy a full license of ORF again.

A few days is not a big deal: please contact us regarding this and we will let you know how you can renew your Software Maintenance Agreement. However, if your SMA expired months ago, you will have to buy a new license to gain access to upcoming releases.

You need exactly as many SMA's as many ORF Enterprise Edition licenses you have, so if you have 1 ORF Enterprise Edition license, you need one SMA. If you have 2 licenses, you need 2 SMA's, accordingly.

The SMA covers access to ORF releases within the SMA validity period.

No, there is no such option.

Yes, the default settings for your newsletter preferences contain SMA expiration notifications, so you will be notified in email at least one week before your SMA expires. This notification can be disabled in the Customers Area. If you previously configured your newsletter preferences to deny all newsletters, the SMA expiration notification will also be disabled.

Yes, you can. The SMA covers only the updates.

Yes, you can. The SMA covers feature updates only. We do not want to force you this way to renew the SMA, we believe that would be an unfair business practice.

No, are no such fees. The SMA licensing does not make difference between minor and major releases, you get all releases in the SMA validity period, regardless the version number or the new features.

No, we currently do not have such option.

Please send us an email to orf@vamsoft.com and include your Customer ID in your request. If you purchased ORF via the reseller and you do not know the Customer ID, ask the reseller to send us the address change request.

It is very simple: if you are not satisfied with ORF, just send us a refund request and include your order reference number. You will get 100% of the product price back in a few days, without any questions. It is not that we would not appreciate an explanation - we are trying to improve ORF every day and if we know what was wrong, that may help - but by the time we ask you anything, the refund process is already started and regardless if you answer or not, you will get your money back.