[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: blacklists



On Thu, Dec 09, 2004 at 11:27:27AM +1100, Russell Coker wrote:
> On Thursday 09 December 2004 01:12, Craig Sanders <cas@taz.net.au> wrote:
> > the log file noise issue is important to me - i've recently started
> > monitoring mail.log and adding iptables rules to block smtp connections
> > from client IPs that commit various spammish-looking crimes against my
> > system.  
> 
> Interesting.  Do you plan to package it for Debian?

nope, it's just a trivial script - and one that's probably dangerous to use if
you don't understand what it's doing, and i don't plan on documenting it beyond
comments in the script itself.  in short, it's a toy for me.

if you want to see it, look in http://taz.net.au/postfix/scripts/

it's called watch-maillog.pl

there's a bunch of other postfix related scripts in there.

you may also like qvmenu.pl, a curses-based postfix queue browser that i wrote.
it allows you to pipe queued messages into less or urlview, select multiple
messages and delete, hold, unhold or re-queue them (i.e. a wrapper around
postsuper).  pretty simple to add new features...as with most of my scripts, i
write for readability rather than optimised speed.

i work on this occasionally, and add new stuff as i need it....e.g. there's a
half-implemented "bounce to sa-spam/sa-ham alias" feature....that's because i
have a header_checks rule to HOLD all mail with an SA score over 10.  this is
the reason i wrote qvmenu.pl in the first place.  false-positives i just
unhold.  spam, i usually view & urlview them to get fodder for my SA &
body_checks rules, then delete them.  i also want to be able to bounce them to
sa-spam or sa-ham (sa-learn aliases on my system).   i'll finish that off when
i get time.

because it calls mailq to get the queue listing, it's probably too slow to use
on any system with thousands of messages in the queue.  i've used it on systems
with hundreds, and found it to be OK.  actually, i doubt if it would be much
faster even if it trawled the queue directories itself - mailq isn't exactly
inefficient and bloated.

craig

-- 
craig sanders <cas@taz.net.au>           (part time cyborg)



Reply to: