2.99.49beta11 with smtp policy filters (fwd)

Date: Fri, 13 Jun 1997 11:43:03 -0300
From: David Trueman <david@cs.dal.ca>
To: csuite-tech@chebucto.ns.ca
Precedence: bulk

next message in archive
no next message in thread
previous message in archive
Index of Subjects



Thought you would like to hear that Help is on its way!

  David Trueman,
    Systems Manager, Dalhousie Math, Stats and Computing Science
    Technical Chair, Chebucto Community Net

---------- Forwarded message ----------
Date: Fri, 13 Jun 1997 11:05:19 -0300
From: Matti Aarnio <mea@nic.funet.fi>
To: zmailer@nic.funet.fi
Subject: 2.99.49beta11 with smtp policy filters

Hello,

	At  ftp://mea.tmt.tele.fi/zmailer-2.99.49b11.tar.gz  are our
	initial smtp-server resident answers for the SPAM fighting,
	and relaying control.

	They are based on Gabor Kissigs ideas, and eat the same config
	file his does.  (But documents are 'a bit' short yet.)
	Processing is done entirely within the smtpserver without running
	a router in subprocess.

	I have added also several 'freeze*' attributes, and support for
	recognizing usernames ( 'user@domain' and 'user@' ) at the analysis.
	(The "freeze" means the message is placed into 'POSTOFFICE/deferred/'
	 directory with name of:  ${inode}.policyfreeze
	 I am considering creating a new directory for such freeze-outs at
	 the postoffice tree, so that the deferral resubmission would not
	 cause frozen messages to be sent out without administrative action;
	 because often 'zmailer resubmit' is run at cron.. )

	The 'makendbm' tool (increasingly inappropriate name) got new
	options for processing policy-filter db:
		makendbm -p btree policy-filter < policy.dat
	It also defaults suffixes to the 3rd parameter (db-file name)
	which in btree case makes the final name to be:  policy-filter.db
	Similarly the  smtpserver  does default suffixes by the type, and
	reference to that file should be:

		PARAM policydb btree /opt/zmailer/db/policy-filter


	Be carefull with it, a mistake at the policy input db may block
	all incoming email!  ( And do realize that I am not running it
	yet myself at my workstation! :-/~ )

	I do feel the input  policy.dat  should be a combination of several
	input databases, and some standard boiler-plate header/trailers, but
	as of yet my thoughts there are extremely vague.  Suggestions accepted.
	(For example so that 'localnames' file is one of the inputs, and
	 all domains in 'localnames' are accepted as always valid targets.)
	(The combination policy should not be coded into 'makendbm', but rather
	 into some SH/PERL utility.)

/Matti Aarnio <mea@nic.funet.fi>



next message in archive
no next message in thread
previous message in archive
Index of Subjects