We received sporadic reports of ORF blacklisting emails from the users’ own domain, because it does not find any MX or A/CNAME record for it. Of course, these records clearly exists when checked from the outside using nslookup, which makes the customer believe it is something wrong with ORF.

Actually, the problem is DNS-related and typically occurs when somebody uses a local DNS server in ORF for DNS resolution (which is recommended), but the very same local DNS acts as the authoritative DNS for his own domain. A common factor leading to this if the internal AD domain is the same as the public domain (e.g. domain.com, instead of domain.local or domain.internal or something like that).

To solve this, you should either switch to external DNS servers in ORF, or consider setting up another DNS server (e.g. on the local host) that forwards to the root DNS servers. The latter is the recommended method.

We published a new article regarding email backscatter at

http://www.vamsoft.com/howto-stop-backscatter.asp

We tried to answer as many questions as we could, hopefully you will find this article useful.

As you may have already read on our Facebook page, we have moved to a new office, so our postal address, phone and fax numbers have changed:

Vamsoft Ltd.
Budapest
Rétköz u. 5.
H-1118
HUNGARY

Phone: (+36) 1 999 0603
Fax: (+36) 1 700 2820

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.