We started to receive reports of Blackholes.us blocking all incoming emails.

This DNS Blacklist does not operate for some time now: the IP address space that they used for name servers now belongs to another, unrelated entity. Since many email administrators forgot to disable Blackholes.us in their anti-spam applications, the new owner continued to receive a huge amount of DNS queries. Due to this, they decided to return a 127.0.0.2 response for all queries, which means if you have Blackholes.us enabled, all incoming email will be rejected. (Similar thing happened to ORDB a while back)

To solve this, you should disable and/or remove Blackholes.us from your DNS Blacklist definition set (ORF Administration Tool: Configuration / Tests / DNS Blacklists). Finally, save your configuration to apply the configuration changes by pressing Ctrl + S. (Pre-4.3 versions also require a restart of the ORF Service: if you have such version, press Ctrl + U instead).

The recommended DNS Blacklists are listed in our best practices guide. We would recommend updating your whole definition set, as Spamhaus has also released an update recently. To wipe out Blackholes.us and to update Spamhaus at once, follow these steps.

Spamhaus has recently announced a new list called Composite Snow Shoe List (CSS), which is now included in Spamhaus SBL and ZEN. To learn more about the new list and to download the updated definition file, please visit

http://www.vamsoft.com/zen.asp

The goal of the Composite Snow Shoe List is to spam the so called “snow shoe” spammers, who send only moderate amount of junk from a single IP to stay under the radar. They spread the load between multiple IP addresses and domains to dilute reputation metrics and evade filters (just like a snow shoe spreads the weight, hence the name).

Hopefully, the new list will improve your current filtering efficiency even further.

We are often asked if ORF could redirect blacklisted emails to the Junk folder of users for further review instead of rejecting them. The answer is yes, it is possible: a guide for Exchange 2003 is already available. For instructions on Exchange 2007, please read on.

On Exchange 2003, we use the Custom Weighting Feature (CWF) of Intelligent Message Filtering (IMF) to increase the Spam Confident Level (SCL) score of the email if ORF tags it. (I wish I could put more three-letter abbreviations into this sentence, but I ran out :) On Exchange 2007, however, thing are much easier, since we can create a simple Transport Rule to achieve the same thing in a few steps:

I. Settings in Exchange

A. Using the GUI

1. Start the Exchange Manage Console
2. Expand Organization Configuration > Hub Transport and select the Transport Rules tab
2. Click on New Transport Rule in the Action pane
3. Name the rule (e.g. “SCL of ORF-tagged emails”). You can add a comment as well.
4. In the Conditions page, select the condition to trigger this rule: “When the subject field contains specific words”
5. Set the “specific word” to [SPAM] (the tag we will use in ORF)
6. In the Actions page, select the action “Set the spam confidence level to value”
7. In the rule description, click on the 0 link and add a value that’s above your SCLJunkThreshold, e.g. 9, and click Next
8. On the Exceptions page, click Next again
9. Click New, then click Finish.

B. Command line

If you prefer command line, issue the following commands instead of using the GUI:

II. Settings in ORF

1. Start the ORF Administration Tool
2. Expand Configuration / Tests / Tests in the left navigation pane
3. Assign all tests possible to On Arrival
4. Expand Configuration / Filtering – On Arrival / Actions
5. Click the Actions button and select “Accept email and perform further actions”
6. Check “Tag email subject with the text below” and enter [SPAM]
7. Click OK and save your settings by pressing Ctrl+S. (If you use an older version (pre-4.3), restarting the ORF Service is also required, so press Ctrl+U in this case)

And that’s it: ORF will tag spam, the Transport Rule will increase the SCL score of the tagged email to 9 and it will land in the Junk folder. Cool, isn’t it?

Some Things To Consider
Note that the above solution may not work if you run any other filtering software which may interfere (e.g. dropping the email before it would reach the Junk folder). Therefore, if you want ALL spam detected by ORF to be redirected, you may want to configure this other software not to drop these emails. This includes the Content Filter Agent of Exchange as well. You can disable the Delete, Reject, and Quarantine actions of CFA using the following command:

Last week we have received a report of a strange problem: the ORF user’s log was full of “Could not create statistics for the client. EORFStatisticsServerError/The statistics server is not initialized.” messages. We suspected a problem with the statistics, which ORF sends to our server anonymously (this data is used to feed the 24 hours statistics counters on our website, and the DNS blacklist popularity list). The statistics to be sent are stored in a file called orfstat.dat. After further examination, We have also found some “Could not load statistics. Error: EORFStatisticsServerError “Statistics file “C:\Program Files\ORF Enterprise Edition\orfstat.dat” is corrupted: XML parsing error.” messages. I asked the user to send over the above mentioned file: it was 0 Kb… Somehow, the file got corrupted beyond repair.

To solve the problem, I suggested to delete the file orfstat.dat from the ORF directory: this will not cause any trouble, since ORF will recreate the statistics file when you restart the service, so you won’t lose the statistics displayed in the Administration Tool either (Configuration / Information / Statistics).

I also suggested to disable sending anonymous statistics sending in Configuration / Global / Statistics if the corruption happens again, but it seems to be OK now. We are still investigating what might have caused this (we suspect some MSXML related problem). Though we received only a single report so far, which clearly points to a system specific problem, I thought it would be better to publish the solution if you experience similar things. Has anyone seen such messages in the ORF log recently?

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