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