Microsoft introduced the Edge and Hub roles in Exchange 2007. The idea was to separate the perimeter (gateway) functions in order to perform filtering before the email reaches the central server. This includes recipient validation, i.e. to reject all emails sent to non-existent recipients. This is performed by an Exchange transport agent called the “Recipient Filter Agent”.

The Active Directory-based Recipient Validation of ORF is not available on Edge servers, because the Edge server do not have direct access to the AD, so ORF cannot query the valid recipients. This would not be a problem, (since Edge will reject emails sent to non-existent recipients anyway), but the Directory Harvest Attack (DHA) Protection test of ORF relies on the recipient validation of ORF, so that test will not be available on Edge (unless you use TXT or SQL-based recipient validation).

Moreover, as the Honeypot test relies on spam emails sent to non-existent email addresses (which you published to lure spammers), that won’t work either, because Edge will reject spam before ORF could record the delivery attempt to the Honeypot database.

Luckily, we can work the latter problem around by configuring the Trasport Agent of ORF to run before the Recipient Filter Agent:

1) Start the Exchange Management Shell
2) Enter the following command:

Get-TransportAgent | Format-List

3) ORF has two agents, the “Vamsoft ORF Routing Agent” and the “Vamsoft ORF Receive Agent”. You should set their priority of the latter higher than the priority of the “Recipient Filter Agent”, so it would run first.

To change the priority (e.g. to 7), run the following command:

Set-TransportAgent -Identity “Vamsoft ORF Receive Agent” -Priority 7

4) Finally, restart the MSExchangeTransport Service to apply the changes:

Restart-Service MSExchangeTransport

This way, the Honeypot test is performed before the email is rejected by the recipient validation of Edge.

We have received many reports that opening the installer executable of the trial or registered version of ORF fails with the following error message:

“Windows cannot access the specified device, path, or file. You may not have the appropriate permission to access the item.”

This error is shown even if you downloaded and try to run the installer as an Administrator, and you have full control over the file and the folder it resides in.

This is caused by a default Windows security feature (or rather: annoyance) to prevent EXE files from running before you Unblock them (huh?)

To fix this, do the following:

1. Right-click the file in Windows Explorer, select Properties
2. On the General tab, click the Unblock button

Now you can proceed with the installation.

ORF 4.4 is a minor update with mostly compatibility updates: both Windows Server 2008 and 2008 R2 IIS SMTP-only installations are now supported and also the Exchange 2010 support no longer requires a patch. For the complete list of changes, check the ORF Change Log.

You can download the new version from the Customers Area (or if you are using the trial, you can switch to 4.4 using the trial installer.

Do you have a secondary MX? If so, we are happy to save you a few bucks today.

How? Well, here is some food for thought! Let’s see a few disadvantages of running a backup MX.

• It costs money. More often than not spam and virus protection will cost you extra for your secondary MX.
• They are spam magnets. Spammers love going straight to your secondary MX, even when primary is up. And when that happens…
• …you will backscatter. Secondary MXs are typically lame relays that happily swallow emails for non-existent recipients. When your primary MX refuses to accept the undeliverable email, the secondary MX will send an NDR to the original and obviously fake sender. At very least you will be NDR-bombing innocent people, or end up on backscatterer.org.
  Be a good netizen, do not backscatter.

Of course, secondary MXs have benefits as well, such us… well, nothing I can think of.

Backup MXs were invented to accept and queue email when your primary MX is down. So if you do not have a backup MX, you will lose email when the primary goes down, right? Well, not quite. Most modern MTAs will recognize your only MX is down and will queue the emails for a few days. What you really gain by a secondary MX is the ability to set your own queue timeout. If it takes a week to fix your primary MX, you surely can make good use of the redundancy.

Is it worth it? Only your situtation justifies it. If you do not find a reasonable excuse, though, drop your secondary MX. Or, buy another copy of ORF for the backup server. We love that option as well :)

The current trial version of ORF (4.3) supports Exchange 2010 after installing a patch, but you may receive an error if you try to install the registered build on top of this patched trial version. That is because the installer of 4.3 registered does not incorporate the Exchange 2010 patch by default.

To solve this problem, you should simply ignore the installation error during the conversion process, install the patch again for the registered build, then issue the following command in the ORF installation directory:

orfainst -install

This will be addressed by the upcoming 4.4 version, which includes the patch by default.