[Mailman-Developers] Re: Cute TMDA use

[J C Lawrence]

<<tmda-users added to distribution list as this is probably of more
interest/topicality there>>

On Mon, 29 Jul 2002 10:51:46 -0600 
Jason R Mastaler <Jason> wrote:
> J C Lawrence <claw@kanga.nu> writes:

>> There are cases where I don't want this however, and its proving
>> rather a bitch to make a non-shared whitelist hang off a shared
>> configuration (in my case a shared procmail RC).

> I haven't found this to be the case at all, but I'm also driving my
> setup with dot-qmail files which makes this sort of thing trivial.

I can't comment well in reaction to QMail as I don't and haven't used
it.  However I suspect that it doesn't solve the problem I'm
referencing, as its not MTa based or specific.

I have the MTA (currently Exim and Postfix) configured to deliver all
Mailman-related messages sent to the system (-owner, -admin, -request,
and list posts) to a singe procmail filter (obviously, shared among all
lists and aliases).  I'm using procmail as I'm also doing MIME filtering
and other pre-processing of messages before handing them to TMDA or the
MLM.  To goal is arrive at a configuration where no maintenance or
extra/unusual actions are required; of alias files, dot files, TMDA
configs, TMDA filters, etc as lists are added and removed from the
system, or for the normal running and operation of a list.

On the TMDA side what I'd like to arrive at a configuration where:

  -- blacklists are shared
 
  -- each list has an auto-whitelist which is private to that list

  -- each list authenticates messages sent to it against the appropriate
  Mailman config.db.

  -- In validating a message for a given list no files or sources other
  than the shared blacklist, the private whitelist, and the
  list-specific roster are checked.

Essentially this means a fully private TMDA filter setup for each list
(modulo the blacklist, but I'm willing to compromise on that).  Choice
of TMDA incoming filter can be selected at runtime (argument to
tmda-incoming) but I can't compute the contents of the incoming filter
at runtime in any regard.  Filter rules are single qualifier only.
Filter files don't have internal variable replacement logic so that they
can rewrite themselves depending on the Sender or similar (thus
effectively providing multiple qualifier logic).  The base result of
these configuration constraints is that I have to write a custom
incoming filter for each list, pointing at the appropriate private
auto-whitelist, Mailman config etc, each filter identical to every other
except for the internal list name references.

I'd rather have a single self-adapting incoming filter.

What I'd really like is to be able to conditionally nest TMDA filters
ala:

  # Generic access controls 

  from-file ~list/.tmda/lists/blacklist bounce
  from-file ~list/.tmda/lists/whitelist ok

  # Custom list specific filters (includes file if exists)

  #include-if "~list/.tmda/filters/${LISTNAME}"

  # Generic list-specific filters

  from-file ~list/.tmda/lists/whitelist.${LISTNAME}.auto ok
  from-mailman -attr=members ~list/lists/${LISTNAME} ok
  from-mailman -attr=digest_members ~list/lists/${LISTNAME} ok
  from ${LISTNAME}-admin@kanga.nu ok
  from ${LISTNAME}-owner@kanga.nu ok
  
That way if I should want to add extra constraints, authentication
sources, behaviours etc to a given list I can, just by dropping a file
in the filters directory.  Currently I'm hacking my way around this by
having a wrapper shell script which assembles a PID-specific incoming
filter in /tmp, calls tmda-filter against it, and then deletes it
afterward in cleanup.  Ugly, expensive, hackish, but works.

-- 
J C Lawrence                
---------(*)                Satan, oscillate my metallic sonatas. 
claw@kanga.nu               He lived as a devil, eh?		  
http://www.kanga.nu/~claw/  Evil is a name of a foeman, as I live.