As I promised, in this part of our series I will demonstrate how the Before Arrival filtering point of ORF can be tested.

Before Arrival vs On Arrival
As you may know, ORF has a unique, dual filtering model: the filtering can be applied before the email would actually arrive (after the RCPT TO: command during the SMTP conversation) or when it arrives in full (after the DATA command during the SMTP conversation, you can learn more about this by reading The “Filtering Points” Concept topic of ORF Help).

Both filtering points have advantages and disadvantages: at Before Arrival, we have limited information about the email, as it has not entirely arrived yet, but we can stop spam based on what we know in a very early stage, saving system resources by not accepting the email itself. We know the connecting IP address, the HELO domain submitted by the sender server, the SMTP sender and recipient addresses. This is not much, but it enough to drop the email for non-existent recipients (Recipient Validation), drop the email if the HELO is malformed (HELO blacklist), check the DNS records of the sender domain (Reverse DNS test) and reject unwanted senders (Sender Blacklist) in the earliest stage possible. If ORF runs on the front-end, the connecting IP is the sender IP, which can be tested against the IP Blacklist, online DNS Blacklists, or against the SPF record of the sender domain.

What we don’t have is the actual email body, including the attachments and the MIME header: these information is known only after the email data has been submitted (On Arrival). At the On Arrival filtering point, we have the entire email, so we can extract any information we want, but we have to wait for this till the end of the data submission stage (i.e. if the email comes with 20 MB of attachments we will drop, we have to wait for them to arrive first to tell whether they should be dropped).

ORF extracts the delivery path information from the MIME header (see Header analysis in ORF Help), that is why we were able to trick ORF when we tested our Agent. That method works for On Arrival testing, but how can we trick ORF to believe that the email is originated from an external IP at Before Arrival?

Difficulties
Due to the above, modifying the MIME header is out of the question (since it is unavailable at Before Arrival). You may use an external email provider like Gmail, but you might not find that suitable in some cases: let’s assume you would like to test Greylisting. Greylisting is a Before Arrival test, which rejects all emails temporary from unknown senders (and records the attempt in a database). According to standards, when the sender encounters such temporary rejection, it should re-attempt the delivery later. When the re-attempt takes place, ORF checks the database and finds that the sender has already been rejected temporary, so this attempt should be allowed through.

This works very well in most cases, since impatient spammers give up the delivery after the first attempt, while legitimate servers don’t (though this causes a delay in email delivery for legitimate emails), however, large providers (like Gmail, Yahoo, Hotmail etc) have many servers, and it is not guaranteed that the second delivery attempt arrives from the same IP address, so the re-attempted email delivery might get rejected again*… Not to mention that you have no real control over anything, so it is impossible to tell when the re-attempt actually takes place. This can make testing a really difficult and frustrating process. What to do then?

The Solution: Loopback Network Interface
To avoid these problems, we will need a sender with an external IP address, which we have full control over. Sure, you can setup a mail server and host it somewhere, but this can also be achieved by a few clicks for free, so let’s proceed with the latter instead :) We can setup a so called “loopback network interface” for testing purposes. The advantage of such loopback (or virtual) network interfaces is that you can test even if your server have no access to the Internet (because you want to keep it safe till everything is working fine). For setup instructions please visit this page.

Note that Windows will automatically assign an IP from the so called APIPA network range (169.254.0.1- 169.254.255.254) to the new network interface. This is good news for us, because this falls out of the private intranet ranges ORF whitelists automatically, so ORF will perform its Before Arrival test on emails originated from this network interface.

Once we have the interface set up, you can telnet to the loopback IP on port 25, send test emails (see our previous article for instructions) to non-existent recipients for example, and voila: Before Arrival filtering is applied (i.e. blacklisted attempts are rejected after the RCPT TO: command during the SMTP conversation).

Stay tuned for the next article, though as I’m about to go on holiday, it will be published in September only. Also, feel free to share your thoughts, suggestions and if you have any ideas for upcoming articles, those are appreciated as well.

* there are several ways you can avoid this, we will cover that in another article (maybe in the next one…)

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…

The latest from the named properties saga (see #1, #2): a new Get-NamedProperty PowerShell cmdlet (available from Exchange 2007 SP2) that helps learning when you are about to end up on the Fail Blog.

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.

Earlier today we went live with a new payment processor called FastSpring, which replaces share-it! as our e-commerce partner. We made this change to make your life easier, by offering a more integrated checkout experience (you will barely notice you left our website when making a payment) and a faster & better customer service in case it’s needed.

FastSpring is a California, US-based company and it’s among the few independent players in secure online payment processing, with distinguished focus on customer service. FastSpring offers practically the same range of payment options as share-it! does, with the exception of wire/bank transfers that will remain at share-it! temporarily. Support for accepting purchase order was recently introduced to FastSpring, we hope to make transition to their service soon.

You can check out the new shopping interface on the Pricing & Order page. If you have any questions, we are here to help.