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. Meanwhile, the delay presents a bit of a defacto tarpit for the spammer.
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. ----- Original Message ----- From: "Gordan Bobic" <[EMAIL PROTECTED]> To: <courier-users@lists.sourceforge.net> Sent: Saturday, October 20, 2007 4:03 PM Subject: Re: [courier-users] RBL Check - When? Sam Varshavchik wrote: >> I would have thought that in the interest of wasting >> fewer resources on spammers, RBL should be checked sooner. Possibly >> even before the server responds with the initial 220. > > … So that the spam source can easily detect that you're using a > blacklist that has this particular IP address listed, and if the spam > sender tries again from a different IP address, there's a good chance > that it will be accepted. The chances are that they'll spam from multiple addresses to multiple MX-es to multiple accounts simultaneously anyway. > As opposed as getting the SMTP transaction rejected in exactly the same > point it would be rejected for an invalid recipient address, for example. I would argue that spammers are not renowned for sticking to RFC compliance and using finesse in their approach. If they are clever enough to notice that, they'll also notice the "rejected by RBL so and so" response message. But luckily, they tend to go for the brute force flooding approaches which are easier to block. I suppose, however, that there is the argument that if one is so worried about the comms overhead, one could just set up user-space filtering with iptables, and plug that straight into an RBL database. I guess it at least gives options of either approach. 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 courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users ------------------------------------------------------------------------- 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 courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
