On Tue, 2002-02-12 at 08:58, Martin Cameron wrote:
> However, the exercise got me to thinking - the cause of the flood in the
> input directory was spam from a few, easily identified sources. I wanted
> to go through the input directory regularly and get rid of any crap from
> these pests.
OK, several problems here than others have referred to, I'm going to
comment on a couple of other issues that other people haven't touched as
yet....
> open(OUTFILE, ">>file");
> foreach $address(@banned)
> {
> chop $address;
> print "$address\n";
> system("egrep '$address' 1* >> file");
> }
> close OUTFILE;
This scales badly as you scan the whole spool for each word in your
block list. Scanning the messages once against all the stop words
would be better - do it directly in perl.
> foreach $row(@db)
> {
> chop $row;
> @data=split/:/,$row;
> print "$data[0]\n";
> system("rm $data[0] -f");
> }
Each exim message consists of 2 (or possibly 3, but there is unlikely to
be a delivery journal in process here) files within the exim queue.
Your script is deleting just one of those, probably the header file, so
you now have a broken queue and a pile of data files in the queue with
no association.
In general its a very bad idea to manually mess around in an
application's data area unless you are really really sure its safe. In
this case its not at all.
Your best bet is to clear the queue of frozen stuff using something like
this:-
mailq | fgrep '*** frozen ***' | awk '{print $3}' | xargs exim -Mrm
Make sure future stuff doesn't build up by using recipient_verify and
ideally sender_verify too.
Nigel.
--
[ Nigel Metheringham Nigel.Metheringham@??? ]
[ Phone: +44 1423 850000 Fax +44 1423 858866 ]
[ - Comments in this message are my own and not ITO opinion/policy - ]
