marekp@torag.uucp (Marek Pawlowski) (09/19/90)
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. The story starts here, where I have come across some VERY vague
documentation on creating such a mailing list, using MMDF. Unfortunately,
the instructions are quite confusing as to what they are trying to
tell the reader. If there is any simple (gack! Simple?) way of doing
this, or even any hard-way-made-simple, to get MMDF doing this, would
be appreciated. Even better, if there is something floating around out
there, that will do the job for me, that would be great. I'm not in
the invent-the-wheel-all-over-again mood as of late.
Replies via "private" mail preferred. I read this newsgroup with
great interest, so there's no real fear of me skipping the message (just
keep the Subject line the same - please!)
I apologise if this has been brought up before, and has fled my organic
memory. If this dog has been beaten before, please follow-up-to the
addresses below.
Take care,
--
Marek Pawlowski | marekp@contact.uucp, marekp@generic.uucp, marekp@pnet91.uucp,
| marekp@torag.uucp, marekp@bkj386.uucp.david@twg.com (David S. Herron) (09/27/90)
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!