Just in case you missed it: we have released a technology demo for the ORF OLE DB Log Provider, called the Web Reports. The demo imports your ORF logs into a Microsoft® SQL Server database and provides a web page where your users can review their blacklisted emails. Full source code is available.

There are two interesting points in the demo. First, it features a Windows Service (written in C#) that polls ORF log files for changes. This component can be used to have your logs in MSSQL, almost real-time. Second, the web page component (ASP.NET/C#) uses Integrated Authentication to identify the user, dig his/her email addresses Active Directory™ and display only the relevant entries from the log database. This authentication method works automatically on the intraweb, so your user is not prompted for a password.

As this is a technology demo as opposed to a full-featured product, there are many ways to improve it, from better database scheme normalization to visual design and features, but is serves as a solid basis to develop your own, custom-tailored end-user information system.

This online tool allows you to blacklist emails based on their source country, by generating an ORF DNS Blacklist definition for the countries.nerd.dk IP-to-country DNS blacklist.

Check out the new Countries.nerd.dk Definition Generator tool on our website.

This new External Agent (download from here) can help with reducing the damages of “backscatter”, a phenomenon that occurs when a spammers sends forged emails in the name of your domain. Given a sufficiently large amount of forged emails, some of these will be undeliverable, resulting in tons of Delivery Status Notifications (DSNs) flooding your servers. As the DSNs are coming from otherwise legitimate servers, IP-based filtering is no big help here and neither the other tools of ORF, except this new one.

The idea behind the agent is that most DSNs contain the original email and this allows the agent to check if the original email is from your network, by examining whether it shows properties unique to your network.

This agent checks specifically for the Message-ID email header, which has a unique format pattern for every network/server. The agent extracts the Message-ID headers from the bounce report, and matches them with your unique pattern. If none of the Message-IDs are like your pattern, the agent reports that the original email was probably from another network—in other words, it’s a backscatter DSN.

Note that this concept of backscatter detection has not been tested in production enviroments and due to this, we call the agent “experimental”. Finding every Message-ID pattern for your email infrastructure can be quite a challenge, depending on how heterogeneous your network is. This is because the Message-ID may be generated by either the email client (MUA) or the email server (MTA). Neither Outlook, nor Outlook Express generate a Message-ID on their own, but Mozilla Thunderbird does. Without knowing what email clients are used in your network and how they behave, you cannot reliably tell your Message-ID patterns. For example, ISPs have no chance to use this agent.

Despite this limited use, we think the agent may be useful for many smaller networks. Also, there are several ways how we can improve the original idea, for example, by recording the Message-IDs of all outgoing emails in a database or by checking other email properties, but these solutions come at a higher cost—let us know if the agent does not work for your and why, so that we can improve it to cover your requirements.

In this post, I would like to talk about an underdesirable effect of rejecting emails at On Arrival—one that may cause your network to take part in abusing innocent servers, called “backscattering”.

Let’s assume you have a front-end SMTP server in the DMZ and an Exchange server on the private intranet. ORF is running on the Exchange server, configured to reject emails. What is going to happen with incoming spam in this setup? The front-end will receive the spam and relay it to the Exchange server. ORF will blacklist and reject the spam during the transmission. The front-end server, encountering the transmission error, will generate Non-Delivery Report (NDR) and return it to the original email sender. Perfectly how the RFC requires.

What’s wrong with this? It’s that the sender is always forged. The NDR will be sent to a perfectly innocent domain that is not involved in the spam attack anyhow. Actually, this is how we got into the anti-spam business in the first place—a spammer forging our domain name forced us to write our first extension to IIS SMTP for disabling a specific recipient.

Help the fellow admins: if you run ORF behind a front-end SMTP server and can’t move ORF to the DMZ, consider changing the On Arrival action to tagging or redirecting.

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…

Preliminary tests with ORF 4.1 and Windows Server 2008 are now finished with the following results:

ORF 4.1 + Exchange 2007 on Windows Server 2008 Standard (64-bit): SEEMS TO BE OK.
Installs fine, filters email. Requires more thorough testing to see if all features work.

ORF 4.1 + IIS SMTP on Windows Server 2008 Standard (32-bit): NOT COMPATIBLE.
The IIS ADSI provider seems to exist, but somehow it does not work. ORF will install fine with the above configuration, however it will not filter any emails, because the SMTP Module is unable to query the Pickup Folder path from the provider. Also, the ServerComment field, which is supposed to contain the SMTP Virtual Server name is empty. We may be able to work this around.

ORF 4.1 + IIS SMTP on Windows Server 2008 Standard (64-bit): NOT COMPATIBLE.
The Event.Manager Windows library is simply not registered for 32-bit. We use this (mostly undocumented) library to manage the SMTP event sink bindings. If the library binary is installed, like in the case of the Exchange 2007-ified CDOSYS, we may be able to work it around by registering the library. It is reasonable to assume that the same issues can be expected as in the case of the 32-bit version, it’s just ORF did not reach that point in testing.

ORF 4.1 + Exchange 2007 on Windows Server 2008 Standard (32-bit): NOT TESTED
As Microsoft strongly discourages using Exchange 2007 for production purposes, we do not plan to prepare any ORF versions for 32-bit Exchange 2007 usage.

Anyway, when you try to open the Current Sessions node in the IIS 6.0 SMTP Management MMC, you get an „Interface is not supported” error. It has nothing to do with ORF, it’s IIS. Anyone cares to submit this to Microsoft PSS? I understand that the SMTP Service is now considered obsolete and Exchange Edge Transport Servers are supposed to replace it, but… come on, this bug is quite hard to miss.

Despite the fact the Open Relay Database (ORDB) DNS Blacklist was shut down in December 2006 and operates no longer (DNS queries timed out since then), a large number of mail server administrators forgot to remove the ORDB definition from their filtering softwares (including ORF).

It seems the guys at ORDB finally had enough of the large number of queries to their servers and decided to return 127.0.0.2 responses to all queries instead of no answers (timeout). This means if you have ORDB enabled, it will blacklist all non-whitelisted mails… So it is strongly suggested to review your configuration to avoid such issues. (If you still have ORDB enabled in Configuration / Tests / DNS Blacklists, remove it immediately).

Quite aggressive measure from their part, but quite effective (and understandable if you ask me).

Since last November, we’ve been receiving sporadic reports of ORF logging “General socket error 0” errors every once in a while.

With the help from a client of us (thank you Peder - your packet capture was the key), we tracked this issue down to a bug in the Microsoft DNS Server. Microsoft PSS has confirmed the bug and a hotfix is now available (as of writing this, not public yet). If you are getting the above error, or you have problems with DNS name resolution under high load, please contact your local Microsoft PSS and ask for hotfix 946565.

A few details for the technical-minded: the issue may occur when the DNS server receives 2 or more concurrent requests to resolve the same DNS resource record. In such event, 1 or more of the DNS responses may be corrupted, which eventually results in the “general socket error 0” message logged by ORF.

The way how the DNS response is corrupted worth writing a few words about. Every DNS query sent by a DNS client (like ORF) has a unique Transaction ID. The DNS response is expected to contain exactly this ID, which helps the DNS client sorting out which response belongs to which request. The Transaction ID is a two-byte value, e.g. 0xAABB in hexadecimal notation. What happens to these corrupted DNS responses is that the response Transaction ID bytes get flipped up—i.e., if ORF sent the the query with Transaction ID 0xAABB, the response it receives has a Transaction ID 0xBBAA. The DNS client in ORF, getting an unknown Transaction ID, discards the DNS response data and generates an error.

We launched a redesigned version of the ORF website a few hours ago; check out what we came up with.

Previous website version

New website version

It was certainly time to update our web appearance—even though the old web site was created in 2003, it looked quite ‘98-ish, with that huge printer port photo (what?!) in the header. I can’t believe we even sold ORF licenses without those Web 2.0 glass effects so mandatory in 2008 :)

The web content did not change much, except that a few old pages and the Regex Corner has been removed (more about this later).

Anyway, the new website is XHTML 1.0 Strict valid, with pure CSS formatting, optimized for the following browsers: Internet Explorer 6, Internet Explorer 7 and the latest versions of Mozilla Firefox, Opera and Safari (Windows). The design is from a professional web design company and the persons to be blamed for the XHTML/CSS/scripting are Krisztian and me.

Migrating the content took only about 3 weeks (once the basic layout CSS was working), but what 3 weeks these were! If you ever worked with CSS and HTML, you probably know that the various web browsers take great liberty of CSS standards interpretation, which is an excellent source of… fun. The two most bizarre rendering bugs we have seen were produced IE6 and IE7. IE6 just forgot to fully render a menu (a quite standard customized <UL>-<LI> combo), but on every refresh a different part of the menu was rendered. We ended up hiding the menu for IE6 and showing a different <TABLE>-based one. IE7 gave us countless minutes of fun with rendering the PNG arrow icons on the FAQ page correctly, just to show them 90 degrees rotated clockwise on the next page refresh. We could not believe our eyes, then we decided it’s real and replaced the PNG arrow with a JPEG arrow, which did not produce the same issue. Later we switched back to PNG, but now saved with another program (the original was created with Adobe Photoshop CS) which has fixed the issue.

As for the Regex Corner, we decided not to port this section of our website to the new design, because it did not fulfill our hopes. Attracting too little attention, we could not justify the cost of migrating these relatively complex pages. Instead, we created a new newsgroup on our news server, called the ORF Tips and Tricks forum, meant to be an active discussion group of keyword filters, HELO filters and everything useful. We know that not everyone has NNTP access, so this is certainly not an ideal solution. However, we are hoping to launch our news <-> web gateway soon. The code is more or less ready, though testing and applying design will take a few more weeks.

From today, ORF licenses are available for 239 US dollars per server. It’s a 20% raise from the previous price that was set in 2004, at 198 USD. The SMA price remains the same, 99 USD per license.

The reasons that led to this decision are several, but the most important one is that the US dollar weakened significantly compared to the common European currency, the Euro. We operate in Hungary, Europe and although we have not yet switched to Euro from the Hungarian forint, our currency is tightly linked to that and so we suffer the same loss on export like the rest of Europe. Also, we think that ORF matured quite a lot in the past more 3+ years (the version that time was 1.5.2) and this could be reflected in our license prices with a reasonable rise.

Thank you for the understanding and we hope you still find ORF worthy at this price.