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

[Rainer Zocholl]

jamie at silverdream.org(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:
>> jamie at silverdream.org(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!