Let’s continue from where we left off: in our previous article, we have created a new External Agent definition file. Now, let’s test it.

Obtaining the test file
To test the Agent, we will use the so called EICAR test virus file. EICAR is short for European Institute for Computer Antivirus Research (it reminds me of some super villain organization like SPECTRE in the James Bond series :) EICAR designed a test file, (an innocent, executable string), to test the integrity of antivirus software. You can obtain this test file in various formats (simple text, COM file, COM file in a ZIP etc) from this page. I recommend using the zipped one, as this way we can test whether the agent finds viruses in archive files as well.

After downloading the test file, we should send it in an email to a local recipient. The test email should arrive from an external IP address, as ORF treats the localhost address (127.0.0.1) and class A, B and C private intranet addresses as they were part of the Intermediate Host List, so emails from these addresses are whitelisted by default in order to prevent blacklisting internal and outgoing emails (see Pros and Cons in Part 2). This means if you send the test mail from an internal IP, it will be whitelisted and the External Agent test will never be triggered.

Sending the test emails
You should either use an external email provider to send the test file (e.g. Gmail), or “trick” ORF to believe the email has arrived from an external IP. The first method is easier, though keep in mind that some email providers may filter their outgoing emails as well, and their anti-virus solution may remove the test file before it would reach ORF.

The second solution can be achieved by adding a “Received: from” MIME header line to the email. As you probably know, ORF extracts the delivery path information from the MIME headers at the On Arrival filtering point (see Header analysis in ORF Help), so by adding an external IP as the source, ORF will skip the local IP and think the email came from the next (non-local) delivery hop.

To ease things, we have built an email with EICAR attached and with an IP from the so called APIPA range as the source (because this falls out of the above mentioned private intranet ranges, so whitelisting will not be applied in ORF).

All you have to do this is save this file, extract the contents to an arbitrary directory (password: virustest), open the EML file with Notepad, and copy the entire contents of it. Now let’s start a command prompt and telnet to port 25 of your local server (e.g. telnet 127.0.0.1 25). To learn how can you send emails using telnet, please read this article. This Wikipedia article may also come in handy.

After you issued the DATA command during the SMTP conversation, paste the contents of the EML file, and hit enter. Finally, finish the DATA phase by typing a single dot (“.”), hit enter again and wait for the magic to happen.

You should receive something like “550 5.7.1 Message rejected. VirusScan found virus in the message” (or the SMTP response you configured) if the agent works. If the email was allowed through, you should check the ORF logs using the ORF Log Viewer: it is possible that it was whitelisted for some reason.

Note that this method can be used for testing any of the On Arrival tests of ORF. “And what about Before Arrival?” you might ask. Well, we will reveal that in our next article, so stay tuned…

Welcome to part three of our series. As I promised in the previous article, now we will build an External Agent definition for an anti-virus product.

What will we need?
First of all, ORF of course (External Agents are supported since version 2.1), an external software which is capable of scanning a file from command line (I chose “McAfee VirusScan Command Line Scanner for Windows” for this demonstration, (you can download it from this page), and a test virus file we can use to test. For the latter, we will use the Eicar test file, which was created for testing anti-virus products (i.e. anti-virus products think it is a virus, but it is not, you can grab it here.

Getting Started
Let’s download the above mentioned files and extract the anti-virus product to an arbitrary directory. Read the documentation file of the anti-virus product, especially those sections which discuss the command line parameters and the exit codes, we will need those later on.

ORF Configuration
As I mentioned in the previous article, ORF creates a temporary copy of the email, which can be scanned by the external product. The temporary email file path should be configured in ORF (Configuration / Filtering – On Arrival / External Agents / Path for temporary email files). This could be any directory, but make sure it is excluded from antivirus filtering, otherwise it may delete the temporary file before ORF would scan it. Now, let’s create the agent definition:

Select Configuration / Filtering – On Arrival / External Agents in the left navigation pane of the ORF Administration Tool, and click New. The External Agent properties dialog will pop up. Let’s go through the different tabs:

Description tab
You can assign a name for the Agent so you can identify it later (e.g. “McAfee VirusScan”), and write some description for it.

Run tab
Agent executable: the path of the external executable should be set here, e.g. C:\Program Files\McAfee\scan.exe
Parameters: this is where we specify the parameters to be passed to the command line executable. The {EMAILFILESPEC} parameter is the variable pointing to the temporary file location. You should use this instead of the actual path of the file to be scanned (the temporary email copy ORF creates), because the file name differs for each email. For McAfee, we will use the following parameters:

/ALL (as we want to scan the file regardless of its extension)
/MIME (scan MIME encoded files)
/NOMEM (this will disable scanning the memory: we would like to restrict the scan for our temporary file only)
/SILENT (as the scan won’t be issued by a human being, there is no need to report anything back to ORF other than the exit codes)
/UNZIP (as we want to scan attached archive files as well)

So the parameter should look like this:

{EMAILFILESPEC} /ALL /MIME /NOMEM /SILENT /UNZIP

Timeout: the name speaks for itself – you can set how long ORF should wait for the response (return code) sent by the external software. If no response is returned within the specified time frame, the test will be simply skipped and ORF will proceed with the next external agent test (if there is any more).

Role tab
As we discussed in the previous article, there are two roles, which could be assigned to our External Agent: the Spam Filter Role should be selected if the agent is used for spam filtering (and whitelists should override the blacklisting it triggers), while the blacklisting triggered by an External Agent with Anti-Virus or Other Email Security Role can override whitelistings (if it is enabled in Configuration / Tests / Tests / Whitelist Test Exceptions). We will choose the latter in this case.

Logging tab
Check what should be recorded in the ORF text log (agent outpot on hit and/or error). Since version 4.3, you can also configure ORF to log the temporary file name.

Exit codes tab
Probably the most important setting: on this tab, you can set what the default action should be (e.g. tag the subject or reject the mail), and assign different actions for different exit codes. For the default action, I will choose “Accept email and perform further actions > Tag email subject with the text below: [VIRUS]” for now, because I want to test my agent first. Now let’s add some exit codes and assign different actions for them:

If you check the documentation of McAfee, you will find a list of exit codes and their meaning. For example exit code 13 means “virus found”, while exit code 6 indicates that “an error occured”. You should add all relevant exit codes and assign different categories for them (you would never guess: “Hit” for hit, and “Error” for error :), than you can assign different actions (e.g. perform the default action on hit, which is tagging the subject). You should not add those exit codes, which indicate the file is clean (unless you want to tag clean emails with a text as well).

I configured the following:

Exit codes 2,6,8,12,15,20,21,102: Error
Exit codes 13, 19: Hit

If everything is set, we can click OK on the External Agent dialog. Make sure you have the Agent enabled and you have the External Agent test enabled in Configuration / Tests / Tests. Now we can proceed with testing…which will be the next part of our series.

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

Recently, we encountered several issues with Skype chat, which made it nearly impossible to provide proper support via this channel.

The first issue we experienced several times (i.e. daily) was that Skype popped up the incoming messages only days later they were sent to us. I checked this on the Skype forums, and found out that Skype handles offline messages in a very weird way: let’s say a customer tries to contact us at 11:00 PM CET (surprisingly, we are not in the office at 11PM :). As we are offline the message is not delivered. Next morning, we start up the engines including Skype, we are online. You would expect that it notifies me that “Hey! Somebody tried to send you an urgent message! He even left his email address so you can contact him immediately!” But no!

Skype delivers the message only when both the customer and us are online! Which means: in most cases, never. Or days, even weeks later.

If you think about it, you can say: “OK, that is reasonable in some way, as we can contact each other via Skype only if both of us are online”. But there are other means of communication as well, that’s what Skype fails to understand.

Moreover, we had several cases when I received an old message from a time period when I was definitely online. In other cases, the customer sent us a message, I received it immediately, we were both online, but I could not answer (I received “Your message is not yet delivered” errors).

How do you explain these? I checked the Skype forums again, others have the same issues (so it’s not just me). Skype replied with the million-dollar solution: update to the latest version. But we already have the latest version… Then they told us this problem may occur if I have a different Skype version from the people I’m trying to talk to. Whaaaaat? So in order to send messages to each other, both of us should be online and both of us should have the same (latest) version. This is nearly impossible, but let’s say we managed to achieve it. Even then, Skype drops the connections randomly.

Imagine this reliability in a product environment, for example if we would decide to provide support via Skype only to save money…

Now I’m not surprised anymore when I get messages like this once in a while:

Me, too, buddy. Me, too…