Ever since the Active Directory-based recipient validation was implemented in ORF, we receive requests to make it exempt from whitelisting, i.e. to reject the invalid recipient even when e.g. the sender is whitelisted.

The request is perfectly reasonable, yet it does not play very well with ORF.

Here is the problem: ORF is primarily a spam filter, but some of its features have email security role more than anti-spam. These tests are the AD Test, Recipient Blacklist (for recipient validation), Attachment Filtering and External Agents (agents filtering for viruses). Regardless role, these are blacklisting tests, so whitelists take precedence over them. This results in hardly reasonable scenarios like letting a virus-infected email enter to your system, just because the sender is (auto) whitelisted.

Obviously, we have to deal with this problem somehow. We went through to quite a few possible solutions, but unfortunately none of these were without tradeoffs.

First, we cannot just re-prioritize these tests to run without whitelist control. Remember that ORF monitors all incoming SMTP connections, including SMTP connections that are used to relay outbound emails. If no whitelisting mechanism is employed, ORF filters outbound email as well. That may sound acceptable, or maybe even great for Attachment Filtering and External Agents, but I am quite confident that you do not want the recipients of your outbound emails validated as local addresses. A few would pass.

Ok, so we still need to exclude outbound emails from these tests. Good news: ORF already does this. Bad news: it does it a weird (but otherwise practical) way.

The best way to tell whether the email is inbound or outbound is to check the recipient domain and if it is a domain that your server is responsible for, the email is inbound, otherwise outbound. Cool, but you might have noticed that ORF does not keep track of the local domains.

Instead, ORF uses two whitelists which almost accidentally eliminate the need for outgoing email detection. The first is the AUTH Whitelist that whitelists emails arriving via authenticated SMTP connections, thus it covers authenticated outbound relaying. The second whitelist is the IP Whitelist, which

• Whitelists email from the local host
• Whitelists emails coming from Intermediate Hosts, which always includes the private intranet address ranges.

These two IP Whitelist rules cover the typical outbound relaying cases, and when not, it is enough to add relaying server’s IP address to the Intermediate Host List.

Excellent, but there is a glitch: the Intermediate Host List is not for detecting outbound emails. Typically, you add your secondary MXs and front-end servers to the IHL, allowing ORF to “look behind” these in the delivery path and check the actual source IP (DNS Blacklists, SPF Test, etc). In other words, the IHL-based IP Whitelist rule tells you whether the email is coming from a trusted source and this covers your trusted outbound relay hosts, too.

So a design decision had to be made: either (A) we require the user to list the local domains for proper
inbound/outbound email detection or (B) run the AUTH Whitelist + IP Whitelist always, even when email security tests are exempt from whitelist scope.

After long consideration, we decided to use option (B). Here are the advanteges and disadvantages:

Advantages:

• No administrative overhead
• Exceptions for email security tests can be enabled by default. This is important because many ORF users actually think that ORF already works this way, so they will not seek a configuration option to enable exceptions.

Disadvantages:

• If you have a front-end server, you will not have recipient validation at the Before Arrival filtering point. It is not that you had that before, but technically you could have it now.
• Your front-ends, secondary MXs and hosts listed on the IP Whitelist or anyone who successfully authenticates with your SMTP server will be able to bypass these email security tests.

We believe this is still better than requiring to list all domains and maintaining that list (sure we can detect the domain list, but eventually you would have to at least confirm that list and maintain it later).

Since ORF 3.0, we sign every ORF binaries with Vamsoft’s Authenticode code signing certificate. This is great, because you can be sure that you have the original files from Vamsoft and no tampering was made with them. This practice is also encouraged by Microsoft and signed components probably will be a requirement for the Windows ‘Longhorn’ Server Certification Logo program.

When we released the Vamsoft Image Spam Agent extension for ORF, we signed the agent imgspamagent.exe binary as usually and let it go. Then we started receiving reports about timeouts running the agent and we did not have any idea why only specific servers were failing to run the agent and why the agent worked when they tried running it from command-line. And we were struggling to find an explanation until one of our clients (thanks!) found that the agent tries to connect to crl.verisign.com:80 every time it starts. Cool.

I mean, uh? Pardon me?

Obviously, the timeout was caused by the security settings of the affected servers—these servers blocked HTTP access to crl.verisign.com, thus the timeout error. But what makes the agent trying to visit VeriSign if we did not add such code to it?

Here is the trick: Windows was checking the Certificate Revocation List (CRL) of VeriSign to make sure that our certificate was not revoked, e.g. because our certificate was compromised and now bad people are trying to impersonate Vamsoft. The funny thing is that Windows does not check the CRL for regular ORF binaries, because they were written in Delphi, but the agent was written in .NET/C# and .NET programs behave differently.

According to this blog entry, if your .NET assembly is signed using Authenticode, every time the assembly is loaded, Windows performs the Certificate Revocation List check (depending on the user settings). This potentially means a couple of seconds wait to get your .NET program started or even more if the firewall prevents the program from accessing the CRL.

Now we know. If you sign it, it won’t run.

In the last few months, I talked with quite a few ORF users who wrote External Agents to implement tests based more complex rules than otherwise allowed by ORF. I have also seen a few good agent proposals that never seen the light and I started wondering why and how could we help these agents born.

The first idea was to write an article about creating agents, with code samples in various languages from C# to PHP, etc., but the more I was thinking of this the more pointless the article seemed. After all, if you already know how to program in Perl, parsing command line parameters would not be big trouble, right? So why not start writing the agent?

My guess is that starting is hard. Banality or not, writing an agent takes a couple of things, like a command-line parser, a MIME parser, maybe a config reader/writer, a testing environment, etc. commonly called “PITA” and when you suddenly realize that, your great agent idea just does not seem that great.

Well, I may be easily wrong here, but if that is a real problem, would not a common source code platform for creating agents help?

What I have been thinking of is an open source C# external agent backbone, hosted on a collaborative development site such as SourceForge.net. The platform would already have most common things in place, like the command-line parser or the MIME parser. It would make adding new tests very easy (just implement a C# interface) and would have a built-in test environment. Due to the “plugin” architecture, you would need to run just one agent (thus save resources) and the end user could select which tests to run.

What do you think, would you participate?

Today, at 11:22AM local time we recorded the 10.000th ORF order. That’s the best Christmas present I can imagine. Thank you for putting your trust in us.

We are leaving now for a Christmas party and I will be back in January only, so I wish you Happy Holidays! See you in 2007.

15 orders left till the 10,000th ORF share-it! order.

Amazing. I mean, wow. When we started developing ORF Standard Edition back in 2002 (and selling that time for $25), we did not even dream of ORF growing into a software that filters more than 300.000.000 emails daily and protects ten thousands of mailboxes, in 86 countries all around the world, used by one-person businesses and 50,000+ employee giants and even ISPs. I just do not know what to say. With a little luck, we will record the 10,000th order tomorrow and even though this number has virtually nothing to do with the actual number of licenses sold, this is a great feeling, great responsibility and I still do not know what to say :)

As of writing this, an SMA order from Belgium and another from Benin was recorded and also an ORF EE order came in from Italy, so actually there are only 12 left. Edit: 1 left and champagne is cooling. Anyone, please? And… 5 digits! :)
Wow!

By the way, if you are the 10.000th, you will be fully refunded for your order :)