jpm@BNL.ARPA (09/17/84)
I'm very new at this so please forgive me if this is obvious to the rest of you, it sure isnt to me. I want to implement a way for users to send to a mailing list stored in a file. I dont want to update the system alias table every time somebody creates a mailing list, and I dont want to implement private alias tables for each user. I have seen messages with a format something like To: My-Dist-List: :INCLUDE: "DISK:MYLIST.DST"@MYHOST.ARPA ; This seems to be what I want, but I cant find that format in RFC822. Is this a hack by a particular host to do file includes or is it the standard way of doing it? John McNamee jpm@Bnl.Arpa
Margolin@MIT-MULTICS.ARPA (Barry Margolin) (09/17/84)
The :INCLUDE: syntax is an obsolete syntax that may have been in
RFC733, but is not in RFC822. It is still in use, however, by some of
the older mailers. There is no standardized syntax for mailing lists.
On Multics we have a number of address types for which there is no
standard syntax, and we handle them by using a special syntax in the
local-part of addresses. In particular, we use the syntax
To: "{list PATHNAME}"@MYHOST.ARPA
for mailing lists. Since the string is quoted it is treated as an
ordinary local-part by properly functioning software on other hosts.
barmarllp@Purdue.ARPA (Larry Peterson) (09/17/84)
Sendmail gives you an easy mechanism for implementing mailing lists defined outside of /usr/lib/aliases. You just tag the list's alias to indirectly point to a file, where the file contains the members of the group. Larry
Margolin@MIT-MULTICS.ARPA (Barry Margolin) (09/18/84)
Larry Peterson's response is not apropos to the question. jpm
specifically asked for a mechanism that did not require updating the
central alias file when a user creates a personal mailing list. It
sounds like your sendmail mechanism doesn't fit the bill. The only
advantage that indirection provides is that the user doesn't have to
modify the alias file to modify the mailing list. However, that isn't
what he asked for.
barmarsteve%cs.ucl.ac.uk@BRL.ARPA (Steve Kille) (07/29/86)
From: Jacob_Palme_QZ@qzcom
Subject: Distribution lists
Date: 26 Jul 86 13:30 +0200
HIER is the method commonly used in INTERNET. The restriction
requiring a hierarchical structure will make message transmission
slower and less efficient in some cases.
In some cases it is
natural to allow every list to be a member of every other list
in a set of linked lists.
I dispute this last sentence. I agree that there is a loss of
generality. However, I would suggest that the convoluted
structures prohibited are undesirable, and that prohibiting them
is an advantage. I can see a few cases where there would be a
need to create an 'invisible' list purely for the purposes of
structuring, but not where this would get out of hand.
I suggest a lemma (I don't have time to figure out a proof),
that ANY list structure can be represented by HIER.
As a challenge, I request REAL examples of list structures for
which HIER is inappropriate. I suggest is is EXACTLY what is
wanted in the majority of cases, and is quite reasonable in
all others. If this suggestion is correct, it makes HIER an
interesting choice of loop control.
SteveJacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA (08/05/86)
(a) We wanted something which (i) would work both under RFC822/821 and under X.400, including gateways betwen these protocols (ii) not requring any change in X.400, so that it could be implemented and used before changes in X.400 have been adopted and implemented everywhere. That is why we chose to encode things in the text bodies. (b) Loop control: There are five major methods of loop control: (HIN) HISTORY-TRACE, CHECK ON RECIEPT: Include with a message a history trace of lists which the message has passed, do not accept into a list a message which has already passed that list. (HOUT) HISTORY-TRACE, CHECK ON SENDING: Include with a message a history trace of lists which the message has passed, do not send it out again via list expansion to a list in the history trace. (ID) MESSAGE-ID CHECK: Include with a message some kind of message-ID, do not accept into a list a message with an ID which already has passed the list. (HIER) HIERARCHICAL ORDER: Enforce an hierarchical order on the sublists. (SPOINT) SINGLE EXPANSION POINT: Do all list expansion at a single point. Comments on these five methods: HOUT is more efficient than HIN in network load, and also less susceptible to problems when mapped onto RFC822. ID is the method commonly used in USENET. This is the only method which stops a person from receiving the same message twice, but it cannot be used as the only loop control mechanisms because of unreliability of Message-ID-s in certain cases. HIER is the method commonly used in INTERNET. The restriction requiring a hierarchical structure will make message transmission slower and less efficient in some cases. In some cases it is natural to allow every list to be a member of every other list in a set of linked lists. SPOINT is inefficient for large lists, and requires access to a global directory system, which we do not have today. We have chosen to suggest the use of HOUT in combination with ID. One can note that CCITT is presently considering SPOINT, but they may change their mind before their new recommendation is ready.