Re: Making the Botnet plugin work with IPv6
On 20.09.2010 20:03 CE(S)T, Yves Goergen wrote: > I'm currently testing a rather simple fix: I've added the following line > to Botnet.cf to ignore anything from IPv6 (hope it works): > > botnet_skip_ip : It doesn't seem to work. I received an e-mail via IPv6 that was sent to the other MTA from a dial-up address, and Botnet catched it. This skip thing only seems to use the next IP address it finds, which is the sender's one and that is most often a dynamic address. Anyway, are there alternative recommendations that I could use instead of the Botnet plugin? The concept seems to be quite good, but the implementation isn't so safe (and future-proof) anymore. -- Yves Goergen "LonelyPixel" Visit my web laboratory at http://beta.unclassified.de
Re: Making the Botnet plugin work with IPv6
On Mon, 20 Sep 2010 20:03:43 +0200 Yves Goergen wrote: > I'm currently testing a rather simple fix: I've added the following > line to Botnet.cf to ignore anything from IPv6 (hope it works): Alternately you can do this by rewriting the BOTNET rule as a metarule (see Botnet.variants.txt) and incorporating an IPv6 check into that. I haven't checked, but it may be that not all of the subtests fail under IPv6 and something can be salvaged. Also some of the functionality might be recreated using header rules e.g. BOTNET_NORDNS could supplemented by RDNS_NONE.
Making the Botnet plugin work with IPv6
Hi there, I've been upgrading to IPv6 yesterday and needed to find out that the Botnet plugin causes false positives on every message that comes in from an IPv6 address. The only information that I've found on that was a thread from January 2010 [1] that contains some debug output and a "good luck" wish. The plugin author doesn't seem to exist anymore. Now I'd definitely like to make this work again. I needed to disable the plugin for now. But unfortunately I can hardly read Perl and not write very much of it. So I'll likely break more than I repair. A problem seems to exist in Botnet.pm from line 760 on where the octets of an IPv4 address are split and computed in some way. I believe the easiest fix for now (as IPv6 isn't so widespread yet) would be to make that function return false when it is passed an IPv6 address (check for colon in the $ip variable). I'm currently testing a rather simple fix: I've added the following line to Botnet.cf to ignore anything from IPv6 (hope it works): botnet_skip_ip : Can anybody assist me with this issue? [1] http://www.mail-archive.com/users@spamassassin.apache.org/msg70589.html (and other copies) -- Yves Goergen "LonelyPixel" Visit my web laboratory at http://beta.unclassified.de
Re: Botnet plugin still relevant?
John Hardin wrote on Mon, 22 Mar 2010 10:47:35 -0700 (PDT): > How do you reject mail from a non-static IP without doing a DNSBL lookup > (e.g. Zen)? we are talking about lookups from SA here ;-) And these you can disable if you reject such mail, anyway. Kai -- Get your web at Conactive Internet Services: http://www.conactive.com
Re: Botnet plugin still relevant?
On Mon, 22 Mar 2010, Kai Schaetzl wrote: Micah anderson wrote on Mon, 22 Mar 2010 10:51:20 -0400: This brings it over the 8 threshold, although it is a legitimate email From a user who has unfortunately been saddled with a dynamic IP Most ISPs reject direct mail from non-static IP addresses nowadays. If you combine this with John Hardin's suggestion you don't need the botnet plugin or do RBL lookups for these clients at all (I guess you would need a new plugin for this, though). How do you reject mail from a non-static IP without doing a DNSBL lookup (e.g. Zen)? If you're suggesting most ISPs are doing egress filtering on port 25 from their dynamic spaces, that's good for them, but until _all_ ISPs do that DNSBLs will still be useful. My suggestion doesn't involve discarding botnet or DNSBLs, it involves offsetting their scores for those instances where you _know_ the mail from a suspicious IP address is legitimate and wanted. -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- Men by their constitutions are naturally divided in to two parties: 1. Those who fear and distrust the people and wish to draw all powers from them into the hands of the higher classes. 2. Those who identify themselves with the people, have confidence in them, cherish and consider them as the most honest and safe, although not the most wise, depository of the public interests. -- Thomas Jefferson --- 164 days since President Obama won the Nobel "Not George W. Bush" prize
Re: Botnet plugin still relevant?
Micah anderson wrote on Mon, 22 Mar 2010 10:51:20 -0400: > This brings it over the 8 threshold, although it is a legitimate email > From a user who has unfortunately been saddled with a dynamic IP Most ISPs reject direct mail from non-static IP addresses nowadays. If you combine this with John Hardin's suggestion you don't need the botnet plugin or do RBL lookups for these clients at all (I guess you would need a new plugin for this, though). Kai -- Get your web at Conactive Internet Services: http://www.conactive.com
Re: Botnet plugin still relevant?
On Mon, 22 Mar 2010 10:51:20 -0400 micah anderson wrote: > Yeah, I've been having problems recently which I think are related to > me using both Zen/PBL along with the Botnet plugin weighted to score > level 5, even if I were to have it lower at 3 it would still be too > much. If you look in the BOTNET documentation, it's possible to have BOTNET as a meta rule rather than have the logic inside the plugin. IMO it would be sensible to score PBL at 0.001 and bring it inside a BOTNET meta rule, and rescore BOTNET at the current value of the PBL score.
Re: Botnet plugin still relevant?
micah anderson wrote: Yeah, I've been having problems recently which I think are related to me using both Zen/PBL along with the Botnet plugin weighted to score level 5, even if I were to have it lower at 3 it would still be too much. Are you using the PBL appropriately? <http://www.spamhaus.org/pbl/> says-- Caution: Because the PBL lists normal customer IP space, do not use PBL on smarthosts or SMTP AUTH outbound servers for your own customers (or you risk blocking your own customers if their dynamic IPs are in the PBL). Do not use PBL in filters that do any deep parsing of Received headers, or for other than checking IP addresses that hand off to your mailservers. Joseph Brennan Columbia University Information Technology
Re: Botnet plugin still relevant?
On Mon, 22 Mar 2010, micah anderson wrote: Many users are complaining and when I finally get some useful messages with headers to analyze I am finding something like the following: X-Spam-Report: * 3.3 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL * [213.6.61.151 listed in zen.dnsbl] * 1.0 RCVD_IN_BRBL RBL: Received via relay listed in Barracuda RBL * [213.6.61.151 listed in b.barracudacentral.org] * 1.4 RCVD_IN_BRBL_LASTEXT RBL: RCVD_IN_BRBL_LASTEXT * [213.6.61.151 listed in bb.barracudacentral.org] * 0.0 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address * [213.6.61.151 listed in dnsbl.sorbs.net] * 0.8 SPF_NEUTRAL SPF: sender does not match SPF record (neutral) * 5.0 BOTNET Relay might be a spambot or virusbot * [botnet0.8,ip=213.6.61.151,rdns=a61-151.adsl.paltel.net,maildomain=palnet.com,client,ipinhostname,clientwords] * 1.0 RDNS_DYNAMIC Delivered to internal network by host with * dynamic-looking rDNS This brings it over the 8 threshold, although it is a legitimate email From a user who has unfortunately been saddled with a dynamic IP that previously was used by a spammer. If your users are connecting from random public Internet dynamic-IP hosts, are you using SMTP authentication? If so, there should be data about that authentication in the Received: headers that you can use within SA to whitelist them and offset legitimate results like those above. -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- Mine eyes have seen the horror of the voting of the horde; They've looted the fromagerie where guv'ment cheese is stored; If war's not won before the break they grow so quickly bored; Their vote counts as much as yours. -- Tam --- 164 days since President Obama won the Nobel "Not George W. Bush" prize
Re: Botnet plugin still relevant?
On Mon, Mar 22, 2010 at 07:51, micah anderson wrote: > From a user who has unfortunately been saddled with a dynamic IP that > previously was used by a spammer. No amount of explanation to these > users about this is going to assuage their feelings, and there isn't > really anything that can be done by them. They can complain to their ISP > I guess, they could also find another ISP, but these are not > particularly productive steps towards resolving this problem. > > I'm interested in other suggestions that I offer people as alternatives, > but until then I think I may need to remove Botnet from the equation. Or you could just put that relay into your botnet cf file so that it doesn't get scored by botnet. That's what the botnet_pass_ip entries are there for. Using the example you just gave, you could just do: botnet_pass_ip^213\.6\.61\.151$ Then just do whatever you need to in your spamassassin environment to make that live (reload something, etc.). Then that particular host wont ever trigger botnet again.
Re: Botnet plugin still relevant?
On 22.3.2010 16:51, micah anderson wrote: > On Wed, 17 Mar 2010 14:45:53 -0700, John Rudd wrote: >> Some people need to put in some alternate values for DNS timeouts, but >> if you've got a local caching name server, you typically don't need >> that. >> >> There aren't any actual bugs in it that I'm aware of, so I haven't >> released a new version. As I see it, there isn't a need (and that is >> a somewhat controversial statement with some of the more opinionated >> people around here). >> >> I do still see some things that get nailed by it ... but there's lots >> of those same hosts that get caught by the Spamhaus PBL. So, it kind >> of depends on what you're doing with PBL and/or Zen, as to whether or >> not you need Botnet. But, there are still plenty of things coming >> from that class of hosts, so if you don't use one, I'd definitely >> recommend using the other. > > Yeah, I've been having problems recently which I think are related to me > using both Zen/PBL along with the Botnet plugin weighted to score level > 5, even if I were to have it lower at 3 it would still be too much. > > Many users are complaining and when I finally get some useful messages > with headers to analyze I am finding something like the following: > > X-Spam-Report: > * 3.3 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL > * [213.6.61.151 listed in zen.dnsbl] > * 1.0 RCVD_IN_BRBL RBL: Received via relay listed in Barracuda RBL > * [213.6.61.151 listed in b.barracudacentral.org] > * 1.4 RCVD_IN_BRBL_LASTEXT RBL: RCVD_IN_BRBL_LASTEXT > * [213.6.61.151 listed in bb.barracudacentral.org] > * 0.0 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP > address > * [213.6.61.151 listed in dnsbl.sorbs.net] > * 0.8 SPF_NEUTRAL SPF: sender does not match SPF record (neutral) > * 5.0 BOTNET Relay might be a spambot or virusbot > * > [botnet0.8,ip=213.6.61.151,rdns=a61-151.adsl.paltel.net,maildomain=palnet.com,client,ipinhostname,clientwords] > * 1.0 RDNS_DYNAMIC Delivered to internal network by host with > * dynamic-looking rDNS > > This brings it over the 8 threshold, although it is a legitimate email > From a user who has unfortunately been saddled with a dynamic IP that > previously was used by a spammer. No amount of explanation to these > users about this is going to assuage their feelings, and there isn't > really anything that can be done by them. They can complain to their ISP > I guess, they could also find another ISP, but these are not > particularly productive steps towards resolving this problem. > > I'm interested in other suggestions that I offer people as alternatives, > but until then I think I may need to remove Botnet from the equation. > > micah It looks like the sender has operated his own smtp server and not used his ISP as a smart host. That is bad practice, with a real server not a single of those rules would have triggeted. Especially Botnet does not have any knowledge about earlier spamming. Botnet does not care. -- http://www.iki.fi/jarif/ Q: What is purple and concord the world? A: Alexander the Grape. signature.asc Description: OpenPGP digital signature
Re: Botnet plugin still relevant?
On Wed, 17 Mar 2010 14:45:53 -0700, John Rudd wrote: > Some people need to put in some alternate values for DNS timeouts, but > if you've got a local caching name server, you typically don't need > that. > > There aren't any actual bugs in it that I'm aware of, so I haven't > released a new version. As I see it, there isn't a need (and that is > a somewhat controversial statement with some of the more opinionated > people around here). > > I do still see some things that get nailed by it ... but there's lots > of those same hosts that get caught by the Spamhaus PBL. So, it kind > of depends on what you're doing with PBL and/or Zen, as to whether or > not you need Botnet. But, there are still plenty of things coming > from that class of hosts, so if you don't use one, I'd definitely > recommend using the other. Yeah, I've been having problems recently which I think are related to me using both Zen/PBL along with the Botnet plugin weighted to score level 5, even if I were to have it lower at 3 it would still be too much. Many users are complaining and when I finally get some useful messages with headers to analyze I am finding something like the following: X-Spam-Report: * 3.3 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL * [213.6.61.151 listed in zen.dnsbl] * 1.0 RCVD_IN_BRBL RBL: Received via relay listed in Barracuda RBL * [213.6.61.151 listed in b.barracudacentral.org] * 1.4 RCVD_IN_BRBL_LASTEXT RBL: RCVD_IN_BRBL_LASTEXT * [213.6.61.151 listed in bb.barracudacentral.org] * 0.0 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address * [213.6.61.151 listed in dnsbl.sorbs.net] * 0.8 SPF_NEUTRAL SPF: sender does not match SPF record (neutral) * 5.0 BOTNET Relay might be a spambot or virusbot * [botnet0.8,ip=213.6.61.151,rdns=a61-151.adsl.paltel.net,maildomain=palnet.com,client,ipinhostname,clientwords] * 1.0 RDNS_DYNAMIC Delivered to internal network by host with * dynamic-looking rDNS This brings it over the 8 threshold, although it is a legitimate email From a user who has unfortunately been saddled with a dynamic IP that previously was used by a spammer. No amount of explanation to these users about this is going to assuage their feelings, and there isn't really anything that can be done by them. They can complain to their ISP I guess, they could also find another ISP, but these are not particularly productive steps towards resolving this problem. I'm interested in other suggestions that I offer people as alternatives, but until then I think I may need to remove Botnet from the equation. micah pgpOYcMscG6vB.pgp Description: PGP signature
Re: Botnet plugin still relevant?
On Wed, 17 Mar 2010 17:34:08 -0400 Micah Anderson wrote: > > Hi, > > I've been using the Botnet plugin version 0.8 for some time now, and > the plugin itself has been around since 2003 or so. I'm just curious > to test the waters and see what other's think about the relevance in > 2010 of this plugin. Does it still contribute in positive ways to > your setup? I do not see a newer version of the plugin since 2007, is > there a newer version than 0.8? What it's trying to do hasn't really changed. There was a report that IPv6 connections FP though. IMO much of the functionality in botnet should be brought into the core so everything integrates better. There are already some overlapping tests, but they are patchy and incoherent. The most important thing is to fix the problem of missing rdns either by infilling or simply a means to tell SA which MX servers don't support it. > Did you do any configuration of it beyond its defaults? Chiefly the default score is a bit too high. > Does the > proliferation of individuals on dynamically assigned cable/dsl modems > cause the plugin to misfire too often? The whole point of the plugin is to detect such accounts when they are delivering direct to MX. The FP's tend to be real mail-servers that have odd dns. In this day and age no-one with a dynamic address should deliver direct to MX. > I've had a number of complaints somewhat recently about the last > point, and I don't have much of a solution to the situation where a > user is stuck with the dynamically assigned IP that previously a > spammer was occupying, except to explain that is the situation and > eventually it will change. This has nothing to do with Botnet, and it shouldn't have much of an effect - provided they are sending through a smarthost. The blocklists that contain Botnets only run on the last external address to avoid that problem.
Re: Botnet plugin still relevant?
Some people need to put in some alternate values for DNS timeouts, but if you've got a local caching name server, you typically don't need that. There aren't any actual bugs in it that I'm aware of, so I haven't released a new version. As I see it, there isn't a need (and that is a somewhat controversial statement with some of the more opinionated people around here). I do still see some things that get nailed by it ... but there's lots of those same hosts that get caught by the Spamhaus PBL. So, it kind of depends on what you're doing with PBL and/or Zen, as to whether or not you need Botnet. But, there are still plenty of things coming from that class of hosts, so if you don't use one, I'd definitely recommend using the other. John Rudd On Wed, Mar 17, 2010 at 14:34, Micah Anderson wrote: > > Hi, > > I've been using the Botnet plugin version 0.8 for some time now, and the > plugin itself has been around since 2003 or so. I'm just curious to test > the waters and see what other's think about the relevance in 2010 of > this plugin. Does it still contribute in positive ways to your setup? I > do not see a newer version of the plugin since 2007, is there a newer > version than 0.8? > > Did you do any configuration of it beyond its defaults? Does the > proliferation of individuals on dynamically assigned cable/dsl modems > cause the plugin to misfire too often? > > I've had a number of complaints somewhat recently about the last point, > and I don't have much of a solution to the situation where a user is > stuck with the dynamically assigned IP that previously a spammer was > occupying, except to explain that is the situation and eventually it > will change. > > thanks for any thoughts or experiences with this plugin! > > micah > > ps. I notice it is not listed on > http://wiki.apache.org/spamassassin/CustomPlugins and I wonder the > reason why? > >
Botnet plugin still relevant?
Hi, I've been using the Botnet plugin version 0.8 for some time now, and the plugin itself has been around since 2003 or so. I'm just curious to test the waters and see what other's think about the relevance in 2010 of this plugin. Does it still contribute in positive ways to your setup? I do not see a newer version of the plugin since 2007, is there a newer version than 0.8? Did you do any configuration of it beyond its defaults? Does the proliferation of individuals on dynamically assigned cable/dsl modems cause the plugin to misfire too often? I've had a number of complaints somewhat recently about the last point, and I don't have much of a solution to the situation where a user is stuck with the dynamically assigned IP that previously a spammer was occupying, except to explain that is the situation and eventually it will change. thanks for any thoughts or experiences with this plugin! micah ps. I notice it is not listed on http://wiki.apache.org/spamassassin/CustomPlugins and I wonder the reason why?
Re: BOTNET plugin download
On Mon, Jun 8, 2009 at 16:31, alexus wrote: > whats botnet plugin? It's a SpamAssassin plugin looks at DNS configurations and attempts to identify hosts that are probably actually clients that are sending email directly to your server, instead of through their own mail server. There's a high likelihood that those senders are actually botnets and not legitimate senders. Thus the name of the plugin. But, botnets aren't its only purpose. It's also an encouragement for email admins to follow best practices in how they set up the DNS of their mail servers. > > On Mon, Jun 8, 2009 at 7:23 PM, John Rudd wrote: >> On Mon, Jun 8, 2009 at 09:55, Jari Fredriksson wrote: >>>> The BOTNET plugin isn't covered in the CustomPlugins wiki >>>> page. When I Googled it I found this: >>>> >>>> http://people.ucsc.edu/~jrudd/spamassassin/Botnet.tar >>>> >>>> but it's a bit old. Is there a later version? >>> >>> That's 0.8 which is AFAIK the latest. >>> >> >> Yes, 0.8 is the latest, and it's ... 2 years old now? or just 1.5? >> somewhere around there. >> >> I haven't really needed to do an update, though there are some things >> I want to re-work once I get some spare time (mostly, how it does DNS >> lookups, to use SA internals more). >> > > > > -- > http://alexus.org/ >
Re: BOTNET plugin download
whats botnet plugin? On Mon, Jun 8, 2009 at 7:23 PM, John Rudd wrote: > On Mon, Jun 8, 2009 at 09:55, Jari Fredriksson wrote: >>> The BOTNET plugin isn't covered in the CustomPlugins wiki >>> page. When I Googled it I found this: >>> >>> http://people.ucsc.edu/~jrudd/spamassassin/Botnet.tar >>> >>> but it's a bit old. Is there a later version? >> >> That's 0.8 which is AFAIK the latest. >> > > Yes, 0.8 is the latest, and it's ... 2 years old now? or just 1.5? > somewhere around there. > > I haven't really needed to do an update, though there are some things > I want to re-work once I get some spare time (mostly, how it does DNS > lookups, to use SA internals more). > -- http://alexus.org/
Re: BOTNET plugin download
On Mon, Jun 8, 2009 at 09:55, Jari Fredriksson wrote: >> The BOTNET plugin isn't covered in the CustomPlugins wiki >> page. When I Googled it I found this: >> >> http://people.ucsc.edu/~jrudd/spamassassin/Botnet.tar >> >> but it's a bit old. Is there a later version? > > That's 0.8 which is AFAIK the latest. > Yes, 0.8 is the latest, and it's ... 2 years old now? or just 1.5? somewhere around there. I haven't really needed to do an update, though there are some things I want to re-work once I get some spare time (mostly, how it does DNS lookups, to use SA internals more).
Re: BOTNET plugin download
> The BOTNET plugin isn't covered in the CustomPlugins wiki > page. When I Googled it I found this: > > http://people.ucsc.edu/~jrudd/spamassassin/Botnet.tar > > but it's a bit old. Is there a later version? That's 0.8 which is AFAIK the latest.
BOTNET plugin download
The BOTNET plugin isn't covered in the CustomPlugins wiki page. When I Googled it I found this: http://people.ucsc.edu/~jrudd/spamassassin/Botnet.tar but it's a bit old. Is there a later version?
Re: Botnet plugin
On Sun, January 18, 2009 19:03, mouss wrote: > This may not be a problem for you, but other people may want to > score if PTR is dynamic (even if helo is not). and reject in mta if both is dynamic :) -- Benny Pedersen Need more webspace ? http://www.servage.net/?coupon=cust37098
Re: Botnet plugin
Henrik K a écrit : > On Sun, Jan 18, 2009 at 03:45:25PM +0100, mouss wrote: >> Henrik K a écrit : >[snip] >>> Less info only if you are running a sad MTA, that doesn't properly resolve. >> not completely true. >> >> $ host 220.174.1.163 >> 163.1.174.220.in-addr.arpa domain name pointer >> 163.1.174.220.broad.hk.hi.dynamic.163data.com.cn. >> $ host 163.1.174.220.broad.hk.hi.dynamic.163data.com.cn >> Host 163.1.174.220.broad.hk.hi.dynamic.163data.com.cn not found: 3(NXDOMAIN) >> >> if you get a message from this IP, postfix will set the name to >> "unknown". so you won't detect that the PTR is dynamic. >> >> and "unknown" is also used if there is a dns failure, or if the PTR >> doesn't "confirm" (ip -> ptr -> different IP). so you can't treat all >> "unknown" similarly. >> >> I know you can block the IP in postfix (I block the whole >> dynamic.163data.com.cn), but this is just an example (I'm too lazy to >> look for a better one), and I hope you see my point. > > Well, for what it matters, unknown is fine by mine. I greylist all of them. > I block unknowns that are in any BLs. I don't directly block hostnames with > dynamic content (only known bad isps), but I do block dynamic helos. I don't > see any problems on what you said. > I only meant that you can have "less infos" even with a not so "sad MTA". This may not be a problem for you, but other people may want to score if PTR is dynamic (even if helo is not).
Re: Botnet plugin
On Sun, Jan 18, 2009 at 03:45:25PM +0100, mouss wrote: > Henrik K a écrit : > > On Fri, Jan 16, 2009 at 01:52:46PM +0100, Jonas Eckerman wrote: > >> Benny Pedersen wrote: > >> > >>> i have changed to use BadRelay from > >>> http://sa.hege.li/BadRelay.pm > >>> http://sa.hege.li/BadRelay.cf > >> After reading BadRelay.pm I see that it does not really replace Botnet. > >> > >> Some of the differences in what is checked are due to Botnet doing > >> DNS-lookups while BadRelay avoids that. That's fair enough since one of > >> the points of BadRelay is to avoid those lookups. It does mean that > >> BadRelay has less info to base decisions on than Botnet though. > > > > Less info only if you are running a sad MTA, that doesn't properly resolve. > > not completely true. > > $ host 220.174.1.163 > 163.1.174.220.in-addr.arpa domain name pointer > 163.1.174.220.broad.hk.hi.dynamic.163data.com.cn. > $ host 163.1.174.220.broad.hk.hi.dynamic.163data.com.cn > Host 163.1.174.220.broad.hk.hi.dynamic.163data.com.cn not found: 3(NXDOMAIN) > > if you get a message from this IP, postfix will set the name to > "unknown". so you won't detect that the PTR is dynamic. > > and "unknown" is also used if there is a dns failure, or if the PTR > doesn't "confirm" (ip -> ptr -> different IP). so you can't treat all > "unknown" similarly. > > I know you can block the IP in postfix (I block the whole > dynamic.163data.com.cn), but this is just an example (I'm too lazy to > look for a better one), and I hope you see my point. Well, for what it matters, unknown is fine by mine. I greylist all of them. I block unknowns that are in any BLs. I don't directly block hostnames with dynamic content (only known bad isps), but I do block dynamic helos. I don't see any problems on what you said.
Re: Botnet plugin
Henrik K a écrit : > On Fri, Jan 16, 2009 at 01:52:46PM +0100, Jonas Eckerman wrote: >> Benny Pedersen wrote: >> >>> i have changed to use BadRelay from >>> http://sa.hege.li/BadRelay.pm >>> http://sa.hege.li/BadRelay.cf >> After reading BadRelay.pm I see that it does not really replace Botnet. >> >> Some of the differences in what is checked are due to Botnet doing >> DNS-lookups while BadRelay avoids that. That's fair enough since one of >> the points of BadRelay is to avoid those lookups. It does mean that >> BadRelay has less info to base decisions on than Botnet though. > > Less info only if you are running a sad MTA, that doesn't properly resolve. not completely true. $ host 220.174.1.163 163.1.174.220.in-addr.arpa domain name pointer 163.1.174.220.broad.hk.hi.dynamic.163data.com.cn. $ host 163.1.174.220.broad.hk.hi.dynamic.163data.com.cn Host 163.1.174.220.broad.hk.hi.dynamic.163data.com.cn not found: 3(NXDOMAIN) if you get a message from this IP, postfix will set the name to "unknown". so you won't detect that the PTR is dynamic. and "unknown" is also used if there is a dns failure, or if the PTR doesn't "confirm" (ip -> ptr -> different IP). so you can't treat all "unknown" similarly. I know you can block the IP in postfix (I block the whole dynamic.163data.com.cn), but this is just an example (I'm too lazy to look for a better one), and I hope you see my point. > I guess the SOHO rule is exception, but I've never seen a need for it > myself. You can always whitelist such minority cases by hand. > >> One differences is simply due to the fact that all Badrelay does is the >> simple regexp matches. BadRelay doesn't have Botnet's check for IP in >> host name, wich it could do without DNS lookups. > > Check for IP in hostname? Does anyone have actual stats, that it's somehow > better than a generic \d+-\d+ regex or whatever? Sometimes it's just better > to KISS. > > Btw, I haven't touched BadRelay in ages, since all these "dynamic" etc > checks should be done in MTA. I pretty much don't get anything through to SA > that would get hit by it. > >> What would be nice though would be a plugin that: >> ... > > All this should be generic SA stuff.. :) If only someone would have time to > revamp the current (old) rules. >
Re: Botnet plugin
Henrik K wrote: Less info only if you are running a sad MTA, that doesn't properly resolve. I guess the SOHO rule is exception, That was what I meant. :-) Check for IP in hostname? Does anyone have actual stats, that it's somehow better than a generic \d+-\d+ regex or whatever? Sometimes it's just better to KISS. I don't have any stats now, but I use a similar check in our selective grey listing and once checked stats for that. There was a clear difference (catching more fqdns with fewer FPs) when I changed from a simple check to a more complex one. (Comparing the fqdn with the IP address allows you to match patterns that might otherwise lead to FPs.) Regards /Jonas -- Jonas Eckerman, FSDB & Fruktträdet http://whatever.frukt.org/ http://www.fsdb.org/ http://www.frukt.org/
Re: Botnet plugin
On Fri, Jan 16, 2009 at 01:52:46PM +0100, Jonas Eckerman wrote: > Benny Pedersen wrote: > >> i have changed to use BadRelay from > >> http://sa.hege.li/BadRelay.pm >> http://sa.hege.li/BadRelay.cf > > After reading BadRelay.pm I see that it does not really replace Botnet. > > Some of the differences in what is checked are due to Botnet doing > DNS-lookups while BadRelay avoids that. That's fair enough since one of > the points of BadRelay is to avoid those lookups. It does mean that > BadRelay has less info to base decisions on than Botnet though. Less info only if you are running a sad MTA, that doesn't properly resolve. I guess the SOHO rule is exception, but I've never seen a need for it myself. You can always whitelist such minority cases by hand. > One differences is simply due to the fact that all Badrelay does is the > simple regexp matches. BadRelay doesn't have Botnet's check for IP in > host name, wich it could do without DNS lookups. Check for IP in hostname? Does anyone have actual stats, that it's somehow better than a generic \d+-\d+ regex or whatever? Sometimes it's just better to KISS. Btw, I haven't touched BadRelay in ages, since all these "dynamic" etc checks should be done in MTA. I pretty much don't get anything through to SA that would get hit by it. > What would be nice though would be a plugin that: > ... All this should be generic SA stuff.. :) If only someone would have time to revamp the current (old) rules.
Re: Botnet plugin
Mark Martinec wrote: In a while I'll send a patch to the author. That is noble, but apparently it doesn't have any effect. When Botnet was known as RelayChecker I made a suggestion to the author. That suggestion was incorporated in the code. For some reason I take that as an indicator that my suggestion did have an effect at that time, and that there is a possibility that my new suggestion also has an effect (depending on, among other things, what the author things about it). I also seem to recall that the author gives credit (in some file included in the Botnet tar) to a whole bunch of people for suggestions and/or changes. Presumably at least some of those suggestions and/or changes did have some kind of effect on the plugin. /Jonas -- Jonas Eckerman, FSDB & Fruktträdet http://whatever.frukt.org/ http://www.fsdb.org/ http://www.frukt.org/
Re: Botnet plugin
Benny Pedersen wrote: i have changed to use BadRelay from http://sa.hege.li/BadRelay.pm http://sa.hege.li/BadRelay.cf After reading BadRelay.pm I see that it does not really replace Botnet. Some of the differences in what is checked are due to Botnet doing DNS-lookups while BadRelay avoids that. That's fair enough since one of the points of BadRelay is to avoid those lookups. It does mean that BadRelay has less info to base decisions on than Botnet though. One differences is simply due to the fact that all Badrelay does is the simple regexp matches. BadRelay doesn't have Botnet's check for IP in host name, wich it could do without DNS lookups. Also, it should be a small and simple change to Botnet in order to use some of it's functions without making it do it's own DNS lookups AFAICT. The eval checks "botnet_ipinhostname", "botnet_clientwords" and "botnet_serverwords" should be able work without any DNS lookups with this small change. I might do a patch for this (if there is any interest). What would be nice though would be a plugin that: 1: Have a simple (for the user) cf option to decide on wether *any* additional DNS lookups should *ever* be done or not. 2: If told to do lookups, do as many of those as possible asynchronously, the way SAs DNSL checks are done. This would require a redesign of the plugins structure though. I *might* do this (in that case I'd do a completely new plugin based on Botnet) if I get time for it, but I currently have no way of knowing when or if that might be. Regards /Jonas -- Jonas Eckerman, FSDB & Fruktträdet http://whatever.frukt.org/ http://www.fsdb.org/ http://www.frukt.org/
Re: Botnet plugin (was: Temporary 'Replacements' for SaneSecurity)
On Thu, Jan 15, 2009 at 09:06, Mark Martinec wrote: > Jonas, > >> I just found one reason for FPs in the Botnet plugin. It doesn't >> make a difference between timeouts (and other DNS errors) and >> negative answers. So if your DNS server/proxy is overloaded (or >> slow for some other reason), you'll get FPs >> >> Since 15 minutes ago, I'm running a slightly modified version of >> the plugin that tries to avoid this. > > Not to forget the long-standing DNS problem with Botnet: > > http://marc.info/?l=spamassassin-users&m=118641079630268 > http://marc.info/?l=spamassassin-users&m=120783518919154 > >> In a while I'll send a patch to the author. > > That is noble, but apparently it doesn't have any effect. Yes, clearly the fact that I didn't get around to fixing something means that I never accept fixes/suggestions/etc. from external sources. Botnet has never incorporated any such external submission. Ever. Hopefully you're smart enough to detect sarcasm.
Re: Botnet plugin patch - avoid FPs from DNS timeouts
I'll incorporate this into the next version. Thanks :-) On Thu, Jan 15, 2009 at 12:47, Jonas Eckerman wrote: > Hello! > > Here's a small patch for the Botnet plugin. > > The difference from the original is that it doesn't treat a timeout or DNS > error the same as a not found answer. This should avoid FPs due to > overloaded or s,low DNS responsesn. > > This patch is against a version that hjas allready been patched in order to > get short timeouts from the resolver. When using the original version, DNS > timesouts will probably not occur as often and this patch will not make as > big a difference. > > Please note that I've only tested this since earlier today. If you see or > notice a mistake or problem in it, please tell me and the list about it. > > Regards > /Jonas > > -- > Jonas Eckerman, FSDB > http://www.fsdb.org/ >
Botnet plugin patch - avoid FPs from DNS timeouts
Hello! Here's a small patch for the Botnet plugin. The difference from the original is that it doesn't treat a timeout or DNS error the same as a not found answer. This should avoid FPs due to overloaded or s,low DNS responsesn. This patch is against a version that hjas allready been patched in order to get short timeouts from the resolver. When using the original version, DNS timesouts will probably not occur as often and this patch will not make as big a difference. Please note that I've only tested this since earlier today. If you see or notice a mistake or problem in it, please tell me and the list about it. Regards /Jonas -- Jonas Eckerman, FSDB http://www.fsdb.org/ --- Botnet.pm Thu Jan 15 21:35:42 2009 +++ Botnet.pm.new Thu Jan 15 21:36:25 2009 @@ -721,8 +721,16 @@ dnsrch=>0, defnames=>0, ); - if ($query = $resolver->search($name, $type)) { - # found matches + if ($query = $resolver->send($name, $type)) { + if ($query->header->rcode eq 'SERVFAIL') { +# avoid FP due to timeout or other error +return (-1); +} + if ($query->header->rcode eq 'NXDOMAIN') { +# found no matches +return (0); +} + # check for matches $i = 0; foreach $rr ($query->answer()) { $i++; @@ -744,12 +752,12 @@ } } } - # $ip isn't in the A records for $name at all + # found no matches return(0); } else { - # the sender leads to a host that doesn't have an A record - return (0); + # avoid FP due to timeout or other error + return (-1); } } # can't resolve an empty name nor ip that doesn't look like an address
Re: Botnet plugin (was: Temporary 'Replacements' for SaneSecurity)
On Thu, January 15, 2009 18:06, Mark Martinec wrote: > Not to forget the long-standing DNS problem with Botnet: > http://marc.info/?l=spamassassin-users&m=118641079630268 > http://marc.info/?l=spamassassin-users&m=120783518919154 i have changed to use BadRelay from http://sa.hege.li/BadRelay.pm http://sa.hege.li/BadRelay.cf Thanks goes to Henrik for make this update >> In a while I'll send a patch to the author. > That is noble, but apparently it doesn't have any effect. we can just hope -- Benny Pedersen Need more webspace ? http://www.servage.net/?coupon=cust37098
Re: Botnet plugin (was: Temporary 'Replacements' for SaneSecurity)
Jonas, > I just found one reason for FPs in the Botnet plugin. It doesn't > make a difference between timeouts (and other DNS errors) and > negative answers. So if your DNS server/proxy is overloaded (or > slow for some other reason), you'll get FPs > > Since 15 minutes ago, I'm running a slightly modified version of > the plugin that tries to avoid this. Not to forget the long-standing DNS problem with Botnet: http://marc.info/?l=spamassassin-users&m=118641079630268 http://marc.info/?l=spamassassin-users&m=120783518919154 > In a while I'll send a patch to the author. That is noble, but apparently it doesn't have any effect. Mark
RE: Botnet plugin (was: Temporary 'Replacements' for SaneSecurity)
> > I just found one reason for FPs in the Botnet plugin. It > doesn't make a difference between timeouts (and other DNS > errors) and negative answers. So if your DNS server/proxy is > overloaded (or slow for some other reason), you'll get FPs > > Since 15 minutes ago, I'm running a slightly modified version > of the plugin that tries to avoid this. In a while I'll send > a patch to the author. > > Apart from this the plugin seems to work fine here with a > score of +2 (with an extra +1 if p0f says it's a Windows system). > > Regards > /Jonas > > -- > Jonas Eckerman, FSDB & Fruktträdet Jonas, please send the patch to the list too whether or not the author does anything with it is his business, and then eventually ours. :-) it will benefit a lot of people that will choose to use your idea or patch regardless. thanks! - rh
Botnet plugin (was: Temporary 'Replacements' for SaneSecurity)
Daniel J McDonald wrote: I too found botnet to be a great source of FP. By combining it with p0f it's moderately useful. I just found one reason for FPs in the Botnet plugin. It doesn't make a difference between timeouts (and other DNS errors) and negative answers. So if your DNS server/proxy is overloaded (or slow for some other reason), you'll get FPs Since 15 minutes ago, I'm running a slightly modified version of the plugin that tries to avoid this. In a while I'll send a patch to the author. Apart from this the plugin seems to work fine here with a score of +2 (with an extra +1 if p0f says it's a Windows system). Regards /Jonas -- Jonas Eckerman, FSDB & Fruktträdet http://whatever.frukt.org/ http://www.fsdb.org/ http://www.frukt.org/
RE: What is current version of Botnet plugin?
Steve Home page is// http://people.ucsc.edu/~jrudd/spamassassin/ Latest is 0.8 -- Martin Hepworth Snr Systems Administrator Solid State Logic Tel: +44 (0)1865 842300 > -Original Message- > From: Steven Stern [mailto:[EMAIL PROTECTED] > Sent: 04 August 2008 21:13 > To: users@spamassassin.apache.org > Subject: What is current version of Botnet plugin? > > I've found Botnet 0.6 and references to Botnet 0.8(ebuild). > What's the preferred version for this plugin? > ** Confidentiality : This e-mail and any attachments are intended for the addressee only and may be confidential. If they come to you in error you must take no action based on them, nor must you copy or show them to anyone. Please advise the sender by replying to this e-mail immediately and then delete the original from your computer. Opinion : Any opinions expressed in this e-mail are entirely those of the author and unless specifically stated to the contrary, are not necessarily those of the author's employer. Security Warning : Internet e-mail is not necessarily a secure communications medium and can be subject to data corruption. We advise that you consider this fact when e-mailing us. Viruses : We have taken steps to ensure that this e-mail and any attachments are free from known viruses but in keeping with good computing practice, you should ensure that they are virus free. Red Lion 49 Ltd T/A Solid State Logic Registered as a limited company in England and Wales (Company No:5362730) Registered Office: 25 Spring Hill Road, Begbroke, Oxford OX5 1RU, United Kingdom **
What is current version of Botnet plugin?
I've found Botnet 0.6 and references to Botnet 0.8(ebuild). What's the preferred version for this plugin?
Botnet plugin?
Hi, what's the current status of the Botnet plugin for SpamAssassin? I used it in my old SA 3.1.8 and think it was doing a good job. I heard that it should be part of SA now, but I couldn't find it by grepping the default rule files. Nor did I find it at SARE or elsewhere on the web. All I see is that web folder with the tarballs, latest from Nov 2007 or so. How can I enable it in SA 3.2.4? Do I still need to get that 3rd party file and install it? Is there a status/news website anywhere? -- Yves Goergen "LonelyPixel" <[EMAIL PROTECTED]> Visit my web laboratory at http://beta.unclassified.de
Re: Botnet Plugin
John Rudd wrote: In my opinion, the Botnet plugin should recognize that as botnet, but I could be wrong. Botnet is looking for hosts whose DNS looks like a dynamic or dial-up customer. So, if the host has no reverse DNS, the reverse DNS doesn't match forward DNS, or the forward DNS contains certain indicators (hostname contains its IP address, hostname contains words like "dial-up" or "dhcp"). That's what the Botnet plugin is looking for. Many thanks, John ! In my opinion, it looked also to the relationship between the relaying hosts, as (perhaps) seen in the sequence of Received headers, but I was wrong. Many thanks for pointing to my error. As I known, here is not pluging available which would do this job. Is my opinion wrong too here ? Thanks a lot ! Claude
Re: Botnet Plugin
Claude Frantz wrote: However, one thing to recognize is that botnet does not parse the Received headers themselves. Spam Assassin does, and puts them into psuedoheaders. Those pseudoheaders are what botnet processes. What exactly contain the pseudoheaders ? You could look at the code or look it up in the docs. I don't remember off the top of my head what the exact name and location of the perl hash is. Claude Frantz wrote: The Botnet Plugin is not able to recognize the following sequence: In my opinion, the Botnet plugin should recognize that as botnet, but I could be wrong. Botnet is looking for hosts whose DNS looks like a dynamic or dial-up customer. So, if the host has no reverse DNS, the reverse DNS doesn't match forward DNS, or the forward DNS contains certain indicators (hostname contains its IP address, hostname contains words like "dial-up" or "dhcp"). That's what the Botnet plugin is looking for. The host you gave in that message, ludwik.warynski.net , doesn't meet those characteristics.
Re: Botnet Plugin
Daniel J McDonald schrieb: On Fri, 2007-06-08 at 14:53 +0200, arni wrote: Can you tell me what you thin i'm doing wrong? [EMAIL PROTECTED] Desktop]$ host 87.118.96.151 151.96.118.87.in-addr.arpa domain name pointer ns.rds27912.i4e-server.de. [EMAIL PROTECTED] Desktop]$ host ns.rds27912.i4e-server.de. Host ns.rds27912.i4e-server.de not found: 3(NXDOMAIN) Compare with a good one: [EMAIL PROTECTED] Desktop]$ host 24.173.248.67 67.248.173.24.in-addr.arpa domain name pointer ns1.austinnetworkdesign.com. [EMAIL PROTECTED] Desktop]$ host ns1.austinnetworkdesign.com. ns1.austinnetworkdesign.com has address 24.173.248.67 stupid me, should have checked for a real problem beforehand - looks like a temporary problem at my sucky provider ... usually both forward and backward resolve properly. arni
Re: Botnet Plugin
Heute (08.06.2007/14:34 Uhr) schrieb arni, > Where do i find this botnet plugin? > arni http://people.ucsc.edu/~jrudd/spamassassin/ -- Viele Gruesse, Kind regards, Jim Knuth [EMAIL PROTECTED] ICQ #277289867 -- Zufalls-Zitat -- Schwerere als Luft? Flugmaschinen sind unmöglich. (Lord Kelvin, Präsident der Royal Society, 1895) -- Der Text hat nichts mit dem Empfaenger der Mail zu tun -- Virus free. Checked by NOD32 Version 2318 Build 10004 08.06.2007
Re: Botnet Plugin
Claude Frantz schrieb: Hi. This is the qmail-send program at rds27912.i4e-server.de. I'm afraid I wasn't able to deliver your message to the following addresses. This is a permanent error; I've given up. Sorry it didn't work out. <[EMAIL PROTECTED]>: 137.193.10.37 does not like recipient. Remote host said: 551 5.7.1 Sorry, but we do not accept email from systems whose hostnames cannot be validated. Your hostname with IP address 87.118.96.151 reports as being forged. Please fix your DNS and try again. Giving up on 137.193.10.37. --- Below this line is a copy of the message. Return-Path: <[EMAIL PROTECTED]> Received: (qmail 13318 invoked from network); 8 Jun 2007 14:34:02 +0200 Received: from p54a78418.dip0.t-ipconnect.de (HELO ?192.168.1.151?) ([EMAIL PROTECTED]) by ns2.rds27912.i4e-server.de with SMTP; 8 Jun 2007 14:34:02 +0200 Message-ID: <[EMAIL PROTECTED]> Date: Fri, 08 Jun 2007 14:34:03 +0200 From: arni <[EMAIL PROTECTED]> User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) Can you tell me what you thin i'm doing wrong?
Re: Botnet Plugin
Where do i find this botnet plugin? arni
Re: Botnet Plugin
John Rudd wrote: The diagnostic output for that message would have been useful. OK ! Here it is, a long as Botnet is concerned: [21114] dbg: Botnet: checking baddns [21114] dbg: Botnet: get_relay good RDNS [21114] dbg: Botnet: IP is '195.82.166.1' [21114] dbg: Botnet: RDNS is 'ludwik.warynski.net' [21114] dbg: Botnet: 'ludwik.warynski.net' resolves [21114] dbg: Botnet: 'ludwik.warynski.net' matches '195.82.166.1' [21114] dbg: Botnet: checking client words [21114] dbg: Botnet: client words regexp is(((\b|\d)cable(\b|\d))|((\b|\d)catv(\b|\d))|((\b|\d)ddns(\b|\d))|((\b|\d)dhcp(\b|\d))|((\b|\d)dial-?up(\b|\d))|((\b|\d)dip(\b|\d))|((\b|\d)(a|s|d(yn)?)?dsl(\b|\d))|((\b|\d)dynamic(\b|\d))|((\b|\d)modem(\b|\d))|((\b|\d)ppp(\b|\d))|((\b|\d)res(net|ident(ial)?)?(\b|\d))|((\b|\d)client(\b|\d))|((\b|\d)fixed(\b|\d))|((\b|\d)pool(\b|\d))|((\b|\d)static(\b|\d))|((\b|\d)user(\b|\d)))\S*\.\S+\.\S+$ [21114] dbg: Botnet: get_relay good RDNS [21114] dbg: Botnet: IP is '195.82.166.1' [21114] dbg: Botnet: RDNS is 'ludwik.warynski.net' [21114] dbg: Botnet: checking server words [21114] dbg: Botnet: server words regexp is(((\b|\d)mail(\b|\d))|((\b|\d)mta(\b|\d))|((\b|\d)mx(\b|\d))|((\b|\d)relay(\b|\d))|((\b|\d)smtp(\b|\d)))\S*\.\S+\.\S+$ [21114] dbg: Botnet: get_relay good RDNS [21114] dbg: Botnet: IP is '195.82.166.1' [21114] dbg: Botnet: RDNS is 'ludwik.warynski.net' [21114] dbg: Botnet: checking ip in hostname [21114] dbg: Botnet: get_relay good RDNS [21114] dbg: Botnet: IP is '195.82.166.1' [21114] dbg: Botnet: RDNS is 'ludwik.warynski.net' [21114] dbg: Botnet: checking nordns [21114] dbg: Botnet: get_relay good RDNS [21114] dbg: Botnet: IP is '195.82.166.1' [21114] dbg: Botnet: RDNS is 'ludwik.warynski.net' However, one thing to recognize is that botnet does not parse the Received headers themselves. Spam Assassin does, and puts them into psuedoheaders. Those pseudoheaders are what botnet processes. What exactly contain the pseudoheaders ? Claude Frantz wrote: The Botnet Plugin is not able to recognize the following sequence: In my opinion, the Botnet plugin should recognize that as botnet, but I could be wrong. Thanks a lot ! Claude
Re: Botnet Plugin
The diagnostic output for that message would have been useful. However, one thing to recognize is that botnet does not parse the Received headers themselves. Spam Assassin does, and puts them into psuedoheaders. Those pseudoheaders are what botnet processes. Claude Frantz wrote: The Botnet Plugin is not able to recognize the following sequence: Received: from ludwik.warynski.net (ludwik.warynski.net [195.82.166.1]) by BlueSrv.rz.unibw-muenchen.de (8.12.11.20060308/8.12.11) with ESMTP id l55L66tA013532 for <[EMAIL PROTECTED]>; Tue, 5 Jun 2007 23:06:07 +0200 Received: by 10.48.206.66 with SMTP id ZFdyrphavZIbn; Tue, 5 Jun 2007 23:06:12 +0200 (GMT) Received: by 192.168.193.149 with SMTP id iofMJgjleKxfwH.3044561993659; Tue, 5 Jun 2007 23:06:10 +0200 (GMT) Why ? Thanks a lot ! Claude
Re: Botnet Plugin
In what way is botnet not properly processing the headers in question? Claude Frantz wrote: Claude Frantz wrote: The Botnet Plugin is not able to recognize the following sequence: Another case: Received: from OrangeSrv.rz.unibw-muenchen.de ([127.0.0.1]) by localhost (OrangeSrv.rz.unibw-muenchen.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 12512-05 for <[EMAIL PROTECTED]>; Tue, 5 Jun 2007 20:24:21 +0200 (CEST) Received: from akx100.internetdsl.tpnet.pl (school-0.bts.net.pl [81.210.26.53]) by OrangeSrv.rz.unibw-muenchen.de (8.13.7/8.13.7) with ESMTP id l55IOHYs013110 for <[EMAIL PROTECTED]>; Tue, 5 Jun 2007 20:24:18 +0200 Received: from marcina-komp by qlwc.com with ASMTP id 8CE3E668 for <[EMAIL PROTECTED]>; Tue, 5 Jun 2007 20:24:58 - Received: from marcina-komp ([199.123.58.110]) by qlwc.com with ESMTP id 82A06E0E6EC7 for <[EMAIL PROTECTED]>; Tue, 5 Jun 2007 20:24:58 - And here the debugging output from SA: [29806] dbg: Botnet: checking baddns [29806] dbg: Botnet: get_relay good RDNS [29806] dbg: Botnet: IP is '81.210.26.53' [29806] dbg: Botnet: RDNS is 'school-0.bts.net.pl' [29806] dbg: Botnet: 'school-0.bts.net.pl' resolves [29806] dbg: Botnet: 'school-0.bts.net.pl' matches '81.210.26.53' [29806] dbg: Botnet: checking client words [29806] dbg: Botnet: client words regexp is(((\b|\d)cable(\b|\d))|((\b|\d)catv(\b|\d))|((\b|\d)ddns(\b|\d))|((\b|\d)dhcp(\b|\d))|((\b|\d)dial-?up(\b|\d))|((\b|\d)dip(\b|\d))|((\b|\d)(a|s|d(yn)?)?dsl(\b|\d))|((\b|\d)dynamic(\b|\d))|((\b|\d)modem(\b|\d))|((\b|\d)ppp(\b|\d))|((\b|\d)res(net|ident(ial)?)?(\b|\d))|((\b|\d)client(\b|\d))|((\b|\d)fixed(\b|\d))|((\b|\d)pool(\b|\d))|((\b|\d)static(\b|\d))|((\b|\d)user(\b|\d)))\S*\.\S+\.\S+$ [29806] dbg: Botnet: get_relay good RDNS [29806] dbg: Botnet: IP is '81.210.26.53' [29806] dbg: Botnet: RDNS is 'school-0.bts.net.pl' [29806] dbg: Botnet: checking server words [29806] dbg: Botnet: server words regexp is(((\b|\d)mail(\b|\d))|((\b|\d)mta(\b|\d))|((\b|\d)mx(\b|\d))|((\b|\d)relay(\b|\d))|((\b|\d)smtp(\b|\d)))\S*\.\S+\.\S+$ [29806] dbg: Botnet: get_relay good RDNS [29806] dbg: Botnet: IP is '81.210.26.53' [29806] dbg: Botnet: RDNS is 'school-0.bts.net.pl' [29806] dbg: Botnet: checking ip in hostname [29806] dbg: Botnet: get_relay good RDNS [29806] dbg: Botnet: IP is '81.210.26.53' [29806] dbg: Botnet: RDNS is 'school-0.bts.net.pl' [29806] dbg: Botnet: checking nordns [29806] dbg: Botnet: get_relay good RDNS [29806] dbg: Botnet: IP is '81.210.26.53' [29806] dbg: Botnet: RDNS is 'school-0.bts.net.pl'
Re: Botnet Plugin
Claude Frantz wrote: The Botnet Plugin is not able to recognize the following sequence: Another case: Received: from OrangeSrv.rz.unibw-muenchen.de ([127.0.0.1]) by localhost (OrangeSrv.rz.unibw-muenchen.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 12512-05 for <[EMAIL PROTECTED]>; Tue, 5 Jun 2007 20:24:21 +0200 (CEST) Received: from akx100.internetdsl.tpnet.pl (school-0.bts.net.pl [81.210.26.53]) by OrangeSrv.rz.unibw-muenchen.de (8.13.7/8.13.7) with ESMTP id l55IOHYs013110 for <[EMAIL PROTECTED]>; Tue, 5 Jun 2007 20:24:18 +0200 Received: from marcina-komp by qlwc.com with ASMTP id 8CE3E668 for <[EMAIL PROTECTED]>; Tue, 5 Jun 2007 20:24:58 - Received: from marcina-komp ([199.123.58.110]) by qlwc.com with ESMTP id 82A06E0E6EC7 for <[EMAIL PROTECTED]>; Tue, 5 Jun 2007 20:24:58 - And here the debugging output from SA: [29806] dbg: Botnet: checking baddns [29806] dbg: Botnet: get_relay good RDNS [29806] dbg: Botnet: IP is '81.210.26.53' [29806] dbg: Botnet: RDNS is 'school-0.bts.net.pl' [29806] dbg: Botnet: 'school-0.bts.net.pl' resolves [29806] dbg: Botnet: 'school-0.bts.net.pl' matches '81.210.26.53' [29806] dbg: Botnet: checking client words [29806] dbg: Botnet: client words regexp is(((\b|\d)cable(\b|\d))|((\b|\d)catv(\b|\d))|((\b|\d)ddns(\b|\d))|((\b|\d)dhcp(\b|\d))|((\b|\d)dial-?up(\b|\d))|((\b|\d)dip(\b|\d))|((\b|\d)(a|s|d(yn)?)?dsl(\b|\d))|((\b|\d)dynamic(\b|\d))|((\b|\d)modem(\b|\d))|((\b|\d)ppp(\b|\d))|((\b|\d)res(net|ident(ial)?)?(\b|\d))|((\b|\d)client(\b|\d))|((\b|\d)fixed(\b|\d))|((\b|\d)pool(\b|\d))|((\b|\d)static(\b|\d))|((\b|\d)user(\b|\d)))\S*\.\S+\.\S+$ [29806] dbg: Botnet: get_relay good RDNS [29806] dbg: Botnet: IP is '81.210.26.53' [29806] dbg: Botnet: RDNS is 'school-0.bts.net.pl' [29806] dbg: Botnet: checking server words [29806] dbg: Botnet: server words regexp is(((\b|\d)mail(\b|\d))|((\b|\d)mta(\b|\d))|((\b|\d)mx(\b|\d))|((\b|\d)relay(\b|\d))|((\b|\d)smtp(\b|\d)))\S*\.\S+\.\S+$ [29806] dbg: Botnet: get_relay good RDNS [29806] dbg: Botnet: IP is '81.210.26.53' [29806] dbg: Botnet: RDNS is 'school-0.bts.net.pl' [29806] dbg: Botnet: checking ip in hostname [29806] dbg: Botnet: get_relay good RDNS [29806] dbg: Botnet: IP is '81.210.26.53' [29806] dbg: Botnet: RDNS is 'school-0.bts.net.pl' [29806] dbg: Botnet: checking nordns [29806] dbg: Botnet: get_relay good RDNS [29806] dbg: Botnet: IP is '81.210.26.53' [29806] dbg: Botnet: RDNS is 'school-0.bts.net.pl' -- You will find the CA certificate and the CRL here: http://www.unibw.de/certs smime.p7s Description: S/MIME Cryptographic Signature
Botnet Plugin
The Botnet Plugin is not able to recognize the following sequence: Received: from ludwik.warynski.net (ludwik.warynski.net [195.82.166.1]) by BlueSrv.rz.unibw-muenchen.de (8.12.11.20060308/8.12.11) with ESMTP id l55L66tA013532 for <[EMAIL PROTECTED]>; Tue, 5 Jun 2007 23:06:07 +0200 Received: by 10.48.206.66 with SMTP id ZFdyrphavZIbn; Tue, 5 Jun 2007 23:06:12 +0200 (GMT) Received: by 192.168.193.149 with SMTP id iofMJgjleKxfwH.3044561993659; Tue, 5 Jun 2007 23:06:10 +0200 (GMT) Why ? Thanks a lot ! Claude
Re: Botnet Plugin Download Link?
Kevin W. Gagel schrieb: Matthias, Worked fine for me. Try it again if it still doesn't work for you - I've uploaded a copy to my public share at: http://mail.cnc.bc.ca/users/gagel/Botnet.tar Thx alot. It was a temporarily problem, it is good to have an alternative download location. I'll keep it there till next week. = Kevin W. Gagel Network Administrator Information Technology Services (250) 562-2131 local 448 My Blog: http://mail.cnc.bc.ca/blogs/gagel --- The College of New Caledonia, Visit us at http://www.cnc.bc.ca Virus scanning is done on all incoming and outgoing email. Anti-spam information for CNC can be found at http://avas.cnc.bc.ca --- -- Grüsse/Greetings MH Dont send mail to: [EMAIL PROTECTED] --
Re: Botnet Plugin Download Link?
Matthias, Worked fine for me. Try it again if it still doesn't work for you - I've uploaded a copy to my public share at: http://mail.cnc.bc.ca/users/gagel/Botnet.tar I'll keep it there till next week. - Original Message - From: Matthias Haegele <[EMAIL PROTECTED]> To: SpamAssassin Subject: Botnet Plugin Download Link? Date: Fri, 11 May 2007 09:59:11 +0200 >Hello! > >http://people.ucsc.edu/~jrudd/spamassassin/Botnet.tar > >link seems to be dead, since John Rudd is not listed at people, the link >perhaps moved? > >Any tips? > > >-- >Grüsse/Greetings >MH > > >Dont send mail to: [EMAIL PROTECTED] >-- > = Kevin W. Gagel Network Administrator Information Technology Services (250) 562-2131 local 448 My Blog: http://mail.cnc.bc.ca/blogs/gagel --- The College of New Caledonia, Visit us at http://www.cnc.bc.ca Virus scanning is done on all incoming and outgoing email. Anti-spam information for CNC can be found at http://avas.cnc.bc.ca ---
Re: Botnet Plugin Download Link?
Matthias Haegele wrote: Hello! http://people.ucsc.edu/~jrudd/spamassassin/Botnet.tar link seems to be dead, since John Rudd is not listed at people, the link perhaps moved? Any tips? That's still the right/current URL. Just looks like people.ucsc.edu might be down right now.
Botnet Plugin Download Link?
Hello! http://people.ucsc.edu/~jrudd/spamassassin/Botnet.tar link seems to be dead, since John Rudd is not listed at people, the link perhaps moved? Any tips? -- Grüsse/Greetings MH Dont send mail to: [EMAIL PROTECTED] --
Re: Botnet plugin
On Thu, 25 Jan 2007, Jason Little wrote: > > I was wondering about the maturity of the botnet plugin and where I can get > my hands on it again. I used an early version of it for a while but I > removed it because we didn't really need it and now it seems I need it again > with all the spammers finding a way to slip a 3.7 acore by spamassassin and > when I look at the headers its so obviously from a botnet. this one: http://people.ucsc.edu/~jrudd/spamassassin/ ? regards, Matthias
Botnet plugin
I was wondering about the maturity of the botnet plugin and where I can get my hands on it again. I used an early version of it for a while but I removed it because we didn't really need it and now it seems I need it again with all the spammers finding a way to slip a 3.7 acore by spamassassin and when I look at the headers its so obviously from a botnet. Jason Little Network Admin Mint Inc 156 Front St W suite 300 Toronto ON
Next Botnet plugin soon
I'm going to release 0.6 on Thursday or Friday. It will only have the following changes: 1) a typo in the .txt file. 2) I figured out how to get the long package name ( Mail::SpamAssassin::Plugin::Botnet ) to work. 3) A coworker found a genuine bug in the IP-in-Hostname check (it would match the same IP octet twice because I took a shortcut in my regular expression; this was almost never a worry, except, if, say, your ip address included an octet of ".1.", and your hostname had something like "101" in it ... not really a fair match, so I have written a slightly less optimal regular expression that makes sure any given octet is only matched once). (I'm using tonight and tomorrow to get some extra time in to be sure the bug fix works, etc.; that's why I'm waiting a _little_ longer before I release this bug fix) I may also do a slight code-reorganization for 0.7 that moves the actual checks into subroutines that can be called outside of spam assassin (ie. that don't use $pms arguments). Then include a "give me an IP address and I'll tell what rules it fails" utility in the tar file. This would also make it easy to use the exact same code directly in things like Mimedefang and such. So, the spamassassin based calls would take the $pms object, extract a relay IP addr and hostname (and test for things like which IP's to skip or pass, etc.). Then they would call the new subroutines with that extracted information. If you wanted to do the same checks from some other perl program, you'd have to feed it an IP address and hostname in the call. So, that's my plans for 0.6 and 0.7. Hopefully I wont need to do anything else before a 1.0 release.
Re: new Botnet plugin version soon
Rosenbaum, Larry M. wrote: From: Dennis Davis [mailto:[EMAIL PROTECTED] ... Question 2: someone asked why my module is "Botnet" instead of "Mail::SpamAssassin::Plugin::Botnet". The answer is: when I first started this (and this is/was my first SA Plugin authoring attempt), I tried that and it didn't work. If someone wants to look at it, and figure out how to make that work I prefer to have all the SpamAssassin plugins grouped together where the default install puts them. This is in the directory: /usr/local/libdata/perl5/site_perl/Mail/SpamAssassin/Plugin/ I would prefer to use the xxx/site_perl/Mail/SpamAssassin/Plugin for plugins that are packaged with SpamAssassin, and that any added-in plugins that I install separately go into /etc/mail/spamassassin. I also see no advantage to moving the "loadplugin" statement into the init.pre file unless there are rules in other .cf files that depend on the plugin. In other words, it's fine the way it is. My perspective is pretty much the same as Larry's. I prefer to keep "installed with the software" and "3rd party or locally installed/maintained" things in different locations. The site_perl stuff is what SpamAssassin installs with the software, and is not "3rd party" nor "locally installed/maintained". Therefore, if I can't make this change work while keeping the files in /etc/mail/spamassassin ... I'm not going to make that change. And, since, for some odd reason, I can't make the change work, I'm not going to break something that's working. Aesthetically I'd like the package name to be the full blown thing ... but practically speaking, "works" is better than "elegant". So, unless I suddenly realize why I couldn't get it to work the other way, this part is going to stay the way it is. (for those who might have insights, I'm currently running this on Mac OS X 10.3.(current), which has a funky perl that doesn't always put things in the right place ... so this might have worked if I was on 10.4.x, or when I switch to putting this on my Solaris machines (which happens Monday, actually))
Re: new Botnet plugin version soon
John Rudd wrote: > Question 2: someone asked why my module is "Botnet" instead of > "Mail::SpamAssassin::Plugin::Botnet". The answer is: when I first > started this (and this is/was my first SA Plugin authoring attempt), I > tried that and it didn't work. I just tested this, and it works perfectly fine for me. This is wjhat I did: 1: Replaced the line package Botnet; with the line package Mail::SpamAssassin::Plugin::Botnet; in Botnet.pm. I did not other changes at all in this file. 2: Replaced the line loadplugin Botnet /usr/local/etc/mail/spamassassin.plugins/Botnet.pm with the line loadplugin Mail::SpamAssassin::Plugin::Botnet /usr/local/etc/mail/spamassassin.plugins/Botnet.pm in plugins.pre (the file I load custom plugins in). I did no other changes to this file. I really don't know why this isn't working for you. It's strange. Regards /Jonas -- Jonas Eckerman, FSDB & Fruktträdet http://whatever.frukt.org/ http://www.fsdb.org/ http://www.frukt.org/
RE: new Botnet plugin version soon
> From: Dennis Davis [mailto:[EMAIL PROTECTED] > ... > > > Question 2: someone asked why my module is "Botnet" instead of > > "Mail::SpamAssassin::Plugin::Botnet". The answer is: when I > > first started this (and this is/was my first SA Plugin authoring > > attempt), I tried that and it didn't work. If someone wants to > > look at it, and figure out how to make that work > > I prefer to have all the SpamAssassin plugins grouped together where > the default install puts them. This is in the directory: > > /usr/local/libdata/perl5/site_perl/Mail/SpamAssassin/Plugin/ I would prefer to use the xxx/site_perl/Mail/SpamAssassin/Plugin for plugins that are packaged with SpamAssassin, and that any added-in plugins that I install separately go into /etc/mail/spamassassin. I also see no advantage to moving the "loadplugin" statement into the init.pre file unless there are rules in other .cf files that depend on the plugin. In other words, it's fine the way it is.
Re: new Botnet plugin version soon
On Thu, 30 Nov 2006, Jonas Eckerman wrote: > John Rudd wrote: > > > Question 1: Someone suggested that, for botnet_pass_domains, I not > > re-invent the wheel. SA already has several whitelist options > > (whitelist* and sare_whitelist* were specifically mentioned). They > > suggested that I leverage them. My first (two part) question is: > > Personally, I prefer to have a plugin be aböe to function independantly > from other addons (such as sare whitelists). > ... > If it can be done with meta rules you could just put a few commented > examples in Botnet.cf instead of having to expand the plugin. > > Or... You could make a separate file with contributed examples and > include that in the Botnet package. This way there could be meta rules > with DKIM, whitelists, p0f, ice cream, dark beer or whatever people send > you without cluttering Botnet.cf and without ýou having to test and take > responsibility for everything (just remember to put a disclaimer at the > top if it). I vote for the separate file / examples as well. Especially the examples or common ones to help us get a working system that handles general whitelisting as well. Per the botnet_pass_domains, this will be a great enhancement. Maybe you could collect false positives reported to you and include a "starting point" of common domains to exempt as well. It's tough to find out all the valid domains out there that still trip the botnet filter on your own. :) > Question 2: someone asked why my module is "Botnet" instead of "Mail::SpamAssassin::Plugin::Botnet". The current method is simple as you just drop the 2 files into /etc/mail/spamassassin and you're done. But, making it standard as long as it works is fine with me. Thanks for a great plugin! Rob
Re: new Botnet plugin version soon
John Rudd wrote the following on 11/30/2006 9:26 AM -0800: Jonas Eckerman wrote: John Rudd wrote: Question 2: someone asked why my module is "Botnet" instead of "Mail::SpamAssassin::Plugin::Botnet". The answer is: when I first started this (and this is/was my first SA Plugin authoring attempt), I tried that and it didn't work. That's odd. What errors did you get? When I change Botnet.pm to have: package Mail::SpamAssassin::Plugin::Botnet; use base 'Mail::SpamAssassin::Plugin'; and then change Botnet.cf to have loadplugin Mail::SpamAssassin::Plugin::Botnet /etc/mail/spamassassin/Botnet.pm I get these errors: [2797] warn: plugin: failed to create instance of plugin Mail::SpamAssassin::Plugin::Botnet: Can't locate object method "new" via package "Mail::SpamAssassin::Plugin::Botnet" (perhaps you forgot to load "Mail::SpamAssassin::Plugin::Botnet"?) at (eval 200) line 1. [2797] info: config: failed to parse line, skipping: botnet_pass_auth 0 [2797] info: config: failed to parse line, skipping: botnet_skip_ip ^127\.0\.0\.1$ [2797] info: config: failed to parse line, skipping: botnet_skip_ip ^10\..*$ (and it keeps going with an error for each of the config lines I have in Botnet.cf) If I go back to what's in the distribution, the errors go away and everything works fine. Here are the changes I made to init.pre and Botnet.pm and Botnet.cf: /etc/mail/spamassassin/init.pre loadplugin Mail::SpamAssassin::Plugin::Botnet /etc/mail/spamassassin/Botnet.pm /etc/mail/spamassassin/Botnet.pm package Mail::SpamAssassin::Plugin::Botnet; /etc/mail/spamassassin/Botnet.cf removed: loadplugin BotnetBotnet.pm added at top of file: ifplugin Mail::SpamAssassin::Plugin::Botnet added at end of file: endif And it works great. Bill
Re: new Botnet plugin version soon
Jonas Eckerman wrote: John Rudd wrote: Question 2: someone asked why my module is "Botnet" instead of "Mail::SpamAssassin::Plugin::Botnet". The answer is: when I first started this (and this is/was my first SA Plugin authoring attempt), I tried that and it didn't work. That's odd. What errors did you get? When I change Botnet.pm to have: package Mail::SpamAssassin::Plugin::Botnet; use base 'Mail::SpamAssassin::Plugin'; and then change Botnet.cf to have loadplugin Mail::SpamAssassin::Plugin::Botnet /etc/mail/spamassassin/Botnet.pm I get these errors: [2797] warn: plugin: failed to create instance of plugin Mail::SpamAssassin::Plugin::Botnet: Can't locate object method "new" via package "Mail::SpamAssassin::Plugin::Botnet" (perhaps you forgot to load "Mail::SpamAssassin::Plugin::Botnet"?) at (eval 200) line 1. [2797] info: config: failed to parse line, skipping: botnet_pass_auth 0 [2797] info: config: failed to parse line, skipping: botnet_skip_ip ^127\.0\.0\.1$ [2797] info: config: failed to parse line, skipping: botnet_skip_ip ^10\..*$ (and it keeps going with an error for each of the config lines I have in Botnet.cf) If I go back to what's in the distribution, the errors go away and everything works fine.
Re: new Botnet plugin version soon
John Rudd wrote: > Question 1: Someone suggested that, for botnet_pass_domains, I not > re-invent the wheel. SA already has several whitelist options > (whitelist* and sare_whitelist* were specifically mentioned). They > suggested that I leverage them. My first (two part) question is: Personally, I prefer to have a plugin be aböe to function independantly from other addons (such as sare whitelists). (I don't use ordinary whitelist commands in SA (when I whitelist something, I do it so that the filkter wiull not call SA at all).) Does the Botnet plugin really need any code at all to use the existing whitelists, or could this be done entirely with meta rules anyway? If it can be done with meta rules you could just put a few commented examples in Botnet.cf instead of having to expand the plugin. Or... You could make a separate file with contributed examples and include that in the Botnet package. This way there could be meta rules with DKIM, whitelists, p0f, ice cream, dark beer or whatever people send you without cluttering Botnet.cf and without ýou having to test and take responsibility for everything (just remember to put a disclaimer at the top if it). Or... You could just point out that meta rules are possible and let those who wants to read the SpamAssassin docs and make there own advanced rules. :-) Regards /Jonas -- Jonas Eckerman, FSDB & Fruktträdet http://whatever.frukt.org/ http://www.fsdb.org/ http://www.frukt.org/
Re: new Botnet plugin version soon
John Rudd wrote: > Question 2: someone asked why my module is "Botnet" instead of > "Mail::SpamAssassin::Plugin::Botnet". The answer is: when I first > started this (and this is/was my first SA Plugin authoring attempt), I > tried that and it didn't work. That's odd. What errors did you get? > If someone wants to look at it, and > figure out how to make that work (but still have the files located in > /etc/mail/spamassassin) I would happily incorporate it. It shoudl just work. I'll take my own p0f plugin as an exampl. This is copied from "/usr/local/etc/mail/spamassassin.plugins/p0fOS.pm": ---8<--- package Mail::SpamAssassin::Plugin::p0fOS; use base 'Mail::SpamAssassin::Plugin'; ---8<--- This is copied from "/usr/local/etc/mail/spamassassin/plugins.pre": ---8<--- loadplugin Mail::SpamAssassin::Plugin::p0fOS /usr/local/etc/mail/spamassassin.plugins/p0fOS.pm ---8<--- As you can see, my local configs are in "/usr/local/etc/mail/spamassassin", the plugin is placed in "/usr/local/etc/mail/spamassassin.plugins", and is named "Mail::SpamAssassin::Plugin::p0fOS". As long as I specify both the full name and full path when loading the plugin, it works just fine. Regards /Jonas -- Jonas Eckerman, FSDB & Fruktträdet http://whatever.frukt.org/ http://www.fsdb.org/ http://www.frukt.org/
RE: new Botnet plugin version soon
> Question 2: someone asked why my module is "Botnet" instead of > "Mail::SpamAssassin::Plugin::Botnet". The answer is: when I first > started this (and this is/was my first SA Plugin authoring > attempt), I > tried that and it didn't work. If someone wants to look at it, and > figure out how to make that work (but still have the files located in > /etc/mail/spamassassin) I would happily incorporate it. Use the loadplugin line to specify the location, for example, I do the following: loadplugin Mail::SpamAssassin::Plugin::ImageInfo c:/perl/site/etc/mail/spamassassin/ImageInfo.pm That way you can put the module anywhere and still have it called Mail::SpamAssasssin::Plugin::___ Bret
Re: new Botnet plugin version soon
On Thu, 30 Nov 2006, John Rudd wrote: > From: John Rudd <[EMAIL PROTECTED]> > To: users@spamassassin.apache.org, > CommuniGate Pro Discussions <[EMAIL PROTECTED]>, > MailScanner discussion <[EMAIL PROTECTED]> > Date: Thu, 30 Nov 2006 04:06:55 -0800 > Subject: new Botnet plugin version soon ... > Question 2: someone asked why my module is "Botnet" instead of > "Mail::SpamAssassin::Plugin::Botnet". The answer is: when I > first started this (and this is/was my first SA Plugin authoring > attempt), I tried that and it didn't work. If someone wants to > look at it, and figure out how to make that work I prefer to have all the SpamAssassin plugins grouped together where the default install puts them. This is in the directory: /usr/local/libdata/perl5/site_perl/Mail/SpamAssassin/Plugin/ on my OpenBSD boxes. So I altered Botnet.pm so the line: package Botnet; now reads: package Mail::SpamAssassin::Plugin::Botnet; and placed it in the above directory. The line: loadplugin BotnetBotnet.pm in /etc/mail/spamassassin/Botnet.cf was altered to: loadplugin Mail::SpamAssassin::Plugin::Botnet It works a treat. I did something similar for the FuzzyOcr.pm plugin. > (but still have the files located in /etc/mail/spamassassin) I > would happily incorporate it. Well, you *could* do this with soft links. But that would be a terrible hack :-( -- Dennis Davis, BUCS, University of Bath, Bath, BA2 7AY, UK [EMAIL PROTECTED] Phone: +44 1225 386101
Re: new Botnet plugin version soon
John, > a) do any of them have a small enough value that they wouldn't counter > botnet's default score of 5? Meaning, if I "do nothing" with respect to > those other whitelist mechanisms, they'll still "do the right thing" and > let the botnet hosts through, right? Not by default, although I set my SA-based whitelist scores at -4 (I only use a handful). > (for similar reasons I'm currently not going to look at making the > BOTNET meta rule's expression more complicated with references to DK and > DKIM; the DK scores in the base SA are scored at -100 and -7.5 ... that > seems useful enough to me; but I might look at putting in alternate meta > rule expressions that are commented out, if people really want me to; > that way people could just choose to comment and uncomment whatever > seems most appropriate for their situation) I 'whitelist' DK-verified yahoo and gmail mail at -2.5 (there is some spam coming from legitimate accounts there). It is also quite unlikely that verified yahoo or gmail mail would be coming from a botnet, so if BOTNET rules fired it would be almost certain false positive. Mark
RE: new Botnet plugin version soon
Suggestion: Rename your plugin to "AntiBotnet" (or something like that) Otherwise, I could see someone getting the "good guys" and "bad guys" mixed up when reading or hearing about this! Rob McEwen
new Botnet plugin version soon
Things I'm putting into the new Botnet version (which will be 0.5): 1) someone noticed that some MTA's (specifically CommuniGate Pro) don't put the relay's RDNS into the Received headers, and thus Botnet 0.4 always triggered "NORDNS" when run on that MTA. In the new version, if Botnet finds that the relay it's going to look at has no rdns in the pseudo-header, then the _first_ time it looks it will try to lookup the relay (and store it in the pseudo-header if it finds it; or store -1 if not). From then on, it will give the right answer for the other Botnet rules. This avoids the performance problem of "every Botnet rule does 1 or 2 DNS checks" that I tried to solve 1 or 2 versions ago, but does mean that at least 1 DNS check will be done (by the first Botnet rule that happens to get called) if the relay doesn't have RDNS. This might happen even if you have network checks turned off. If you're concerned about the small performance hit on this, then it might be a good idea to run a caching name server on the host where Botnet runs. (I had also considered only doing this if the user set a new config option, "botnet_lame_mta_rdns", to 1 ... but I thought I'd try this first) 2) As suggested, I've added "botnet_pass_domains" -- regular expressions, anchored to the end of the hostname string, that look for domains to exempt from Botnet checks. 3) I modifed the "IP in hostname" check slightly. It used to look for mixed deximal and hexidecimal octets in the hostname. This caused a small problem with the following Received header: Received: from badger07006.apple.com (badger07006.apple.com [17.254.6.173]) ("ad" is hexadecimal for "173", and you can see "006" right in there, therefore 2 octets are present in the hostname) To avoid this special case, I have made it so that it doesn't put the hexicecimal and decimal checks into the same regular expression. This could, however, slightly reduce Botnet's effectiveness. I'm going to re-evaluate it over time. (note: I have ALSO addressed this by putting apple\.com into the botnet_pass_domains example; using botnet_pass_domains or botnet_pass_ip might be the better way to address these special cases in the future, but I'm not sure yet) 4) I've added "mx" to the included botnet_serverwords. Technically this alone would exempt the ebay hosts that use "mxpool", so ebay wouldn't need a botnet_skip_domains entry ... but I also made such an entry for ebay. I'm not sure yet if "mx" is a good idea to have in botnet_serverwords though. 5) In the past, I only had the 127.* localhost IP address block, and the 10.* private IP address block in the example botnet_skip_ip config. From a suggestion I received, I've added the other two private IP blocks as well ( 192.168.* and 172.(16-31).* ). I have two questions: Question 1: Someone suggested that, for botnet_pass_domains, I not re-invent the wheel. SA already has several whitelist options (whitelist* and sare_whitelist* were specifically mentioned). They suggested that I leverage them. My first (two part) question is: a) do any of them have a small enough value that they wouldn't counter botnet's default score of 5? Meaning, if I "do nothing" with respect to those other whitelist mechanisms, they'll still "do the right thing" and let the botnet hosts through, right? b) clearly I've gone ahead and done botnet_pass_domains ... but part of me wants to "do both". So what is the right way to have Botnet recognize those other host/domain whitelisting mechanisms? I have no idea what the sare_whitelist entries look like, but I was thinking maybe I could do take the whitelist_from argument, the 2nd argument to whitelist_from_rcvd, and maybe the whitelist_from_spf argument, and munge them into a domain name to exempt. The catch is: if I do that, shouldn't I _also_ recognize the unwhitelist_* configs? That starts to get a bit hairy, IMO. For now, I'm not going to go down this path... but I'm interested in people's opinions about whether or not I should recognize whitelist*, sare_whitelist*, and unwhitelist* config options and somehow incorporate them into botnet_pass_domains. I'd also consider code snippets that would be compatible with the code I already have for Botnet::parse_config. My main hope, though, is that the scores for those mechanisms are already negative enough that they over-ride Botnet anyway. Given that the ones in the base SA are scored at -6, -15, or -100 ... I think that's a comfortable assumption on my part. I don't know if sare_whitelist fits into that or not, though. (for similar reasons I'm currently not going to look at making the BOTNET meta rule's expression more complicated with references to DK and DKIM; the DK scores in the base SA are scored at -100 and -7.5 ... that seems useful enough to me; but I might look at putting in alternate meta rule expressions that are commented out, if people really want me