9-DEC-79 15:30:53-PST,5741;000000000001 Date: 9 DEC 1979 0210-PST Subject: MSGGROUP#1401 Survey of [ECL]MSGGROUP#.1351-1400;1 From: ESTEFFERUD at USC-ECL To: MSGGROUP at USC-ECL Mail-from: MIT-ML rcvd at 9-Dec-79 0225-PST Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 MSGGROUP#1351 Survey of [ECL]MSGGROUP#.1301-1350 5519 chars 29 Oct 1979 at 1203-PST From: EStefferud at USC-ECL MSGGROUP#1352 Re: UNCLE!!! 374 chars 29 OCT 1979 1356-PST From: MACKENZIE at USC-ECL MSGGROUP#1353 Sinking into concentration 2591 chars 29 OCT 1979 1313-PST From: MACKENZIE at USC-ECL MSGGROUP#1354 Reply to: Sinking into concentration 866 chars 30 Oct 1979 at 0614-CST From: david at UTEXAS MSGGROUP#1355 TRS-80 Mailgram Package Offered 1643 chars 30 Oct 1979 0650-PST From: Zellich at OFFICE-1 MSGGROUP#1356 The use of CC 3391 chars 30 Oct 1979 0735-PST From: William G. Martin MSGGROUP#1357 Re: Handling of Reply.. 2419 chars 30 Oct 1979 0957-EST From: MOOERS at BBN-TENEXA MSGGROUP#1358 Re: The use of CC 2452 chars 30 Oct 1979 0940-PST From: the tty of Geoffrey S. Goodfellow MSGGROUP#1359 Re: The use of CC 1726 chars 30 Oct 1979 0940-PST From: Larry Campbell Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 It is certainly true that people use this list for lots of things having no relation whatever to message systems, apparently for lack of a better medium. Maybe there should be a general "flame-throwers" mailing list. 11-DEC-79 17:12:41-PST,1121;000000000001 Mail-from: MIT-ML rcvd at 9-Dec-79 1649-PST Date: 9 DEC 1979 1923-EST From: rms at MIT-AI (Richard M. Stallman) Sent-by: ___047 at MIT-AI Subject: MSGGROUP#1403 Selective perception To: msggroup at MIT-ML Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 I sent this message to MSGGROUP because I seem to recall that that is where I spoke up about it the last time I was screwed in this way, and everyone denied that there could EVER be a situation in which sending network mail was not enough. Well, here is one, but I suppose I should have known it was no use to say "I told you so". If people don't want to hear, they won't hear. But if you object to the use of MSGGROUP for this subject, as anything but an excuse not to hear what you don't like, then please supply an alternative. By the way, the message that I saw when I logged in seemed to say that SRI would be running the experimental system for DAYS, not just a couple of more hours. I don't know whether it was my mistake or theirs. Does it matter? 11-DEC-79 17:12:41-PST,1982;000000000001 Mail-from: MIT-ML rcvd at 9-Dec-79 2112-PST Date: 9 Dec 1979 2054-PST Sender: STEFFERUD at OFFICE-1 Subject: MSGGROUP#1404 Intention to restructure MsgGroup From: STEFFERUD at OFFICE-1 To: MsgGroup at MIT-ML Message-ID: <[OFFICE-1] 9-Dec-79 20:54:52.STEFFERUD> Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 Based on requests for action from the members of MSGGROUP, I have concluded that something must be done to allow the members to shield themselves from unwanted traffic such as we have just received. As a student of the computer network mail phenomenon, I have found it interesting to observe such episodes, but I also find that it seriously inhibits the flow of group traffic on broader issues of substance. The emotional load of these outbursts is no longer tolerable for the group, and they must be confined to private side traffic. Toward this end, I am working out arrangements for a three level membership list that will afford editorial control on the content of the "published record" of MsgGroup, and therby afford filtering of raw "fray" traffic for those who are interested in the substantive isssues. Sometime over the next two weeks I will send out my new scheme and ask you to select your level (or levels) of membership. With approximately 150 mailboxes in the list, it will be important to me to process your selections in an orderly preplanned way, so I ask your indulgence to put up with the current open and uncontrolled situation for just a little while longer. Right now I simply cannot jepardize my own contract deadlines and obligations to mount a crash project to restructure MsgGroup. In the meantime, I wish to exhort those flamers among you to please retire to the sidelines and keep the main channel of MsgGroup clear of flames. In short, keep your private laundry out of this public channel. Best regards - Stef 11-DEC-79 17:12:41-PST,559;000000000001 Mail-from: MIT-ML rcvd at 9-Dec-79 2309-PST From: RMS@MIT-AI Date: 12/10/79 01:16:23 Subject: MSGGROUP#1405 Alternatives to MSGGROUP Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 RMS@MIT-AI 12/10/79 01:16:23 Re: Alternatives to MSGGROUP To: msggroup at MIT-ML I repeat, if MSGGROUP is not the right place to discuss a general issue of how people should be able to communicate with other people on computer systems, can someone tell me what the right place is? 11-DEC-79 17:12:41-PST,696;000000000001 Mail-from: MIT-ML rcvd at 9-Dec-79 2347-PST From: RMS@MIT-AI Date: 12/10/79 02:09:44 Subject: MSGGROUP#1406 An apology Subject: for what it seems people thought I was saying Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 RMS@MIT-AI 12/10/79 02:09:44 Re: An apology for what it seems people thought I was saying To: msggroup at MIT-ML It seems that most people thought my first message was a condemnation of people at SRI for running an experimental system version and not being up for users. That was not what I was trying to say, so I apologize to anyone who felt hurt by it. 11-DEC-79 17:12:41-PST,2005;000000000001 Mail-from: MIT-ML rcvd at 10-Dec-79 0124-PST Date: 10 Dec 1979 0041-PST (Monday) From: Lauren at UCLA-Security (Lauren Weinstein) Subject: MSGGROUP#1407 Stratification and Isolation: Subject: The Future of MSGGROUP? To: MSGGROUP at ML Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 I understand the problems that have been developing with flaming messages and the like in MSGGROUP, and I may even be ready to concede that some sort of "layering" of MSGGROUP is called for, but I can't help this gut feeling I have that it would be a basically negative development. As we all know, the ARPANET message systems are the leading edge of the future in electronic message systems (at least, I hope they are.) I feel that it is very important that the official MSGGROUP records show more than high level discussions of technical matters -- those will tend to work themselves out over time one way or another. But the issues of human interface and organizational policy are another matter. Most organizations tend toward the status quo in such matters, and unless people raise a fuss, things continue along in the old patterns forever. What's the point? The point is that it is these non-technical issues that tend to bring forth highly emotional (that is, "flaming") arguments and feelings in both system designers and users. The danger is that the desire to avoid such flames may lead some persons to try insulate themselves against these messages, which, while they may be highly emotional, also often have a high information content. Life IS largely emotion, after all. This is not to say that there is not a place for strictly technical, non- emotional discussions. Only that I hope people will consider very carefully before they decide to "subscribe" ONLY to the highly filtered levels of MSGGROUP that Stef may formulate. Peace. --Lauren-- ------- 11-DEC-79 17:12:41-PST,2477;000000000001 Mail-from: MIT-ML rcvd at 10-Dec-79 1647-PST Date: 10 Dec 1979 1622-PST Sender: STEF at SRI-KA Subject: MSGGROUP#1408 The Common Etiquette Issue Subject: Re: Selective perception From: STEF at SRI-KA To: rms at MIT-AI Cc: msggroup at MIT-ML Message-ID: <[SRI-KA]10-Dec-79 16:22:12.STEF> In-Reply-To: Your message of 9 DEC 1979 1923-EST Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 Richard M. Stallman, et al - I can appreciate your frustrations quite well, having found myself locked out from files that I needed, because I had not noticed the downtime schedule, or because I had not planned ahead well enough. In those cases, I have found that I must bite the bullet and call someone on the phone or give up the effort. Message systems are clearly not the solution to every communication need, but neither is an open systems access policy the answer to every access need. I think it is nice that open access rules work well for MIT-AI (et al), but I clearly recognize that other sites have other requirements that cannot, and should not be met with MIT-AI policies and practices. So, your issue about the completeness of message systems adequacy for all occasions is clearly a proper MSGGROUP topic, but that is not the issue you dumped on the group in your first message. If you don't state rather carefully what you mean when you send a message to a list of 150 (approx) mailboxes in the ARPANET, you can certainly expect one or more folks to misunderstand what you are trying to say. Especially when your statement seems to be publicly blaming certain individuals for your private problems with their system's downtime schedule. You can also expect that when you castigate others in public with what should be communicated in private, you will offend them and find them to react offensively. So, what does this have to do with MSGGROUP at this point? Well, I find that this new medium seems to relax its users' common sense of etiquette for some reason. I do not think such phenomena are limited to this new medium. I expect that every new medium suffers from lapses of common etiquette. H.G. Wells War of the Worlds being one possible case in point for another medium. So, I wonder how we might make some good use of this observed loss of etiquette transfer into new communication media? Best - Stef 11-DEC-79 17:12:42-PST,2129;000000000001 Mail-from: STEFFERUD filed at 10-Dec-79 1730-PST Date: 10 Dec 1979 1730-PST Sender: STEFFERUD at OFFICE-1 Subject: MSGGROUP#1409 Re: Stratification and Isolation: Subject: The Future of MSGGROUP? From: STEFFERUD at OFFICE-1 To: Lauren at UCLA-SECURITY Cc: MSGGROUP at ML Message-ID: <[OFFICE-1]10-Dec-79 17:30:51.STEFFERUD> In-Reply-To: Your message of 10 Dec 1979 0041-PST (Monday) Fcc: SAVED.MESSAGES;1 Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 Hi Lauren - I have avoided acting to stratify for the reasons you cite, and because it involves more work for me which I have been shunning as best I can. My stratification plan is as follows: Establish three levels of membership to be - . FRAY.LST for those who want to be in on the rapid exchange, though maybe noisy level. . PUBLICATION.LST for those who only want to see stuff that has passed muster, been tidied up in format to fit inside 72 char printers, and have the MSGGROUP accession numbers inserted. . SURVEY.LST for those who only want to see the srveys as messages accumulate. Hopefully this will open up the forum rather than close it, if more people ca afford to monitor one or more of these levels. I see no reason to limit anyone to a single level of membership, so I think this will lead to more and better participation. I plan to REDISTRIBUTE the PUBLCATION.LST stuff to MARS-Filer@CCA for retrieval via MARS-Retriever@CCA. Procedures for CCA retrieval of MSGGROUP "Publication.LST" items are in the process of being written now. To sort out the current members, I will send each member a set of 3 messages, one for each level. Then each member can execute a simple reply to tell me what lists they want to be on, and I can process the replies with HERMES to construct the lists by creating appropriate templates. When I am ready, I will move out on this plan. Till then, I will vbe interested in comments, and in offers of assistannce. Best - Stef 11-DEC-79 17:12:42-PST,1121;000000000001 Mail-from: MIT-ML rcvd at 10-Dec-79 1927-PST From: FFM@MIT-MC Date: 12/10/79 22:11:40 Subject: MSGGROUP#1410 The word 'experimental' and other things Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 FFM@MIT-MC 12/10/79 22:11:40 Re: The word 'experimental' and other things To: RMS at MIT-AI CC: msggroup at MIT-ML Hoping not to further throw flames and cause pain and fustration to those 150 humans and whatnots out there, here is my comments on the word 'experimental' in reference to system uptime/downtime. Experimental is a bad word to use!!! Whenever a system is not available to users; it should say "NOT AVAILABLE TO USERS". I have seen numerous cases of what I feel is using the word experimental when it really meant NOT AVAILABLE TO USERS. This goes for no one particular system, I have seen this done on all sorts systems both on and off the net, I don't think highly of it. If you make a user or set of users set around for 2 hours guessing then it is a loss. Oh well Have fun sends Steve 14-DEC-79 12:28:32-PST,1633;000000000001 Mail-from: MIT-ML rcvd at 13-Dec-79 0946-PST From: Gaines at Rand-Unix Date: 13 Dec 1979 at 0926-PST To: msggroup at Mit-Ml Subject: MSGGROUP#1411 A vote against limitations on MSGGROUP traffic Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 I think occasional flaming, and messages we might rather not see for other reasons, and the price we have to pay for an open discussion group where people are free to voice their ideas. It seems to me that it is easy enough to discard an uninteresting message that the pain is more apparent than real. (In the same vein, who is actually hurt when junk mail comes to them? An ounce of common sense will convince one to throw it away without an emotional reaction, and all the cost to those upset about it appears to be self-generated emotional cost.) If someone has a problem, and expresses it in emotional form, still it is hard to say when it will be a real problem we should consider, and when it is something that probably should not have been aired to the msggroup public. Sometimes we won't know until after the debate, when, hopefully, the real issues and some answers will have surfaced. We must also expect that this whole process produces a fair amount of nonsense. We are feeling our way in a murky area, and have to expect to make lots of mistakes. Let us judge the msggroup by the good ideas that surface, which by the nature of the area have to be expected to be few and far between, but worth the overhead of the other traffic when they arrive. Stock Gaines 14-DEC-79 12:28:32-PST,1317;000000000001 Mail-from: MIT-ML rcvd at 13-Dec-79 1035-PST Date: 13 December 1979 1301-EST (Thursday) From: Brian.Reid at CMU-10A Subject: MSGGROUP#1412 Re: vote against limitations on MSGGROUP traffic To: msggroup at Mit-Ml Message-ID: <13Dec79 130108 BR10@CMU-10A> In-Reply-To: Gaines' message of 13 Dec 79 12:26-EST Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 Bravo! I agree wholeheartedly, but felt reluctant to broach the topic. Why, the presence of occasional junk mail in MsgGroup has led to technological improvements in our mail reading programs (various minimum-work ways of dealing with messages without reading very much of them). I really think that MsgGroup will die if it is segmented. Something else would probably spring up in its place; of course, but that something else would not have a moderator. In much the same way that most of the real learning at conferences does not take place during the formal talks but in the cocktail parties and impromptu groups that form to explore restaurants, much of the significant discussion in MsgGroup--significant in the sense that it is on topics that would not otherwise be aired-- happens in the hip-shooting and flaming and informal traffic. Brian 14-DEC-79 12:28:32-PST,556;000000000001 Mail-from: MIT-ML rcvd at 13-Dec-79 1126-PST Date: 13 Dec 1979 1022-PST From: POSTEL at USC-ISIB Subject: MSGGROUP#1413 Re: vote against limitations on MSGGROUP traffic To: Gaines at RAND-UNIX, msggroup at MIT-ML cc: POSTEL Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 In response to the message sent 13 Dec 1979 at 0926-PST from Gaines@Rand-Unix Any one willing to make a list of "the good ideas that have surfaced in msg group"? --jon. ------- 14-DEC-79 12:28:32-PST,1193;000000000001 Mail-from: MIT-ML rcvd at 13-Dec-79 1217-PST Date: 13 Dec 1979 1029-PST From: FYLSTRA at SRI-KL (David Jon Fylstra) Subject: MSGGROUP#1414 Re: vote against limitations on MSGGROUP traffic To: Brian.Reid at CMU-10A, msggroup at MIT-ML Cc: FYLSTRA at SRI-KL In-reply-to: Your message of 13-Dec-79 1001-PST Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 But the hip-shooting and flaming and informal traffic doesn't take place at the conference session in front of the entire community, with the chance of public embarassment and other ill feelings! These things belong in the private side conversations between individuals, just as at conferences they take place at the cocktail parties and restaurants. I wish that people would simply use more judgement as to what they burden the air waves with. I tend to agree with Brian and Stock. I like the moderation that Steff provides, but I also like the free interchange supplied by the automatic forwarder. I would prefer to avoid the segmentation of MSGGROUP and hope for more discretion on the part of the participants. Dave ------- 14-DEC-79 12:28:32-PST,509;000000000001 Mail-from: MIT-ML rcvd at 13-Dec-79 1247-PST From: Gaines at Rand-Unix Date: 13 Dec 1979 at 1106-PST To: msggroup at Mit-Ml Subject: MSGGROUP#1415 No good ideas? Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 In reply to Postel's comment: those who think they have learned nothing from the msggroup traffic certainly should take their names off the list, if for no other reason than to stop wasting their own time. 14-DEC-79 12:28:32-PST,688;000000000001 Mail-from: MIT-ML rcvd at 13-Dec-79 1325-PST Date: 13 Dec 1979 1305-PST From: POSTEL at USC-ISIB Subject: MSGGROUP#1416 Re: No good ideas? To: Gaines at RAND-UNIX, msggroup at MIT-ML cc: POSTEL Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 In response to the message sent 13 Dec 1979 at 1106-PST from Gaines@Rand-Unix I am supprised by Gaines's reply to my comment. I was encouraging someone to make up a list of good ideas that had come up in msg group correspondence. I think it would be quite valuable to have such a list and to update it from time to time. --jon. ------- 14-DEC-79 12:28:33-PST,1085;000000000001 Mail-from: MIT-ML rcvd at 13-Dec-79 1356-PST Date: 13 Dec 1979 1318-PST From: Walsh at OFFICE-1 Subject: MSGGROUP#1417 STRATIFICATION To: STEF at SRI-KA cc: MSGGROUP at MIT-ML, WALSH Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 STEF SPEAKING AS A MEMBER WHO HAS SPENT THE LAST FEW YEARS OBSERVING (AND ENJOYING) THE DEBATES IN MSGGROUP,I WOULD NOT PERSONALLY CARE TO BE ISOLATED FROM ANY PART OF THE FRAY. HOWEVER,I DO AGREE THAT MEMBERS SHOULD HAVE THE OPPURTUNITY TO INDIVIDUALLY DECIDE THEIR LEVEL OF EXPOSURE-ALTHOUGH I ALWAYS FELT I HAD THAT. IT SEEMS TO ME THAT WATCHING WHAT UPSETS PEOPLE IN THIS TECHNOLOGY HAS SERVED ME WELL. EMOTIONAL OUTBURSTS AND OCCASSIONAL BAD MANNERS EXIST IN MY CLIENT COMMUNITY AS I SUSPECT IT DOES IN ALL OTHERS,BUT IGNORING IT DOESNT MAKE IT LESS REAL. I WONDER HOW MANY OTHER ADMINISTRATORS OUT THERE FIND THEMSELVES USING POINTS MADE DURING MSGGROUP FLAMING DEBATES,DURING POLICY AND STRATEGY SESSIONS. REGARDS,BILL ------- 14-DEC-79 12:28:33-PST,894;000000000001 Mail-from: MIT-ML rcvd at 13-Dec-79 1433-PST Date: 13 Dec 79 16:45-EST Thu From: Dcrocker at UDel-EE Reply-to: Dcrocker at Rand-Unix To: MsgGroup at Mit-Ml Subject: MSGGROUP#1418 options Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 If I understand some of you correctly, you wish to PREVENT users from having the OPTION of allowing someone else (in this case, Stef) from filtering a data stream for them. That doesn't make sense. Certainly, the filter should not be mandatory for anyone, but why object to what, for some/many, can only be viewed as an efficiency hack which is in common use in other environments and media (e.g., secretary's pre-handling trivial mail)? Separate from its use, I think Stef gets the good-Samaritan award of the day for even offering. Dave. 14-DEC-79 12:28:33-PST,973;000000000001 Mail-from: MIT-ML rcvd at 13-Dec-79 1457-PST Date: 13 December 1979 1721-EST (Thursday) From: Brian.Reid at CMU-10A Subject: MSGGROUP#1419 voila! We learn something. To: POSTEL at USC-ISIB CC: msggroup at MIT-ML Message-ID: <13Dec79 172124 BR10@CMU-10A> In-Reply-To: POSTEL's message of 13 Dec 79 16:05-EST Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 One of the many things we have all learned is how frequently an informal or casual sentence, which when spoken could make use of intonation and gesturing, is misinterpreted, as yours was. I certainly read it as a sarcastic expression of belief that nothing had been learned from MsgGroup. I'm kind of a flamer myself, but I've learned from MsgGroup that informal style, though somewhat natural in this medium, is very frequently ineffective or downright antieffective in getting the message across. Brian 14-DEC-79 12:28:33-PST,1499;000000000001 Mail-from: MIT-ML rcvd at 13-Dec-79 1702-PST Date: 13 Dec 1979 1510-PST From: PICKENS at SRI-KL Subject: MSGGROUP#1420 Messages about Messaging To: msggroup at MIT-ML Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 A significant proportion of the msggroup dialogue has been about the act of dialoguing itself. New ideas have been rare; flogging has been the norm. This is probably to be expected, and is probably healthy. I concur with others who believe that an excessive amount of "hall talk" has been aired over the msggroup "PA system". However, the only effective way to limit such behavior is by gentle group persuasion. But wait! Perhaps we can turn this social and emotional issue into a technical one. I wonder if an extension to the message system could be devised to make it more convenient to spawn special-interest conversations, and thereby reduce unwanted message traffic for the community as a whole. For example, if it were possible to spawn pseudo- private message repeaters, such as NETWORK-SERVICE-GRIPES at MIT-ML, and then to allow interested members of MSGGROUP to join without manual setup, might we see a natural, by demand, partitioning of the community on an issue-by-issue basis? I wonder if there are other technical approaches that can make the medium more accomodating to the needs of large group discussions. Any ideas? John Pickens ------- 14-DEC-79 12:28:33-PST,784;000000000001 Mail-from: MIT-ML rcvd at 13-Dec-79 1725-PST Date: 13 December 1979 2006-EST (Thursday) From: Brian.Reid at CMU-10A Subject: MSGGROUP#1421 Re: Messages about Messaging To: msggroup at MIT-ML Message-ID: <13Dec79 200639 BR10@CMU-10A> In-Reply-To: PICKENS' message of 13 Dec 79 18:10-EST Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 That reminds me of another thing I've learned in a few years of MsgGroup: that a "committee" discussion held via electronic mail never reaches a consensus. C.f. some of the less-general "conferencing systems" described in Hiltz&Turoff's "Network Nation", whose only use is to hold an electronic "meeting" in which a consensus is actually reached. 14-DEC-79 12:28:33-PST,982;000000000001 Mail-from: MIT-ML rcvd at 13-Dec-79 2117-PST Date: 13 December 1979 23:21 est From: Frankston.Frankston at MIT-Multics (Bob Frankston) Subject: MSGGROUP#1422 Clipping Service To: msggroup at MIT-ML Message-ID: <791214042106.249560 at MIT-Multics> Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 It sounds that Steff is offering to provide a clipping service for the msggroup readers, at least those who do not want to be annoyed by less serious mail. This service can, of course, be extended to a wider collection of mailling lists. The level of traffic in msggroup itself does seem relatively small and within the ability of current mail systems to deal with (at least on 120 cps terminals and above). When we do reach the stage that electronic mail is an effective means of publication such services will become more important--Steff's effort will be interesting to watch. 14-DEC-79 12:28:33-PST,1030;000000000001 Mail-from: MIT-ML rcvd at 13-Dec-79 2231-PST Date: 13 Dec 1979 2212-PST Sender: GEOFF at SRI-KA Subject: MSGGROUP#1423 Re: vote against limitations on MSGGROUP traffic From: the tty of Geoffrey S. Goodfellow To: FYLSTRA at SRI-KL Cc: Brian.Reid at CMU-10A, msggroup at MIT-ML Message-ID: <[SRI-KA]13-Dec-79 22:12:18.GEOFF> In-Reply-To: Your message of 13 Dec 1979 1029-PST Reply-to: Geoff @ SRI-KA Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 But the hip-shooting and flaming DOES TAKE PLACE at conference sessions in front of entire communities! If you've ever attended a DECUS (DEC machine users conference), there have been many vicious attacks in the sessions by unhappy customers upon DEC management. I'm down in San Diego this week attending DECUS, which just reminded that such things do happen. Of course, its up to the session chairperson to bring things under control if they get to out of hand... Geoff 14-DEC-79 12:28:33-PST,746;000000000001 Mail-from: MIT-ML rcvd at 14-Dec-79 0352-PST Date: 14 December 1979 05:26-EST From: "Marvin A. Sirbu, Jr." Subject: MSGGROUP#1424 Clipping Service To: Frankston.Frankston at MIT-MULTICS, msggroup at MIT-ML Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 Not only will clipping services be required in the real world, but in the real world sending messages to large groups won't be free, and you will likely think twice before replying. For example, when I use the mail system on the Source, I pay 15 cents extra for each additional addressee past the first one. At that rate it would cost me $22.50 to send something to MSGGROUP! 14-DEC-79 12:28:33-PST,1464;000000000001 Mail-from: MIT-ML rcvd at 14-Dec-79 0422-PST From: FFM@MIT-MC Date: 12/14/79 07:15:30 Subject: MSGGROUP#1425 Clipping Service and MSGGROUP in general To: SIRBU at MIT-MC, msggroup at MIT-ML Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 However it may not cost that much. I would consider 15 cents a reply to be a ripoff.Thus I think that when a truly great volume of mail starts going electronically then some sort of filter will be needed. I don't think I need such now if I wanted to as my mail comes into RMAIL or whatever mailer I am using, if I really disliked flaming I know after a week or so who the flamers are and how in general the headers to flaming messages look and if I wanted I could avoid them. However I tend to like them so I read them, I remember when flaming went away for awhile MSGGROUP was nearly dead for awhile. As far as anything useful that has come up on MSGGROUP I remember when there was a tchnological literacy discussion and a discussion about office mail in the future and a wide interaction between people of varying persuasions about numerous and sundry things. I think this was moderately winning SInce I tend to hack both in the real world as well as SU thesedays MSGGROUP also assures me that someone somewhere outhere is still alive and flaming. Have fun all... Merry Christmas etc.... Sends Steve 15-DEC-79 02:29:28-PST,742;000000000001 Mail-from: MIT-ML rcvd at 14-Dec-79 1237-PST Date: 14 Dec 1979 0927-PST Sender: FARBER at SRI-KA Subject: MSGGROUP#1426 Re: No good ideas? From: FARBER at SRI-KA To: Gaines at RAND-UNIX Cc: msggroup at MIT-ML Message-ID: <[SRI-KA]14-Dec-79 09:27:58.FARBER> In-Reply-To: Your message of 13 Dec 1979 at 1106-PST Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 What I learned to a very large degree is the dynamics of this new medium ; its problems and its advantages. I also learned the technology necessary to live in this world. I vote for increasing the maturity of the participants not limiting the discussion. Dave 15-DEC-79 02:29:29-PST,2732;000000000001 Mail-from: MIT-ML rcvd at 14-DEC-79 1348-PST Date: 14 Dec 1979 1302-PST (Friday) From: Lauren at UCLA-Security (Lauren Weinstein) Subject: MSGGROUP#1427 message ratings To: MSGGROUP at ML Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 When Stef first announced the new plans for MSGGROUP, I was the first one to reply with my "Stratification and Isolation: The Future of Msggroup" message. Having read the resulting discussion with considerable interest, I have a proposal (that I hope is practical to implement.) Does anybody think that we, as individuals, are qualified to "rate" our own messages into one of several "flame-quotient" catagories? I think we MIGHT be so qualified. That is, when a person sends a message, he/she puts a "rating" for that message ON THE SUBJECT LINE. For example, if the established catagories were TECHNICAL, GENERAL, and FLAME, most messages would fall pretty easily into one or more of these catagories. Maybe more or different catagories would be required, these are only examples. If I sent a message with the subject: SRI FINGER PROGRAM [FLAME], I think most people would have some idea of what to expect. At least those persons who dislike flaming mail so much (I'm not one of them) would be able to delete it w/o reading it -- which I prefer in concept to never being told about it at all due to the presence of an omnipotent "filter". Obviously this would not be a perfect system, but I suspect it would be preferable to filtering or having people drop out of MSGGROUP. It would simply be a mechanism for allowing the simple deletion of unwanted mail. (When you get junk US mail, you USUALLY can recognize it can't you? Do you feel obligated to read the whole thing, or do you toss it IMMEDIATELY if you don't care about it? -- I think the same should be true for this medium.) One other point. The fact that "real world" mail systems are ripping people off with insane fees is not applicable to our discussion. (15 cents for "The Source" mail system? That's awful -- I'll bet when the Postal Service ups their rate you'll find "The Source" following it!) The whole point of MSGGROUP, to me, is that we are free to communicate without undue worry about costs, and to borry a line from the closing episode of the "Connections" program from PBS, "the easier it is to communicate, the faster change occurs." It is this very change that is creating the systems, concepts, and most importantly, the EXPECTATIONS of people for message systems of the future. Any comments/discussion on my rating proposal would be welcome... --Lauren-- ------- 15-DEC-79 02:29:29-PST,2288;000000000001 Mail-from: MIT-ML rcvd at 14-DEC-79 1447-PST Date: 14 Dec 1979 1335-PST Sender: STEFFERUD at OFFICE-1 Subject: MSGGROUP#1428 Plans for MsgGroup stratification From: STEFFERUD at OFFICE-1 To: MsgGroup at MIT-ML Message-ID: <[OFFICE-1]14-Dec-79 13:35:49.STEFFERUD> Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 As I reflect on all your comments and your concerns, I do not yet see any reason to abandon what I suggested. I think my scheme will actually open up the discussion rather than close it down. There are current constraints on the discussion because everyone is in it without any option to be close but not inside. There is a rather large segment of the membership that only observes, without contribution. There are others who would like to see only the SURVEY listings with access to the published record for perusal from time to time. What I intend is to apply minimal editing to the FRAY flow, to insert the MSGGROUP# accession numbers, to tidy up the formatting when it is out of bounds, and to divert obviously inappropriate messages from the "PUBLISHED" record. Diverted messages can be kept in an "UNPUBLISHED" file for reference on request. I sense that as a group, you want me to apply rather open criteria in my decisions, to avoid excessive diversion. It is also clear that editing of any message must be limited to format adjustments to fit the 72 column standard, and to fit the RFC733 standard. I concur with that, and I would propose to establish an editorial board to assist me with policy and with specific decisions from time to time. My expected net result is that discussion will open up some because we need not fear dumping unwanted mail on those who want to watch from a distance. The FRAY list subgroup then could have at it with as much gusto as they might wish, and the watchers can watch from a comfortable distance. For one thing, all MSGGROUP mail going to the PUBLISHED list will contain the MSGGROUP# "flag" in the subject field to make it stand out in their inboxes. I trust this message will allay some of your concerns, and explain more of what I have in mind. Your comments are invited. Best - Stef 15-DEC-79 02:29:29-PST,1403;000000000001 Mail-from: MIT-ML rcvd at 14-DEC-79 1515-PST Date: 14 Dec 1979 1349-PST From: PICKENS at SRI-KL Subject: MSGGROUP#1429 Analogy to real conferencing To: msggroup at MIT-ML Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 Unlike normal conferences, where there are limited microphones, a chairperson, and where audience energy tends to wear down, MSGGROUP style conferences never resolve issues much less adjourn. This effect follows naturally from the observation that every participant reenters the discussion by choice, perhaps following a recuperative and regenerative period of rest. This style of conferencing is by nature an interaction between persons and their machines much more than between people. To be an exact analogy to a MSGGROUP conference, each speaker in a normal conference would record and edit his thoughts into a tape recorder, in an isolated room, and then would hand it off to a courier who would queue it up for playback over a PA system. (Which playback no one would monitor in real time, but would be captured in private recorders with the record button always depressed). Which brings me back to the point of my previous message. Are there any good ideas of how the technology can be used to improve, rather than degrade, large group conferencing? ------- 17-DEC-79 02:56:31-PST,6109;000000000001 Mail-from: MIT-MC rcvd at 16-Dec-79 1149-PST Date: 16 December 1979 14:12-EST From: Robert W. Kerns Subject: MSGGROUP#1430 More about not-logged-in mail non-flame, I hope! To: MSGGROUP at MIT-MC Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 This message was originally directed in response to CARLSON of ARPA's Information Processing Techniques Office. The circumstances are that one Jules Gilbert (forbidden by Arpa to use the Arpanet net, and continuing to use it with commercial intent, more I shall not say in public) has sent another message by connecting to one of our machines and sending mail while not logged in. -------- Date: 12 DEC 1979 1156-EST From: RWK at MIT-MC (Robert W. Kerns) Subject: Why we let people send mail To: carlson at USC-ISI CC: ELLEN at MIT-MC, Kahn at USC-ISI Date: 12 Dec 1979 0648-PST From: CARLSON at USC-ISI Subject: Jules Gilbert etc. To: ellen at MIT-MC cc: carlson, kahn Ellen: We are curious. why doesn't your login implementation prevent the user from doing ANYTHING (especially sending messages) until after authentication is complete? Bill I'll answer this since ELLEN isn't in, and I consider the question to be of some importance. This is a little wordy, please bear with me. I hope it will adaquatly satisfy your curiosity, and not be too much like drinking from a fire hose. The reason we allow people to send mail while not logged in is the same reason why some people are quite upset with some arpanet sites for NOT doing so. Namely that the ability to contact a human being online is an ESSENTIAL SERVICE. There are several situations in which it is necessary for an unlogged-in user to send mail, and I'll only list a few of them. One of the most important to us, since we have a large number of people unfamiliar with our system or computers in general, is people who are having problems logging in. If they've forgotten their password, they can't just come down the hall and ask us to help them, they may be in California or even London! Also, while considering if someone should be granted an account, it is often necessary to communicate with them, and netmail is by far the most convenient means both for them and for us. Another situation has recieved a fair amount of attention in MsgGroup from time to time. It is often necessary to ask someone at a specific site a question, or tell someone at a specific site of a problem. To do this you need the ability to find out who is on the system, and to send messages. Why not simply log into your home site to send the mail? This can be impossible due to a number of factors, such as your own site being down. One common occurance here is someone will connect to another MIT machine and ask someone about the prognosis on his usual machine being down. Another situation which has happened is that a site will be having problems with recieving mail via the network. It's helpful to be able to connect to that site via TELNET and inform someone of the problem! Yet another situation is that someone without an account will connect to talk to a person with an account, to talk to him or ask him a question about his research. Or perhaps he will connect to print a file of information stored here. Or any of a number of reasons of this nature. To attempt to prevent this just because a person hasn't gone through the accounts proceedure would restrict the flow of information, something which is simply not tolerable in a research environment. I once ended up sending mail to ASmith, BSmith, CSmith, etc. at U-TEXAS looking for someone I could ask a question of! All because the site did not allow even finding out who was logged in! (Actually, they did, via an "escape mechanism" of logging in as "WHO" with no password. I had no way of knowing of the convention at the time). I have often made use of all of these capabilities on other sites that support them while not logged in. I have been in every situation I've talked about above, and can personally testify as to the greatly increased difficulty that would result if these capabilities were not there on our machines and other network sites. For the record, the services which we provide while not logged in consist of: LOGIN, ACCOUNT, setting terminal parameters, HELP, online help, PRINT, online messages, mail, and bug-reports, who is logged in, echoing octal values of characters (for people having terminal problems), system load, and time of day. We also allow FTP from other sites to access files without logging into FTP. Many of these capabilities exist on your own site (USC-ISI). I just TELNETed there and found out the time of day and that you are logged in. I did note, however, that I was not allowed to send you a message. Maybe after the length of this message you're grateful for that, but I and others consider it an "unfriendlyness" on the part of your site. Your site does not even support listing and typing files, but forces me to use FTP and the anonymous/arpa. This is a decided inconvenience if you should wish to publicize something by placing it in a file. Most people don't even know of the anonymous/arpa convention, while they could probably figure out how to type a file given the filename. In short (finally) we feel the importance of not sealing ourselves into a hermetic environment is far more important than problems with one or two people sending "unauthorized" messages. Even as obnoxious and undesirable as the Jule's Gilbert messages. I think it is far more apropriate to deal with the occasional problem at its source than to make life harder for everyone else. Restricting sending messages is analogous to restricting who can call you on the telephone to "authenticated users". I'm sure you wouldn't like that! Yet Jules Gilbert's phone calls are as much a problem as his network messages. 17-DEC-79 02:56:31-PST,573;000000000001 Mail-from: MIT-MC rcvd at 16-Dec-79 1259-PST Date: 16 DEC 1979 1525-EST From: RWK at MIT-MC (Robert W. Kerns) Subject: MSGGROUP#1431 Postscript To: MSGGROUP at MIT-MC Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 Hmm. Our mailer wedged sending that Msg to SRI-KL ... It would have been convenient to have been able to send messages to someone there while not logged in (I tried it). I ended up linking instead and interrupting someone. The system forced me to be impolite! 17-DEC-79 02:56:31-PST,722;000000000001 Mail-from: MIT-ML rcvd at 16-Dec-79 1314-PST Date: 16 Dec 1979 1251-PST From: Mark Crispin Subject: MSGGROUP#1432 not logged in mail To: MsgGroup at MIT-ML Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 There is an excellent method of getting in touch with a human at another site. It is called the telephone. To simplify such access, the Network Information Center publishes outstanding documents containing this and other important information. If MIT doesn't believe in using paper, then the same information is available online at SRI-KL by typing NIC after connecting to SRI-KL. ------- 17-DEC-79 02:56:31-PST,2139;000000000001 Mail-from: MIT-MC rcvd at 16-Dec-79 1357-PST From: Gaines at Rand-Unix Date: 16 Dec 1979 at 1334-PST To: RWK at Mit-Mc cc: MSGGROUP at Mit-Mc Subject: MSGGROUP#1433 Re: More about not-logged-in mail In-reply-to: Your message of 16 December 1979 14:12-EST. Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 It is interesting to observe how quickly the capability to do something turns into the "right" to do it in some people's minds. And what a big deal we are making of the "unfriendliness" of a system if it doesn't allow one to communicate with someone logged in when some hacker has a burning question of life-and-death importance in the middle of the night. But personally I opt for strong access controls, and doubt that much of importance comes up that can't wait until morning. The world is not so urgent, and the opportunity for misuse of our interconnected computer systems is quite large. And what about the rights of users to use a system in peace, and especially un-spied upon? Almost all use of "finger" facilities and the like that I have observed can be classed as a form of invasion of privacy. People seem ready to read each other's mail on-line when it can be found unprotected under circumstances which would be considered highly irregular if paper mail were read that way. The clever network hackers snoop all over the place, with little positive benefit that I can see, and plenty of potential for harm. This is not a world in which we leave our houses or cars unlocked, and the "open system" concept makes no more sense to me. It would be lovely if all system users were honest and courteous, but it is naive to expect that they are other than a representative sample of the society in which we live. So let up provide some well-defined paths for those who need to know something about a system, like the phone number of the system administrator from 9am to 5pm, and not dismantle our security and access controls on the silly grounds that someone can't get some on-line help at odd hours. 17-DEC-79 02:56:31-PST,819;000000000001 Mail-from: MIT-ML rcvd at 16-Dec-79 1441-PST Date: 16 Dec 1979 1415-PST (Sunday) From: Lauren at UCLA-Security (Lauren Weinstein) Subject: MSGGROUP#1434 not logged in mail In-reply-to: Your message of 16 Dec 1979 1251-PST To: Admin.MRC at SU-SCORE CC: MSGGROUP at ML Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 The phone is fine for 8-5 sorts of problems. But in my experience, the worst problems seem to occur at "odd" hours (natch!) and those office numbers almost always go unanswered. Often the people you want to contact ARE online but are logged in from home or similiar "unpublished" locales. I have often been stymied by TOPS-20 lack of even allowing links when not logged in ... --Lauren-- ------- 17-DEC-79 02:56:31-PST,2695;000000000001 Mail-from: MIT-ML rcvd at 16-Dec-79 1508-PST Date: 16 Dec 1979 1421-PST (Sunday) From: Lauren at UCLA-Security (Lauren Weinstein) Subject: MSGGROUP#1435 "odd" hours and "rights" To: GAINES at RAND-UNIX CC: MSGGROUP at ML Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 Stockton: My first urge was just to grit my teeth and ignore your last message. But I don't have the will power I'm afraid. Your last message, if I read it right, is a perfect example of what I might term an almost snobbish attitude toward those people who don't work what you would call "regular" hours. Buried in your message was the implication that those "odd" hour people are just hackers who should be willing to wait for the "real" day if they want to do any serious work. Well, first of all, many of us are forced to work offset from the rest of the world through no real desire of our own. There are a multitude of reasons for this which I'm sure you can imagine. Many researchers prefer to work at night when machine loads are low and they don't have to wait hours for crunching. And these people deserve at least a token amount of support from the systems staffs, I would think you would agree. I damn well don't know why we leave these computers running all night if people are not supposed to be able to use them for work! The issues of finger, reading other people's mail, and the like, are not what we are talking about right now. We are discussing the ability to contact a single person on a system that may have 25 persons logged in but nobody at an office phone at 9 PM. I would not think that that would be a hideous intrusion of privacy. There could always be means for individual users, who don't want to bothered by some poor slob who can't get logged in, to avoid being bothered by messages. But it should not be a system-wide decision. If my memory serves me correctly, rand-unix is almost completely dead after ordinary office hours, more so than almost any other site I know of. In such an environment, your attitude might make sense, but for most of the rest of the net, it does not. Somehow, it doesn't seem reasonable to say that, simply because a person isn't living in sync with the 8-5 lifestyle, he/she is some sort of second-class citizen of networkland who should be prevented from reaching people who ARE logged and might well be ready and willing to help. Too much of the world is already set up to insulate us from each other, let's at least make an ATTEMPT not to perpetuate this attitude into this new medium. --Lauren-- ------- 17-DEC-79 02:56:32-PST,1032;000000000001 Mail-from: MIT-MC rcvd at 16-Dec-79 1512-PST Date: 16 Dec 79 17:22-EST (Sun) From: Dcrocker at UDel-EE Reply-to: Dcrocker at Rand-Unix Subject: MSGGROUP#1436 Re: More about not-logged-in mail To: Gaines at Rand-Unix cc: MSGGROUP at Mit-Mc Message-ID: <79349.62579.5630 @ UDel-EE> In-Reply-To: Your message of 16 Dec 1979 at 1334-PST Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 Along the lines of control you suggest, it was interesting to me that the explanation of about the MIT system's making mail-sending available to non-logged-in users did not mention the option of prohibiting arpanet mail going out under the program. The reason cited for allowing the sending was quite reasonable, but did not sound as if it justified letting such users send copies of mail to non-mit sites. (This last re-wording suggests a particular implementation of the check and does not require prohibiting arpanet use, per se.) Dave. 17-DEC-79 02:56:32-PST,1848;000000000001 Mail-from: MIT-ML rcvd at 16-Dec-79 1537-PST Date: 16 Dec 1979 1510-PST From: Mark Crispin Subject: MSGGROUP#1437 not logged in mail To: MsgGroup at MIT-ML Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 I have seldom encountered a problem that could not wait until weekday business hours. If it can't, it is probably due to poor planning on the part of the person with the problem than anything else. Seldom do deadlines for urgent tasks appear without adequate advance warning. If I am logged in from home, then SCORE must be up for users, net mail will work, and will probably be read (at MY leisure) shortly. If I am logged in and SCORE is not up for users, then I probably do not want to be bothered anyway unless it is urgent enough for a phone call to the machine room. And if I'm not logged in and can't be reached by phone (lots of systems, including the "hacker" systems, know my home phone number for dire emergencies), then the person is out of luck. I don't see how not logged in links or mail affects this, except to allow network randoms to harass my users. I don't allow anybody to link to me unannounced; links are slow and painful and if a link is necessary, then the person must send to me and I'll link back. Not logged in mail has the bug that you can't reply to it. The person can't leave a network address, since supposedly his/her system is down, and there might be a 15-30 minute turnaround between when the message is sent and when I get to read it, ASSUMING that I am logged in to begin with. So this doesn't help for "emergencies" either. Anyway, why should ANYBODY have me at their beck and call? I think a 24-hour maximum turnaround is perfectly reasonable. ------- 17-DEC-79 02:56:32-PST,1653;000000000001 Mail-from: MIT-ML rcvd at 16-Dec-79 1600-PST Date: 16 Dec 1979 1526-PST (Sunday) From: Lauren at UCLA-Security (Lauren Weinstein) Subject: MSGGROUP#1438 not logged in mail In-reply-to: Your message of 16 Dec 1979 1510-PST To: Admin.MRC at SU-SCORE CC: MSGGROUP at ML Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 Mark, I'm ashamed of you. I thought I knew you better than that. Who said anything about being at someone's "beck and call" or "dire emergencies"? ** I ** didn't! I simply implied that with the communications system of the net available, not having the OPTION of allowing somebody to reach you is rather silly. There are innumerable ways that such a mechanism could be implemented. There could be a network wide username to represent "someone who could help" (as in LUSERS on the ITS systems). A person could send to that name, and wait a few minutes. If nobody responds, oh well, the person does lose. But if a logged in user wfeels like helping, they can come back with a reply within some predefined timeout interval. Once again, people always have the dual options of: 1) not being on the list of people notified of such "lusers" and/or: 2) not being notified of such mail/messages at any given time. I don't know that needing a little assistance at a funny hour must be a "dire emergency" to qualify as at least being worthy of CONSIDERATION. I vote for individual choice in such matters, not system wide determination of what is going to "bother" or "upset" individual users... --Lauren-- ------- 17-DEC-79 02:56:32-PST,949;000000000001 Mail-from: MIT-ML rcvd at 16-Dec-79 1618-PST Date: 16 Dec 1979 1541-PST (Sunday) From: Lauren at UCLA-Security (Lauren Weinstein) Subject: MSGGROUP#1439 clarification on LUSERS To: MSGGROUP at ML Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 I should add that it was not my intention to imply that ANYONE on a system should be able to add himself/herself to a "help" luser's list (or whatever it would be called.) It WOULD be the job of the system administrators to determine which users should be the ones who would be notified of people needing help, if they WISHED to be notified. In the case of SCORE, this list would be one: ADMIN.MRC In the case of other systems, the list might be much longer. It would at least provide a mechanism for reaching persons WILLING to help without knowing a priori who they are... --Lauren-- ------- 17-DEC-79 02:56:32-PST,1761;000000000001 Mail-from: MIT-ML rcvd at 16-Dec-79 1637-PST Sender: Mike at Rand-Unix Date: 16 Dec 1979 at 1550-PST To: Msggroup at Mit-Ml cc: Mike at Rand-Unix Subject: MSGGROUP#1440 Not-logged-in mail: A SOLUTION? From: Mike at Rand-Unix (Michael Wahrman) Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 Folks, Am I missing the point, or is the following simplistic mechanism a solution to this problem? -- Provide a program which will allow a not-logged-in user to send a message to the system maintainer(s) on that system. -- The mechanism will either have a name standard on all systems (with a reasonably common user interface) or be mentioned by name in a 'help' command available on all systems. Then, a user who can not log in will be able to ask for help, and either be helped immediately if one of the system maintainers is logged in and reads his mail, or be helped the next day. Remote users will not have to know in advance who to send mail to, because there will be a standard alias on all systems. Users will not be able to send mail to remote sites because this mechanism will not allow it. Proposed scenario of the 'HELPME' command: @ HELPME Enter request for help, terminate with ^Z. Please be sure to identify yourself and leave a mailbox or phone number where you can be reached. Enter message: please help me very confused unhappy. account doesnt work files dont print and coke machine ate my quarter. can you please tell me where game about caves and dwarves is? thanks. joe at 444-1212. ^Z @ Comments? Michael Wahrman. 17-DEC-79 18:32:05-PST,923;000000000001 Mail-from: BBN-TENEXD rcvd at 17-Dec-79 0825-PST Date: 17 Dec 1979 1117-EST Sender: BERNSTEIN at BBN-TENEXD Subject: MSGGROUP#1441 Re: Plans for MSGGROUP stratification From: BERNSTEIN at BBN-TENEXD To: STEFFERUD at OFFICE-1 Cc: MsgGroup at MIT-ML Message-ID: <[BBN-TENEXD]17-Dec-79 11:17:16.BERNSTEIN> In-Reply-To: <[OFFICE-1]14-Dec-79 13:35:49.STEFFERUD> Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 Please excuse a relative newcomer to this sometimes rather heated conclave, but I have a little trouble following all the verbiage flying back and forth, and sometimes have to peruse the mail several times to seperate the gold from the pyrite. I wonder if anyone is putting together those things learned in the MSGGroup with the hope of disseminating it to those who sit at the feet of the masters. David Bernstein 17-DEC-79 18:32:05-PST,1209;000000000001 Mail-from: MIT-ML rcvd at 17-Dec-79 1056-PST Date: 17 December 1979 1334-EST From: David Lamb Subject: MSGGROUP#1442 Re: Not-logged-in mail: A SOLUTION? Sender: RdMail at CMU-10A To: Mike at Rand-Unix (Michael Wahrman) CC: Msggroup at Mit-Ml Reply-To: RdMail at CMU-10A Message-ID: <17Dec79 133455 RD00@CMU-10A> In-Reply-To: Michael Wahrman's message of 16 Dec 79 18:50-EST Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 Your solution is a good one for those sites that have the manpower to implement technical solutions. However, I still believe that the telephone is an easier solution in general. CMU's computers have operators 24 hours per day, and the operator phone number is published in the Arpanet Resources Handbook. If other sites that were manned full-time also published such phone numbers, it would go a long way towards solving these problems. I realise that many sites AREN't manned full time, but many sites probably have some number where hacker-types can be found. For example, CMU could also publish the numbers of its terminal rooms or its lounge. David Alex Lamb 17-DEC-79 18:32:05-PST,1178;000000000001 Mail-from: MIT-ML rcvd at 17-Dec-79 1431-PST Date: 17 December 1979 17:08-EST From: Robert W. Kerns Subject: MSGGROUP#1443 not logged in mail To: Admin.MRC at SU-SCORE cc: MsgGroup at MIT-ML Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 Mark, I'm supprised at you! Surely you know more about our situation than your note implies. The number of telephones a person might have to call (long distance!!!) before finding the apropriate person can be very large. (Indeed, Gilbert does call one office after another!) Or he might not even get anybody! One nice feature of mail is that it is asynchronous, as opposed to the telephone, which requires that the person on the other end be there at the same time as you! The telephone is distinctly deficient for this purpose. A telephone call is almost as disruptive as a link! I'd usually rather get mail unless a high baud rate discussion is called for. But much of this discussion misses the point. I don't have time to generate a concise reply o everyone's mail right now, but I'll get to it later. 17-DEC-79 18:32:05-PST,2632;000000000001 Mail-from: MIT-ML rcvd at 17-Dec-79 1711-PST Date: 17 Dec 1979 1646-PST From: Klh at SRI-KL (Ken Harrenstien) Subject: MSGGROUP#1444 Another angle to the site-contact problem To: msggroup at ML Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 The time seems appropriate to explain another viewpoint of the site-contact problem. So far, those opposed to the idea of permitting some form of links or messages while not logged in have consistently focused on the idea that "this is what the telephone number is for". What if the user can't afford the call, or doesn't have a telephone available, or CAN'T USE THE TELEPHONE???? I belong to the latter category. No matter what hours I work or what sites I am involved with (and I am known to work all hours, on a great variety of sites) the only thing I can use a telephone for is computer access. I have frequently been screwed by sites which didn't permit any form of on-line communication without logging in; if it wasn't for the fact that some sites support the RSSER remote linking protocol, I won't have been able to contact the NCC during some periods of urgent need. From this viewpoint, the existence of 24-hour operators only implies that such sites should furnish 24-hour link access to these operators. A "helpme" (or as it currently exists at MIT, "LUSER") function should always exist as a minimum, at any server site. SRI-KL isn't really so bad; for example, saying "talk operator" will search for an on-duty operator to link to. (I like to think this was in response to my complaints that I could never figure out which user out of 100 was the current operator). It is certainly a loss, though, that this isn't allowed until after you log in, and of course you're out of luck if you don't know about the feature. Speaking of obscure features, some people may not know that it is possible to send Mail-from: a TIP, provided you know a single valid address at the site. There was a proposal a while back to settle on some standard name like "SYSTEM" or "HELP" which would be valid at all sites, as a last (or first) resort for those trying to contact SOMEONE. This is still a good idea since it can be used by those without telnet access/knowledge, but doesn't of course obviate the previously mentioned needs -- for cases when the FTP server is dead, or one is dialed in directly, etc. Anyway... any argument advocating the sole use of a voice-transmission telephone can count on my strong opposition. --Ken ------- 26-DEC-79 21:48:36-PST,2713;000000000001 Mail-from: MIT-ML rcvd at 19-Dec-79 1504-PST Date: 19 Dec 1979 1433-PST Sender: STEFFERUD at OFFICE-1 Subject: MSGGROUP#1445 [DICKSON at DEC: Re: Plans for MsgGroup strat... From: STEFFERUD at OFFICE-1 To: MsgGroup at MIT-ML Message-ID: <[OFFICE-1]19-Dec-79 14:33:23.STEFFERUD> Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 Begin forwarded messages Mail-from: DEC-MARLBORO rcvd at 19-Dec-79 0730-PST Date: 19 Dec 1979 1015-EST From: DICKSON at DEC-MARLBORO To: STEFFERUD at OFFICE-1 Subject: Re: Plans for MsgGroup stratification In-reply-to: Message from STEFFERUD at OFFICE-1 of 16-Dec-79 0002-EST You can put my msg in MsgGroup. -------- Mail-from: DEC-MARLBORO rcvd at 15-Dec-79 1239-PST Date: 15 Dec 1979 1531-EST From: DICKSON at DEC-MARLBORO To: STEFFERUD at OFFICE-1 Subject: Re: Plans for MsgGroup stratification In-reply-to: Message from STEFFERUD at OFFICE-1 of 14-Dec-79 1635-EST I like your idea. Put me down for the middle group. Just getting the index would delay things too much for me, since you would proabably wait until you had 50 or 100 messages before sending one out. We are in a design-mode now, and ideas have to get incorporated quickly. I also like the idea of the MSGGROUP# in the subject line. The mail system I use (MS) can't differentiate messages by To: field, so the subject line is the only way available. Now there's an idea: we need to be able to filter incoming messages according to the discussion of which it is a part. With paper mail, you can usually tell, if it is from some organization. The electronic equivalent of an organization of people is the mailing list which contains their names. Since the To: field contains the mailing list name, we can differentiate by that. The RFC733 notation for an expanded list should be used for more ad-hoc groups. Which suggests a way to cheaply implement ad-hoc groups. A variation on the REPLY command to send the reply to both the To: and From: fields (but let us not bring that up again), with the address list enclosed in the NAME:...; brackets, where NAME is either taken from the To: list, if it is there (indicating that the ad-hoc group already exists), or is something supplied with a prompt. Thus an ad-hoc discussion group starts up with just the first sender and those he sends to. Including a large group in the discussion list would be poor ettiquete. You just have to exercise the same care that prevents you from replying to the To: field if you mail program does not protect you from such a faux pas. -------- End forwarded messages 26-DEC-79 21:48:36-PST,842;000000000001 Mail-from: MIT-ML rcvd at 20-Dec-79 0845-PST Date: 20 Dec 1979 0822-PST From: Bair at SUMEX-AIM Subject: MSGGROUP#1446 Re: clarification on LUSERS To: Lauren at UCLA-SECURITY, MSGGROUP at ML cc: bair Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 In response to the message sent 16 Dec 1979 1541-PST (Sunday) from Lauren at UCLA-Security (Lauren Weinstein) I am gathering material that represents the groups activities over the last 5 yrs. I notice many efforts that did not come to fruition but were noble and worthy. The mailing will be relatively expensive so I will send IFIP through you the cost of packaging and mailing the 50 or so pages. I will try to phone Roger Pye. Merry Christmas and Happy New Year. jim ------- 26-DEC-79 21:48:36-PST,844;000000000001 Mail-from: MIT-ML rcvd at 23-Dec-79 1942-PST Date: 23 Dec 1979 1909-PST From: Mark Crispin Subject: MSGGROUP#1447 SU-SCORE host address To: MsgGroup at MIT-ML cc: Feinler at SRI-KL, [SU-SCORE]Tops-20.DIS.22: ; Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 People - I have noticed that a bunch of hosts still think that SCORE is on host address 2/56 (184 decimal, 270 octal, 1204000070 BBN-style). When SCORE moved, its host address also changed because we are now on the same IMP as SAIL. Our new address is 3/11 (203 decimal, 313 octal, 1206000013 BBN-style). Please update your host table or have the responsible person at your host do so. Thank you!! Mark Crispin SCORE Arpanet liaison ------- 28-DEC-79 23:58:00-PST,793;000000000001 Mail-from: MIT-MC rcvd at 27-Dec-79 2028-PST Date: 27 Dec 79 04:10-EST (Thu) From: Farber at UDel-EE Reply-to: Farber at Rand-Unix Subject: MSGGROUP#1448 Quoted without comment To: msggroup at Mit-Mc Message-ID: <79360.15007.6411 @ UDel-EE> Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 The latest copy of Changing Times (one of the "joys" of air travel magazines) comments about future investment opportunities in communications with the statement: "Much effort in the future will be in an area some analysts have begun calling 'telematics', a linking of computers with telecommunications instruments, such as TV sets and telephones." Ah yet another buzz word. Dave 28-DEC-79 23:58:01-PST,603;000000000001 Mail-from: MIT-MC rcvd at 27-Dec-79 2245-PST Date: 27 Dec 1979 2231-PST Sender: STEFFERUD at OFFICE-1 Subject: MSGGROUP#1449 Re: Quoted without comment From: STEFFERUD at OFFICE-1 To: Farber at UDEL-EE Cc: msggroup at MIT-MC Message-ID: <[OFFICE-1]27-Dec-79 22:31:00.STEFFERUD> In-Reply-To: <79360.15007.6411 @ UDel-EE> Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 Chuckle, Chuckle - Dave, I was mightily impressed by your ability to avoid comment. Merry New Year to All Yonder MsgGroupies! Stef 28-DEC-79 23:58:01-PST,597;000000000001 Mail-from: MIT-MC rcvd at 28-Dec-79 1618-PST Date: 28 December 1979 19:09-EST From: "Marvin A. Sirbu, Jr." Subject: MSGGROUP#1450 Re: Quoted without comment To: Farber at RAND-UNIX, STEFFERUD at OFFICE-1 cc: MSGGROUP at MIT-MC Redistributed-To: PUB.LIST;1:, PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 The word "telematique" has been used by the French for some time to describe the intersection of computers and communications. (They also speak of "informatique" and even "bureautique" for office automation!) 29-DEC-79 00:04:59-PST,6255;000000000001 Date: 28 DEC 1979 1634-PST Subject: MSGGROUP#1451 SURVEY [ECL]MSGGROUP#.1401-1450 From: ESTEFFERUD at USC-ECL To: MSGGROUP Redistributed-To: MAIL.LST;11:, Redistributed-To: PUB.LIST;1:, PUBLIC at CCA, Redistributed-To: SURVEY.LIST;1: Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 SURVEY OF MESSAGES FROM FILE [ECL]MSGGROUP#.1401-1450 MSGGROUP#1401 Survey of [ECL]MSGGROUP#.1351-1400;1 5613 chars 9 DEC 1979 0210-PST From: ESTEFFERUD at USC-ECL MSGGROUP#1402 Misuse of MsgGroup mailing list 452 chars 9 Dec 79 13:32-PST From: Greep at Rand-Unix MSGGROUP#1403 Selective perception 993 chars 9 DEC 1979 1923-EST From: rms at MIT-AI (Richard M. Stallman MSGGROUP#1404 Intention to restructure MsgGroup 1854 chars 9 Dec 1979 2054-PST From: STEFFERUD at OFFICE-1 MSGGROUP#1405 Alternatives to MSGGROUP 431 chars 12/10/79 01:16:23 From: RMS@MIT-AI MSGGROUP#1406 An apology for what it seems people thought I was saying 568 chars 12/10/79 02:09:44 From: RMS@MIT-AI MSGGROUP#1407 Stratification and Isolation: The Future of MSGGROUP? 1877 chars 10 Dec 1979 0041-PST (Monday) From: Lauren at UCLA-Security MSGGROUP#1408 The Common Etiquette Issue Re: Selective perception 2349 chars 10 Dec 1979 1622-PST From: STEF at SRI-KA MSGGROUP#1409 Re: Stratification and Isolation: The Future of MSGGROUP? 2001 chars 10 Dec 1979 1730-PST From: STEFFERUD at OFFICE-1 MSGGROUP#1410 The word 'experimental' and other things 993 chars 12/10/79 22:11:40 From: FFM@MIT-MC MSGGROUP#1411 A vote against limitations on MSGGROUP traffic 1505 chars 13 Dec 1979 at 0926-PST From: Gaines at Rand-Unix MSGGROUP#1412 Re: vote against limitations on MSGGROUP traffic 1189 chars 13 December 1979 1301-EST (Thursday) From: Brian.Reid at CMU MSGGROUP#1413 Re: vote against limitations on MSGGROUP traffic 428 chars 13 Dec 1979 1022-PST From: POSTEL at USC-ISIB MSGGROUP#1414 Re: vote against limitations on MSGGROUP traffic 1065 chars 13 Dec 1979 1029-PST From: FYLSTRA at SRI-KL (David Jon Fyls MSGGROUP#1415 No good ideas? 381 chars 13 Dec 1979 at 1106-PST From: Gaines at Rand-Unix MSGGROUP#1416 Re: No good ideas? 560 chars 13 Dec 1979 1305-PST From: POSTEL at USC-ISIB MSGGROUP#1417 STRATIFICATION 957 chars 13 Dec 1979 1318-PST From: Walsh at OFFICE-1 MSGGROUP#1418 options 766 chars 13 Dec 79 16:45-EST Thu From: Dcrocker at UDel-EE MSGGROUP#1419 voila! We learn something. 845 chars 13 December 1979 1721-EST (Thursday) From: Brian.Reid at CMU MSGGROUP#1420 Messages about Messaging 1371 chars 13 Dec 1979 1510-PST From: PICKENS at SRI-KL MSGGROUP#1421 Re: Messages about Messaging 656 chars 13 December 1979 2006-EST (Thursday) From: Brian.Reid at CMU MSGGROUP#1422 Clipping Service 854 chars 13 December 1979 23:21 est From: Frankston.Frankston at MIT MSGGROUP#1423 Re: vote against limitations on MSGGROUP traffic 902 chars 13 Dec 1979 2212-PST From: the tty of Geoffrey S. Goodfellow MSGGROUP#1424 Clipping Service 618 chars 14 December 1979 05:26-EST From: "Marvin A. Sirbu, Jr." PUB.LIST;1:, Redistributed-To: PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 maybe even "bureaucratique". --jon. ------- 29-DEC-79 00:04:59-PST,898;000000000001 Mail-from: MIT-MC rcvd at 28-Dec-79 2122-PST Date: 28 DEC 1979 2058-PST From: ESTEFFERUD at USC-ECL Subject: MSGGROUP#1453 re: quoted without comment To: POSTEL at USC-ISIB, msggroup at MIT-MC Redistributed-To: PUB.LIST;1:, Redistributed-To: PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 In response to the message sent 28 Dec 1979 1635-PST from POSTEL@USC-ISIB From my point of view, it all holds together nicely in terms of semantics. My conclusion is that the theory of bureaucracies will serve very well as the basis for a theory of distributed processes. After all, a bureaucracy is a collection of automomous processing entities that operate together in message coupled mode. Now, where did I see that nice complete theory of bureaucracies? Reductio ad absurdum anyone? Onward MsgGroup! Stef ------- 29-DEC-79 00:04:59-PST,804;000000000001 Mail-from: MIT-MC rcvd at 28-Dec-79 2215-PST Date: 29 December 1979 01:02 est From: Frankston.Frankston at MIT-Multics Subject: MSGGROUP#1454 Re: quoted without comment To: POSTEL at USC-ISIb cc: msggroup at MIT-MC In-Reply-To: Msg of 12/28/79 19:35 from POSTEL Redistributed-To: PUB.LIST;1:, Redistributed-To: PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 29 DEC 1979 About 30 years ago my father named his company Telematic. Turns out, though he wasn't the first -- there was a typewriter company in Chicago (I thnk) with that name. Since then that name has been used by a company (Western Telematic) selling timesharing software for the IBM 1130. Adding new meanings to old words is even more confusing than fresh new buzzwords. 13-JAN-80 21:09:39-PST,1047;000000000001 Mail-from: MIT-ML rcvd at 6-Jan-80 0124-PST Date: 6 Jan 1980 1:07 am (Sunday) From: Becker at PARC-MAXC Subject: MSGGROUP#1455 Electronic Mail Systems To: Farber @ UDEE cc: DCrocker @ UDEE, DCC@MIT-MC, MsgGroup@MIT-ML, Becker Redistributed-To: PUB.LIST;1:, Redistributed-To: PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 14 JAN 1980 I am currently shopping for electronic mail systems that are or will be available on common carriers (ARPAnet qualifies in this case) to provide point to point, broadcast, and in some cases large text file message capability. I would appreciate it if you might let me know about systems available, along with pointers to documentation if you know of any. We are interested in 'user-cordial' systems because the potential users will not be technical people. Our applications also require capabilities for storing and aggregating messages, and indexing them for later retrieval, printing and forwarding. Many thanks for your help. Joe Becker 13-JAN-80 21:09:39-PST,1147;000000000001 Mail-from: MIT-ML rcvd at 10-JAN-80 0226-PST Date: 10 Jan 1980 0200-PST (Thursday) From: Lauren at UCLA-Security (Lauren Weinstein) Subject: MSGGROUP#1456 PBS program on computers and education To: MSGGROUP at ML Redistributed-To: PUB.LIST;1:, Redistributed-To: PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 14 JAN 1980 My local PBS TV station just aired a program called, "Don't Bother Me, I'm Learning." It concerned the use of computers in modern education systems, and was very comprehensive. Uses from game playing with PETs and APPLEs to more serious applications with time-shared mainframes, and everything in between, was discussed. Also briefly considered were items such as special help for the physically and emotionally handicapped that can be provided through computer education systems. Children, of all ages, were shown at all shape and manner of terminal. The one kid I REALLY felt sorry for was trying to work with a HAZELTINE 2000. The poor kid. Anyway, if the program airs in your area, it might be worth your time for a looksee... --Lauren-- ------- 13-JAN-80 21:09:39-PST,2523;000000000001 Mail-from: MIT-ML rcvd at 10-JAN-80 1704-PST Date: 10 Jan 1980 4:41 pm (Thursday) From: Becker.PA at PARC-MAXC Subject: MSGGROUP#1457 Replies to Electronic Meta-Mail To: JILL, DaveSmith, Haeberli, GUYTON, Mike@Rand-Unix, DIEBERT, Lavendel, THORNBURG, Burton, GREEP, MsgGroup@MIT-ML, Karlton, DCrocker@UDEE, DEUTSCH, DCC@MIT-MC, VanLehn, AHenderson, Kaehler, Farrell, Panko, Lauer.PA, Farber@UDEE, SIRBU@MIT-MC, Admin.MRC@SU-SCORE, PBARAN@USC-ECL, Korb, Engelbart@OFFICE-2, Maxion, GONZALEZ@BBN-TENEXD, ALBrown, JZS@CCA, LUKASIK@USC-ISI, Bair@SUMEX-AIM, Malone.Maxc2, INFOMEDIA@BBN-TENEX, Swinehart cc: Becker Redistributed-To: PUB.LIST;1:, Redistributed-To: PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 14 JAN 1980 I'm really grateful to all of you who took time to answer my RFI concerning electronic mail!! A number of you asked to be given a pointer to the replies that I received. I do this with some hesitation, since I did not give any advance warning that I would publish them. I have decided to make them available, mainly on the grounds that one of the fascinating applications of electronic mail is to allow a community of people to pool their knowledge-resources, and I presume that the folks who answered my request are precisely the people who would feel that this is in-keeping with the spirit of the game. But please think twice before deluging each other with requests for information, ESPECIALLY people who were innocent bystanders that were cited secondarily by someone else. Thus warned, you may find a slightly-edited concatenation of the replies on: [MAXC]electronicmail.replies Having said that causes this message to be electronic meta-meta-mail. Nuff said. Point of information for you out-of-towners: I'm not the highly-respected Joseph Becker of information retrieval fame, nor even the former 1st base coach Joe Becker of the Brooklyn Dodgers. I'm another one. By the way, those of you who are interested in the social-impact or sociological side of nationwide consumer electronic networks might well find it worthwhile to dig out DATAMATION of June 1968. This contains a brilliant short story called "In Each of Us a Monster Dwells", by Boris Beizer, which depicts several forms of electronic crime that the network will make possible. Beizer's thinking was 20 years ahead of his time, but it won't be so long now before we're there! Thanks again, Joe Becker 13-JAN-80 21:09:39-PST,1485;000000000001 Mail-from: MIT-ML rcvd at 11-Jan-80 1254-PST Date: 11 January 1980 1448-EST (Friday) From: David.Lamb at CMU-10A Subject: MSGGROUP#1458 message floods and mail protocols To: MSGGROUP at MIT-ML Message-ID: <11Jan80 144819 DL10@CMU-10A> Redistributed-To: PUB.LIST;1:, Redistributed-To: PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 14 JAN 1980 The enclosed note mentions a problem that some of us should be thinking about. The particular mailing list mentioned places a severe strain on the host whenever it is used. Right now, the only ways I know of avoiding such floods require a lot of manual intervention, and much less convenience than using mailing lists. David Alex Lamb - - - - Begin forwarded message - - - - Date: 10 JAN 1980 1338-EST From: MOON5 at MIT-AI (David A. Moon) To: SF-LOVERS at MIT-AI Via: MIT-AI; 10 Jan 1980 1455-EST Please limit yourselves to 2 or 3 messages a day. I hate to be fascist about this, but at present the redistribution of SF-LOVERS mail is using up an entirely unacceptable amount of our highly-overloaded computer. Bear in mind that when you send a message to SF-LOVERS, it is going to over 225 people. This means that you are committing about an hour of computer time, several hundred tenex-pages worth of disk storage, and at least 3 hours of human time. If you have a trivial remark to make, keep it to yourself. - - - - End forwarded message - - - - 13-JAN-80 21:25:55-PST,1548;000000000001 Mail-from: MIT-ML rcvd at 12-Jan-80 1711-PST Date: 12 January 1980 19:58 est From: Frankston.Frankston at MIT-Multics (Bob Frankston) Subject: MSGGROUP#1459 After the deluge To: send_mail.bugs at MIT-Multics cc: msggroup at MIT-ML Message-ID: <800113005824.513572 at MIT-Multics> Redistributed-To: PUB.LIST;1:, Redistributed-To: PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 14 JAN 1980 I think the recent set of messages points out the need for elimination of duplicate messages by the recipient mail reading programs. A message ID would make this easier. The increasing number of messages and discussion groups points up the need for better dialogue control and ordering faiclities. The duplicate elimination is a minimal part of such a facility. Other facilities such as the ability to select messages by a topic (or keyword) are soon going to become necessary. I realize that these are old issues, but finding fifty messages, mostly duplicates for a single discussion is annoying. Finding 200 for intertwined conversions will be unmanageable. PS: I am not complaining about the messages themselves, in fact I am glad to see mechanisms being stretched to the point where the initerim kludges will have to be reexamined. I hope the result is improved design (such as multiple recipients for FTP) rather than simply outlawing such lists. Unfortunately the current model for the use of the net for such discussions is that the resources required be negligable. 24-Feb-80 12:28:58-PST,2760;000000000001 Mail-from: MIT-ML rcvd at 13-Jan-80 1543-PST Date: 13 Jan 1980 1519-PST From: Zellich at OFFICE-1 Subject: MSGGROUP#1460 Re: After the deluge To: MsgGroup at MIT-ML Redistributed-To: PUB.LIST;1:, Redistributed-To: PUBLIC at CCA Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 14 JAN 1980 In reply to the message from Frankston.Frankston at MIT-Multics (Bob Frankston), 12 January 1980 19:58 est Indeed... If we have finally gotten to the point where the various kludges (especially the very convenient mail-forwarders) strain the capacity of the networks hosts, maybe someone will begin on the next generation of mail facilities. It seems to me that two basic things are needed: 1. Multiple FTP recipients -- along with this, the sending mailer should have the courtesy to filter out duplicate addresses. 2. Mail sending programs should make use of address lists rather than putting a heavy burden on someone else's hosts with mail- forwarders. Since it is unreasonable to expect every member of a group to keep a current copy of all necessary group-address lists somewhere on his/her host, something like the NIC WHOIS facility should be used: Where the address-list specified to the mailer could be an off-host file-name. Since this would put an unreasonable burden on the NIC host, the WHOIS database would necessarily have to be a distributed one -- I've heard/read of several workable-sounding proposals along this line; it's just a matter of some loud discussion to choose one such method for net-wide implementation (this may be required, anyway, to satisfy DCA's god-awful desires for TIP and TELNET Login/Access- controls in the near future). While I don't think any of the above is all that difficult, technically, I realize that almost all of us have resource problems and the above possible solutions couldn't be accomplished overnight. I don't, however, see anything to prevent the required protocols from being defined and individual mailers and FTP servers thereafter being upgraded on an individual basis. At any rate, we can't go on swamping the MIT systems with mail frequently having little or nothing to do with the economic justifications for the existence of those hosts. ...and the sooner the better. Electronic mail is becoming VERY important to the conduct of day-to-day business and next-generation mail systems are already being developed. We should have at least the specifications for the new facilities before too many new mail systems are implemented, or the changeover to more-rational procedures will be extremely expensive. Rich ------- 24-FEB-80 12:28:58-PST,917;000000000001 Mail-from: MIT-ML rcvd at 15-Jan-80 1844-PST Date: 15 Jan 1980 (Tuesday) 2130-EDT From: DREIFU at WHARTON (Henry Dreifus) Subject: MSGGROUP#1461 SAVE-LARGE-LISTS mailings To: msggroup at MIT-ML Redistributed-To: PUB.LIST;1: Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 25 FEB 1980 Have any of you been following the melee of events spurred by the overloading of massive amounts of mail being processed by lists over 200 names long. Also is anyone interested in creating a new protocol (TCP I think is the newest nickname for these) to solve this problem? Perhaps a FTP style retrieval, with a negotiation initially to determine how much of the file should be transported, and have this running in the background. It would clean up on disk space, as Geoff or Lauren pointed out it costs 7MB or so of storage/list. Also just how efficient is the mail process? /Hank 24-FEB-80 12:28:58-PST,1787;000000000001 Mail-from: MIT-ML rcvd at 15-Jan-80 2233-PST Date: 15 Jan 1980 2212-PST From: Mark Crispin Subject: MSGGROUP#1462 implementation note to mailsystem implementors To: MsgGroup at MIT-ML cc: Header-People at MIT-MC Redistributed-To: PUB.LIST;1: Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 25 FEB 1980 This note is addressed to anybody likely to implement or work on a program which will send FTP mail. It is well-known that for Multics sites you must send USER NETML followed by PASS NETML (and that NETML must be all upper case). What isn't as well-known is that the Multics FTP server sends TELNET protocol commands; in particular, you are likely to encounter IAC GA in your data stream. If your user program is unprepared to handle this, you are likely to get into trouble (he says from sad experience). In the strictest sense, Multics is not violating protocol either by requiring NETML login or by sending the TELNET protocol commands. Both are explicitly allowed by the published protocol. However, standard usage has been that no TELNET protocol commands are used, although one or two other sites have used old TELNET protocol to implement the ABOR feature. The moral is: to be as robust as possible don't use TELNET protocol or require NETML login, but be prepared to accept TELNET protocol or to be told to use NETML at any time from any host. -- Mark -- PS My apologies to those who received this message twice, or to those of you who already knew all this. I didn't know about the TELNET protocol part (neither did the author of the mailer daemon I am using); had I known before this several hours of my time and quite possibly a system reload might have been prevented. ------- 24-FEB-80 12:28:58-PST,1357;000000000001 Mail-from: MIT-ML rcvd at 19-Jan-80 2334-PST Date: 20 JAN 1980 0222-EST From: RMS at MIT-AI (Richard M. Stallman) Subject: MSGGROUP#1463 Large mailing lists To: msggroup at MIT-ML Redistributed-To: PUB.LIST;1: Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 25 FEB 1980 I've proposed a new feature for large mailing lists. Instead of asking to receive all messages sent to the mailing list, a user could ask to be notified after each day if there was mail sent to the list that day. He could read the messages from a log file in a standard place. The notification would be useful since most mailing lists go through bursts of activity between long periods of dormance. For many users, the advantage of a mailing list over a log file is that they find out automatically when the list becomes active, With just a log file, they have to remember to check it regularly, and since there will usually be nothing new in the file, it they become discouraged and don't check very often; when a discussion does start, nobody finds out about it for a while so it can't really get anywhere. Notifications should be enough to avoid these problems. Also, if the format of notifications is standardized, a mail reader program can have a command to show the log file, taking the name from the notification message. 24-FEB-80 12:28:58-PST,2008;000000000001 Mail-from: MIT-ML rcvd at 20-Jan-80 0850-PST Date: 20 Jan 1980 0832-PST From: Zellich at OFFICE-1 Subject: MSGGROUP#1464 Re: Large mailing lists To: MsgGroup at MIT-ML Redistributed-To: PUB.LIST;1: Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 25 FEB 1980 In reply to the message from RMS at MIT-AI (Richard M. Stallman), 20 JAN 1980 0222-EST Yes, but remember that we have users from a diverse number of sites, who are used to using their own brand of operating system, mail program, etc., and also have accounts only on those systems. Unless someone wants to fund one or more hosts strictly for BBOARD mail-storage and random logins to read the mail, a "standard log file" is kinda hard to implement. We have 225+ users on the SF-LOVERS distribution now -- what happens when they all start logging in on one [set of] machines to read the mail instead of having it sent to them? I have no argument with BBOARDS, or similar facilities, per se, but someone has to pay for them and we're talking about LARGE communities of users here. I think it would be extremely nice for each host to have the same redistribution facility that MIT-xx has. Then we could set up the initial distribution list to be to an address on each host and then the hosts could redistribute to their own users. It's not "fair" for a small set of sites to bear the cost of supporting the entire network (unless specifically established and funded for it, of course, which could be a future possibility if DCA and/or the Sponsors decided that such was functionally necessary to the functioning of the military and official research projects). Does anyone know how many users are represented on the following lists: MsgGroup at MIT-ML, Header-People at MIT-ML, INFO-PCNET at MIT-MC, HOME-SAT at MIT-AI, TELETEXT at MIT-AI, HUMAN-NETS at MIT-MC (Human-Nets is combination of PCNET, HomeSat & Teletext lists), Telephone-Network- People at MIT-MC Rich ------- 24-FEB-80 12:28:58-PST,1001;000000000001 Mail-from: MIT-ML rcvd at 20-Jan-80 0939-PST Date: 20 January 1980 12:27-EST From: "Marvin A. Sirbu, Jr." Subject: MSGGROUP#1465 Re: Large mailing lists To: MsgGroup at MIT-ML, Zellich at OFFICE-1 Redistributed-To: PUB.LIST;1: Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 25 FEB 1980 The idea of each host implementing redistribution would seem to avoid some of the problems of multiple inter-host message passing, but not all. I would still need to send my message to say MSGGROUP@ML from which it would be distributed to MSGGROUP@MC, MSGGROUP@OFFICE-1, MSGGROUP@CMU, etc. In fact, this is what is already being done within the ITS machines. One host would still be the focal point, although I admit that the traffic through that host would be reduced considerably. Alternatively, many hosts would have to maintain an address list of hosts having MSGGROUP members, and we're back to the distributed directory problem of RFC 757. 24-FEB-80 12:28:58-PST,2043;000000000001 Mail-from: MIT-ML rcvd at 20-Jan-80 1024-PST Date: 20 January 1980 1303-EST (Sunday) From: Brian.Reid at CMU-10A Subject: MSGGROUP#1466 Large lists: the next time people talk about ... To: MsgGroup at MIT-ML Message-ID: <20Jan80 130326 BR10@CMU-10A> In-Reply-To: "Marvin A. Sirbu, Jr."'s message of 20 Jan 80 12:27-EST Redistributed-To: PUB.LIST;1: Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 25 FEB 1980 Arpanet mail has been in existence since the early 1970's. Many of us who think a lot about mail delivery issues in a more abstract sense have certainly contemplated such problems as this "what do we do with a huge mailing that is saturating our machine" problem. But it has finally appeared, in the flesh, and the network systems people are beginning to approach it as a real, serious, and growing problem in the extension of our network mail world to larger communities. I would like to make sure that everybody notices that this deadly serious issue came up in the context of a science-fiction mailing list. And furthermore to note that it @i[didn't] come up enough to attract any attention during any of the "government business" mailing lists. As talk abounds about proper use of the arpanet, and its military funding begins to loom over its users more and more, I would like to point out to everyone that if the purpose of the Arpanet is to support research in computer and communication science, at the vanguard of technology, then it is essential to allow such things to continue. Now it may be that the official purpose of the Arpanet is no longer to support research but to carry out Government business--I really don't know the Policy From On High these days--but if it is still viewed as a research vehicle, then let's make sure that as this new year starts and this new decade starts, we all remember that serious and challenging research issues @i[and the energy to attack them] come from seemingly "frivolous and wasteful" use of the network. Brian 24-FEB-80 12:28:58-PST,1045;000000000001 Mail-from: MIT-ML rcvd at 20-Jan-80 1051-PST Date: 20 Jan 1980 1037-PST From: Zellich at OFFICE-1 Subject: MSGGROUP#1467 Re: Sirbu reply to "Re: Large mailing lists" To: MsgGroup at MIT-ML Redistributed-To: PUB.LIST;1: Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 25 FEB 1980 Ah, but one host would no longer have to be the focal point...MsgGroup could be "centered" on the host where it used to be (and where the indexing, etc. still takes place). All (or at least many) hosts providing this facility would allow distribution of the initial redistribution load as well as the follow-on fanout at each host. There would still remain the problem of talking someone at each host into establishing the directory, providing address-list disk space, and alowing use of CPU cycles for all the interest-groups desired by the users at those hosts. I imagine some of the site administrators would be rather hard-nosed about such things as SF-LOVERS, recipe- exchanging groups, etc. Rich ------- 24-FEB-80 12:28:59-PST,688;000000000001 Mail-from: MIT-ML rcvd at 20-Jan-80 1133-PST Date: 20 January 1980 14:25 est From: Frankston.Frankston at MIT-Multics Subject: MSGGROUP#1468 Re: Large mailing lists To: RMS at MIT-AI (Richard M. Stallman) cc: msggroup at MIT-ML In-Reply-To: Msg of 01/20/80 02:22 from Richard M. Stallman Redistributed-To: PUB.LIST;1: Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 25 FEB 1980 It would seem that notification could be implemented at the descretion of the reciever. A notify attribute associated with a user in the NAMES file would cause that user to get only notification not the text of the message. Other could still recieve the message. 224-FEB-80 12:28:59-PST,1608;000000000001 Mail-from: MIT-ML rcvd at 20-Jan-80 1201-PST Date: 20 Jan 1980 (Sunday) 1447-EDT From: DREIFU at WHARTON (Henry Dreifus) Subject: MSGGROUP#1469 More in the battle To: msgroup at MIT-ML Redistributed-To: PUB.LIST;1: Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 25 FEB 1980 I would like to make the following observations: 1] Why should we be constrained by ONE host, that is a serious problem especially if one considers getting DCA to fund a monster, that would NEVER fail, nor lose 'a message' 2] The problem with the conjestion of a given machine is a serious one, which Roger Duffey (DUFFEY@MIT-AI) is experimenting with, namely a digest approach...but that is only a stop-gap, not a solution. 3] It would be reasonable to predict that lists of over 400 people would become a common site in the next 5-10 years. 4] Postel et al are working on some of this with their work on distribution once a message came to a site, eg: In the header there would be information on how to distribute the mail locally (LCS nets included) 5] Another idea to think about is to have the user's stagger recption of mail messages. For example a small study could be done to determine when a site 'reads its mail' and stagger the delevery as needed. Staggering the mail transmission will keep the network at a steady load, rather than peaking/overloading parts of it...etc... 6] Notes: For [4] the RFC is 753, Roger Duffey is mending the SAVE-LARGE-LISTS mailing list. Hank 24-FEB-80 12:28:59-PST,2852;000000000001 Mail-from: MIT-ML rcvd at 20-Jan-80 1638-PST From: RMS@MIT-AI Date: 01/20/80 19:19:12 Subject: MSGGROUP#1470 Correcting misunderstandings from my suggestion Redistributed-To: PUB.LIST;1: Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 25 FEB 1980 RMS@MIT-AI 01/20/80 19:19:12 Re: Correcting misunderstandings from my suggestion To: msggroup at MIT-ML There is no reason why there has to be only one log file on only one host, if that isn't the most convenient thing. If there is a use for a log file on another host, because there are several users there who want to read it, by all means think of having one there. All that matters is that each user know where he can find a log file to read ("a log file in a standard place", is what I suggested). The issue has been raised of the difficulty of implementing any sort of "standard" log file format. There's no need to do any such thing. The log files on machine X would probably be in whatever format the mailer on machine X likes to make log files in, or might look like a mailbox, which would allow people to read it using mail reading software. This way, no new software is needed to keep a log file at machine X. Only sites that want to support sending the notifications require any work to be done. Since this is an internal issue for each system there is no reason to worry about it any further. (By the way, I just checked the text of my original message and I didn't say anything about a standard format for log files, so it was just a misunderstanding). IF a particular mailing list decides to keep only one log file, on only one machine, and IF that machine keeps log files in a funny format, then people might be unable to FTP the log file and read it locally. They would have to TELNET there and read it that way, using the software that understands the funny format. But people wouldn't generally want to FTP log files. The log files will be long, with lots of old messages in them. It would be much faster to TELNET and read the interesting recent part than to wait for the whole file to FTP. So there really isn't a problem. This is not to say that we shouldn't make all hosts able to redistribute. That is also a good idea. I think this one might be useful in addition. Even considering just one host, notifications save a lot of disk space for multiple copies of the message. They also might benefit hosts which don't have the manpower to implement redistribution. If MIT implemented notifications, we wouldn't mind sending several people there one message a day, when we might not be able to accept sending each of them a dozen messages a day. Especially since the notifications could be sent out at some off-peak time when nobody would notice, like 7am, when everyone has gone home. 24-FEB-80 12:28:59-PST,1693;000000000001 Mail-from: MIT-ML rcvd at 21-Jan-80 0237-PST Date: 21 January 1980 02:32-EST From: Robert W. Kerns Subject: MSGGROUP#1471 Large lists: next time people talk about misuse. To: Brian.Reid at CMU-10A cc: MsgGroup at MIT-ML Redistributed-To: PUB.LIST;1: Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 25 FEB 1980 Actually, MsgGroup and Header-People lists have overloaded our machine a lot longer than things like SF-lovers. The problem has been with us for years, but when there were only a few problem lists, and they were often quiescent, it could be ignored, although we knew the question would have to be faced someday. And when the crunch came, it was not only SF-lovers that was the cause. SF-lovers was just the most expendable one, the one that would be deleted if no other solutions were found. It's definitely not true that "it didn't come up enough to attract any attention during any of the 'government business' mailing lists." Indeed, one of the other major troublemakers was a collection of list known say "HUMAN-NETS" which includes various MsgGroup spinoffs! Of course, it hasn't been readily visible to most people, since only MIT has been providing mail-forwarding service for the rest of the net. We're the only ones who've had to put up with the problem so far. We've been aware of it for years, but I would have thought the rest of the world would be providing local forwarding by now and taken the heavy load away from us. But since local forwarding hasn't become prevelant (often due to continued reliance on certain BBN crocks with no maintainance) growth has inevitably caught up with us. 24-FEB-80 12:28:59-PST,2020;000000000001 Mail-from: MIT-ML rcvd at 21-Jan-80 0239-PST Date: 21 January 1980 03:04-EST From: Robert W. Kerns Subject: MSGGROUP#1472 Large mailing lists To: Zellich at OFFICE-1 cc: MsgGroup at MIT-ML Redistributed-To: PUB.LIST;1: Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 25 FEB 1980 Date: 20 Jan 1980 0832-PST From: Zellich at OFFICE-1 To: MsgGroup at MIT-ML Re: Large mailing lists In reply to the message from RMS at MIT-AI (Richard M. Stallman), 20 JAN 1980 0222-EST Yes, but remember that we have users from a diverse number of sites, who are used to using their own brand of operating system, mail program, etc., and also have accounts only on those systems. Unless someone wants to fund one or more hosts strictly for BBOARD mail-storage and random logins to read the mail, a "standard log file" is kinda hard to implement. We have 225+ users on the SF-LOVERS distribution now -- what happens when they all start logging in on one [set of] machines to read the mail instead of having it sent to them? I have no argument with BBOARDS, or similar facilities, per se, but someone has to pay for them and we're talking about LARGE communities of users here. I think it would be extremely nice for each host to have the same redistribution facility that MIT-xx has. Then we could set up the initial distribution list to be to an address on each host and then the hosts could redistribute to their own users. It's not "fair" for a small set of sites to bear the cost of supporting the entire network (unless specifically established and funded for it, of course, which could be a future possibility if DCA and/or the Sponsors decided that such was functionally necessary to the functioning of the military and official research projects). Does anyone know how many users are represented on the following lists: Rich 24-FEB-80 12:28:59-PST,729;000000000001 Mail-from: MIT-ML rcvd at 21-Jan-80 0241-PST Date: 21 January 1980 03:13-EST From: Robert W. Kerns Subject: MSGGROUP#1473 Large mailing lists To: Zellich at OFFICE-1 cc: MsgGroup at MIT-ML Redistributed-To: PUB.LIST;1: Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 25 FEB 1980 Counts of the number of people on various mailing lists: MsgGroup(157*) Header-People(75) , INFO-PCNET(88), HOME-SAT (153), TELETEXT(81), HUMAN-NETS (about 200), Telephone-Network-People(43), INFO-EMACS(196*) MsgGroup and INFO-EMACS are locally distributed to a degree, this does not take that into account. This list is not at all a complete listing of large mailing lists. 24-FEB-80 12:28:59-PST,887;000000000001 Mail-from: MIT-ML rcvd at 21-Jan-80 0242-PST Date: 21 January 1980 03:23-EST From: Robert W. Kerns Subject: MSGGROUP#1474 (oops) Large mailing lists To: Zellich at OFFICE-1 cc: MsgGroup at MIT-ML Redistributed-To: PUB.LIST;1: Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 25 FEB 1980 Sorry for the garbage inclusion of most of your message. What I meant to send you was the sizes of the various mailing lists. I don't know what went wrong. Anyway, here's the info I meant to send: MsgGroup(157*) Header-People(75) , INFO-PCNET(88), HOME-SAT (153), TELETEXT(81), HUMAN-NETS (about 200), Telephone-Network-People(43), INFO-EMACS (200*) * MsgGroup and INFO-EMACS are locally distributed to a degree, this does not take that into account. This list is not at all a complete listing of large mailing lists. 24-FEB-80 12:28:59-PST,604;000000000001 Mail-from: MIT-ML rcvd at 21-Jan-80 0321-PST Date: 21 Jan 1980 0312-PST Sender: SDSAN-DMS at SRI-KA Subject: MSGGROUP#1475 Re: Large mailing lists From: SDSAN-DMS at SRI-KA To: Frankston.Frankston at MIT-MULTICS Cc: msggroup at MIT-ML Message-ID: <[SRI-KA]21-Jan-80 03:12:53.SDSAN-DMS> In-Reply-To: Your message of 20 January 1980 14:25 est Redistributed-To: PUB.LIST;1: Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 25 FEB 1980 On SRI-KA, OFFICE-1 and OFFICE-2, we have: SRI-KA.Community 268 OFFICE-1.Community 95 Office-2.Community 78 Tom Bowerman 24-FEB-80 12:28:59-PST,1203;000000000001 Mail-from: MIT-ML rcvd at 21-Jan-80 0708-PST Date: 21 Jan 80 09:39-EST (Mon) From: Dcrocker at UDel-EE Reply-to: Dcrocker at Rand-Unix Subject: MSGGROUP#1476 Re: Large lists: next time people talk about ... To: Robert W. Kerns cc: MsgGroup at Mit-Ml Message-ID: <8020.34790.4761 @ UDel-EE> In-Reply-To: Your message of 21 January 1980 02:32-EST Redistributed-To: PUB.LIST;1: Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 25 FEB 1980 As a point of reference, there exist some Unix sites which are able to do "group" forwarding. The facility is based upon a VERY simple name-expansion mechanism and seems to work quite smoothly. When Delaware comes onto the net as a full host (soon...) we intend to offer some assistance, partly to see what the load is like on a relatively tailored distribution system. As it is, now, there is already a (very) small degree of list- distribution going on. For example, the Rand-Unix MsgGroup recipients get a single copy from MIT, to Rand, and Rand-Unix expands the copies to one-per-local-recipient. Perhaps some other sites should be encouraged to assume their fair share of the load? Dave. 24-FEB-80 12:28:59-PST,649;000000000001 Mail-from: MIT-MC rcvd at 21-Feb-80 1831-PST Date: 21 Feb 80 20:36-EST (Thu) From: Farber at UDel-EE Reply-to: Farber at Rand-Unix Subject: MSGGROUP#1477 Preliminary announcment of Symposium To: list: Message-ID: <8051.74167.9630 @ UDel-EE> Redistributed-To: PUB.LIST;1: Redistributed-By: MSGGROUP at USC-ECL Redistributed-Date: 25 FEB 1980 IFIPS TC6 will be sponsoring a Symposium on Computer Message Systems in 1981. The Symposium is scheduled in early April 1981 and will be in Ottawa Canada. Announcements of the Symposium will be mailed out in the near future. Start thinking of papers etc. Dave 3-Mar-80 15:03:57-PST,2332;000000000001 Mail-from: MIT-ML rcvd at 3-Mar-80 1204-PST Date: 3 Mar 1980 1022-PST From: KLH at SRI-KL Subject: MSGGROUP#1478 Teacher's Dirty Looks? To: msggroup at ML, human-nets at AI Redistributed-To: PUB.LIST;1: Redistributed-By: STEFFERUD at OFFICE-1 Redistributed-Date: 3 Mar 1980 This doesn't specifically involve electronic mail, but like many others I am taking advantage of existing mailing lists to reach the appropriate people... What I'm wondering is what sort of influences computers are having on our use and style of language. I'm not interested so much in "jargon" peculiar to the field, since every field has its own vocabulary; I'm thinking about linguistic changes resulting from the heavy use of computer or command languages. For example, there is a standard of english usage which says specifically that any punctuation coming immediately after a quoted or parenthesized clause should be included within these quotes or parentheses (as in this example.) However, in all my writings now I persistently put such punctuation AFTER them (such as this example). This almost certainly results from my experiences with computer language parsing, where using the "style standard" will INVARIABLY and IMMEDIATELY produce negative feedback... just compare these two statements: strvar = "arbitrary string"; /* Machine */ strvar = "arbitrary string;" /* English teacher */ Of course this is a fairly obvious example, which has given my editors (the human type) chronic indigestion; their red pencils wage a perpetual feud with my notions of English parsing. It is also more of a representational matter than a linguistic one. But it makes me wonder what other less apparent effects exist now, or will in the future, as computers become ubiquitious and higher-level artificial languages evolve to manipulate them. I would theorize that people will adapt to machine logic much faster than the converse; at the moment this may only be visible at the printed-text level, but the development of sophisticated speech-recognition devices might produce some interesting side effects as people discover their use requires more precision of thought and intonation than one addresses to human service personnel. Any others have related experiences? --Ken ------- 5-Mar-80 01:15:08-PST,1193;000000000001 Mail-from: MIT-ML rcvd at 3-Mar-80 2015-PST From: JNC@MIT-AI Date: 03/03/80 22:45:25 Subject: MSGGROUP#1479 Parsing.. Redistributed-To: PUB.LIST;1: Redistributed-By: STEFFERUD at OFFICE-1 Redistributed-Date: 5 Mar 1980 JNC@MIT-AI 03/03/80 22:45:25 Re: Parsing.. To: msggroup at MIT-ML, human-nets at MIT-MC With refernce to KLH's example and to his comments about human usage being easier to change: I think that the habits of the computer are usually easier to change, as well as usually being wrong. Computers should be people's slaves, not the other way around, as things like cars and TV have become. But that does not mean taht I am wholesale in favour of retaining "peopleisms". The case with punctuation is a case in point: I would rather see the standard be the machine one, because it seems more logical (to me, at least). Sometimes there are silly things in human habits that could benefit from being changed. (Another possible, although more far fetched example is the base of our number system. Remember the Kzinti? You can tell how long a species has had computing machines by observing the base they count in!) Comments? 5-Mar-80 01:15:08-PST,2842;000000000001 Mail-from: MIT-ML rcvd at 4-Mar-80 1357-PST Date: 4 Mar 1980 1553-EST Sender: MOOERS at BBN-TENEXA Subject: MSGGROUP#1480 Re: Teacher's Dirty Looks? From: MOOERS at BBN-TENEXA To: KLH at SRI-KL Cc: msggroup at ML, human-nets at AI, Mooers Message-ID: <[BBN-TENEXA] 4-Mar-80 15:53:15.MOOERS> In-Reply-To: Your message of 3 Mar 1980 1022-PST Redistributed-To: PUB.LIST;1: Redistributed-By: STEFFERUD at OFFICE-1 Redistributed-Date: 5 Mar 1980 I'm not sure that your example about punctuation with parentheses and quotes is actually accepted English style. The University of Chicago Press, A MANUAL OF STYLE, pretty consistently punctuates according to logic, placing the period before or after the parthesis or quote according to the sense and structure of the sentence. I have heard of the rule you give, but the typographer who dicussed it in a class I once took in professional copyediting said that it was used only for typeset material, where the period or comma is much thinner than the quotes or parens. Some typographers feel that the period all alone, after the quote, looks lonely ... and more to the point, is apt to get broken if it is placed at the end of the line in hand-set type. That's not very relevant today. My pet example of bad typography caused by the influence of computers is the over-long line length used by many computer people. Because Hollerith cards were originally made the size of the old-style dollar bill, they were had 80 columns. That is, the number of columns was set by the mechanical limitations of the machinery and the size of the card. This became the standard "record" size for IBM computers. Therefore, scope terminals have 80 characters to the line. Therefore, people come to believe that this is a "natural" length for a line of text. Actually 80 characters is much too long for comfortable reading, and the difficulty is compounded when the text is single-spaced. The 72-character line, which is the longest that can be fitted on an 8-1/2 inch paper width, with stingy margins, is also too long. You will almost never find line lengths of 72 characters in printed matter designed by professional typographers. The funny thing is, that when you print text with difficult- to-read typefaces (such as the fuzzy, single-width characters produced by most lineprinters) and with too-long lines, many readers blame the authors for the fact that the stuff is unreadable, when actually the text is illegible. In this case, alas, people have not become more logical and precise because they are exposed to computers. They have merely accepted the conventions associated with some computers, without pausing to investigate whether an 80-column line really is a reasonable length of line to read. ---Charlotte Mooers 5-Mar-80 01:15:08-PST,2758;000000000001 Mail-from: MIT-ML rcvd at 4-Mar-80 2019-PST Date: 4 Mar 1980 2146-EST From: SWG at MIT-DMS (S. W. Galley) To: SWG at MIT-DMS, KLH at SRI-KL Cc: msggroup at MIT-ML, human-nets at MIT-AI In-reply-to: Message of 03 Mar 80 at 1022 PST by KLH@SRI-KL Subject: MSGGROUP#1481 [Re: Teacher's Dirty Looks?] Message-id: <[MIT-DMS].139210> Redistributed-To: PUB.LIST;1: Redistributed-By: STEFFERUD at OFFICE-1 Redistributed-Date: 5 Mar 1980 Your question raised an issue that I would like to comment on at length in another message. But first, let me say that quotation marks are a better example of "illogical" style in (American) English syntax than are parentheses: the style manuals that I consulted gave "logical" rules for placing parentheses with respect to periods and the like. For example, the University of Chicago Press (eleventh edition, 1949) says: The period is placed inside the quotation marks for appearance' sake. Put it inside the parentheses or brackets when the matter inclosed is an independent sentence forming no part of the preceding sentence; otherwise, outside: Tennyson's "In Memoriam." Put the period inside the quotation marks. (This is a rule without exception.) When the parentheses form a part of the preceding sentence, put the period outside (as, for instance, here). I used such a long quote here to show other illogicalities (e.g. "appearance'" rather than "appearance's") and their (essential?) justification: APPEARANCE. The British seem to have more concern for logical syntax. Nicholson's "A dictionary of American-English usage: based on Fowler's modern English usage" (Oxford, 1957) says In US the following rules are generally observed. Periods and commas are always placed inside the quotation marks. . . . Exclamation marks, question marks, semicolons, and colons go inside if they are part of the quotation, outside if they belong to the main sentence. . . . In Brit. usage (as also older US usage) there is no difference in the treatment of the various kinds of punctuation; all are placed in accordance with their relation to the sentence--i.e. as are exclamation marks &c. in modern US usage. I think the main point here is that human editors are as much concerned with form as with content, and that the human audience will understand the content regardless of the form. (Perhaps children, to the extent that they care about such things, would prefer logical rules to esthetic ones, simply because logical rules are easier to remember. Perhaps children will more easily communicate with machines (as peers?) than will adults, because children tend to know the rules better than the exceptions.) 5-Mar-80 01:15:08-PST,1447;000000000001 Mail-from: MIT-ML rcvd at 4-Mar-80 2204-PST Date: 5 Mar 1980 0045-EST Sender: MOOERS at BBN-TENEXA Subject: MSGGROUP#1482 Re: [Re: Teacher's Dirty Looks?] From: MOOERS at BBN-TENEXA To: SWG at MIT-DMS Cc: KLH at SRI-KL, msggroup at MIT-ML, human-nets at MIT-AI, Cc: Mooers Message-ID: <[BBN-TENEXA] 5-Mar-80 00:45:45.MOOERS> In-Reply-To: <[MIT-DMS].139210> Redistributed-To: PUB.LIST;1: Redistributed-By: STEFFERUD at OFFICE-1 Redistributed-Date: 5 Mar 1980 A brief comment on your comment. You looked deeper into the Chicago Manual of Style than I did -- but I am sure (a) that the "modern US" rule for quotes is not followed as generally as the Manual od Style says, particularly in text written on a typewriter (because of the single-width characters), and (b) that the rule applies only to periods and commas, not large punctuation marks like question marks. In some type faces, the periods an commas can be "kerned" under the quotation marks, and also under letters such as y, so that the reader doesn't see a large gap between the last letter and the quote, even when the period or comma is present. That's logical, really. Also the usage "appearance'" instead of appearance's" is quite logical. The writer is telling you that one "s" sound pronounced at the end of a word is enough. It is logical to indicate pronounciation if the sense of the sentence is clear, I think. ---Charlotte 20-Mar-80 14:24:50-PST,1525;000000000001 Mail-from: MIT-ML rcvd at 11-Mar-80 2125-PST Date: 11 Mar 1980 2104-PST From: Andrew Knutsen Subject: MSGGROUP#1483 mailing list additions/deletions To: msggroup at MIT-ML there has been a controversy over the past few days on info-micro about additions and deletions to that list. altho that list is one of the most harried by that sort of request, it isnt really appropriate for continued flamage. thus when i claim that creating an auxiliary mailing list to collect such requests for every mailing list is not the correct solution, i am also attempting to shift the forum. not only are hundreds of xx-request lists confusing and inelegant, i am sure the demon does a search thru the entire collection of lists (or does it hash?) when it gets a letter with no real box, making that scheme wasteful. in my opinion the proper method would be a single, easy to remember box for all requests, advertised on most lists and *its. this box would output to a file, which anyone who was sure knew what they were doing could refer to to update the list-file, deleting fulfilled requests. lists maintained by seperate people could have a note in the list-file explaining the preferred procedure for that list; hopefully this would just be a pointer to a file to add the name to. this would spread the work out, and prevent reliance on a single person. in my opinion mailing list maintainers are a bad idea in the first place; what has happened to sf-lovers and humnet? ------- 20-Mar-80 14:24:51-PST,1659;000000000001 Mail-from: MIT-ML rcvd at 17-Mar-80 1857-PST Date: 17 Mar 1980 1827-PST (Monday) From: Lauren at UCLA-Security (Lauren Weinstein) Subject: MSGGROUP#1484 mailer problems and inadequate FTP reply codes To: MSGGROUP at ML Recently, when sending a message to an MIT (ITS) site, I noticed that the FTP server processing my message was just closing the connection as soon as it saw my mail command, without so much as a single reply code to tell what was going on. On inquiry to the ITS wizards, I learned that this "feature" has been specifically programmed into the ftp server to take place whenever the local COMSAT (mailer handling daemon) is overloaded with mail. The SRI deafnet gateway machine also implements this same feature. When I asked further, I learned that there seems to be no universally implemented reply code (at least one everyone can count on) that means "temporary failure, try again later." The argument is that some of the codes that come "close" to this might result in the sending mailer doing the wrong thing, like sending the message back to the original sender, or continuing trying to send messages to other users at the site, or other "permanent failure" type actions. So, they have purposely implemented a simulated ftp server "crash" to make things work with all mailers. This seems to me to be a rather non-elegant answer to this problem. Can we not agree on a reply code that will do the right thing in this relatively simple situation? What we need is a code that means: 1) Cannot accept mail now 2) This is only a temporary condition, try again later. --Lauren-- ------- 20-Mar-80 14:24:51-PST,664;000000000001 Mail-from: MIT-ML rcvd at 17-Mar-80 2000-PST Date: 17 MAR 1980 2247-EST From: KLH at MIT-AI (Ken Harrenstien) Subject: MSGGROUP#1485 mailer problems and inadequate FTP reply codes To: Lauren at UCLA-SECURITY CC: msggroup at MIT-ML There isn't much problem AGREEING on a reply code. The problem is IMPLEMENTING it on every single netmail-sending program at every arpanet site... if and when this happens, we will happily use the code. Actually, if going to all this trouble, I would much rather campaign for implementation of XRCP (RFC #743) than for anything else; it will save several billion more cycles. Yours in swamp-draining, --Ken 20-Mar-80 14:24:51-PST,610;000000000000 Mail-from: MIT-ML rcvd at 19-Mar-80 0556-PST Date: 19 Mar 1980 at 0740-CST From: david at UTEXAS Subject: MSGGROUP#1486 Arpanet access control To: header-people at mit-ai,msggroup at mit-ml I just learned that the administrator of this system is working to install some form of Arpanet access control. In my work around the net I have seen no evidence of such controls on other systems. So I am curious as to whether there are systems that have access control, and if so, can you characterize how official access policy is applied? Thank you. David M. Phillips, liaison UTexas ------- 20-Mar-80 14:24:51-PST,1407;000000000000 Mail-from: MIT-ML rcvd at 19-Mar-80 0715-PST Date: 19 Mar 1980 0619-PST From: Zellich at OFFICE-1 Subject: MSGGROUP#1487 Re: Arpanet access control To: david at UTEXAS, header-people at MIT-AI, To: msggroup at MIT-ML cc: ZELLICH In response to the message sent 19 Mar 1980 at 0740-CST from david@UTEXAS I am aware of one type of existing control that, at least in theory, is applied to commercial systems such as the one I am using, that does not permit commercial-account users from accessing the ARPANET. I assume they are restricted from using certain programs (TELNET, FTP, mayne MSG?) and must instead use TYMNET-access programs for equivalent uses. I am also aware that DCA is working on, or has at least proposed, two different ways of restricting ARPANET access: TIP Logins, to keep randoms from getting into the net via Ma Bell's phone "net"; Some kind of TELNET access control (TELNET Login, God forbid?), intended to keep non-ARPANET users at ARPANET host sites from gaining access to the net once logged in on their local hosts. Since access to any of the hosts via either TIP or TELNET (or FTP) generally requires a login and password at the host being accessed, I see no valid reason for either of these proposed controls (other than it keeps GAO, who doesn't know the difference anyway, happy and off DCA's collective back). ------- 20-Mar-80 14:24:51-PST,706;000000000000 Mail-from: MIT-ML rcvd at 19-Mar-80 0832-PST Date: 19 March 1980 11:16 est From: Sibert.SysMaint at MIT-Multics (W. Olin Sibert) Subject: MSGGROUP#1488 ARPAnet access control, Multics To: HEADER-PEOPLE at MIT-AI, MSGGROUP at MIT-AI Multics, bless its complicated little heart, implements a highly flexible form of access control for the network, which allows one to restrict a users access to the network as a whole, or allow him to access only particular hosts. There are also all sorts of privileged administrative tools for making enquiries of the network software. All this control is, of course, an inconvenience, but it does seem to be exactly what the DCA wants. -- Olin 20-Mar-80 14:24:51-PST,4070;000000000000 Mail-from: MIT-ML rcvd at 19-Mar-80 0923-PST Date: 19 Mar 1980 0827-PST Sender: GEOFF at SRI-KA Subject: MSGGROUP#1489 Re: Arpanet access control From: the tty of Geoffrey S. Goodfellow To: Zellich at OFFICE-1 Cc: header-people at MIT-MC, msggroup at MIT-ML Message-ID: <[SRI-KA]19-Mar-80 08:27:08.GEOFF> In-Reply-To: Your message of 19 Mar 1980 0619-PST Reply-to: Geoff @ SRI-KA The only problem with your theory (that access to any of the hosts via either TIP or TELNET generally requires a login and password) would (almost) work if that were indeed the case. There is a collection of hosts on the east coast at a well known institute, that seems to give out accounts/logins and password to just about any ol' random who requests them (and if this is a mistatement, an out right lie or otherwise, feel free to rake me over the coals for it and/or correct me). There are also other hosts that have a general guest account on them. You'd be surprised how fast these accounts get found out. I have seen a new system come on the net, have an unannounced guest account, and in one week they are saturated, and then usually by the end of month, one of the guests has done something nasty like compromise security or crash the system or delete or munge unsuspecting users files. Which brings me to the next point; allowing the randoms to get on the net in the first place, allows them to then have run-of-the-arpanet-backyard, and try their sharp hands as cracking and breaking into the various systems around the net --- fun fun fun! There have also been cases in the past, where such randoms, would link to a user (the random not being logged in) and fake him/her out that the password file had been lost or something and for them to tell this "official" person their password. The piece da resistance of this was when Col. Dave Russell was director of IPTO at ARPA, we got a link from "him" supposedly on the AMES-TIP via RSEXEC, which said "your contract has been canceled, and your host will be removed from the net". The other piece da resistance was a link from "the almighty himself" from the UTAH-TIP. There have also been numerous other "hacks" like this pulled on users from net randoms, and hence, i came to the consensus that its best to keep them at bay at the shell of the net. If someone feels they want to bear the responsibility of letting a "random" on the net, that is fine, they can just let them use THEIR tip login or otherwise, so that when an abuse is detected, the system administrator of the hacked system can call up net control and say "Who was logging in last night at 3am from the X-TIP" and get an answer with a finger to point. This to me seems much more responsible than just changing tip numbers around every 6 months, which get passed around and fall into the wrong hands, as no one feels its THEIR responsibility to protect them. Of course, the entire TIP login system will be shot to nothing if "general" type logins are done, as opposed to one for each net user. Last I heard on TIP LOGIN was that BBN wanted a million bucks to do it, and that it would be based on some of the concepts done in the NSW system, and would consist of 2 PDP-11/70 systems. I wonder of the GAO is willing to bite off a million bucks to do it, if indeed, that is the correct amount. Lastly, I want to make clear (in order to avoid having upset some people and taking some flak) that i have nothing against randoms on the net, just as long as they are controlled. i feel that the responsibility of such randoms will be of a much higher quaility than it is now, and there will be a less proliferation of them. if each one of these randoms feels that someone in a "responsible" position was kind enough to lend them their tip or host login in order for them to have access to the net -- and there are several people on my list who will be using my tip login in order to communicate with me and use my systems at my discretion when and if tip login is ever implemented. 20-Mar-80 14:24:52-PST,2316;000000000001 Mail-from: MIT-ML rcvd at 19-Mar-80 1015-PST Date: 19 Mar 1980 1037-EST Forwarded-to: header-people at MIT-AI, msggroup at MIT-ML, Raver at MIT-DMS Forwarded-by:WJN at MIT-DMS on 19 Mar 80 at 1151 EST From: WJN at MIT-DMS (Wayne J. Noss) To: david at UTEXAS In-reply-to: Message of 19 Mar 80 at 0000 EST by david@UTEXAS Subject: MSGGROUP#1490 [Re: Arpanet access control] Message-id: <[MIT-DMS].140843> Notes: [From WJN] Perhaps I should have distributed this to the mailing list rather than just to the sender. A few months ago a situation arose where FTP-type access between MIT-MULTICS and MIT-XX was desired, so the comments are not merely hypothetical. Given that restricting FTP access from outside is pointless when TELNET works, I think a more reasonable approach would be either to prohibit logging into non-net accounts from outside or to allow the FTP server, logged in as some user, to access anything that user can access AND access the necessary monitor support to do the FTP. I prefer the latter of these alternatives because I think the proper role of a server (TELNET or FTP) in authentication is determining what access to allow to the local machine, NOT deciding whether or not the user should be on the net. Access to the net has already been established before the user tries to log the FTP server, so why check again? Message: David, I understand that MIT-MULTICS has ARPAnet access control. I know little about it, except that Multics users can't TELNET or FTP from Multics to other sites unless they have the necessary privilege, which can be granted by a system administrator. Also, one can not log in the Multics FTP server from another site without Multics net access. What seems to me to be a rather absurd inconsistency is that anyone can TELNET into the system if (s)he has an account, whether or not that account has net access privileges. So files can be transferred (inefficiently) using TELNET by dumping to a log file at the other site or by feeding data in from another site. Lack of FTP access therefore just means that the system gets more bogged down than it would otherwise when someone wants to transfer a file. I would suggest contacting the Liaison on that system for details. the Raver 20-Mar-80 14:24:52-PST,731;000000000000 Mail-from: MIT-ML rcvd at 19-Mar-80 2311-PST Date: 19 Mar 1980 1413-PST (Wednesday) From: Lauren at UCLA-Security (Lauren Weinstein) Subject: MSGGROUP#1491 arpanet access control under Unix To: HEADER-PEOPLE at AI,MSGGROUP at AI While we felt no need for extremely hairy access restrictions, I implemented a group structure a couple of years ago that prevented unauthorized users from accessing any net software (telnet, ftp, etc.) on our unix system, simply by setting protections correctly. Unless a user can demonstrate a real need for net access, he/she is put in one of the restricted groups that cannot access those programs. The whole thing was very simple and has worked fine. --Lauren-- ------- 20-Mar-80 14:24:52-PST,520;000000000000 Mail-from: MIT-ML rcvd at 19-Mar-80 2316-PST Date: 19 March 1980 17:47-EST From: Earl A. Killian Subject: MSGGROUP#1492 ARPAnet access control, Multics To: Sibert.SysMaint at MIT-MULTICS cc: HEADER-PEOPLE at MIT-MC, MSGGROUP at MIT-AI I wouldn't call Multics' ARPAnet access control "highly flexible". Last time I was a Multics user the system administrator was unable to grant me access to both MIT-Multics itself (there was an obscure reason for wanting this) and the ITS systems. 20-Mar-80 14:24:52-PST,339;000000000001 Mail-from: MIT-ML rcvd at 19-Mar-80 2318-PST Date: 19 MAR 1980 2232-EST From: JNC at MIT-AI (J. Noel Chiappa) Sent-by: ___050 at MIT-AI Subject: MSGGROUP#1493 Foo... To: msggroup at MIT-ML, header-people at MIT-MC Do I hear a volunterr for creating MSG-HDR-GROUP-PEOPLE? Getting all this mail TWICE is a real drag. Noel 20-Mar-80 14:24:52-PST,271;000000000000 Mail-from: MIT-ML rcvd at 19-Mar-80 2320-PST Date: 20 March 1980 01:14-EST From: FOO at MIT-AI Subject: MSGGROUP#1494 header-people To: MSGGROUP at MIT-AI Can't we assume that header people is nearly a subset of msggroup? So send messages to msggroup only. 20-Mar-80 14:24:52-PST,673;000000000000 Mail-from: MIT-ML rcvd at 20-Mar-80 0622-PST Date: 20 Mar 1980 at 0800-CST From: david at UTEXAS Subject: MSGRROUP#1495 Arpanet access control To: msggroup at mit-ml I have the information I wanted. I learned there are a number of hosts that have some form of access control, but a person might not be aware of the controls because they are transparent to one who does have access. Most sites with controls have them only on telnet or ftp. At UTexas they are proposing to control outgoing netmail, but allow incoming to go to anybody. Thanks to everyone who responded, and to those others not interested who had to look at the mail traffic. ------- 20-Mar-80 14:24:52-PST,530;000000000000 Mail-from: MIT-ML rcvd at 20-Mar-80 0900-PST Date: 20 March 1980 11:39 est From: Pogran.CompNet at MIT-Multics Subject: MSGGROUP#1496 Re: ARPAnet access control, Multics To: Earl A. Killian cc: Sibert.SysMaint at MIT-Multics, HEADER-PEOPLE at MIT-MC, MSGGROUP at MIT-AI In-Reply-To: Msg of 03/19/80 17:47 from Earl A. Killian For heaven's sake! The Multics system's ARPANET access control certainly IS highly flexible; trouble is, some of their system adminsitrators might not be! Ken 25-Mar-80 00:47:04-PST,451;000000000001 Mail-from: MIT-MC rcvd at 20-Mar-80 1857-PST Date: 20 MAR 1980 2149-EST From: KLH at MIT-MC (Ken Harrenstien) Subject: MSGGROUP#1497 Duplicate eliminations To: HEADER-PEOPLE at MIT-MC, MSGGROUP at MIT-MC Unfortunately, CBF's statement (that COMSAT will weed out duplicates if you send the message to just the MC lists) is only true if the mail-sending program is local (on MC) or uses the FTP XRCP mechanism that I mentioned previously. 25-Mar-80 00:47:04-PST,3195;000000000001 Mail-from: MIT-ML rcvd at 23-Mar-80 1701-PST Date: 23 Mar 1980 1636-PST From: Zellich at OFFICE-1 Subject: MSGGROUP#1498 Line lengths and columnated text To: MsgGroup at MIT-ML, Human-Nets at MIT-AI cc: Zellich ________________________________________________________________________ | In reply to: Various messages | now, the boxes, lack of vertical | | on the subject of terminal/page | margins, and page numbers are | | size and line length in recent | all fixed attributes. The | | correspondence via Human-Nets | program will accept a page width | | and MsgGroup. | of from 11 to 127 columns and a | | | length of 3 to 99 lines (and | | This is an experiment in | some of the width/length | | response to the remarks on | combinations are really wild!!). | | columnation in commercial | | | publications. I have developed | Frankly, I don't really like the | | a small program to copy my | looks of this output on a | | original structured text and | hardcopy terminal, because I try | | copy it to a new location in my | to read message text as the | | file, formatted into two | message is printing, and two- | | columns, boxed, and page- | column text is frustrating. It | | numbered. | does seem to be pretty nice on a | | | display, and that is why this | | The way it is written right | particular message is formatted | --------------------------------------------------------------------- 1 ________________________________________________________________________ | into 72 columns and 20 lines | Cheers, | | (of course, somebody out there | Rich | | will undoubtedly complain that | | | s/he is using a micro with 64 | | | columns and 16 lines, but I | | | tried that and text width of 27 | | | characters or less in each | | | column doesn't look too good). | | | | | | For reading later, instead of | | | as a message/file is printing, | | | this columnation does seem to | | | be pretty nice - except then it | | | is better formatted in longer | | | pages, which are a pain on a | | | CRT if it ever has to be read | | | online again. | | | | | --------------------------------------------------------------------- 2 ------- 25-Mar-80 00:47:04-PST,618;000000000001 Mail-from: MIT-ML rcvd at 23-Mar-80 1754-PST Date: 23 Mar 1980 17:40 PST From: Brodie at PARC-MAXC Subject: MSGGROUP#1499 Re: Line lengths and columnated text In-reply-to: Zellich's message of 23 Mar 1980 1636-PST To: Zellich at OFFICE-1 cc: MsgGroup at MIT-ML, Human-Nets at MIT-AI Of course, we here at Xerox have proportionally spaced fonts on our displays and printers, so your nicely columnated message comes out ragged. Why not have your mail-reading program parse incoming messages and display them any way you want them, rather than worry about what format people send them in? Richard 25-Mar-80 00:47:04-PST,889;000000000001 Mail-from: MIT-ML rcvd at 23-Mar-80 1958-PST Date: 23 March 1980 2245-EST (Sunday) From: Brian.Reid at CMU-10A Subject: MSGGROUP#1500 Re: Line lengths and columnated text To: Zellich at OFFICE-1, MsgGroup at MIT-ML, Human-Nets at MIT-AI Message-ID: <23Mar80 224537 BR10@CMU-10A> In-Reply-To: Brodie@PARC-MAXC's message of 23 Mar 80 20:40-EST Don't put text in message bodies, but put instead the text and labels for some document formatter; we can then each reformat the text the way we please on our local terminals. This is of course not practical for current Arpanet mail, but then how much of this is? P.S. to somebody earlier in this fray; I don't remember who-- the reason that newspapers and other mass-circulation media use multiple columns with short line lengths is so they can cram more on a page. You can space the lines closer if they are narrower.