New spamhaus list not included
SpamHaus announced a new list a couple of days back - http://www.spamhaus.org/news.lasso?article=646 According to that page it returns results of 127.0.0.3 I just took a quick look at 20_dnsbl_tests.cf and it doesn't seem to include it yet. Currently we have: RCVD_IN_SBL - 127.0.0.2 RCVD_IN_XBL - 127.0.0.[45678] RCVD_IN_PBL - 127.0.0.1[01] -- Mike Cardwell - IT Consultant and LAMP developer Cardwell IT Ltd. (UK Reg'd Company #06920226) http://cardwellit.com/
Re: New spamhaus list not included
Mike Cardwell wrote: SpamHaus announced a new list a couple of days back - http://www.spamhaus.org/news.lasso?article=646 According to that page it returns results of 127.0.0.3 I just took a quick look at 20_dnsbl_tests.cf and it doesn't seem to include it yet. Currently we have: RCVD_IN_SBL - 127.0.0.2 RCVD_IN_XBL - 127.0.0.[45678] RCVD_IN_PBL - 127.0.0.1[01] It was announced 2 days ago.. are you really surprised it's not in SA proper yet? (2 days isn't really enough time to test a new RBL for accuracy) :-) That said, we do appreciate you passing along the announcement, and it looks like Alex committed a rule for it to his sandbox for testing shortly after your email and created bug 6215 to track it. So, the ball is now rolling. Thanks much.
Re: New spamhaus list not included
Matt Kettler wrote: SpamHaus announced a new list a couple of days back - http://www.spamhaus.org/news.lasso?article=646 According to that page it returns results of 127.0.0.3 I just took a quick look at 20_dnsbl_tests.cf and it doesn't seem to include it yet. Currently we have: RCVD_IN_SBL - 127.0.0.2 RCVD_IN_XBL - 127.0.0.[45678] RCVD_IN_PBL - 127.0.0.1[01] It was announced 2 days ago.. are you really surprised it's not in SA proper yet? (2 days isn't really enough time to test a new RBL for accuracy) :-) That said, we do appreciate you passing along the announcement, and it looks like Alex committed a rule for it to his sandbox for testing shortly after your email and created bug 6215 to track it. So, the ball is now rolling. Thanks much. Sure, I wasn't complaining or anything, I just wanted to make sure that it was being looked at. Personally, I've just updated RCVD_IN_SBL to match 127.0.0.[23] for now, but I wouldn't expect it to be added to the main distribution until it was properly tested. -- Mike Cardwell - IT Consultant and LAMP developer Cardwell IT Ltd. (UK Reg'd Company #06920226) http://cardwellit.com/
Re: spamd not logging
On 3-Oct-2009, at 23:54, Sahil Tandon wrote: On Sat, 03 Oct 2009, LuKreme wrote: My spammed.log file is empty: Do you mean spamd.log? Yes (sometimes auto-spelling correcting sucks) $ cat /var/log/spamd.log Oct 3 00:00:00 mail newsyslog[82079]: logfile turned over OK, so newsyslog(8) is working as expected. $ psa spam root 921 0.0 0.9 76268 4536 ?? Ss 26Sep09 5:04.07 /usr/local/bin/spamd -c -s /var/log/spamd.log -d -r /var/run/spamd/ spamd.pid (perl5.10.0) As documented in the spamd(1) man page: -s facility, --syslog=facilitySpecify the syslog facility So, specifly a syslog FACILITY instead of a FILENAME. See syslogd (8) and syslog.conf(5) man pages for more. So setting the -s to 'local1' and then setting syslog.conf to log local1.* to /var/log/spamd.log? root 26345 31.8 14.5 76612 74804 ?? Ss6:45AM 0:20.94 /usr/ local/bin/spamd -c -s local1 -d -r /var/run/spamd/spamd.pid (perl5.10.0) /etc/newsyslog.conf:/var/log/spamd.log 640 91 *@T00 J /etc/syslog.conf:local1.* /var/log/spamd.log OK, just waiting for a spam to come in and get past the RBL/HELO checks. Seems early Sunday morning are the worst time… -- If the #2 pencil is the most popular, why is it still #2?
Re: New spamhaus list not included
On 4-Oct-2009, at 04:31, Mike Cardwell wrote:
SpamHaus announced a new list a couple of days back -
http://www.spamhaus.org/news.lasso?article=646
According to that page it returns results of 127.0.0.3
I just took a quick look at 20_dnsbl_tests.cf and it doesn't seem to
include it yet. Currently we have:
RCVD_IN_SBL - 127.0.0.2
RCVD_IN_XBL - 127.0.0.[45678]
RCVD_IN_PBL - 127.0.0.1[01]
Can't you do something like this in local.cf:
# CSS is the Snowshoe Block List: http://www.spamhaus.org/css/
header RCVD_IN_CSS eval:check_rbl('zen-lastexternal',
'zen.spamhaus.org.', '127.0.0.3')
describe RCVD_IN_CSSReceived via a relay in Spamhaus CSS
tflags RCVD_IN_CSS net
score RCVD_IN_CSS 0.1
or something? (Me? I reject spamhaus matches at smtp)
--
I leave symbols to the symbol-minded - George Carlin
Re: New spamhaus list not included
On 10/4/2009 3:20 PM, LuKreme wrote:
On 4-Oct-2009, at 04:31, Mike Cardwell wrote:
SpamHaus announced a new list a couple of days back -
http://www.spamhaus.org/news.lasso?article=646
According to that page it returns results of 127.0.0.3
I just took a quick look at 20_dnsbl_tests.cf and it doesn't seem to
include it yet. Currently we have:
RCVD_IN_SBL - 127.0.0.2
RCVD_IN_XBL - 127.0.0.[45678]
RCVD_IN_PBL - 127.0.0.1[01]
Can't you do something like this in local.cf:
# CSS is the Snowshoe Block List: http://www.spamhaus.org/css/
header RCVD_IN_CSS eval:check_rbl('zen-lastexternal',
'zen.spamhaus.org.', '127.0.0.3')
describe RCVD_IN_CSSReceived via a relay in Spamhaus CSS
tflags RCVD_IN_CSS net
score RCVD_IN_CSS 0.1
or something? (Me? I reject spamhaus matches at smtp)
why lastexternal ?
would you expect ham traffic from those IPs? and want to loose deeper
header parsing?
Re: [SA] .cn Oddity
On 10/04/2009 12:21 AM, John Hardin wrote: On Sat, 3 Oct 2009, Warren Togami wrote: On 10/03/2009 07:50 PM, Adam Katz wrote: 8 is *extremely* important in Chinese culture. When running these tests, make sure that there is a good quantity of .cn TLD URIs in the ham before drawing any conclusions. Right, in adding things to the sandbox it does not necessarily mean I suggest they should become rules. I am mainly curious to see what the results say. Warning: autopromotion Is there a way to prevent autopromotion for a particular rule? Warren
Re: .cn Oddity
On Sun, 2009-10-04 at 09:59 -0400, Warren Togami wrote:
On 10/04/2009 12:21 AM, John Hardin wrote:
Right, in adding things to the sandbox it does not necessarily mean I
suggest they should become rules. I am mainly curious to see what the
results say.
Warning: autopromotion
Is there a way to prevent autopromotion for a particular rule?
Yep, using tflags nopublish, or explicitly naming the rule with a T_
prefix. Also see bug 5545 [1].
[1] https://issues.apache.org/SpamAssassin/show_bug.cgi?id=5545
--
char *t=\10pse\0r\0dtu...@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4;
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: New spamhaus list not included
On søn 04 okt 2009 12:31:37 CEST, Mike Cardwell wrote
SpamHaus announced a new list a couple of days back -
http://www.spamhaus.org/news.lasso?article=646
According to that page it returns results of 127.0.0.3
I just took a quick look at 20_dnsbl_tests.cf and it doesn't seem to
include it yet. Currently we have:
RCVD_IN_SBL - 127.0.0.2
RCVD_IN_XBL - 127.0.0.[45678]
RCVD_IN_PBL - 127.0.0.1[01]
local.cf
require_version 3.002005
ifplugin Mail::SpamAssassin::Plugin::DNSEval
# CSS is the Spamhaus Block List: http://www.spamhaus.org/css/
header RCVD_IN_CSS eval:check_rbl_sub('zen', '127.0.0.3')
describe RCVD_IN_CSSReceived via a relay in Spamhaus CSS
tflags RCVD_IN_CSS net
#reuse RCVD_IN_CSS
endif
--
xpoint
Re: New spamhaus list not included
On søn 04 okt 2009 15:20:09 CEST, LuKreme wrote
# CSS is the Snowshoe Block List: http://www.spamhaus.org/css/
header RCVD_IN_CSS eval:check_rbl('zen-lastexternal',
'zen.spamhaus.org.', '127.0.0.3')
you make another dns lookup here compared to what rule i maked :)
--
xpoint
Re: .cn Oddity
On Sun, 4 Oct 2009, Karsten Br?ckelmann wrote: On Sun, 2009-10-04 at 09:59 -0400, Warren Togami wrote: On 10/04/2009 12:21 AM, John Hardin wrote: Right, in adding things to the sandbox it does not necessarily mean I suggest they should become rules. I am mainly curious to see what the results say. Warning: autopromotion Is there a way to prevent autopromotion for a particular rule? Yep, using tflags nopublish, Done. Will be committed momentarily. -- 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 --- Warning Labels we'd like to see #1: If you are a stupid idiot while using this product you may hurt yourself. And it won't be our fault. --- Approximately 9152160 firearms legally purchased in the U.S. this year
Re: spamd not logging
On Sun, 04 Oct 2009, LuKreme wrote: As documented in the spamd(1) man page: -s facility, --syslog=facilitySpecify the syslog facility So, specifly a syslog FACILITY instead of a FILENAME. See syslogd (8) and syslog.conf(5) man pages for more. So setting the -s to 'local1' and then setting syslog.conf to log local1.* to /var/log/spamd.log? root 26345 31.8 14.5 76612 74804 ?? Ss6:45AM 0:20.94 /usr/local/bin/spamd -c -s local1 -d -r /var/run/spamd/spamd.pid (perl5.10.0) /etc/newsyslog.conf:/var/log/spamd.log 640 91 *@T00 J Once again, newsyslog.conf is for log ROTATION. /etc/syslog.conf:local1.* /var/log/spamd.log OK, just waiting for a spam to come in and get past the RBL/HELO checks. Seems early Sunday morning are the worst time… Unless you believe this is still a spamd issue, please send all follow-ups to a more appropriate mailing list. -- Sahil Tandon sa...@tandon.net
How to log sending IP in spamd
We use Spamassassin via spamc/spamd via procmail. In the maillog file, we see when there is spam, the message indicates a bunch of information. raddr shows up always as 127.0.0.1, which is our course our connection to SPAMD from our machine via procmail. Similarly, rhost is our machine. We are trying to tally up totals by sending IP of SPAM. So, none of the log messages show sending IP when used in this environment. How can we get spamd to log the sending ip? Alternatives? Steve
Re: New spamhaus list not included
On Sun, 04 Oct 2009 15:53:34 +0200 Yet Another Ninja sa-l...@alexb.ch wrote: why lastexternal ? would you expect ham traffic from those IPs? and want to loose deeper header parsing? Right, although I doubt this list is going to be much use for SpamAssassin. With zen being so popular, I think everything that can be caught with it will get caught at the smtp level . With SBL you get additional deep hits from spammers hiding behind open-relays and other exploited servers, but that seems unlikely with CSS.
Re: New spamhaus list not included
On Sunday, October 4, 2009, 1:55:55 PM, RW wrote: R Right, although I doubt this list is going to be much use for R SpamAssassin. With zen being so popular, I think everything that can R be caught with it will get caught at the smtp level . With SBL you get R additional deep hits from spammers hiding behind open-relays and other R exploited servers, but that seems unlikely with CSS. Zen includes the SBL. The SBL includes CSS. If you are blocking at the SMTP level using Zen, there is no point in doing additional lookups in SA. -- Best regards, Robert Braver rbra...@ohww.norman.ok.us
Re: spamd not logging
On 3-Oct-2009, at 23:54, Sahil Tandon wrote: As documented in the spamd(1) man page: -s facility, --syslog=facilitySpecify the syslog facility So, specifly a syslog FACILITY instead of a FILENAME. See syslogd (8) and syslog.conf(5) man pages for more. man spamd(1) says: facility is interpreted as a file name to log to if it contains any characters except a-z and 0-9. null disables logging completely (used internally). So, setting it to spamd.log should log to that file since it contains a '.' This does not appear to work as the man page documents. In fact, the examples lists: spamd -s ./mail # log to file ./mail It appears that the issue is that spamd gets confused when the logfile is rotated from man spamd(1): If logging to a file is enabled and that log file is rotated, the spamd server must be restarted with a SIGHUP. According to newsyslog.conf's comment section the syslogd process is signalled when the logfile is rotated, but I don't see anything about how to SIGHUP the spamd process when the logfile is rotated out from under it. -- I'm just like every modern woman trying to have it all. A loving husband, a family. I only wish I had more time to seek out the dark forces and join their hellish crusade.
Re: .cn Oddity
On Thu, 1 Oct 2009, Warren Togami wrote:
The Oddity I was pointing out at the beginning of the thread is not
prevalence of .cn URI's, but rather most of them appear to be exactly 8
characters long.
Are there any other .cn domain formats (like {8}.com.cn) that would be of
interest? I was trolling through a spam quarantine I'd forgoten about and
found a message containing this:
{domain}.cn
{domain}.com.cn
{domain}.net.cn
--
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
---
One difference between a liberal and a pickpocket is that if you
demand your money back from a pickpocket he will not question your
motives. -- William Rusher
---
Approximately 9157680 firearms legally purchased in the U.S. this year
Re: spamd not logging
On Sun, 04 Oct 2009, LuKreme wrote: On 3-Oct-2009, at 23:54, Sahil Tandon wrote: As documented in the spamd(1) man page: -s facility, --syslog=facilitySpecify the syslog facility So, specifly a syslog FACILITY instead of a FILENAME. See syslogd (8) and syslog.conf(5) man pages for more. man spamd(1) says: facility is interpreted as a file name to log to if it contains any characters except a-z and 0-9. null disables logging completely (used internally). So, setting it to spamd.log should log to that file since it contains a '.' This does not appear to work as the man page documents. In fact, the examples lists: spamd -s ./mail # log to file ./mail It appears that the issue is that spamd gets confused when the logfile is rotated from man spamd(1): If logging to a file is enabled and that log file is rotated, the spamd server must be restarted with a SIGHUP. According to newsyslog.conf's comment section the syslogd process is signalled when the logfile is rotated, but I don't see anything about how to SIGHUP the spamd process when the logfile is rotated out from under it. I'm not sure how you could SIGHUP spamd upon rotation, which is why I personally think it's better to specify a facility instead of a log file. One less thing to maintain. -- Sahil Tandon sa...@tandon.net
Re: .cn Oddity
On 10/04/2009 04:07 PM, John Hardin wrote:
On Thu, 1 Oct 2009, Warren Togami wrote:
The Oddity I was pointing out at the beginning of the thread is not
prevalence of .cn URI's, but rather most of them appear to be exactly
8 characters long.
Are there any other .cn domain formats (like {8}.com.cn) that would be
of interest? I was trolling through a spam quarantine I'd forgoten about
and found a message containing this:
{domain}.cn
{domain}.com.cn
{domain}.net.cn
I wouldn't bother. I only wanted to check the relative % of CN_EIGHT to
CN_URL because I found it strange that the majority of CN_URL had
exactly 8 characters.
In the end this rule is unsafe to use in production so it doesn't matter
much to check for even less prevalent matches that we can't use either.
BTW, I have commit access now. Mind if I move these rules from your
sandbox into my own sandbox?
Warren Togami
wtog...@redhat.com
Re: New spamhaus list not included
On Sunday, October 4, 2009, 1:55:55 PM, RW wrote: R Right, although I doubt this list is going to be much use for R SpamAssassin. With zen being so popular, I think everything that can R be caught with it will get caught at the smtp level . With SBL you get R additional deep hits from spammers hiding behind open-relays and other R exploited servers, but that seems unlikely with CSS. On 04.10.09 14:03, Robert Braver wrote: Zen includes the SBL. The SBL includes CSS. If you are blocking at the SMTP level using Zen, there is no point in doing additional lookups in SA. unless you are checking more than lastexternal which was discussed here and could be interesting. I guess, since it's included in SBL and not PBL, it should not be restricted to lastexternal, however I'd invite someone who would run masscheck for both cases. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. 2B|!2B, that's a question!
Re: New spamhaus list not included
RW a écrit : On Sun, 04 Oct 2009 15:53:34 +0200 Yet Another Ninja sa-l...@alexb.ch wrote: why lastexternal ? would you expect ham traffic from those IPs? and want to loose deeper header parsing? Right, although I doubt this list is going to be much use for SpamAssassin. With zen being so popular, I think everything that can be caught with it will get caught at the smtp level . well, - some people pull mail (fetchmail, getmail, ...) from servers that don't implement zen at smtp time. - some people receive mail via external relays/forwarders that don't implement zen at smtp time. - some people add some mailing list servers to their trusted net, so they may be in the situation above (relay/forwarder) With SBL you get additional deep hits from spammers hiding behind open-relays and other exploited servers, but that seems unlikely with CSS. true. they send directly, from what I've looked at.
Re: How to log sending IP in spamd
On Sun, 2009-10-04 at 11:46 -0700, Steve Fatula wrote: We use Spamassassin via spamc/spamd via procmail. In the maillog file, we see when there is spam, the message indicates a bunch of information. raddr shows up always as 127.0.0.1, which is our course our connection to SPAMD from our machine via procmail. Similarly, rhost is our machine. We are trying to tally up totals by sending IP of SPAM. So, none of the log messages show sending IP when used in this environment. How can we get spamd to log the sending ip? Alternatives? Steve Steve, are you looking for something like this: X-senderip: 213.240.247.107 X-asn: ASN-20911 X-cidr: 213.240.244.0/22 If so I can send you the formail recipes I use. Chris -- KeyID 0xE372A7DA98E6705C signature.asc Description: This is a digitally signed message part
Spam Eating Monkey?
http://spameatingmonkey.com Anyone have any experience using these DNSBL and URIBL's? Is anyone from this site on this list? I wonder if we should add these rules to the sandbox for masschecks as well. Warren Togami wtog...@redhat.com
Re: Spam Eating Monkey?
Warren Togami wrote: http://spameatingmonkey.com Anyone have any experience using these DNSBL and URIBL's? Is anyone from this site on this list? I wonder if we should add these rules to the sandbox for masschecks as well. Warren Togami wtog...@redhat.com I've been using them for a few weeks and I don't have stats but seems like a high quality list. Definitely worth testing.
Re: .cn Oddity
On Sun, 4 Oct 2009, Warren Togami wrote:
On 10/04/2009 04:07 PM, John Hardin wrote:
On Thu, 1 Oct 2009, Warren Togami wrote:
The Oddity I was pointing out at the beginning of the thread is not
prevalence of .cn URI's, but rather most of them appear to be exactly
8 characters long.
Are there any other .cn domain formats (like {8}.com.cn) that would be
of interest? I was trolling through a spam quarantine I'd forgoten about
and found a message containing this:
{domain}.cn
{domain}.com.cn
{domain}.net.cn
I wouldn't bother. I only wanted to check the relative % of CN_EIGHT to
CN_URL because I found it strange that the majority of CN_URL had exactly 8
characters.
In the end this rule is unsafe to use in production so it doesn't matter much
to check for even less prevalent matches that we can't use either.
OK
BTW, I have commit access now. Mind if I move these rules from your sandbox
into my own sandbox?
Go ahead.
--
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
---
I'm seriously considering getting one of those bright-orange prison
overalls and stencilling PASSENGER on the back. Along with the paper
slippers, I ought to be able to walk right through security.
-- Brian Kantor in a.s.r
---
Approximately 9164580 firearms legally purchased in the U.S. this year
Re: Spam Eating Monkey?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Warren Togami wrote: http://spameatingmonkey.com Anyone have any experience using these DNSBL and URIBL's? Is anyone from this site on this list? I wonder if we should add these rules to the sandbox for masschecks as well. Since someone is bound to ask I figure I'll state right now that I have no objections to the SEM lists being included in the masschecks. In fact, I'm quite curious. I would also recommend adding AnonWhois.org to the list. - --Blaine Fleming SEM Admin http://spameatingmonkey.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) iEYEARECAAYFAkrJTLYACgkQLp9/dJH6k+Mc4ACeII1l3SSA2y2hz30A7ulqzp1Q yWIAnjxIj63wAbqYDdzrU0DW/Rsj1eSz =X6Nx -END PGP SIGNATURE-
Re: Do I need to do anything to maintain MySQL?
On 10/03/09 20:16, quoth Benny Pedersen: On lør 03 okt 2009 23:41:41 CEST, Steven W. Orr wrote Thank you. I am still confused in one area: no problem These scripts do not touch the bayes_token table, and it is this table that has by far the most number of rows. i do not touch it for one reason is that it will autoflush oldest tokens, if the db gets to big you simply have to much tokens know in the db, its not a error I currently have over 23 rows in that table. Do I manage these myself, no this is part of how bayes works or is there something that is supposed to make this happen automatically? nope, my setup above is all needed to make it optimized, i could make a bug on this for 3.3.x but it will be nice others can confirm if i miss something :) I admit that I am confused by the man page for sa-learn because it seems to suggest that expiry (whatever that is) is performed there, but I just don't see anything that says exactly what to do. Also, the man page refers to a journal that I know nothing about. this is for non mysql setup imho I did some googling, and the more I read, the more apparent that the documentation is a little light. So here are the questions that I think are really the 800 pound elephant in the room: * If I do set bayes_auto_expire to 0 and I am using MySQL then does any run of sa-learn cause the expired rows of bayes_token to be removed if there are no corresponding rows that relate back to bayes_seen? * If I set bayes_auto_expire to 0, and I am using MySQL then do I need to run a cron job which does this? How often should I run it? sa-learn --force-expire --sync * I set bayes_sql_override_username to something. If I did not, then do I have to have a cron job as described above that runs as each user that is listed in bayes_vars.username? * If I set bayes_auto_expire to 1, then does every update of any row in the spamassassin database try to clean up these rows that could be removed? I'm hoping that I'm not ranting. Sorry. -- Time flies like the wind. Fruit flies like a banana. Stranger things have .0. happened but none stranger than this. Does your driver's license say Organ ..0 Donor?Black holes are where God divided by zero. Listen to me! We are all- 000 individuals! What if this weren't a hypothetical question? steveo at syslang.net signature.asc Description: OpenPGP digital signature
