Welcome to part two in our series. Today, we will discuss External Agents.

External Agents – What are they?
External Agents allow you to link external software to ORF to perform additional tests on the incoming emails. The external software could be virtually anything (anti-virus, anti-spam or simple text analyzing software), the only requirement is that it should be a command line tool and it should run on the same server ORF is installed on.

How do External Agents work?
When an email arrives and reaches the External Agent test of ORF, a temporary copy of the email file is created (in a directory you specify). Then the agent calls the executable of the external software to scan this temporary file, the same way as you would perform a scan from command line. Once the scanning is finished, the external software returns an exit code (which tells ORF the final status of the email (e.g. 1 – I found no viruses, 2 – the incoming email is infected, 3 – I could not scan the file due to an error)) then it exits and the temporary copy is deleted. ORF can perform different actions based on the exit code returned by the external software: for example, if the email file is infected, drop it, or tag the subject line with [VIRUS].

External Agent Roles
Basically, there are two groups of External Agents: the ones you use for spam filtering purposes, and the ones you use for other security purposes (anti-virus). The latter ones can override regular whitelists in ORF, while the spam filtering agents act like other, normal tests in ORF (whitelists are applied, even if the email would be blacklisted by the agent).

Pros and Cons
Using External Agents provide further control over the email flow, for example you can add keyword filtering expressions using egrep and assign different actions for each (tag the email on X keyword but drop it on Y). You may also use it as an additional line of defense against viruses, or to scan incoming emails with an additional spam filtering software like SpamAssassin. Unfortunately, in most cases these additional, free software are quite complicated and hard to setup, but usually they worth the hassle.

However, no matter how effective some external software can be, you should keep in mind that some whitelists are applied in ORF no matter what (even if you add the External Agent test to the whitelist exceptions): emails originated from private local IP addresses (in other words, outgoing and internal emails) will never be scanned by ORF, so viruses may spread on your local network undetected if you rely on External Agents alone. Due to this, we strongly suggest using this feature as a second line of defense in addition to your existing anti-virus solution.

Shall I Use External Agents?
That depends on your intentions and the software you want to connect ORF with: if you anti-virus product has an email filtering feature by default which runs in the background, it does not make sense to use the command line feature of that anti-virus product in addition and scan all emails twice. But if you would like to widen the filtering tools of ORF, you may find the External Agent test quite useful.

In the next article, we will build an External Agent definition for a 3rd party anti-virus product to demonstrate how easy it is :)

We are launching a new support article series here on Vamsoft Insider, written by the ORF technical support guy, Krisztian (that would be me :). In these series I will provide in-depth answers for common ORF support questions and share my tips & tricks of using ORF. The first part of these series is about the databases of ORF, hope you will find it useful.

Databases in ORF
ORF has some features which rely on databases, namely the Auto Sender Whitelist, the Greylisting, the DHA protection and the Honeypot features (the latter two was introduced in version 4.3). SQL support the ORF databases was introduced in ORF version 4.0, and we encourage switching to an external SQL database ever since, as it has more benefits than drawbacks (for starters, you can see the actual database contents).

Of course, setting up a database can be a pain sometime (probably that is why most people uses the default Private Local database option, which requires no manual setup), but we provide step by step guides and scripts at our database guide page to ease the process as much as possible. If you ever experienced problems with the private local databases (e.g. occasional database corruption issues) or want more control over the database contents, switching to SQL is strongly recommended.

How will I know if my local databases are corrupted?
The symptoms of database corruption issues are

• “Error EABSException cleaning up expired database items. Database: (Auto Sender Whitelist | Greylisting | Honeypot | DHA)” error messages in the ORF logs
• “Unexpected (Auto Sender Whitelist | Greylisting | Honeypot | DHA) error. EAccessViolation [...]“ error messages in the ORF logs

I see the above mentioned error messages, what should I do?
It is advised to perform a repair on the affected database and to migrate the database to SQL.

How can I repair the corrupted local database files in the ORF Administration Tool?

Auto Sender Whitelist: Configuration / Tests / Auto Sender Whitelist / Database / Manage
Greylisting: Configuration / Filtering – Before Arrival / Database / Manage
Honeypot: Configuration / Tests / Honeypot test / Database / Manage
DHA: Configuration / Tests / DHA protection test / Database / Manage

How to setup the SQL database?
Please see our guides regarding this at http://www.vamsoft.com/dbguides.asp If you do not have any SQL servers installed, we suggest using the free Microsoft SQL Server Express products. If you use them for ORF only, these free editions are sufficient.

How to migrate all data from the current (local) databases to the external one (SQL)?
To migrate all information from the local databases (ABS files), you should use our Database Converter Tool (can be downloaded from http://www.vamsoft.com/vsdbconvert/). Note that you will need to have the SQL server prepared to receive the contents of the local databases.

How can I view the database contents?
We suggest using the free Microsoft SQL Server Management Studio Tool (see the guides regarding this tool).

Yesterday’s big news story is that Microsoft has announced the pricing model of Windows Azure, its new cloud services platform.

This is an exciting development and I think ORF could benefit greatly from cloud storage various ways (though I understand my ethusiasm is certainly not shared by you :).

The most obvious way to use Azure is to move ORF databases into the cloud, saving plenty of time (and money) setting up and administering SQL Server, while having the same benefits of a secure, reliable, shareable database. Private Local Databases of ORF can do a pretty good job until you reach a certain email volume (about 50,000 per day), when switching to an External Database becomes a necessity. External Databases are also required when you have multiple ORF servers. This is where Azure could help: once subscribed, ORF could create and maintain its databases in Microsoft’s cloud without your assistance.

Calculating the costs is not easy as it scales with use, but at around 100,000 emails you’d probably still get a database below 1Gb ($9.99), transmitting less than 1Gb data per month ($0.10 + $0.15) with about a million transactions for all ORF tables (about $1 for transaction requests). The total is only $11.24 per month or $134.88 per year. That is still quite compelling if you check Microsoft SQL Server 2008 pricing or just think about the time taken by the SQL Server setup and administration.