🚀 go-pugleaf

In article <1990Sep18.220250.961@torag.uucp> marekp@torag.uucp (Marek Pawlowski) writes:
>I'm running MMDF on SCO Unix V 3.2, and I have come across the need, to
>create a mailing list ( >24 recipients), to which I can easily add
>addresses.  The mailing list should be easy to maintain, if not to set
>up.  


Fortunately it isn't very hard to configure mailing lists in MMDF and
once you do have them configured they work VERY VERY VERY nicely...

First off you need to declare at least one alias table.  In MMDF you
can have many alias tables, simply repeat the following:

MTBL    name=alist,     file="Aliases/list",    show="List Aliases"
ALIAS   table=alist, nobypass, trusted

as many as necessary.  The "file" entry, like all MTBL directives, is
relative to the "table" directory in (usually) /usr/mmdf.  The "table"
tag refers to the particular MTBL directive.  "nobypass" means that
the sender cannot use "~name" to bypass the alias expansion.  Normally
using "~name" will not expand the alias ... I forget what "trusted" means,
but probably has to do with aliases which execute commands.

"private" would mean that the contents of the aliases in that file
are not returned through SMTP with the VRFY command.  Otherwise they are.

In the alias table you put in this group of aliases:

name:                    name-outbound@list-processor
name-outbound:           :include:/usr/mmdf/table/Mailinglists/name-list
name-request:            maintainer

Back in mmdftailor you put the following directives to enable a list channel

MTBL    name=list,        file="Channels/list",
                          show="Fast List Expansion"
MCHN    list,      que=list, tbl=list, pgm=list,
                   mod=reg, ap=822, host="Mercury.TWG.COM"


And finally, Channels/list

list-processor:    list-processor
list-proc:         list-processor

And REALLY finally, run a background deliver to watch over the list
channel like so:

	deliver -b -clist
or	deliver -b -clist,uucp,local
or	...

THEORY OF OPERATION

The "name" alias causes it to be sent to the host named "list-processor".
There isn't a PHYSICAL host by that name, however.  But there is a channel
which claims to handle mail directed to "list-processor", so the mail
gets put into that channel's queue.

Since "mod=reg" is set above an immediate "delivery" attempt is not tried,
but it is left for the background daemon.  It is left as an excercise for
the reader to configure it for mod=imm if they wish.

"Delivery" in the list channel consists of

	the list channel grabbing the message

	looking up "name-outbound" in the alias tables, since that is
	now the "local part" of the address

	seeing that "name-outbound" is an alias whose members come
	from a file

	setting the list of recipients to be whoever is listed in the
	file

	since the alias is a "name-outbound" type alias it strips
	off the "-outbound" and looks for "name-request"

	since it finds name-request it sets the return address (the
	out-of-band return address to which any errors are to be sent)
	to the maintainer of the list.

	requeues the message through submit telling it all the recipients,
	and submit will put it into whatever queues are appropriate and
	eventually a deliver daemon (or daemons) will wake up and handle
	the mail.

MAINTAINING THE LIST

One could maintain the list with `vi' but there's a program lying around
called "mlist".

If run by a normal user then it lets the user see the list of mailing
lists on the local system.  (Actually, all that happens there is that
the contents of a file is printed out, assumably that file lists all the
mailing lists but could contain baby recipes if you want...)  Normal users
can also request to be addes to a mailing list.  Or some lists can be
made "public" meaning that anybody can sign up.

If run by a list maintainer or by 'mmdf' then you're put into a mode
which lets you edit the list.  It's fairly obvious what to do from
the prompts you're given.





Well, it's time to go home & sleep ... hopefully this is enough
information and that it's coherent enough for you.  Sorry for the
delay in answering but I'm rather busy lately ...
-- 
<- David Herron, an MMDF & WIN/MHS guy, <david@twg.com>
<- Formerly: David Herron -- NonResident E-Mail Hack <david@ms.uky.edu>
<-
<- Sign me up for one "I survived Jaka's Story" T-shirt!