From: davidf@golem.uucp (David J. Fiander)
Newsgroups: biz.sco.general
Subject: Re: Mailing lists with MMDF
Keywords: MMDF MAIL MAILING LIST
Date: 4 Sep 92 23:52:33 GMT

According to dlucy@sandr.COM (Douglas Lucy):
>>>	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.

I'm no longer associated with SCO, so I can't say one way or
the other, but I _have_ continued my association with the
generic MMDF source product which is publicly maintained.
Because of changes mandated by newer Internet standards (namely
RFC 1123 -- Host Requirements), a future version of MMDF _may_
no longer support the second syntax.  Whether SCO continues to
track UDEL MMDF that closely or not is a separate question.

>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.

If you're still running ODT 1.x, then I sympathize with you.
You should upgrade to ODT 2.x as soon as possible.  It has the
newer MMDF, and all the other problems with ODT 1.1 fixed.

>
>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?

Not the accounting information, but C2 UNIX maintains this
thing called the login uid, which is different from the real
and effective uids.  Your mmdf is running with an effective uid
of mmdf (and maybe a real uid of mmdf as well, depending on
other things), but if you were logged in as root when you
started it going, then MMDF is running with a login uid of
'root'.  This will confuse some information that is recorded if
you use the C2 features.

>>
>> 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.

An included alias list, like that in

>>>	list-outbound:	</usr/list/of/addresses

is treated exactly like an in-line list of recipients stored in
the alias table.

How much do you really want to know about how the list
processor actually works?

- David
Newsgroups: biz.sco.general