Thanks to pressure applied by our users, and a Google Summer of Code 05 student Anagha Mudigonda, James now supports 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: Doesn't this open me up to a denial-of-service situation where my mail server will be less available or slower? 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. 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. I don't want to waste my CPU cycles and disk space 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. I don't want to waste my bandwidth 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. It will cut down on the amount of spam 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: It makes a spammers life easier 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. Mail should be processed asynchronously 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. Not processing asynchronously is a great way to open yourself to a denial of service attack. Even on the simplest of blacklist prevention, if your DNS server goes down for a bit, then your SMTP server is stuck with open SMTP connections that are queueing as you query DNS to see if it's on the blacklist. It is easier on the server if you say "ok, give it to me", and then when you have the resources you chug through the emails and determine its legitimacy. Don't reveal your legitimate addresses to address harvesters (I'm Danny Angus not Serge!) Using fast fail and returning error messages can reveal a lot of useful information to spammers, in the simplest case returing an error indicating that a user doesn't exist allows address harversters to trawl likely addresses to find legitimate users and spam them. Silent running is a recommended security technique (Danny again..) Most security consultants will agree that it is better to reveal as little as possible about your systems, silently eating spam is a logical extension of this principle, and many commercial firewalls which offer mail gatewaying are also blackholes for spam. 
However the arguments presented below are still valid, only the question has changed: "should I use Fast Fail?"