CentOS - Mar 2007 - sendmail and rbl blocking - generating statistics

I have enabled the feature in sendmail.mc to check with spamhaus for
spammers. However since this block is being made at MTA level, I would
like to know is something can be done to obtain statistics of blocked
attemps.

thanks


-- 
------------------------------------------------------------
Erick Perez
Panama Sistemas
Integradores de Telefonia IP y Soluciones Para Centros de Datos
Panama, Republica de Panama
Cel Panama. +(507) 6694-4780
------------------------------------------------------------

On 14/03/07, Erick Perez <eaperezh at gmail.com>
wrote:
> I have enabled the feature in sendmail.mc to check with spamhaus for
> spammers. However since this block is being made at MTA level, I would
> like to know is something can be done to obtain statistics of blocked
> attemps.
What's the Sendmail feature called? And does it generate specific log
entries in /var/log/maillog? Could you provide a couple of sample log
lines?

It should be relatively easy to either add another script or modify
the Sendmail script ( /etc/log.d/scripts/services/sendmail - be sure
to use revision control or keep a pristine copy) to Logwatch to parse
specific entries out of maillog and to include a breakdown of them in
your daily Logwatch mails. Or to knock up an additional item in
Cacti/Munin or just use MRTG/RRDTool directly, to generate graphical
representations.

Will.

Erick Perez wrote:
> I have enabled the feature in sendmail.mc to check with spamhaus for
> spammers. However since this block is being made at MTA level, I would
> like to know is something can be done to obtain statistics of blocked
> attemps.

I don't know what you mean, are you talking about stats for your 
machine, or more globally?

I use postfix; the logwatch report tells me who's blocked.

I have other rules too:
ehlo <something>
Something has to be present, resolvable and not a simple name. Stops 
lots (and some, but not many legit senders, and they get warned by their 
server if it's working)

The sender's IP must resolve to a domain name.

Those rules probably stop more than the block lists.



-- 

Cheers
John

-- spambait
1aaaaaaa at coco.merseine.nu  Z1aaaaaaa at coco.merseine.nu

Please do not reply off-list

On Wed, 14 Mar 2007, Erick Perez wrote:
> I have enabled the feature in sendmail.mc to check with spamhaus for 
> spammers. However since this block is being made at MTA level, I 
> would like to know is something can be done to obtain statistics of 
> blocked attemps.
grep -c works. :-)

I specify a 554 SMTP error message in my spamhaus FEATURE setting:

FEATURE(`dnsbl', `sbl-xbl.spamhaus.org',
   `"554 Mail rejected -
http://www.spamhaus.org/query/bl?ip="$&{client_addr}')

Finding rejections is easy (add -c for counting):

   grep 'www.spamhaus.org/query/' /var/log/maillog

-- 
Paul Heinlein <> heinlein at madboa.com <> www.madboa.com

On Wed, March 14, 2007 01:38, Erick Perez wrote:
> I have enabled the feature in sendmail.mc to check with spamhaus for
> spammers. However since this block is being made at MTA level, I would
> like to know is something can be done to obtain statistics of blocked
> attemps.
I do this by parsing the logs:

Mar 14 09:31:36 io sendmail[19416]: ruleset=check_relay, arg1=[84.4.97.105],
arg2=127.0.0.2, relay=[84.4.97.105], reject=554 5.7.1 Rejected 84.4.97.105 found
in
bl.spamcop.net

Try doing a simple 'cat /var/log/maillog | grep -c check_relay'

For my server:

cat /var/log/maillog | grep checK_relay | grep -c spamhaus
836

cat /var/log/maillog | grep checK_relay | grep -c spamcop
120

cat /var/log/maillog | grep checK_relay | grep -c njabl
8

You could write a simple script to give you more details, like highest hit days.
I'm
*sure* there are log analyzers out there that do this. I've also seen a few
people
who have written script and stuffed the numbers in to RRDTool to visualize the
RBLs.

-Ryan

On Wed, March 14, 2007 14:08, Will McDonald wrote
(trimmed):
> On 14/03/07, Ryan Simpkins <centos at ryansimpkins.com> wrote:
>> Try doing a simple 'cat /var/log/maillog | grep -c check_relay'
>
> You can avoid the unnecessary 'cat' by just passing the filename to
grep directly:
>
> # grep -c 'checK_relay.*spamhaus' /var/log/maillog
> # grep -c 'checK_relay.*spamcop' /var/log/maillog
> # grep -c 'checK_relay.*njabl' /var/log/maillog
>
> Would probably be more efficient and faster, you can test with
'time' to verify
this. You're spawning one process 'grep', instead of three seperate
processes,
'cat, 'grep' and 'grep' again.

Am I using time right to measure it?

# time cat /var/log/maillog | grep check_relay | grep -c njabl
8

real    0m0.299s
user    0m0.289s
sys     0m0.009s

# time grep -c 'check_relay.*njabl' /var/log/maillog
8

real    0m0.404s
user    0m0.402s
sys     0m0.000s

Is the first 'time' measuring the whole one-liner, or just the time it
takes to 'cat'?

I also tried this:
time echo `cat /var/log/maillog | grep check_relay | grep -c njabl` 8

real    0m0.325s
user    0m0.312s
sys     0m0.012s

time echo `grep -c 'check_relay.*njabl' /var/log/maillog`
8

real    0m0.411s
user    0m0.408s
sys     0m0.002s

I ran these several times mixed back and forth to try and see if they were
flukes,
these numbers appear to be representitive of the average. What do you get on
your
system? Maybe passing the file name to grep gets faster as the file size
increases?

wc /var/log/maillog
  12323  142894 1588860 /var/log/maillog

I wonder if the issue here is actually the 'stuff*morestuff' as that
might be a more
expensive match:

time echo `grep -c 'check_relay' /var/log/maillog | grep njabl`


real    0m0.269s
user    0m0.263s
sys     0m0.006s

-Ryan