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.