From: dlucy@sandr.COM (Douglas Lucy)
Subject: Re: Mailing lists with MMDF
Organization: S&R Software, Inc.
Date: Fri, 04 Sep 1992 20:13:15 GMT
Keywords: MMDF MAIL MAILING LIST

In article <1992Sep03.223714.1462@golem.uucp> davidf@golem.uucp
(David J. Fiander) writes:

> According to dlucy@sandr.COM (Douglas Lucy):
>>
>> The SCO ODT System Admin Guide (ODT-NET section, somewhere around page
>> 188-190) tells you to use one of two formats for the list-of-recipients:
>>
>>	list-outbound:	":include:/usr/list/of/addresses"
>>
>>	or
>>
>>	list-outbound:	</usr/list/of/addresses
>>
>> I've found only the second of these two formats work. At least with
>> 3.2.2 and the patches & kludges (read as SLS/EFS) I've added here.
>
> That's odd, I always use the first form, and I've never had a
> problem.  The second form may be eliminated in a future
> release, owing to RFC 1123.

Okay. The order they appear in the manual (*I think*) shows your
preferred way FIRST, which is what I  tried first. It didn't work
and I simply tried method #2, hoping it WOULD work without having
to spend any time tracking down some obscure file or directory
problem. If the redirection method wil not be supported in a
furture release of MMDF, thanks for saying so; I'd never figure
out why the old method wouldn't work.

> Secondly, there has never been an MMDF SLS or EFS.  There has
> been 1 (one) MMDF TLS, which is a complete drop-in replacement
> for the entire MMDF subsystem that came with 3.2.2.

What was the TLS for? I've got the plain, out-of-the-box ODT
Pers (1.1?) + Dev + Multi-user MMDF. If there's something wrong,
I'd like to know what. I APPRECIATE the way SCO handles distribution
of supplements, meaning anon uucp and uunet ftp.

> Since I
> was the person that packaged the TLS (and half of the people
> responsible for the contents), I resent the implication that it
> is a collection of patches and kludges.  The MMDF TLS (which is
> also the MMDF shipped with ODT 2.0) is a much better product
> that the MMDF that SCO initially shipped with UNIX and ODT.

Nope, you caught my intent wrong. I don't think MMDF is kludged or
patched, I didn't even NOTICE the MMDF TLS in the last listing I got.
What I meant was, ODT was patched and kludged. Not necessarily by SCO,
but after looking at my CUSTOM screen and paging through the two
screen fulls of installed SLS, EFS and TLS headings and the xinstall
heading and just KNOWING there's a complete directory heirarchy of
non-SCO addition (fas, gnu, X386, etc.) to make up my system, I have
to stand by my label of "patched and kludged". No slight to SCO, or
anyone for that matter, intended.

>>
>>	5. Now, you've still got the MMDF deliver program running, and
>>	since I'm not convinced the thing EVER reads the database when
>>	it should, I look for the program "deliver" in a ps listing,
>>	kill it, and then re-execute the deliver command just as it
>>	looks in the boot script /etc/rc2.d/S*mmdf. It'll be the line
>>	that su's to mmdf and then executes "deliver".
>>
>
> FYI, the _only_ time the deliver daemon needs to be restarted
> is after you have added or deleted channels.

Great! I can leave out those two steps.

> Also, if you do kill and restart the deliver daemon, make sure
> you do this _logged_in_ as mmdf.  Otherwise the accounting
> information recorded by the C2 security system will be wrong
> (if you care).

Well, the point here is moot, but this brings up another question: my
"restart" script is setuid mmdf. So, in a ps listing, the deliver
program looks like it was started as mmdf, even tho' I kicked it off
as root. Will this corrupt the acct info?

>> Are you confused yet? Well, the above steps worked for me. The only
>> addition I put in was an additional address in the list of mailing
>> list members. I put in "blue-sky-archive" in the list and then added
>> this line to /usr/mmdf/alias.list:
>>
>>	blue-sky-archive:	"mmdf//mail/archives/blue-sky"
>>
>> After following the same re-build steps for the MMDF database above in
>> steps 3-5, this additional line told MMDF to keep a copy of all
>> incoming mail to the list in the file /mail/archives/blue-sky.
>
> The other option is to just add the line
>
>	mmdf//mail/archives/blue-sky
>
> to the mailing list file, but having a separate archive alias
> means that it is easier to modify the behaviour of the archive
> process.

Does this mean the members file (where which the list-processor pulls
addresses of those actually "on" the list) is processed just like the
line in /usr/mmdf/table/alias.user ? If so, some other neat tricks
could be shoved in there and forget about re-building the database
after every change.

-- 
[ W. Douglas Lucy, VP Technical Services, S and R Software, Inc. ]
[ dlucy@sandr.COM                                                ]