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
On 14/03/07, Erick Perez eaperezh@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.
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=%22$&%7Bclient_addr%7D')
Finding rejections is easy (add -c for counting):
grep 'www.spamhaus.org/query/' /var/log/maillog
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 14/03/07, Ryan Simpkins centos@ryansimpkins.com wrote:
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'
You can avoid the unnecessary 'cat' by just passing the filename to grep directly:
# grep -c check_relay /var/log/maillog
This *should* be quicker, especially in looping constructs.
For my server:
cat /var/log/maillog | grep checK_relay | grep -c spamhaus 836
Again:
# 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.
Will.
Will McDonald wrote:
On 14/03/07, Ryan Simpkins centos@ryansimpkins.com wrote:
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'
You can avoid the unnecessary 'cat' by just passing the filename to grep directly:
# grep -c check_relay /var/log/maillog
This *should* be quicker, especially in looping constructs.
For my server:
cat /var/log/maillog | grep checK_relay | grep -c spamhaus 836
Again:
# 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.
It might be quicker, but that doesn't make it more efficient;-)
I often "evolve" my commandlines (I commonly use one that's 500+ characters long) and if I don't start with a cat I often wish I did:-/
On 14/03/07, John Summerfield debian@herakles.homelinux.org wrote:
Will McDonald wrote: It might be quicker, but that doesn't make it more efficient;-)
And that's why I mentioned it'd be wise to test :) I know things are never cut 'n dried and it depends on log makeup, datasets and whatnot. There's always dozens of ways to do things and no one way is perfect.
I often "evolve" my commandlines (I commonly use one that's 500+ characters long) and if I don't start with a cat I often wish I did:-/
I can't think of a single instance of needing to 'cat | somethingelse' unless 'somethingelse' doesn't accept STDIN unless explicitly told to. I could obviously be missing some corner case or just be ill educated? :)
Will.
Will McDonald wrote:
On 14/03/07, John Summerfield debian@herakles.homelinux.org wrote:
Will McDonald wrote: It might be quicker, but that doesn't make it more efficient;-)
And that's why I mentioned it'd be wise to test :) I know things are never cut 'n dried and it depends on log makeup, datasets and whatnot. There's always dozens of ways to do things and no one way is perfect.
Or even best for everyone.
I often "evolve" my commandlines (I commonly use one that's 500+ characters long) and if I don't start with a cat I often wish I did:-/
I can't think of a single instance of needing to 'cat | somethingelse' unless 'somethingelse' doesn't accept STDIN unless explicitly told to. I could obviously be missing some corner case or just be ill educated? :)
cat /var/log/messages | grep is more easily changed to include another file cat /var/log/messages{.0,} | grep than grep cat /var/log/messages to grep -h cat /var/log/messages{.0,} | grep -h Note, I'm often typing through a modem and have to contend with unpredictable response times.
Even worse is changing to include compressed files: (gunzip -dc /var/log/messages.{4,3,2,1}.gz;cat /var/log/messages{.0,})\ | grep
I need to do this kind of thing fairly often.
--- John Summerfield debian@herakles.homelinux.org wrote:
Will McDonald wrote:
On 14/03/07, John Summerfield
debian@herakles.homelinux.org wrote:
Will McDonald wrote: It might be quicker, but that doesn't make it
more efficient;-)
And that's why I mentioned it'd be wise to test :)
I know things are
never cut 'n dried and it depends on log makeup,
datasets and whatnot.
There's always dozens of ways to do things and no
one way is perfect.
Or even best for everyone.
I often "evolve" my commandlines (I commonly use
one that's 500+
characters long) and if I don't start with a cat
I often wish I did:-/
I can't think of a single instance of needing to
'cat | somethingelse'
unless 'somethingelse' doesn't accept STDIN unless
explicitly told
to. I could obviously be missing some corner case
or just be ill
educated? :)
cat /var/log/messages | grep is more easily changed to include another file cat /var/log/messages{.0,} | grep than grep cat /var/log/messages to grep -h cat /var/log/messages{.0,} | grep -h Note, I'm often typing through a modem and have to contend with unpredictable response times.
Even worse is changing to include compressed files: (gunzip -dc /var/log/messages.{4,3,2,1}.gz;cat /var/log/messages{.0,})\ | grep
does zcat for looking at compressed files work on linux? i know it use to work on HP-UX a while back. instead of uncompressing the file and then reading it. I have not used it for a while so dont hold me to it.
I need to do this kind of thing fairly often.
--
Cheers John
-- spambait 1aaaaaaa@coco.merseine.nu Z1aaaaaaa@coco.merseine.nu
Please do not reply off-list _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Steven
"On the side of the software box, in the 'System Requirements' section, it said 'Requires Windows or better'. So I installed Linux."
-
Erick Perez -
John Summerfield -
Paul Heinlein -
Ryan Simpkins -
Steven Vishoot -
Will McDonald