Bug#318731: [Logcheck-devel] Bug#318731: spamd rule does not work

2005-07-18 Thread Rainer Zocholl
[EMAIL PROTECTED](Jamie L. Penman-Smithson)  17.07.05 13:31


Your rule has a trailing space, 

i know that. Without it did not work either.

since all log messages have trailing
spaces stripped before they are processed, your rule will never match
anything. 

Sorry, i wasn't aware of that and throught something wiered inside logcheck.
That's why i file a bug.

Too i was not warned that testing rules with egrep -f 
is not recommandable/is senseless, because logcheck modifies the logfile reads.


Removing the trailing space should fix the problem:

^\w{3} [ :0-9]{11} [._[:alnum:]-]+ spamd\[[0-9]+\]: Argument \RBL\
isn't numeric in addition \(\+\)
at /usr/share/perl5/Mail/SpamAssassin/Conf.pm line 244.$

Yes! I wonder why it did not work some days before...


Finally, this message indicates a _PROBLEM_ with your spamassassin
configuration, ignoring it _will not_ make the problem disappear.

I assume it's problem in some users config...

I don't want littering logcheck mails with messages i
can't change. That's to dangerous as some day no one will
take a look into the file.

Ignoring errors is not a good strategy. See bug #3853 in SA's bugzilla
(which I found within 5 seconds using Google) 

I have several(!) times tried google and did not find any useful hints
or solution.

Which words did you use?
I tried Argument isn't numeric in addition etc. with spamd and without
and only see that others asking the same.

http://www2.list.logwatch.org:81/pipermail/logwatch/2004-February/000459.html
no access..
http://www.dclug.org.uk/archive/2004/09/msg00214.html
no answer
http://www.mailarchives.org/list/spam-assassin/msg/2004/11717
no answer
etc.


The error is very common.



which was the result of misconfiguration:

 --- Additional Comments From [EMAIL PROTECTED]  2004-10-01
 10:05 ---
 This type of issue has always been something like:

 score FOO_RULE RBL 3

 somewhere in the configuration files.  Could be in any of
 the /etc/mail/spamassassin/*.cf files, or in
 user_prefs, or anywhere your SA installation gets configuration data
 from.

Fix the problem in your SA configuration.

find the user with the wrong config! ;-)


Rainer



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#318731: [Logcheck-devel] Bug#318731: spamd rule does not work

2005-07-18 Thread Jamie L. Penman-Smithson
On Sun, 2005-07-17 at 20:19 +0200, Rainer Zocholl wrote:
 [EMAIL PROTECTED](Jamie L. Penman-Smithson)  17.07.05 13:31
 since all log messages have trailing
 spaces stripped before they are processed, your rule will never match
 anything. 
 
 Sorry, i wasn't aware of that and throught something wiered inside logcheck.
 That's why i file a bug.
 
 Too i was not warned that testing rules with egrep -f 
 is not recommandable/is senseless, because logcheck modifies the logfile 
 reads.

There's a paragraph in README.logcheck-database:

| To test new rules, you can grep your log file, and remove trailing
| space with something like this:
|
| sed -e 's/[[:space:]]*$//' /var/log/syslog | egrep \
| '^\w{3} [ :0-9]{11} oempc wwwoffled\[[0-9]+\]: \
| WWWOFFLE (On|Off)line\.$'
|
| If the log line is displayed, then your regex works.

 Finally, this message indicates a _PROBLEM_ with your spamassassin
 configuration, ignoring it _will not_ make the problem disappear.
 
 I assume it's problem in some users config...
 
 I don't want littering logcheck mails with messages i
 can't change. That's to dangerous as some day no one will
 take a look into the file.

Then find out which users config is causing the problem?

If your users config files are in the same directory, something like
egrep -H  RBL * might find the culprit. Or find / -name foobar.cf
-exec grep -H  RBL \{\} \;

That'll only work if your config files have identical names, if they are
named after the user, you could try something similar to:

cat /etc/passwd | egrep -v ^[[:alnum:]]+:x:[0-9]{1,2}:.*$ | cut -f 1
-d :  .users  for i in $(cat .users); do find /foo -name $i.cf
-exec grep -H  RBL \{\} \;; done ; rm .users

 Ignoring errors is not a good strategy. See bug #3853 in SA's bugzilla
 (which I found within 5 seconds using Google) 
 
 I have several(!) times tried google and did not find any useful hints
 or solution.
 
 Which words did you use?

Argument RBL isn't numeric in addition

 I tried Argument isn't numeric in addition etc. with spamd and without
 and only see that others asking the same.

You may or may not already know, but placing quotation marks around
words causes Google to search for the entire phrase[1], rather than
occurrences of the individual words.

The first result from that is relevant to your problem, as are most of
the other results from the first page.

[1] http://www.google.co.uk/help/basics.html#phrases

-- 
-Jamie L. Penman-Smithson [EMAIL PROTECTED]
 t: +44 1273 424795; f: +44 1273 424795
 PGP: C0A7 955E EED6 A309 23D7 863B C76A 26A3 F0DC FCA8
 never send mail to: [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part


Bug#318731: [Logcheck-devel] Bug#318731: spamd rule does not work

2005-07-18 Thread Rainer Zocholl
[EMAIL PROTECTED](Jamie L. Penman-Smithson)  18.07.05 14:38

Once upon a time Jamie L. Penman-Smithson  shaped the electrons to say...

On Sun, 2005-07-17 at 20:19 +0200, Rainer Zocholl wrote:
 [EMAIL PROTECTED](Jamie L. Penman-Smithson)  17.07.05 13:31
since all log messages have trailing
spaces stripped before they are processed, your rule will never
match anything.

 Sorry, i wasn't aware of that and throught something wiered inside
 logcheck. That's why i file a bug.

 Too i was not warned that testing rules with egrep -f
 is not recommandable/is senseless, because logcheck modifies the
 logfile reads.

There's a paragraph in README.logcheck-database:

Yes, i found that sentence meanwhile.
Previously i stopped reading because the part above did not
look very interessing and i thought that were all the same theme,
because there suddenly where no subtitles.

That's always the problem between the knowing (deverloper) and
the just only user to fidn teh right way of documenting.
(Logcheck documentation is really good, compared to several other OOS).
The developer knows that it is there, but the user have to read
tons and tons of text and try to weight what'S relevant and what can
be omitted/neglected..


A subtitle like

Testing Your New Rules
==

before that would have eaesd reading a lot!

| To test new rules, you can grep your log file, and remove trailing
| space with something like this:
|
| sed -e 's/[[:space:]]*$//' /var/log/syslog | egrep \
| '^\w{3} [ :0-9]{11} oempc wwwoffled\[[0-9]+\]: \
| WWWOFFLE (On|Off)line\.$'
|
| If the log line is displayed, then your regex works.

 I don't want littering logcheck mails with messages i
 can't change. That's to dangerous as some day no one will
 take a look into the file.

Then find out which users config is causing the problem?

Yes. And as long as i am searching, i wanted to suppress the message,
not to oversee important notes.


If your users config files are in the same directory, something like
egrep -H  RBL * might find the culprit. 
Or find / -name foobar.cf -exec grep -H  RBL \{\} \;

I tried searching RBL, but, qwww, did not find.
Maybe it was too late in that evening?


That'll only work if your config files have identical names, if they
are named after the user, you could try something similar to:

cat /etc/passwd | egrep -v ^[[:alnum:]]+:x:[0-9]{1,2}:.*$ | cut -f 1
-d :  .users  for i in $(cat .users); do find /foo -name $i.cf
-exec grep -H  RBL \{\} \;; done ; rm .users

I would not hesitate to run a grep over the entire disk.
The disk is only 80GB, so let it run 1h or maybe 2h.
It's a computer, it's his job, isn't it?


 Which words did you use?

Argument RBL isn't numeric in addition

I did too. Funny, or not so funny...
Sometimes i have the feeling googles knows who is searching ;-)



 I tried Argument isn't numeric in addition etc. with spamd and
 without and only see that others asking the same.

You may or may not already know, but placing quotation marks around
words causes Google to search for the entire phrase[1], rather than
occurrences of the individual words.

Yes, i added the  only here.
I too serach with RBL like you did.
Very wiered, tah i did not get any hit into the bugzilla of
spamassasin.


The first result from that is relevant to your problem, as are most of
the other results from the first page.

[1] http://www.google.co.uk/help/basics.html#phrases
   *~*!
My google jumps to google.de...regardless which language i choose.
And it's known that google is censoring the result country specific.
Maybe the censorment detect bad words in your URL?


But we are going offtopic, and the problem is solved!
Thanks a lot!




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#318731: [Logcheck-devel] Bug#318731: spamd rule does not work

2005-07-17 Thread Jamie L. Penman-Smithson
package logcheck
merge 317642 318731
tags 318731 wontfix
thanks

On Sun, 2005-07-17 at 12:33 +0200, Rainer Zocholl wrote:
 Package: logcheck   
 Version: most recent stable

Use apt to find the version number, most recent stable is pretty
useless.

Don't open multiple bug reports about the same issue. There is already
#317642. This isn't a problem with logcheck, it's a problem with _your
own_ rules, therefore this isn't a bug and the BTS isn't really the best
place, there's the logcheck-users mailing list which would be better.

Read README.logcheck-database, it explains, in detail, how to write
rules and how to test them correctly.

 i can't block the spamd warning.
 
 Why?

Your rule has a trailing space, since all log messages have trailing
spaces stripped before they are processed, your rule will never match
anything. Removing the trailing space should fix the problem:

^\w{3} [ :0-9]{11} [._[:alnum:]-]+ spamd\[[0-9]+\]: Argument \RBL\
isn't numeric in addition \(\+\)
at /usr/share/perl5/Mail/SpamAssassin/Conf.pm line 244.$

Finally, this message indicates a _PROBLEM_ with your spamassassin
configuration, ignoring it _will not_ make the problem disappear.
Ignoring errors is not a good strategy. See bug #3853 in SA's bugzilla
(which I found within 5 seconds using Google) which was the result of
misconfiguration:

 --- Additional Comments From [EMAIL PROTECTED]  2004-10-01 10:05
 ---
 This type of issue has always been something like:
 
 score FOO_RULE RBL 3
 
 somewhere in the configuration files.  Could be in any of
 the /etc/mail/spamassassin/*.cf files, or in
 user_prefs, or anywhere your SA installation gets configuration data
 from.

Fix the problem in your SA configuration.

-- 
-Jamie L. Penman-Smithson [EMAIL PROTECTED]
 t: +44 1273 424795; f: +44 1273 424795
 PGP: C0A7 955E EED6 A309 23D7 863B C76A 26A3 F0DC FCA8
 never send mail to: [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part