Re: Bogus MX - blacklist service viable?
Aaron Wolfe wrote: I have 24 hours of data to play with.. at first results seemed promising. I found over 300,000 hosts that had connected only to my highest MX and did not issue a quit. But.. of that group: 96.0% are listed on spamhaus (zen, i did not breakdown onto the individual lists) 2.3% of the hosts *not* listed on spamhaus are listed on Rob McEwen's ivmSIP list (note that this is over 50% of the remaining hosts, about 10% higher than this list's hit rate with my normal mail flow). ...snip... I'm sure my quick test is not perfect. The remaining 1.7% of hosts may include some amount of non spam sources (very small if any I would guess). Also, I ran the RBL checks all at once at the end of the cycle. so some of the hits were 24 hours old. Some amount of the remainder were probably on the RBLs at the time they hit my server and were since removed Aaron, Here are my thoughts/observations: Assuming that you ran these dnsbl checks *after* the 24 hour period (as I think you are saying...), then I believe that the 96% also caught by Zen would probably be lower, not higher. IPs (from recent spam!) don't generally expire out of any lists THAT quickly, if at all. However, in contrast, there is typically a propagation delay before *some* of these get into DNSBLs. (this delay can vary widely between dnsbls). So if you ran this test after the fact, you actually gave Zen some time to catch up. You mentioned that, of these IPs that only connected to the highest MX batch, half of the IPs that Zen didn't catch were already on Rob McEwen's ivmSIP list. Thanks for the plug! But I fear that this may accidentally paint an inaccurate picture of ivmSIP. This seems to imply that half my list is made up of IPs that would be caught if someone were using the connected only to the highest MX method. (I know you didn't intend to imply this.. but there is the potential for someone to interpret it that way.) In fact, just so *others* will know, I should add that there is MUCH spams that my lists catches which the IPs that only connected to the highest MX method misses. For example, I took that last 100 ivmSIP catches and ran them against Zen. 88 of these 100 were already caught by Zen. Of the 12 left, 3 were caught by widely used and respected dnsbls: 84.79.21.212 (spamcop) 200.66.32.226 (dsbl/psbl) 212.147.5.133 (spamcop Mark Perkel's host karma list) As shown, of the 12 left, (and of these three), 1 was caught by Perkel's host karma list, which, therefore, is probably the *only* IP of these 12 that the connected only to the highest MX method would have caught. (of those not caught by zen...) While your stats show that 50% of what the connected only to the highest MX method catches was also caught by ivmSIP. These additional stats above show that the connected only to the highest MX method catches *only* 8% of the spams that ivmSIP catches (again, of those not already in Zen.) Of these twelve, 9 of them are IPs that would NOT have been caught by ANY reliable FP-safe DNSBLs, nor would these (likely) be caught by the connected only to the highest MX method. Here are those 9 uniques (for anyone to examine/critique): 79.137.219.171 79.137.223.42 79.137.225.194 79.137.231.242 79.137.233.223 79.137.235.210 79.137.235.252 79.137.237.210 213.254.194.26 9 uniques out of 100 doesn't sound impressive... and most of these were already caught by UCEPROTECT's level 3, but that is UCE's most FP-risky list... and certainly a list too FP-riskly to outright block or score high on... UCE even states that this list, probably will cause collateral damage to innocent users when used to block email But since, in contrast, ivmSIP has an extremely low FP-rate and seeks to *not* ever create collateral damage, then, unlike UCE-3, when these IPs show up in ivmSIP, they are safe to outright block (or score very high, for those who are ultra careful) without fear of FPs. (of course, during the time it took me to type this message, another 1,142 IPs were added to ivmSIP. This was an 'ad hoc snapshot... I suspect that a few of these uniques will get into other lists by the time that some people read this post. But, in the meantime, spams send from these IPs to those who use ivmSIP have been blocked.) FINAL NOTE: ivmSIP seeks to be a supplemental list focused mostly on new series of spams... and purposely skips out on listing spammer's IPs that have been in circulation for more than X number of weeks/months... therefore, Zen is going to list many IPs that ivmSIP isn't even trying to list. So ivmSIP is NOT trying to be a Zen replacment, but, instead, more of a supplement. Rob McEwen
Re: Bogus MX - blacklist service viable?
Rob McEwen wrote: Aaron Wolfe wrote: I have 24 hours of data to play with.. at first results seemed promising. I found over 300,000 hosts that had connected only to my highest MX and did not issue a quit. But.. of that group: 96.0% are listed on spamhaus (zen, i did not breakdown onto the individual lists) 2.3% of the hosts *not* listed on spamhaus are listed on Rob McEwen's ivmSIP list (note that this is over 50% of the remaining hosts, about 10% higher than this list's hit rate with my normal mail flow). ...snip... I'm sure my quick test is not perfect. The remaining 1.7% of hosts may include some amount of non spam sources (very small if any I would guess). Also, I ran the RBL checks all at once at the end of the cycle. so some of the hits were 24 hours old. Some amount of the remainder were probably on the RBLs at the time they hit my server and were since removed Aaron, Here are my thoughts/observations: Assuming that you ran these dnsbl checks *after* the 24 hour period (as I think you are saying...), then I believe that the 96% also caught by Zen would probably be lower, not higher. IPs (from recent spam!) don't generally expire out of any lists THAT quickly, if at all. However, in contrast, there is typically a propagation delay before *some* of these get into DNSBLs. (this delay can vary widely between dnsbls). So if you ran this test after the fact, you actually gave Zen some time to catch up. You mentioned that, of these IPs that only connected to the highest MX batch, half of the IPs that Zen didn't catch were already on Rob McEwen's ivmSIP list. Thanks for the plug! But I fear that this may accidentally paint an inaccurate picture of ivmSIP. This seems to imply that half my list is made up of IPs that would be caught if someone were using the connected only to the highest MX method. (I know you didn't intend to imply this.. but there is the potential for someone to interpret it that way.) In fact, just so *others* will know, I should add that there is MUCH spams that my lists catches which the IPs that only connected to the highest MX method misses. For example, I took that last 100 ivmSIP catches and ran them against Zen. 88 of these 100 were already caught by Zen. Of the 12 left, 3 were caught by widely used and respected dnsbls: 84.79.21.212 (spamcop) 200.66.32.226 (dsbl/psbl) 212.147.5.133 (spamcop Mark Perkel's host karma list) As shown, of the 12 left, (and of these three), 1 was caught by Perkel's host karma list, which, therefore, is probably the *only* IP of these 12 that the connected only to the highest MX method would have caught. (of those not caught by zen...) While your stats show that 50% of what the connected only to the highest MX method catches was also caught by ivmSIP. These additional stats above show that the connected only to the highest MX method catches *only* 8% of the spams that ivmSIP catches (again, of those not already in Zen.) Of these twelve, 9 of them are IPs that would NOT have been caught by ANY reliable FP-safe DNSBLs, nor would these (likely) be caught by the connected only to the highest MX method. Here are those 9 uniques (for anyone to examine/critique): 79.137.219.171 79.137.223.42 79.137.225.194 79.137.231.242 79.137.233.223 79.137.235.210 79.137.235.252 79.137.237.210 213.254.194.26 9 uniques out of 100 doesn't sound impressive... and most of these were already caught by UCEPROTECT's level 3, but that is UCE's most FP-risky list... and certainly a list too FP-riskly to outright block or score high on... UCE even states that this list, probably will cause collateral damage to innocent users when used to block email But since, in contrast, ivmSIP has an extremely low FP-rate and seeks to *not* ever create collateral damage, then, unlike UCE-3, when these IPs show up in ivmSIP, they are safe to outright block (or score very high, for those who are ultra careful) without fear of FPs. (of course, during the time it took me to type this message, another 1,142 IPs were added to ivmSIP. This was an 'ad hoc snapshot... I suspect that a few of these uniques will get into other lists by the time that some people read this post. But, in the meantime, spams send from these IPs to those who use ivmSIP have been blocked.) FINAL NOTE: ivmSIP seeks to be a supplemental list focused mostly on new series of spams... and purposely skips out on listing spammer's IPs that have been in circulation for more than X number of weeks/months... therefore, Zen is going to list many IPs that ivmSIP isn't even trying to list. So ivmSIP is NOT trying to be a Zen replacment, but, instead, more of a supplement. Rob McEwen Rob - you make a good point about the 24 hours after issue. I can detect the spambots in almost real time. The combination of the no quit and only hitting the highest numbered MX takes about 2 minutes. (The connection inavtivity timeout). Once detected the IP is added to a
Large spam IP list - was Re: Bogus MX - blacklist service viable?
79.137.219.171 79.137.223.42 79.137.225.194 79.137.231.242 79.137.233.223 79.137.235.210 79.137.235.252 79.137.237.210 Slightly off subject, This list of class Cs appears to be a HUGE block 79.137.170ish.0/24 - 79.137.240.0ish a russian spam gang. They appear to right now be using the odd ending class/24s. I suspect they will be using the evens in the next few weeks. -L -- Larry Ludwig Empowering Media 1-866-792-0489 x600 Managed and Unmanaged Xen VPSes http://www.hostcube.com/
Re: Bogus MX - blacklist service viable?
Aaron Wolfe wrote: On Thu, Feb 21, 2008 at 11:47 PM, Marc Perkel [EMAIL PROTECTED] wrote: Steve Radich wrote: Sorry; apparently I was unclear. MX records I'm saying as follows: 100 - Real 200 - Real perhaps, as many real as you want 300 - Bogus - one that blocks port 25 with tcp reset for example 400 - accept port, logs ip - blacklist (not to be scored aggressively at all) with a 421/retry. If a whole bunch of places are seeing the same smtp server hitting this 400 level MX then I'm saying that seems like a useful thing to be included in a blacklist using a low score in sa. The point was to offer the 400 level mx as a free service to log the ips quickly for those that don't want to set up the server themselves. In theory the 400 level MX wouldn't be used by real smtp very often, hence it's likely a spammer and therefore the IP could be auto blacklisted. Realize I'm NOT proposing we block on this, just score based on this list. Steve Radich - http://www.aspdeveloper.net / http://www.virtualserverfaq.com BitShop, Inc. - Development, Training, Hosting, Troubleshooting - http://www.bitshop.com I'm actually doing something like that. What I do is track hits on the highest MX that has not hit the lowest numbered MX, then because I use Exim I can track which IP addresses don't send the QUIT command to close I am thinking about playing around with the same type of thing here.. Is this any different from looking for lost connection after DATA or lost connection after RCPT errors in a postfix server's logs? Not sure why you can detect this because you run Exim specifically. Or am I missing something? Exim has ACLs that let you do things when the QUIT is received or not received. Exim probably has 100x the commans that Postfix does and you can do a lot of tricky stuff in Exim that no other MTA has. the connection. This combination creates a highly reliable blacklist and I'm currently tracking about 1.1 million virus infected spambots that have tried to spam me in the last 4 days. It's my hostkarma list. Sounds interesting.. do you block based on this list or just use it for scoring in SA or something like that? What is the false positve rate? Yes, I do block based on this list. Ther are some false positives but it's rare. I have a way for people to remove themselves from the list. There are other criteria that we blacklist on as well that makes for a few FP. But it's extremely low. I've put a lot of effort into getting it right.
Re: Bogus MX - blacklist service viable?
On Fri, Feb 22, 2008 at 7:55 AM, Marc Perkel [EMAIL PROTECTED] wrote: Aaron Wolfe wrote: On Thu, Feb 21, 2008 at 11:47 PM, Marc Perkel [EMAIL PROTECTED] wrote: Steve Radich wrote: Sorry; apparently I was unclear. MX records I'm saying as follows: 100 - Real 200 - Real perhaps, as many real as you want 300 - Bogus - one that blocks port 25 with tcp reset for example 400 - accept port, logs ip - blacklist (not to be scored aggressively at all) with a 421/retry. If a whole bunch of places are seeing the same smtp server hitting this 400 level MX then I'm saying that seems like a useful thing to be included in a blacklist using a low score in sa. The point was to offer the 400 level mx as a free service to log the ips quickly for those that don't want to set up the server themselves. In theory the 400 level MX wouldn't be used by real smtp very often, hence it's likely a spammer and therefore the IP could be auto blacklisted. Realize I'm NOT proposing we block on this, just score based on this list. Steve Radich - http://www.aspdeveloper.net / http://www.virtualserverfaq.com BitShop, Inc. - Development, Training, Hosting, Troubleshooting - http://www.bitshop.com I'm actually doing something like that. What I do is track hits on the highest MX that has not hit the lowest numbered MX, then because I use Exim I can track which IP addresses don't send the QUIT command to close I am thinking about playing around with the same type of thing here.. Is this any different from looking for lost connection after DATA or lost connection after RCPT errors in a postfix server's logs? Not sure why you can detect this because you run Exim specifically. Or am I missing something? Exim has ACLs that let you do things when the QUIT is received or not received. Exim probably has 100x the commans that Postfix does and you can do a lot of tricky stuff in Exim that no other MTA has. the connection. This combination creates a highly reliable blacklist and I'm currently tracking about 1.1 million virus infected spambots that have tried to spam me in the last 4 days. It's my hostkarma list. Sounds interesting.. do you block based on this list or just use it for scoring in SA or something like that? What is the false positve rate? Yes, I do block based on this list. Ther are some false positives but it's rare. I have a way for people to remove themselves from the list. There are other criteria that we blacklist on as well that makes for a few FP. But it's extremely low. I've put a lot of effort into getting it right. Ok... I have 24 hours of data to play with.. at first results seemed promising. I found over 300,000 hosts that had connected only to my higest MX and did not issue a quit. But.. of that group: 96.0% are listed on spamhaus (zen, i did not breakdown onto the individual lists) 2.3% of the hosts *not* listed on spamhaus are listed on Rob McEwen's ivmSIP list (note that this is over 50% of the remaining hosts, about 10% higher than this list's hit rate with my normal mail flow). I don't have the zone files for any other RBLs and I didn't want to send out 300k queries via DNS. But I think the picture is fairly clear.. a vast majority of the hosts hitting the fake high MX will be hosts already listed in major RBLs. I'm sure my quick test is not perfect. The remaining 1.7% of hosts may include some amount of non spam sources (very small if any I would guess). Also, I ran the RBL checks all at once at the end of the cycle. so some of the hits were 24 hours old. Some amount of the remainder were probably on the RBLs at the time they hit my server and were since removed. I will continue to look into this to see if today was a typical day. Based on these number though... is this a promising way to reduce server load/blacklist more hosts... or is this pointless? I'm interested in what people think since the data is so easy to gather and use, if it makes any sense to use it. -Aaron
Re: Bogus MX - blacklist service viable?
Hi! provide this hosted (i.e. I'm thinking of offering), but instead of ONLY log it somehow feed / create a blacklist based on this? I'm not as familiar with blacklists as many of you, but the network / smtp / logging side of this is easy for me to implement. I'm thinking make this a very public (free) service to gather data for the blacklist, anyone could list the mx. Whats wrong with : http://www.rfc-ignorant.org/tools/submit_form.php?table=bogusmx Bye, Raymond.
Re: Bogus MX - blacklist service viable?
On Thu, 2008-02-21 at 21:58 +0100, Raymond Dijkxhoorn wrote: Hi! provide this hosted (i.e. I'm thinking of offering), but instead of ONLY log it somehow feed / create a blacklist based on this? I'm not as familiar with blacklists as many of you, but the network / smtp / logging side of this is easy for me to implement. I'm thinking make this a very public (free) service to gather data for the blacklist, anyone could list the mx. Whats wrong with : http://www.rfc-ignorant.org/tools/submit_form.php?table=bogusmx wrong direction. That lists domains that don't have their MX records set up properly, not ip addresses that attempt to send mail to sites that are not MX records. -- Daniel J McDonald, CCIE #2495, CISSP #78281, CNX Austin Energy http://www.austinenergy.com signature.asc Description: This is a digitally signed message part
Re: Bogus MX - blacklist service viable?
Steve Radich wrote: What's everyone's opinion on something like: defermx.domain.com bogusmx.domain.com provide this hosted (i.e. I'm thinking of offering), but instead of ONLY log it somehow feed / create a blacklist based on this? I'm not as familiar with blacklists as many of you, but the network / smtp / logging side of this is easy for me to implement. I'm thinking make this a very public (free) service to gather data for the blacklist, anyone could list the mx. Thoughts? Steve Radich - http://www.aspdeveloper.net / http://www.virtualserverfaq.com BitShop, Inc. - Development, Training, Hosting, Troubleshooting - http://www.bitshop.com I'm confused. What are you trying to accomplish?
Re: Bogus MX - blacklist service viable?
Hi! defermx.domain.com bogusmx.domain.com provide this hosted (i.e. I'm thinking of offering), but instead of ONLY log it somehow feed / create a blacklist based on this? I'm not as familiar with blacklists as many of you, but the network / smtp / logging side of this is easy for me to implement. I'm thinking make this a very public (free) service to gather data for the blacklist, anyone could list the mx. Thoughts? I'm confused. What are you trying to accomplish? I thought i was lost, but even if Marc can follow you ;) eh eh Bye, Raymond.
Re: Bogus MX - blacklist service viable?
McDonald, Dan wrote: On Thu, 2008-02-21 at 21:58 +0100, Raymond Dijkxhoorn wrote: Hi! provide this hosted (i.e. I'm thinking of offering), but instead of ONLY log it somehow feed / create a blacklist based on this? I'm not as familiar with blacklists as many of you, but the network / smtp / logging side of this is easy for me to implement. I'm thinking make this a very public (free) service to gather data for the blacklist, anyone could list the mx. Whats wrong with : http://www.rfc-ignorant.org/tools/submit_form.php?table=bogusmx wrong direction. That lists domains that don't have their MX records set up properly, not ip addresses that attempt to send mail to sites that are not MX records. and the difference is? if you force our servers to retry each time we connect to your server, then we will find other people to talk to (in short, we'll BL you) unless you ask the IETF to modify SMTP by adding a knocking requirement.
RE: Bogus MX - blacklist service viable?
Sorry; apparently I was unclear. MX records I'm saying as follows: 100 - Real 200 - Real perhaps, as many real as you want 300 - Bogus - one that blocks port 25 with tcp reset for example 400 - accept port, logs ip - blacklist (not to be scored aggressively at all) with a 421/retry. If a whole bunch of places are seeing the same smtp server hitting this 400 level MX then I'm saying that seems like a useful thing to be included in a blacklist using a low score in sa. The point was to offer the 400 level mx as a free service to log the ips quickly for those that don't want to set up the server themselves. In theory the 400 level MX wouldn't be used by real smtp very often, hence it's likely a spammer and therefore the IP could be auto blacklisted. Realize I'm NOT proposing we block on this, just score based on this list. Steve Radich - http://www.aspdeveloper.net / http://www.virtualserverfaq.com BitShop, Inc. - Development, Training, Hosting, Troubleshooting - http://www.bitshop.com -Original Message- From: mouss [mailto:[EMAIL PROTECTED] Sent: Thursday, February 21, 2008 8:25 PM Cc: users@spamassassin.apache.org Subject: Re: Bogus MX - blacklist service viable? McDonald, Dan wrote: On Thu, 2008-02-21 at 21:58 +0100, Raymond Dijkxhoorn wrote: Hi! provide this hosted (i.e. I'm thinking of offering), but instead of ONLY log it somehow feed / create a blacklist based on this? I'm not as familiar with blacklists as many of you, but the network / smtp / logging side of this is easy for me to implement. I'm thinking make this a very public (free) service to gather data for the blacklist, anyone could list the mx. Whats wrong with : http://www.rfc-ignorant.org/tools/submit_form.php?table=bogusmx wrong direction. That lists domains that don't have their MX records set up properly, not ip addresses that attempt to send mail to sites that are not MX records. and the difference is? if you force our servers to retry each time we connect to your server, then we will find other people to talk to (in short, we'll BL you) unless you ask the IETF to modify SMTP by adding a knocking requirement.
Re: Bogus MX - blacklist service viable?
Steve Radich wrote: Sorry; apparently I was unclear. MX records I'm saying as follows: 100 - Real 200 - Real perhaps, as many real as you want 300 - Bogus - one that blocks port 25 with tcp reset for example 400 - accept port, logs ip - blacklist (not to be scored aggressively at all) with a 421/retry. If a whole bunch of places are seeing the same smtp server hitting this 400 level MX then I'm saying that seems like a useful thing to be included in a blacklist using a low score in sa. The point was to offer the 400 level mx as a free service to log the ips quickly for those that don't want to set up the server themselves. In theory the 400 level MX wouldn't be used by real smtp very often, hence it's likely a spammer and therefore the IP could be auto blacklisted. Realize I'm NOT proposing we block on this, just score based on this list. Steve Radich - http://www.aspdeveloper.net / http://www.virtualserverfaq.com BitShop, Inc. - Development, Training, Hosting, Troubleshooting - http://www.bitshop.com I'm actually doing something like that. What I do is track hits on the highest MX that has not hit the lowest numbered MX, then because I use Exim I can track which IP addresses don't send the QUIT command to close the connection. This combination creates a highly reliable blacklist and I'm currently tracking about 1.1 million virus infected spambots that have tried to spam me in the last 4 days. It's my hostkarma list.
Re: Bogus MX - blacklist service viable?
On Thu, Feb 21, 2008 at 11:47 PM, Marc Perkel [EMAIL PROTECTED] wrote: Steve Radich wrote: Sorry; apparently I was unclear. MX records I'm saying as follows: 100 - Real 200 - Real perhaps, as many real as you want 300 - Bogus - one that blocks port 25 with tcp reset for example 400 - accept port, logs ip - blacklist (not to be scored aggressively at all) with a 421/retry. If a whole bunch of places are seeing the same smtp server hitting this 400 level MX then I'm saying that seems like a useful thing to be included in a blacklist using a low score in sa. The point was to offer the 400 level mx as a free service to log the ips quickly for those that don't want to set up the server themselves. In theory the 400 level MX wouldn't be used by real smtp very often, hence it's likely a spammer and therefore the IP could be auto blacklisted. Realize I'm NOT proposing we block on this, just score based on this list. Steve Radich - http://www.aspdeveloper.net / http://www.virtualserverfaq.com BitShop, Inc. - Development, Training, Hosting, Troubleshooting - http://www.bitshop.com I'm actually doing something like that. What I do is track hits on the highest MX that has not hit the lowest numbered MX, then because I use Exim I can track which IP addresses don't send the QUIT command to close I am thinking about playing around with the same type of thing here.. Is this any different from looking for lost connection after DATA or lost connection after RCPT errors in a postfix server's logs? Not sure why you can detect this because you run Exim specifically. Or am I missing something? the connection. This combination creates a highly reliable blacklist and I'm currently tracking about 1.1 million virus infected spambots that have tried to spam me in the last 4 days. It's my hostkarma list. Sounds interesting.. do you block based on this list or just use it for scoring in SA or something like that? What is the false positve rate? -Aaron
