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.

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.

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.