Re: RelayChecker 0.3
On 17 Nov 2006, Michael Alan Dorman outgrape: I lowered the score from 6 to 4.5, though, and it's continued to be effective, while letting those emails through. 6 is an insane score for *any* rule, IMNSHO. -- `The main high-level difference between Emacs and (say) UNIX, Windows, or BeOS... is that Emacs boots quicker.' --- PdS
Re: RelayChecker 0.3
On Thu, 16 Nov 2006 17:56:21 -0800 Derek Harding [EMAIL PROTECTED] wrote: On Sun, 2006-11-12 at 17:26 -0800, John Rudd wrote: http://people.ucsc.edu/~jrudd/spamassassin/RelayChecker.tar I've been running this for a few days now and am finding it to be pretty effective, especially against the bots that are producing all the image spam. Currently it's running about 87.55% hit rate with only two false positives so far (one a company on adsl, the other a mail server with no reverse DNS). For reasons that I haven't investigated closely, I'm finding RelayChecker consistently tags mail from the dojo toolkit's mailing list as well as the catalyst toolkit's mailing list. I lowered the score from 6 to 4.5, though, and it's continued to be effective, while letting those emails through. Mike.
Re: RelayChecker 0.3
Michael Alan Dorman wrote: On Thu, 16 Nov 2006 17:56:21 -0800 Derek Harding [EMAIL PROTECTED] wrote: On Sun, 2006-11-12 at 17:26 -0800, John Rudd wrote: http://people.ucsc.edu/~jrudd/spamassassin/RelayChecker.tar I've been running this for a few days now and am finding it to be pretty effective, especially against the bots that are producing all the image spam. Currently it's running about 87.55% hit rate with only two false positives so far (one a company on adsl, the other a mail server with no reverse DNS). For reasons that I haven't investigated closely, I'm finding RelayChecker consistently tags mail from the dojo toolkit's mailing list as well as the catalyst toolkit's mailing list. I lowered the score from 6 to 4.5, though, and it's continued to be effective, while letting those emails through. Mike. Can you post the Received headers for messages from those two mailing lists? (maybe send them to me off-list) I'll figure out something to put in the readme file to help mitigate it. (someone else contacted me off list for a feature suggestion of keywords that indicate a host that should NOT be triggered, such as mail or smtp in the hostname; I'll be trying to work that into the next version too)
Re: RelayChecker 0.3
John Rudd wrote: Stuart Johnston wrote: Peter H. Lemieux wrote: Billy Huddleston wrote: Reverse DNS is a must. I'm surprised at how many people still haven't got that yet in the IT world.. (Consultants mostly..) It's not uncommon outside the industrialized world. Last few days I got a few false positives for a client that was corresponding with folks in the Caribbean. One of the few services I believe AOL provided the rest of us was deciding a few years' back not to accept mail from servers without reverse DNS. Suddenly lots of admins had to deal with the problem of correct server configuration because you couldn't fail to deliver mail to the millions of AOL users worldwide. Unfortunately, AOL only validates in one direction and some people only do the bare minimum. So, they only look to see that the IP address has a PTR record, but don't verify that the PTR record's hostname resolves back to the IP address? That's correct. You can test it here: http://postmaster.aol.com/tools/rdns.html You can put in for example: 209.74.97.115 whose rdns resolves back to a different IP. AOL specifically says: If the sender's domain is the only domain sending mail from a specific IP address, we recommend that the reverse DNS entry (PTR Record) match the domain name (A Record), but we do not require it.
Re: RelayChecker 0.3
Michael Alan Dorman wrote: On Thu, 16 Nov 2006 17:56:21 -0800 Derek Harding [EMAIL PROTECTED] wrote: On Sun, 2006-11-12 at 17:26 -0800, John Rudd wrote: http://people.ucsc.edu/~jrudd/spamassassin/RelayChecker.tar I've been running this for a few days now and am finding it to be pretty effective, especially against the bots that are producing all the image spam. Currently it's running about 87.55% hit rate with only two false positives so far (one a company on adsl, the other a mail server with no reverse DNS). For reasons that I haven't investigated closely, I'm finding RelayChecker consistently tags mail from the dojo toolkit's mailing list as well as the catalyst toolkit's mailing list. I just noticed that SourceForge's list sever has a kinda funky rdns. Can RelayChecker handle an alias in rdns? (66.35.250.225) It looks like neither of the lists you mention use SF but it might cause problems for other lists.
Re: RelayChecker 0.3
Stuart Johnston wrote: Michael Alan Dorman wrote: On Thu, 16 Nov 2006 17:56:21 -0800 Derek Harding [EMAIL PROTECTED] wrote: On Sun, 2006-11-12 at 17:26 -0800, John Rudd wrote: http://people.ucsc.edu/~jrudd/spamassassin/RelayChecker.tar I've been running this for a few days now and am finding it to be pretty effective, especially against the bots that are producing all the image spam. Currently it's running about 87.55% hit rate with only two false positives so far (one a company on adsl, the other a mail server with no reverse DNS). For reasons that I haven't investigated closely, I'm finding RelayChecker consistently tags mail from the dojo toolkit's mailing list as well as the catalyst toolkit's mailing list. I just noticed that SourceForge's list sever has a kinda funky rdns. Can RelayChecker handle an alias in rdns? (66.35.250.225) It looks like neither of the lists you mention use SF but it might cause problems for other lists. Off the top of my head, I don't know. I'll be sure to test it before the next release. John
Re: RelayChecker 0.3
On Sun, 2006-11-12 at 17:26 -0800, John Rudd wrote: http://people.ucsc.edu/~jrudd/spamassassin/RelayChecker.tar I've been running this for a few days now and am finding it to be pretty effective, especially against the bots that are producing all the image spam. Currently it's running about 87.55% hit rate with only two false positives so far (one a company on adsl, the other a mail server with no reverse DNS). Thanks, Derek
Re: RelayChecker 0.3
I wouldn't consider those false positives.. Just incorrectly configured /administrated servers.. Reverse DNS is a must. I'm surprised at how many people still haven't got that yet in the IT world.. (Consultants mostly..) Thanks, Billy - Original Message - From: Derek Harding [EMAIL PROTECTED] To: John Rudd [EMAIL PROTECTED] Cc: SpamAssassin Users users@spamassassin.apache.org Sent: Thursday, November 16, 2006 8:56 PM Subject: Re: RelayChecker 0.3 On Sun, 2006-11-12 at 17:26 -0800, John Rudd wrote: http://people.ucsc.edu/~jrudd/spamassassin/RelayChecker.tar I've been running this for a few days now and am finding it to be pretty effective, especially against the bots that are producing all the image spam. Currently it's running about 87.55% hit rate with only two false positives so far (one a company on adsl, the other a mail server with no reverse DNS). Thanks, Derek
Re: RelayChecker 0.3
Billy Huddleston wrote: Reverse DNS is a must. I'm surprised at how many people still haven't got that yet in the IT world.. (Consultants mostly..) It's not uncommon outside the industrialized world. Last few days I got a few false positives for a client that was corresponding with folks in the Caribbean. One of the few services I believe AOL provided the rest of us was deciding a few years' back not to accept mail from servers without reverse DNS. Suddenly lots of admins had to deal with the problem of correct server configuration because you couldn't fail to deliver mail to the millions of AOL users worldwide. Peter
Re: RelayChecker 0.3
Peter H. Lemieux wrote: Billy Huddleston wrote: Reverse DNS is a must. I'm surprised at how many people still haven't got that yet in the IT world.. (Consultants mostly..) It's not uncommon outside the industrialized world. Last few days I got a few false positives for a client that was corresponding with folks in the Caribbean. One of the few services I believe AOL provided the rest of us was deciding a few years' back not to accept mail from servers without reverse DNS. Suddenly lots of admins had to deal with the problem of correct server configuration because you couldn't fail to deliver mail to the millions of AOL users worldwide. Unfortunately, AOL only validates in one direction and some people only do the bare minimum.
Re: RelayChecker 0.3
Stuart Johnston wrote: Peter H. Lemieux wrote: Billy Huddleston wrote: Reverse DNS is a must. I'm surprised at how many people still haven't got that yet in the IT world.. (Consultants mostly..) It's not uncommon outside the industrialized world. Last few days I got a few false positives for a client that was corresponding with folks in the Caribbean. One of the few services I believe AOL provided the rest of us was deciding a few years' back not to accept mail from servers without reverse DNS. Suddenly lots of admins had to deal with the problem of correct server configuration because you couldn't fail to deliver mail to the millions of AOL users worldwide. Unfortunately, AOL only validates in one direction and some people only do the bare minimum. So, they only look to see that the IP address has a PTR record, but don't verify that the PTR record's hostname resolves back to the IP address?
Re: RelayChecker 0.3 (more overhead?)
Dylan Bouterse wrote: -Original Message- From: John Rudd [mailto:[EMAIL PROTECTED] Sent: Sunday, November 12, 2006 8:26 PM To: SpamAssassin Users Subject: RelayChecker 0.3 New version of RelayChecker. http://people.ucsc.edu/~jrudd/spamassassin/RelayChecker.tar Changes: - It's now in a single tar file. Put the tar file into your plugin directory, expand it, and all should be good. The tar file includes: COPYING- the GPL RelayChecker.txt - explanations of each rule and option RelayChecker.pm- the plugin, now with copyright info RelayChecker.cf- example cf file (you should check the file) - There is now an option, relaychecker_reduced_dns, which eliminates all extra DNS checks. Instead of the PTR check, it uses the rdns= part of the Untrusted Relays pseudo-header, and the RELAY_CHECKER_BADDNS test always returns 0. Is there anything about v 0.3 that would require more overhead than the initial version? I just implemented the new version and sa passed --lint with no errors but within 5-10 min of reloading amavis-new my smtp response time went to multiple seconds and the load on the box went to over 6. Renamed the RelayChecker.cf so it isn't read by sa and reloaded amavisd and back to normal. Any suggestions? Dylan There shouldn't be anything that makes it _more_ intensive than the previous versions. Have you tried the relaychecker_reduced_dns option? It might be that you're just doing a lot of DNS calls today. John
Re: RelayChecker 0.3 (more overhead?)
John Rudd wrote: Dylan Bouterse wrote: -Original Message- From: John Rudd [mailto:[EMAIL PROTECTED] Sent: Sunday, November 12, 2006 8:26 PM To: SpamAssassin Users Subject: RelayChecker 0.3 New version of RelayChecker. http://people.ucsc.edu/~jrudd/spamassassin/RelayChecker.tar Changes: - It's now in a single tar file. Put the tar file into your plugin directory, expand it, and all should be good. The tar file includes: COPYING- the GPL RelayChecker.txt - explanations of each rule and option RelayChecker.pm- the plugin, now with copyright info RelayChecker.cf- example cf file (you should check the file) - There is now an option, relaychecker_reduced_dns, which eliminates all extra DNS checks. Instead of the PTR check, it uses the rdns= part of the Untrusted Relays pseudo-header, and the RELAY_CHECKER_BADDNS test always returns 0. Is there anything about v 0.3 that would require more overhead than the initial version? I just implemented the new version and sa passed --lint with no errors but within 5-10 min of reloading amavis-new my smtp response time went to multiple seconds and the load on the box went to over 6. Renamed the RelayChecker.cf so it isn't read by sa and reloaded amavisd and back to normal. Any suggestions? Dylan There shouldn't be anything that makes it _more_ intensive than the previous versions. Have you tried the relaychecker_reduced_dns option? It might be that you're just doing a lot of DNS calls today. Oh.. wait, there IS something that could make it more intensive. Each test is going to do the PTR lookup on its own. So, instead of 1 or 2 DNS checks, it's going to do 5 (PTR in NORDNS, PTR in BADDNS, A in BADDNS, PTR in IPHOSNAME, PTR in KEYWORDS). That's per message. But, like I said, you can reduce that with the reduced_dns option. Then it should do 0 DNS checks.
RE: RelayChecker 0.3 (more overhead?)
-Original Message- From: John Rudd [mailto:[EMAIL PROTECTED] Sent: Monday, November 13, 2006 2:21 PM To: John Rudd Cc: Dylan Bouterse; users@spamassassin.apache.org Subject: Re: RelayChecker 0.3 (more overhead?) John Rudd wrote: Dylan Bouterse wrote: -Original Message- From: John Rudd [mailto:[EMAIL PROTECTED] Sent: Sunday, November 12, 2006 8:26 PM To: SpamAssassin Users Subject: RelayChecker 0.3 New version of RelayChecker. http://people.ucsc.edu/~jrudd/spamassassin/RelayChecker.tar Changes: - It's now in a single tar file. Put the tar file into your plugin directory, expand it, and all should be good. The tar file includes: COPYING- the GPL RelayChecker.txt - explanations of each rule and option RelayChecker.pm- the plugin, now with copyright info RelayChecker.cf- example cf file (you should check the file) - There is now an option, relaychecker_reduced_dns, which eliminates all extra DNS checks. Instead of the PTR check, it uses the rdns= part of the Untrusted Relays pseudo-header, and the RELAY_CHECKER_BADDNS test always returns 0. Is there anything about v 0.3 that would require more overhead than the initial version? I just implemented the new version and sa passed -- lint with no errors but within 5-10 min of reloading amavis-new my smtp response time went to multiple seconds and the load on the box went to over 6. Renamed the RelayChecker.cf so it isn't read by sa and reloaded amavisd and back to normal. Any suggestions? Dylan There shouldn't be anything that makes it _more_ intensive than the previous versions. Have you tried the relaychecker_reduced_dns option? It might be that you're just doing a lot of DNS calls today. Oh.. wait, there IS something that could make it more intensive. Each test is going to do the PTR lookup on its own. So, instead of 1 or 2 DNS checks, it's going to do 5 (PTR in NORDNS, PTR in BADDNS, A in BADDNS, PTR in IPHOSNAME, PTR in KEYWORDS). That's per message. But, like I said, you can reduce that with the reduced_dns option. Then it should do 0 DNS checks. Even after setting the reduced_dns option to 1 the load on the server stays high. I re-enabled AWL and my load stays low as long as I don't enable the RelayChecker. I get the following in the log::: Nov 13 15:51:23 p1-lk-mxfilter.power1.com /usr/sbin/amavisd[30169]: (30169-01) SMTP: NOTICE: client broke the connection without a QUIT () Nov 13 15:51:23 p1-lk-mxfilter.power1.com /usr/sbin/amavisd[30169]: (30169-01) extra modules loaded: /etc/mail/spamassassin/RelayChecker.pm Nov 13 15:51:23 p1-lk-mxfilter.power1.com /usr/sbin/amavisd[30169]: (30169-01) load: 100 %, total idle 0.000 s, busy 0.144 s Nov 13 15:51:23 p1-lk-mxfilter.power1.com /usr/sbin/amavisd[30169]: (30169-01) process_request: fileno sock=13, STDIN=0, STDOUT=1
Re: RelayChecker 0.3 (more overhead?)
Dylan, Even after setting the reduced_dns option to 1 the load on the server stays high. I re-enabled AWL and my load stays low as long as I don't enable the RelayChecker. I get the following in the log::: Nov 13 15:51:23 p1-lk-mxfilter.power1.com /usr/sbin/amavisd[30169]: (30169-01) extra modules loaded: /etc/mail/spamassassin/RelayChecker.pm Just a general note: 'extra modules loaded:' is seen with the first mail being processes by each child process, if it turns out that some modules were not pre-fetched by a master process. It is normal and is usually not a problem (except in chroot), except for some overhead if loading/compiling a module takes a long time. Starting with amavisd-new-2.4.3 it is possible to pre-compile such additional modules which got missed by SA initialization, by placing a list of such modules in amavisd.conf, e.g: @additional_perl_modules = qw( /etc/mail/spamassassin/RelayChecker.pm /usr/local/etc/mail/spamassassin/FuzzyOcr.pm /usr/local/etc/mail/spamassassin/ImageInfo.pm /usr/local/etc/mail/spamassassin/WebRedirect.pm String::Approx Net::HTTP Net::HTTP::Methods URI URI::http URI::_generic URI::_query URI::_server HTTP::Date HTTP::Headers HTTP::Message HTML::HeadParser HTTP::Request HTTP::Response HTTP::Status LWP LWP::Protocol LWP::Protocol::http LWP::UserAgent LWP::MemberMixin LWP::Debug ); From 2.4.3 RELEASE_NOTES: - added a global configuration variable @additional_perl_modules, which is a list of additional Perl module names or absolute file names that should be compiled/executed (by calling 'require') at a program startup time by a master parent process, before chroot-ing and before changing UID takes place. Its purpose is to pre-load additional non-standard SpamAssassin plugins and similar modules that a standard SpamAssassin initialization would miss, causing them to be loaded later by each child process, which is inefficient and may not work in a chrooted process. Mark
Re: RelayChecker 0.3
On Sun, Nov 12, 2006 at 05:26:10PM -0800, John Rudd wrote: New version of RelayChecker. http://people.ucsc.edu/~jrudd/spamassassin/RelayChecker.tar Changes: - It's now in a single tar file. Put the tar file into your plugin directory, expand it, and all should be good. The tar file includes: COPYING- the GPL RelayChecker.txt - explanations of each rule and option RelayChecker.pm- the plugin, now with copyright info RelayChecker.cf- example cf file (you should check the file) - The individual tests are now individual rules. Each has a score of .01 - The badrdns and baddns test are combined into one rule, RELAY_CHECKER_BADDNS - The RELAY_CHECKER rule is now a meta rule, with a score of 6. It is now set statically in the cf file instead of dynamically in the pm file. - The config options have changed a bit. You no longer set a skip preference for individual tests. Since the tests are now rules, you just set that rule to 0. - There is now an option, relaychecker_reduced_dns, which eliminates all extra DNS checks. Instead of the PTR check, it uses the rdns= part of the Untrusted Relays pseudo-header, and the RELAY_CHECKER_BADDNS test always returns 0. - The dynhostname and clienthostname tests have been combined and replaced by the RELAY_CHECKER_KEYWORDS rule. This uses a cf file option, relaychecker_keywords, which feeds this test with keywords to search for in the hostname. If you don't like certain keywords, just don't use them. Or you can add more keywords just by changing the cf file. - The iphostname check (now RELAY_CHECKER_IPHOSTNAME) now allows more than 1 character of separation between the octets (since some hosts have multiple characters), automatically pads a 0 for hex values less than 10 (to avoid tripping on words with ff or ee in them), and looks for decimal values that combine 2 or 3 of the octets. - I think the relaychecker_skip_ip, relaychecker_pass_ip, and relaychecker_pass_auth options had been in the previous release so I'm not going to explain them here. If I'm wrong, then the explanation is in the .txt file. I still haven't set it up to use Net::DNS. Not sure if I'm going to at this point, or not. Let me know if you have opinions, one way or the other, about it. I'm still interested in hearing about bug reports, feed back, etc. I think the main thing I have left for a 1.0 release is getting it into the wiki, assuming there aren't any major complaints, requests, nor bug reports. Though, I had contemplated renaming it to BotNetHunter, since that's what it's real goal is. But, not yet. If you have an opinion there, let me know. Hello, how do you install this? -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- Member - Liberal International This is [EMAIL PROTECTED] Ici [EMAIL PROTECTED] God Queen and country! Beware Anti-Christ rising! Lest we forget 11 Nov 2006
Re: RelayChecker 0.3
The Doctor wrote: On Sun, Nov 12, 2006 at 05:26:10PM -0800, John Rudd wrote: New version of RelayChecker. http://people.ucsc.edu/~jrudd/spamassassin/RelayChecker.tar Changes: - It's now in a single tar file. Put the tar file into your plugin directory, expand it, and all should be good. The tar file includes: COPYING- the GPL RelayChecker.txt - explanations of each rule and option RelayChecker.pm- the plugin, now with copyright info RelayChecker.cf- example cf file (you should check the file) - The individual tests are now individual rules. Each has a score of .01 - The badrdns and baddns test are combined into one rule, RELAY_CHECKER_BADDNS - The RELAY_CHECKER rule is now a meta rule, with a score of 6. It is now set statically in the cf file instead of dynamically in the pm file. - The config options have changed a bit. You no longer set a skip preference for individual tests. Since the tests are now rules, you just set that rule to 0. - There is now an option, relaychecker_reduced_dns, which eliminates all extra DNS checks. Instead of the PTR check, it uses the rdns= part of the Untrusted Relays pseudo-header, and the RELAY_CHECKER_BADDNS test always returns 0. - The dynhostname and clienthostname tests have been combined and replaced by the RELAY_CHECKER_KEYWORDS rule. This uses a cf file option, relaychecker_keywords, which feeds this test with keywords to search for in the hostname. If you don't like certain keywords, just don't use them. Or you can add more keywords just by changing the cf file. - The iphostname check (now RELAY_CHECKER_IPHOSTNAME) now allows more than 1 character of separation between the octets (since some hosts have multiple characters), automatically pads a 0 for hex values less than 10 (to avoid tripping on words with ff or ee in them), and looks for decimal values that combine 2 or 3 of the octets. - I think the relaychecker_skip_ip, relaychecker_pass_ip, and relaychecker_pass_auth options had been in the previous release so I'm not going to explain them here. If I'm wrong, then the explanation is in the .txt file. I still haven't set it up to use Net::DNS. Not sure if I'm going to at this point, or not. Let me know if you have opinions, one way or the other, about it. I'm still interested in hearing about bug reports, feed back, etc. I think the main thing I have left for a 1.0 release is getting it into the wiki, assuming there aren't any major complaints, requests, nor bug reports. Though, I had contemplated renaming it to BotNetHunter, since that's what it's real goal is. But, not yet. If you have an opinion there, let me know. Hello, how do you install this? 1) Put the tar file into whatever directory you use for plugins (ex: /etc/mail/spamassassin ) 2) cd into that directory 3) tar xpf RelayChecker.tar 4) if you use spam assassin through some persistent mechanism (spamd, mailscanner, a milter, etc.), then you'll need to restart that. Otherwise, if you just call it directly (not with spamc) through procmail, you should be fine.
RE: RelayChecker 0.3
Am I missing something or is the use of Sys::Syslog not necessary? I can't find a compatible Win32 build.. Though I didn't look all that hard for it, as the module seems to work correctly without it (from my limited testing). Thanks, Steven -Original Message- From: John Rudd [mailto:[EMAIL PROTECTED] Sent: Sunday, November 12, 2006 6:26 PM To: SpamAssassin Users Subject: RelayChecker 0.3 New version of RelayChecker. http://people.ucsc.edu/~jrudd/spamassassin/RelayChecker.tar Changes: - It's now in a single tar file. Put the tar file into your plugin directory, expand it, and all should be good. The tar file includes: COPYING- the GPL RelayChecker.txt - explanations of each rule and option RelayChecker.pm- the plugin, now with copyright info RelayChecker.cf- example cf file (you should check the file) - The individual tests are now individual rules. Each has a score of .01 - The badrdns and baddns test are combined into one rule, RELAY_CHECKER_BADDNS - The RELAY_CHECKER rule is now a meta rule, with a score of 6. It is now set statically in the cf file instead of dynamically in the pm file. - The config options have changed a bit. You no longer set a skip preference for individual tests. Since the tests are now rules, you just set that rule to 0. - There is now an option, relaychecker_reduced_dns, which eliminates all extra DNS checks. Instead of the PTR check, it uses the rdns= part of the Untrusted Relays pseudo-header, and the RELAY_CHECKER_BADDNS test always returns 0. - The dynhostname and clienthostname tests have been combined and replaced by the RELAY_CHECKER_KEYWORDS rule. This uses a cf file option, relaychecker_keywords, which feeds this test with keywords to search for in the hostname. If you don't like certain keywords, just don't use them. Or you can add more keywords just by changing the cf file. - The iphostname check (now RELAY_CHECKER_IPHOSTNAME) now allows more than 1 character of separation between the octets (since some hosts have multiple characters), automatically pads a 0 for hex values less than 10 (to avoid tripping on words with ff or ee in them), and looks for decimal values that combine 2 or 3 of the octets. - I think the relaychecker_skip_ip, relaychecker_pass_ip, and relaychecker_pass_auth options had been in the previous release so I'm not going to explain them here. If I'm wrong, then the explanation is in the .txt file. I still haven't set it up to use Net::DNS. Not sure if I'm going to at this point, or not. Let me know if you have opinions, one way or the other, about it. I'm still interested in hearing about bug reports, feed back, etc. I think the main thing I have left for a 1.0 release is getting it into the wiki, assuming there aren't any major complaints, requests, nor bug reports. Though, I had contemplated renaming it to BotNetHunter, since that's what it's real goal is. But, not yet. If you have an opinion there, let me know.
Re: RelayChecker 0.3
On Sun, Nov 12, 2006 at 06:06:53PM -0800, John Rudd wrote: The Doctor wrote: On Sun, Nov 12, 2006 at 05:26:10PM -0800, John Rudd wrote: New version of RelayChecker. http://people.ucsc.edu/~jrudd/spamassassin/RelayChecker.tar Changes: - It's now in a single tar file. Put the tar file into your plugin directory, expand it, and all should be good. The tar file includes: COPYING- the GPL RelayChecker.txt - explanations of each rule and option RelayChecker.pm- the plugin, now with copyright info RelayChecker.cf- example cf file (you should check the file) - The individual tests are now individual rules. Each has a score of .01 - The badrdns and baddns test are combined into one rule, RELAY_CHECKER_BADDNS - The RELAY_CHECKER rule is now a meta rule, with a score of 6. It is now set statically in the cf file instead of dynamically in the pm file. - The config options have changed a bit. You no longer set a skip preference for individual tests. Since the tests are now rules, you just set that rule to 0. - There is now an option, relaychecker_reduced_dns, which eliminates all extra DNS checks. Instead of the PTR check, it uses the rdns= part of the Untrusted Relays pseudo-header, and the RELAY_CHECKER_BADDNS test always returns 0. - The dynhostname and clienthostname tests have been combined and replaced by the RELAY_CHECKER_KEYWORDS rule. This uses a cf file option, relaychecker_keywords, which feeds this test with keywords to search for in the hostname. If you don't like certain keywords, just don't use them. Or you can add more keywords just by changing the cf file. - The iphostname check (now RELAY_CHECKER_IPHOSTNAME) now allows more than 1 character of separation between the octets (since some hosts have multiple characters), automatically pads a 0 for hex values less than 10 (to avoid tripping on words with ff or ee in them), and looks for decimal values that combine 2 or 3 of the octets. - I think the relaychecker_skip_ip, relaychecker_pass_ip, and relaychecker_pass_auth options had been in the previous release so I'm not going to explain them here. If I'm wrong, then the explanation is in the .txt file. I still haven't set it up to use Net::DNS. Not sure if I'm going to at this point, or not. Let me know if you have opinions, one way or the other, about it. I'm still interested in hearing about bug reports, feed back, etc. I think the main thing I have left for a 1.0 release is getting it into the wiki, assuming there aren't any major complaints, requests, nor bug reports. Though, I had contemplated renaming it to BotNetHunter, since that's what it's real goal is. But, not yet. If you have an opinion there, let me know. Hello, how do you install this? 1) Put the tar file into whatever directory you use for plugins (ex: /etc/mail/spamassassin ) 2) cd into that directory 3) tar xpf RelayChecker.tar 4) if you use spam assassin through some persistent mechanism (spamd, mailscanner, a milter, etc.), then you'll need to restart that. Otherwise, if you just call it directly (not with spamc) through procmail, you should be fine. You just may want to add this into an install.txt file . -- Member - Liberal International This is [EMAIL PROTECTED] Ici [EMAIL PROTECTED] God Queen and country! Beware Anti-Christ rising! Lest we forget 11 Nov 2006 -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: RelayChecker 0.3
The Doctor wrote: On Sun, Nov 12, 2006 at 06:06:53PM -0800, John Rudd wrote: The Doctor wrote: On Sun, Nov 12, 2006 at 05:26:10PM -0800, John Rudd wrote: New version of RelayChecker. http://people.ucsc.edu/~jrudd/spamassassin/RelayChecker.tar Changes: - It's now in a single tar file. Put the tar file into your plugin directory, expand it, and all should be good. The tar file includes: COPYING- the GPL RelayChecker.txt - explanations of each rule and option RelayChecker.pm- the plugin, now with copyright info RelayChecker.cf- example cf file (you should check the file) - The individual tests are now individual rules. Each has a score of .01 - The badrdns and baddns test are combined into one rule, RELAY_CHECKER_BADDNS - The RELAY_CHECKER rule is now a meta rule, with a score of 6. It is now set statically in the cf file instead of dynamically in the pm file. - The config options have changed a bit. You no longer set a skip preference for individual tests. Since the tests are now rules, you just set that rule to 0. - There is now an option, relaychecker_reduced_dns, which eliminates all extra DNS checks. Instead of the PTR check, it uses the rdns= part of the Untrusted Relays pseudo-header, and the RELAY_CHECKER_BADDNS test always returns 0. - The dynhostname and clienthostname tests have been combined and replaced by the RELAY_CHECKER_KEYWORDS rule. This uses a cf file option, relaychecker_keywords, which feeds this test with keywords to search for in the hostname. If you don't like certain keywords, just don't use them. Or you can add more keywords just by changing the cf file. - The iphostname check (now RELAY_CHECKER_IPHOSTNAME) now allows more than 1 character of separation between the octets (since some hosts have multiple characters), automatically pads a 0 for hex values less than 10 (to avoid tripping on words with ff or ee in them), and looks for decimal values that combine 2 or 3 of the octets. - I think the relaychecker_skip_ip, relaychecker_pass_ip, and relaychecker_pass_auth options had been in the previous release so I'm not going to explain them here. If I'm wrong, then the explanation is in the .txt file. I still haven't set it up to use Net::DNS. Not sure if I'm going to at this point, or not. Let me know if you have opinions, one way or the other, about it. I'm still interested in hearing about bug reports, feed back, etc. I think the main thing I have left for a 1.0 release is getting it into the wiki, assuming there aren't any major complaints, requests, nor bug reports. Though, I had contemplated renaming it to BotNetHunter, since that's what it's real goal is. But, not yet. If you have an opinion there, let me know. Hello, how do you install this? 1) Put the tar file into whatever directory you use for plugins (ex: /etc/mail/spamassassin ) 2) cd into that directory 3) tar xpf RelayChecker.tar 4) if you use spam assassin through some persistent mechanism (spamd, mailscanner, a milter, etc.), then you'll need to restart that. Otherwise, if you just call it directly (not with spamc) through procmail, you should be fine. You just may want to add this into an install.txt file . It was in the first bullet item of the announcement.. but, yeah, I've put it in a file named INSTALL and in RelayChecker.txt
Re: RelayChecker 0.3
You're right. Not necessary. Must have been something I had intended to use and use the SA debug output instead. I've taken it out of my sources. Wont be in the next release. Thanks! Steven Manross wrote: Am I missing something or is the use of Sys::Syslog not necessary? I can't find a compatible Win32 build.. Though I didn't look all that hard for it, as the module seems to work correctly without it (from my limited testing). Thanks, Steven -Original Message- From: John Rudd [mailto:[EMAIL PROTECTED] Sent: Sunday, November 12, 2006 6:26 PM To: SpamAssassin Users Subject: RelayChecker 0.3 New version of RelayChecker. http://people.ucsc.edu/~jrudd/spamassassin/RelayChecker.tar Changes: - It's now in a single tar file. Put the tar file into your plugin directory, expand it, and all should be good. The tar file includes: COPYING- the GPL RelayChecker.txt - explanations of each rule and option RelayChecker.pm- the plugin, now with copyright info RelayChecker.cf- example cf file (you should check the file) - The individual tests are now individual rules. Each has a score of .01 - The badrdns and baddns test are combined into one rule, RELAY_CHECKER_BADDNS - The RELAY_CHECKER rule is now a meta rule, with a score of 6. It is now set statically in the cf file instead of dynamically in the pm file. - The config options have changed a bit. You no longer set a skip preference for individual tests. Since the tests are now rules, you just set that rule to 0. - There is now an option, relaychecker_reduced_dns, which eliminates all extra DNS checks. Instead of the PTR check, it uses the rdns= part of the Untrusted Relays pseudo-header, and the RELAY_CHECKER_BADDNS test always returns 0. - The dynhostname and clienthostname tests have been combined and replaced by the RELAY_CHECKER_KEYWORDS rule. This uses a cf file option, relaychecker_keywords, which feeds this test with keywords to search for in the hostname. If you don't like certain keywords, just don't use them. Or you can add more keywords just by changing the cf file. - The iphostname check (now RELAY_CHECKER_IPHOSTNAME) now allows more than 1 character of separation between the octets (since some hosts have multiple characters), automatically pads a 0 for hex values less than 10 (to avoid tripping on words with ff or ee in them), and looks for decimal values that combine 2 or 3 of the octets. - I think the relaychecker_skip_ip, relaychecker_pass_ip, and relaychecker_pass_auth options had been in the previous release so I'm not going to explain them here. If I'm wrong, then the explanation is in the .txt file. I still haven't set it up to use Net::DNS. Not sure if I'm going to at this point, or not. Let me know if you have opinions, one way or the other, about it. I'm still interested in hearing about bug reports, feed back, etc. I think the main thing I have left for a 1.0 release is getting it into the wiki, assuming there aren't any major complaints, requests, nor bug reports. Though, I had contemplated renaming it to BotNetHunter, since that's what it's real goal is. But, not yet. If you have an opinion there, let me know.
