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.

The new ORF 4.1 Alpha release offers keyword filtering in the raw MIME email header with the usual simple text search / regular expression modes. This opens up a few possibilities that were previously unavailable in ORF, such as filtering based on the MIME sender, a specific email header field or the charset.

We strongly recommend using regular expressions for creating header keyword filters, as simple text filters may have unexpected consequences. For instance, you may want to blacklist emails with the koi8-r Cyrillic charset, but using just “koi8-r” may blacklist emails that has subject “How to blacklist koi8-r emails”.

A few regular expression examples for filtering for specific email fields:

• MIME sender email address
  .*^From:.*\bsendertofilter@example.org\b.*\s$
• Email subject with koi8-r charset
  .*^Subject:.*=\?koi8-r\?.*\s$
• Presence of “X-Spam-Status: YES header”
  .*^X-Spam-Status: YES\s$