Thanks to pressure applied by our users, and a Google Summer of Code 05 student Anagha Mudigonda, James now supports fast-fail. :-) However the arguments presented below are still valid, only the question has changed: "should I use Fast Fail?"

Fast-failing means that when someone connects to your SMTP server, you reject the connection, sender, or email during the SMTP session rather than accept it first and reject it later.)

Many people request this feature, so I'm writing up why we have decided against it. Note that I am presenting my personal (Serge Knystautas) view that is not necessarily shared 100% by the community (and, in fact, there is a proposal that will allow robust fast-fail in future versions of James). However, I present my complete biased philosophy so you can hear the argument in lieu of trying to explain the pragmatic, moderate stance of the community that is a balance of many voices.

First I will list the reasons people typically want fast-fail:

No, spammers have no interest in slowing your mail server down. If they make your mail server slower, it will mean you'll get off your duff and do something to stop them. They want to milk your mail server for spam as much as possible, so this would defeat the purpose.

We abandon James after a spammer detected that we where an open relay. We subsequently blocked mail from them but they keeped sending it since we didn't reject it in the first place. The only way we managed to get control of the box again was to block offending ips in our firewall. -- JeffMartin

(a) you probably mean that they thought you were an Open Relay. If you actually were one, that wouldn't be the fault of James. (b) James v2.2 does support fast-fail reject for relay purposes. As a data-point, since implementing and configuring fast-fail support for relay requests, our "relay spam" rate is down almost 90%!

Admitedly there are people who want to create a denial-of-service situation. These are very straight-forward and often easily handled with a basic message-rate cap.

Unfortunately, the Sobig.F attack provides a massive counter-example. Pipeline filtering can consume even large servers. One effective counter-measure against Sobig.F is described here and relies upon limited fast-fail.

The amount of CPU cycles and disk space to handle spam is trivial, until you approach a denial of service level. Email is incredibly easy to process to modern equipment, and hardware is almost never the limitation.

This is the most compelling reason to fast fail. If you are running your mail server at home over an ISDN line or some low bandwidth connection, you might want to fast fail. Even then, I would encourage you to do some estimates on the amount of email traffic you receive versus how much you expect fast-fail to prevent, and I believe you will find fast-fail's effectiveness to be relatively small. Many spammers will give up after a couple of hours, in some rare cases many weeks, if you are properly blocking.

I would mention a similar problem. It is easy to bounce back any messages which is suspicious (virus or spam). On the other hand, on the receiver's side, this practice doesn't seem so nice... Virus and spam use invalid addresses and that may very well be your innocent address. We got several hundred bounces per day, because of Sobig.F I guess, to our support email address from other similarly configured email servers. Of course we don't send out virus emails, but our support address appears in many user's address book, so the virus uses it. Using fast fail we wouldn't harrass innocents by false bounces.

This is a red-herring. While blacklists can stop a significant amount of spam, it will only stop a small percentage of it. The IP address or sender email are no longer effective means of spam prevention, and you typically need to receive the body of the email before you can determine if it is spam. At that point, you've already received the email, and it's just a question of whether you a) tell the spammer during the SMTP session this is spam, b) send a bounce message back, or c) just silently eat it.

Here are the reasons why we don't want to fast-fail:

Think as a spammer if you hit a fast-fail server compared to a server that sends a bounce later or never sends a bounce. If the server fast-fails, then I know immediately that I was blocked. This means I can a) go look at another server, b) refine my technique until I get around your fast-fail.

If your server sends a bounce separately, then I have to write extra logic to listen for these bounces, parse them, and match bounces with attempts. This makes my life harder. Even harder is when you are so certain this is spam that you don't send me a bounce at all. This means I (the spammer) has to create mock tests to see if I can get around your spam prevention techniques, either send to dummy email addresses or wait for users to open the email and get some confirmation via http requests for images in the spam. This is much slower and takes a lot more work.

If you insist on reviewing email while it's during the SMTP session, then you are tying up that remote connection while you do it. Either you will be forking way too many processes to handle all of them when a burst of email (legitimate or otherwise) arrives, or you create a number of worker threads that process these, and you have to leave the queued SMTP sessions open during this time.

NoFastFail (last edited 2009-09-20 22:58:13 by localhost)