[pmmail-list] SPAM filtering with PROGRAM.<..\UTIL\CK_blacklist.cmd>

[L.Willms]

On Wed, 22 Jan 2003 12:09:45 -0600 (CST), Maynard Riley wrote:

> >  I already had second thoughts when I wrote the installer which 
> >installs the filter into all accounts with status "Enabled" as the 
> >default... I should do something about it... 
> 
> I've got it working OK without the installer by putting it into 
> pmmail\..\util\
> and creating a complex filter of:
> PROGRAM.<F:\tcpip\southsde\Util\CK_blacklist.cmd>="Spam-Warning"

   Funny ... you use the same subdirectory "southsde" as I do... 

> 
> Your readme.txt could indicate these manual installation instructions
> as an option to your installer, without really changing the installer.

  I might do both. 

  I think of a PM based installer (using DrDialog) which presents the 
list of existing accounts for the user to select where to install or at 
least where to install with "Enabled" ticked. With your 45 accounts, 
this might become e looong dialogue, though... 

> I see *.ret files accumulating in pmmail\temp\ for each message
> checked; those puppies could add up in relatively short order on an
> active system.

   PMMail is cleaning up the TEMP directory from time to time, actually 
it gets deleted and recreated, but I don't know under which conditions. 
It seems, at least at startup. The TEMP directory on my system has been 
created today at about 11 o'clock. That is about the time when I had 
restarted PMMail after upgrading to 2.10.2382. 

> 
> I see pmmail\..\util\ck_blacklist.log accumulating 8 line entries for
> each positive return. 

   I have somewhere a program called TAIL in one of the Unix ports, 
which creates a new file from the last xxx lines in a file. 

 
> I haven't checked but am curious. In the case of a message with 
several
> Received lines, and more than one IP which would be found in more than
> one tested blocklist, where you stop processing.

   The current version of CK_Blacklist checks all of them. 

> It occurrs to me that your program could test for the pre-existence of
> the appropriate .ret file, and just exit back to PMMail without doing
> any duplicate testing. That way a user could filter on different
> blocklists or results by a series of tests.

   I plan a new version where a list of blacklisters can be administered 
via a GUI interface with a configurable severity for every blacklister 
and a minimum number of hits before quitting to check. I want to avoid 
that people have to edit the source of the script. 

> 
> I understand that the filter can check for the existance of any text 
in
> the pmmail\temp\*.ret files. That's a powerful potential which I've
> tabled for future pondering.

   Yeah. A hardly known feature. 

Yours, 
Lüko Willms
-----------------------------------------------
Frankfurt/Main  
- pmmail-list - The PMMail Discussion List ---------------------------
To POST to the list, send your message to:
pmmail-list@blueprintsoftwareworks.com

To UNSUBSCRIBE, send a message to mdaemon@bmtmicro.com 
with the first line of the message body being...
UNSUBSCRIBE pmmail-list@blueprintsoftwareworks.com
---------------------------------------------------------------------