Re: [courier-users] RBL Check - When?
Gordan Bobic wrote: Leigh S. Jones, KR6X wrote: 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. Gordan wrote: 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. Whitelists aren't really practicaly on big setups handling mail for half a million domains. Ahhh, but nonetheless they are a part of the Courier algorithm... Every now and then, some legitimate user is being blocked by RBLs. IME, DSNs triggered by SMTP-level rejection are more useful than log files for diagnosing those cases. I have one user who insists some addresses of his shall not be filtered by RBLs. He is afraid he may lose contacts otherwise. (He is careful not to spread those addresses, so he can afford downloading the little amount of spam they gather.) The Courier algorithm lets me use a BLOCK2 variable in order to selectively reject RBL tagged messages according to the RCPT. I'm not saying the idea is bad. I am saying that when your server is receiving the best part of a million emails per hour, most of which is spam, you cannot necessarily afford to pick up the connection, see who it's for, check the white list for the recipient if they are valid, and the selectively let the mail through to be processed by, e.g. content based scanning for spam and virii, and then maybe deliver it to the final destination. The listening SMTP server is good at using a limited amount of resources and I'm quite happy that it may become rather slow to respond to incoming mail, even if 1 out of 250 connections is from a legitimate relay. Even if I cannot compete with millions of runaway zombies, that still produces some friction for spammers to go through. I only have a few domains, but I guess if I had much more I'd need some more resources too, in order to still provide a good service. There are good ways of separating wheat from the chaff without incurring any false positives before you ever pick up a TCP connection. But this is rapidly becoming a conversation OT for this list... OT for OT, let me mention this antispam/ip-monitoring service http://www.projecthoneypot.org/?rf=34756 - 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
Re: [courier-users] RBL Check - When?
Gordan Bobic writes: I've just been looking through my mail logs to assess the effectiveness of the RBLs, and I see things like the following: courieresmtpd: error,relay=:::88.236.181.253,from=[EMAIL PROTECTED],to=[EMAIL PROTECTED]: 511 http://www.spamhaus.org/query/bl?ip=88.236.181.253 Since it has the from and to addresses listed, that implies that the RBL was consulted after the MAIL FROM and RCPT TO commands were sent. Is this not wrong? No, it's right. 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. As opposed as getting the SMTP transaction rejected in exactly the same point it would be rejected for an invalid recipient address, for example. pgpOe7XzlcMwk.pgp Description: PGP signature - 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
Re: [courier-users] RBL Check - When?
Gordan Bobic wrote: I've just been looking through my mail logs to assess the effectiveness of the RBLs, and I see things like the following: courieresmtpd: error,relay=:::88.236.181.253,from=[EMAIL PROTECTED],to=[EMAIL PROTECTED]: 511 http://www.spamhaus.org/query/bl?ip=88.236.181.253 Should a legitimate message be rejected by RBL, it's useful to have those logs. Users will ask why they haven't received a message they expected, and you can look for the senders address in the logs to see if RBLs are at fault. Since it has the from and to addresses listed, that implies that the RBL was consulted after the MAIL FROM and RCPT TO commands were sent. Is this not wrong? I would have thought that in the interest of wasting fewer resources on spammers, RBL should be checked sooner. No, the DNS lookup happened at the beginning of the connection. smtpd just doesn't give errors until the RCPT command. smtpd won't accept messages (errors on DATA command), and as far as I know doens't even look up the addresses requested, so the resources consumed are a handful of bytes (rate limited by tarpitting). It's nothing to worry about. :) - 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
Re: [courier-users] RBL Check - When?
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
Re: [courier-users] RBL Check - When?
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 courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] RBL Check - When?
- Original Message - From: Gordan Bobic [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: 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. Gordan wrote: 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. Whitelists aren't really practicaly on big setups handling mail for half a million domains. Ahhh, but nonetheless they are a part of the Courier algorithm... - 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
Re: [courier-users] RBL Check - When?
Leigh S. Jones, KR6X wrote: [EMAIL PROTECTED] wrote: 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. Gordan wrote: 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. Whitelists aren't really practicaly on big setups handling mail for half a million domains. Ahhh, but nonetheless they are a part of the Courier algorithm... I'm not saying the idea is bad. I am saying that when your server is receiving the best part of a million emails per hour, most of which is spam, you cannot necessarily afford to pick up the connection, see who it's for, check the white list for the recipient if they are valid, and the selectively let the mail through to be processed by, e.g. content based scanning for spam and virii, and then maybe deliver it to the final destination. There are good ways of separating wheat from the chaff without incurring any false positives before you ever pick up a TCP connection. But this is rapidly becoming a conversation OT for this list... 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
