Leigh S. Jones, KR6X wrote: > To sum up what has been said on this issue thus far, > some believe that it's inefficient to wait until the target of > the spammer has been identified to send the 511, while > others believe it's nice to be able to identify the user > who has been targeted in the logs in order to ease the > facilitation of whitelists whenever needed. No one > has mentioned that usually the response from two > or three RBL's will take a little bit of time anyway. > Meanwhile, it's more efficient to allow the sending > server to continue the conversation with the receiving > server until the RBL response comes back.
I insinuated that point in the original post. :-) > Meanwhile, the delay presents a bit of a defacto tarpit for the > spammer. That's dubious. One of the problems with tar pitting is that it takes up resources on the server - at least a TCP connection, plus whatever listens on it. If you're going to tar pit, the way forward is to jam the 3-way TCP hand-shake and wedge the connection half open. That takes no resources on the server (not even a TCP connection), and it stops the sender from re-using that connection until TCP times out. And there is very much a finite number of TCP connections you can have open at any one time - especially on a malware infested Windows zombies usually used for spamming. > No one has mentioned that it's necessary to wait until > the possible spammer identifies his target to know > whether the target has him whitelisted. Whitelists aren't really practicaly on big setups. You need to block a lot before they even get as far as talking TCP. If you can manage a decent job with that, RBLs can prune enough of what's left for spamassassin and virus scanners to be able to cope with the minute amount of mail that is actually deliverable. It is not all that uncommon to see the spam:ham ratio of around 250:1. When you have a system handling mail for half a million domains, well, you get the idea. Gordan ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ courier-users mailing list [email protected] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
