From 349b16efbf7e74bf508915818257014178d9625d Mon Sep 17 00:00:00 2001 From: Lars Brinkhoff Date: Fri, 3 Feb 2017 09:00:19 +0100 Subject: [PATCH] Add missing text files to .MAIL. --- src/_mail_/*msg.exp | 172 ++++++++++++++++++++ src/_mail_/-read-.-this- | 27 ++++ src/_mail_/names.info | 339 +++++++++++++++++++++++++++++++++++++++ 3 files changed, 538 insertions(+) create mode 100755 src/_mail_/*msg.exp create mode 100755 src/_mail_/-read-.-this- create mode 100755 src/_mail_/names.info diff --git a/src/_mail_/*msg.exp b/src/_mail_/*msg.exp new file mode 100755 index 00000000..ed9ed77b --- /dev/null +++ b/src/_mail_/*msg.exp @@ -0,0 +1,172 @@ +This is .MAIL.;*MSG EXP. + +The easiest way I can explain how broadcast mail (system and bboard +messages) work with respect to ITS is to display the actual mailing lists +and add useful commentary. Vide infra: + +Everything between the lines of dashes is an excerpt from AI's file of +mailing lists; as the comments point out, the broadcast addresses shown are +the same as those on MC except for the address "*". The astute will note +that this means that you can mail to any of these addresses at either AI or +MC and reach the same audience. + +The excerpt, like the entire file, is in a LISP-ish format. Everything on +any line after a semicolon is a comment from the file; my inserted comments +are enclosed in curly braces to differentiate them. For the purposes of +this explanation, you can ignore any set of parentheses which contain R-x +(for any x) as their first item; R-options are instructions to COMSAT, the +ITS mailer, on how (rather than where) to delivery the mail. The phrase +EQV-LIST is important -- it means equivalence list, or, loosely translated, +"expands into". + +---------- +;; The entry for "*" is the only one which varies in the NAMES file for +;; each site. +(* (R-OPTION NOTDIST) (EQV-LIST *AI)) +{In other words, mail to *@AI goes to the address *AI@AI, which is further + expanded below. Other than as a trivial example, you can pretty much + ignore this one.} + +;; *msg mailing lists -- see .MAIL.;BBOARD INFO for accepted policy on +;; which list to use for what purpose. +{I wrote the file referred to several years ago. If you're interested in + it but can't snarf a copy for yourself -- the ITSs are alas not on the + Internet, which makes life difficult in several ways -- let me know and + I'll send you one.} + +(*MIT (R-OPTION NOTDIST) + (EQV-LIST *MAC *CIPG *DSPG *INFOODS *LIDS *PFC *XV *AMT *RANDOMS)) +{*MIT, as will become apparent, goes all over MIT -- or at least as far as + anyone has informed us that it is desired. This is the best address to + send announcements of sufficiently general and wide-spread interest that + lots of people all over MIT will be at least mildly interested in hearing + them. Some seminar or lecture announcements might qualify.} + +(*MAC (R-OPTION NOTDIST) + (EQV-LIST *ITS *HX *LCS-UVAX *MLSITE *REAGAN *WH)) +{*MAC was originally intended to reach everyone in Tech Sq.; I believe that + on XX the address TECH-SQ forwarded directly to *MAC@MC. But the mailing + lists must be manually altered to add new hosts which want to receive such + messages, and over the years people have dropped the habit of informing + the Postmaster here that their new systems should be added to the list + (not to mention the habit of logging into an ITS and making the changes + themselves). So I have been told that this list no longer works as well + as it used to. If you know of hosts which ought to have addresses added + to these lists, please inform Postmaster@MC about them -- that's the only + way to rectify the situation. *MAC should be used for messages which you + expect numerous people in this building -- that is, LCS and AIL members -- + to be interested in. I would think most seminars and lectures would + qualify, as would announcements from building management, warnings about + important demos, etc. + +(*TENS (R-OPTION NOTDIST) (EQV-LIST *ITS)) +{Merely a synonym these days, *TENS used to be more important when there + were other PDP-10 family machines at MIT.} + +(*ITS (R-OPTION NOTDIST) (EQV-LIST *AI *MC + ;; *MD *ML + )) +{*ITS is for matters affecting only users of ITS machines -- not a large + contingent these days. It would be the right list for announcements of + machine shut-downs or changes to the operating system or important utility + programs. Note that MD and ML, which have been declared deceased, have + been commented out of the list.} + +;; BBOARD goes most everywhere but is not shown by :MSGS by default +(BBOARD (EQV-LIST (*BBOARD))) +{BBOARD is simply a synonym.} + +(*BBOARD (EQV-LIST *MSGS-TO-ITSES + (*REAGAN (R-OPTION NOTDIST)) (*WH-BBOARD (R-OPTION NOTDIST)) + (*HX (R-OPTION NOTDIST)) (*LCS-UVAX (R-OPTION NOTDIST)) + (*MLSITE (R-OPTION NOTDIST)) + (*AMT (R-OPTION NOTDIST)) + (*EDDIE (R-OPTION NOTDIST)) + (*INFOODS (R-OPTION NOTDIST)) + (*LIDS (R-OPTION NOTDIST)) + (*PFC (R-OPTION NOTDIST)) + (*RANDOMS (R-OPTION NOTDIST)))) +{*BBOARD goes all over MIT, like *MIT, but is for low-priority messages -- + housing searches, sales of personal property, announcements of events + which are not directly AI- or CS- related. See below for further + expansions.} + +{Below are the single-machine exquivalences used in the lists above. These + can of course be used in their own rights, but in most cases these days + the lists above are more useful. The first section contains addresses for + delivering system msgs to ITS machines themselves.} +;; Hosts that can receive *msgs +(*AI (EQV-LIST *MSGS-TO-ITSES)) +(*MC (EQV-LIST *MSGS-TO-ITSES)) +;; (*ML (EQV-LIST *MSGS-TO-ITSES)) +;; (*MD (EQV-LIST *MSGS-TO-ITSES)) +(*MSGS-TO-ITSES (R-OPTION NOTDIST) ; This just makes above 4 simpler. + (EQV-LIST + (*MSG-SINK@AI (R-OPTION NOTDIST)) + (*MSG-SINK@MC (R-OPTION NOTDIST)) + ;; (*MSG-SINK@ML (R-OPTION NOTDIST)) + ;; (*MSG-SINK@MD (R-OPTION NOTDIST)) + )) +; This is final "sink". Mailer converts to filename. +(*MSG-SINK (R-OPTION NOTDIST)) + +{The second section is equivalences for machines in Tech Sq.} +(*HX (EQV-LIST (msgs@HX (R-HEADER-FORCE NET)))) +(*LCS-UVAX ;LCS Microvax community, add hosts as needed + (EQV-LIST bboard-forum@ALLSPICE msgs@BROKAW + bboard@EXPO ;not a UVAX, but restricting to them is stupid + )) +(*MLSITE (EQV-LIST (MSGS@ZERMATT (R-HEADER-FORCE NET)))) +(*REAGAN (EQV-LIST (*REAGAN@REAGAN (R-HEADER-FORCE NET)))) +(*WH (EQV-LIST (msgs@WHEATIES (R-HEADER-FORCE NET)))) +(*WHEATIES (EQV-LIST *WH)) +(*WH-BBOARD (EQV-LIST (bboard-dist@WHEATIES (R-HEADER-FORCE NET)))) +(*WHEATIES-BBOARD (EQV-LIST *WH-BBOARD)) + +{Below is the section of equivalences for machines not in Tech Sq. but + elsewhere at MIT. *EDDIE is probably the address that gateways such + messages into the appropriate uucp newsgroup -- mit.bboard or whatever.} +(*AMT (EQV-LIST bboard-recipients@MEDIA-LAB.MEDIA.MIT.EDU)) +(*CIPG (EQV-LIST (msgs@CIPG.MIT.EDU (R-HEADER-FORCE NET)))) +(*DSPG (EQV-LIST (msgs@DSPVAX.MIT.EDU (R-HEADER-FORCE NET)))) +(*EDDIE (EQV-LIST (bboard-local@EDDIE.MIT.EDU (R-HEADER-FORCE NET)))) +(*INFOODS (EQV-LIST bboards@INFOODS.MIT.EDU)) +(*LIDS (EQV-LIST FORUM@LIDS.MIT.EDU)) +(*PFC (EQV-LIST BBOARD@PFCVAX.PFC.MIT.EDU)) +(*XV (EQV-LIST SYSMSG-INCOMING@XV.MIT.EDU)) + +{The last section is for sites not at MIT which nonetheless wish to see our + announcements. Most of these places are near enough that their people + could easily come to seminars and such at MIT.} +;; Randoms who want to get all the bboard msgs. -- GAB +(*RANDOMS (EQV-LIST mithal%slda.DEC@DECWRL.DEC.COM + mit-forum@CRL.DEC.COM + mitbb@xait.xerox.com + mitbboards%cs.umass.edu@umass-gw.cs.umass.edu)) + +(ALL-AI (EQV-LIST ALL-AI@wheaties)) +{This is actually a forwarding pointer. There is clearly a class of system + message which contains information that all AIL people should see, but + that no one else will be much interested in. Since AIL people are + scattered over many machines, some of which have numerous users who are + not AIL members, this list evolved. On WHEATIES or LIFE or wherever it + lives now, it expands into a list of floor lists. The original concept + was that floor lists -- 7AI, 8AI, etc. -- could each encompass all the lab + members who actually used that floor and would be used to send mail to + those people of relevant news -- individual mail as opposed to system + messages so that recipients couldn't miss the information by skipping + system messages. ALL-AI is the combination of all these lists, and in my + opinion is overused; I think many of the messages sent to it would more + appropriately go to *MAC or *BBOARD (depending on the content). Sally + Bemus says that LCS has a somewhat different mechanism -- a mailing list + of group secretaries and administrators, who are expected to decide who in + their groups will want to know the information so distributed. In this + respect the AIL has a much looser organization.} +---------- + +A final comment: It is an unfortunately increasing habit for people, even +MIT people, even AI/LCS people, to send their messages to more than one of +the broadcast lists above -- e.g. *BBOARD@AI and *BBOARD@MC, or *MAC and +*BBOARD. This practice of course causes multiple copies of the same +message to be sent, and is to be discouraged by any reasonable means +available. \ No newline at end of file diff --git a/src/_mail_/-read-.-this- b/src/_mail_/-read-.-this- new file mode 100755 index 00000000..5b4f9d18 --- /dev/null +++ b/src/_mail_/-read-.-this- @@ -0,0 +1,27 @@ +This directory is used by the ITS mailing system; that is, the QMAIL +and Satellite programs. Please DO NOT EVER delete any file from this +directory; also, the programs therein should not be modified without +first consulting BUG-MAIL. If GC'ing must be done on program files, +do not delete either the most recent or most ancient file (which is +usually around for a reason). Under some circumstances, BURNUP dumps +can gobble up gross amounts of space. In this situation, flushing +intermediate dumps (never first or last) is OK. + +The files with particular automated functions are: + ID 69 creation date indicates when current STATS file began. + FROM INQUIR creation date indicates when current INQUIR file written. + LOCK UNIQUE page shared by all comsats for lock-switch functions + LIST MASTER master message list + LIST QUEUE queue information file + LIST REMIND reminders list file + LIST EQVS equivalence table data "compiled" from NAMES + LISTS MSGS holds text of messages in queue. + +BURNUP binary dumps of satellites that detect fatal errors. +COMSAT the binary actually loaded and run. +MAIL input to the satellite. +NAMES the ASCII form of the equivalence tables. +STATS statistics and running commentary kept by the satellite. + + there also exist parallel sets for experimental versions: +XLOCK XQUEUE XREF XMAIL XNAMES XSTATS etc. \ No newline at end of file diff --git a/src/_mail_/names.info b/src/_mail_/names.info new file mode 100755 index 00000000..5f513b60 --- /dev/null +++ b/src/_mail_/names.info @@ -0,0 +1,339 @@ +.MAIL.; NAMES > is a list of mailbox equivalences. Each machine has +its own distinct copy for addresses at that machine; do not copy the +file to other machines! + +Here's basic documentation of the standard cases. What follows is +more detailed documentation of hairy cases. That documentation is now +pretty badly out of date; don't believe everything it says. If you +want to do something hairy, try and find an instance of someone else +doing it in the NAMES file and imitate it. For help, send mail to +BUG-MAIL. + +The file defines a set of mailing lists. List specifications are +Lispy; they look like + +( (EQV-LIST ...)) + +Recipients can be of the following forms: + +* KLH -- mails to KLH on the local machine +* KLH@MC -- sends the mail on to MC, telling MC that the mail is for KLH +* ( (R-OPTION FOO)) -- modifies the way the mail is delivered +* [FOO;BAR BAZ] -- delivers the mail into the specified file on the + local machine. DO NOT put devices (such as AI:) + in the file name! It will seem to work but really + break things. +* (FILE [FOO;BAR BAZ]@MC) -- delivers the mail to the specified + file on another machine. +* (@FILE [FOO;BAR BAZ]) -- indirects through the specified file, which + should contain a list of recipients. + +The list can be continued onto a continuation line (as +in + +(FOO (EQV-LIST SOMEONE SOMEONE-ELSE + ANOTHER-PERSON)) + +), but the continuation lines MUST start with a space or tab. Ideally +they should be Lisp ground. + +Make sure you balance parentheses correctly. + +Comments start with a semicolon. + +Alphabetical order is not crucial, but improves readability within +groupings. + +For pathological names, "/" or "^Q" will quote characters such as +spaces, parentheses, brackets, etc. + + +GENERAL RECIPIENT SYNTAX + + Each list in the NAMES > file is really just a +recipient specification, in a structured format which is +almost always the same anywhere one may wish to specify +a "recipient". + +A recipient spec or RSPEC in standard form is: + + ( <#1> ... ) + +or + + @ + +Where: + - Recipient type, such as NAME, FILE, RUN, BUG. + If is not a recognized type, it is interpreted + as being the , of type NAME. + + - Recipient name string, such as KLH, INFO-ITS, [SYS;TS FOO]. + + - Attributes, each of which is parsed as: + (ATTR AVAL) + Where ATTR - Attribute name. + AVAL - Attribute value. + If is an atom rather than a list, it is read as + (ATTR). I.e. it exists but has no value. + <#1> - Also an Attribute, but interpreted crockishly. + If a list, it is a normal Attribute. + If an atom, + 1) If "@" is the first character, interpretation is (SITE X) + 2) If a number or site name, interpretation is as above. + 3) Else as for atomic . + + Other special notes: If contains a @ and the text +after it is a valid host name, it is interpreted as having the +syntax Foo@Site. It is possible to have multiple site definitions +just as it is possible to multiply define anything; the effects +of this are QUITE undefined and which one gets priority depends +on where it actually hangs in the internal core list storage. + + Equivalence entries are just like rcpt specs, +except that they can have the attribute (EQV-LIST ... ) +which implies that when mail arrives for the recipient name, +it will be sent instead to the recipients on the EQV-LIST. +Thus, (KLH (EQV-LIST KLH@MC)) in the NAMES > file will +cause any mail arriving for KLH to be "forwarded" to KLH@MC. + +For the case where you want to specify an EQV-LIST, but +still want the original recipient to receive a copy, hearken +to the following example: + (KLH (R-OPTION FOO) (EQV-LIST KLH KLH@OTHERSITE)) +Simply including the name itself as part of the EQV-LIST causes +a circularity which is detected and handled properly. This also +demonstrates the setting of an R-OPTION for the original name. + +MINOR RECIPIENT OPTIONS - "R-OPTION" + + There are several options, switches, and attributes +which a recipient might wish to set in NAMES >. The bulk of these are +specified as R-OPTION arguments, and are listed here in alphabetical order: + +(R-OPTION APPEND) + This is a very useful option which specifies that + all of your mail be APPENDED onto the bottom of your mail + file, rather than being "pushed" on the top in reverse + chronological order. + +(R-OPTION FAST-APPEND) + This is similar in effect to APPEND, but uses a special + mode for output which is MUCH more efficient than APPEND. + This is a new feature and is not yet recommended for use with + regular personal MAIL files, which should be fairly small anyway. + However, large script files should definitely try this out. + Read MC:KSC;?APPND > before using it. + +(R-OPTION CC) + This option causes its recipient to be listed in message headers + as a "CC:" or "Carbon-Copy:" recipient, rather than "To:". + +(R-OPTION INFINITE-CLI) + Message notifications ("You have mail...") will include the + complete message. See SMALL-CLI and NO-LOCAL-CLI. + +(R-OPTION NEW-FILE) + This option causes the message to always be written into + a "new" file by itself. That is, if a file already exists + with the same name, it is flushed; the message is not added + to it, but rather replaces it. For FN2's of "<" or ">", + the NEW-FILE option is assumed; however, due to the fact that + writing with these filenames creates a new, unique filename, + no existing file is replaced (flushed) by the write operation. + +(R-OPTION NO-CLI) + This option suppresses all message notification; the recipient + will never be notified of arriving mail. See SMALL-CLI, + NO-LOCAL-CLI, and INFINITE-CLI for graduated control. + +(R-OPTION NO-LOCAL-CLI) + This option suppresses message notification if the message + originated locally; thus the only notifications which are + sent are those pertaining to incoming network mail. + +(R-OPTION NOQC) + This specifies that you don't want to be notified either + of messages which were queued, or which were queued and finally + were sent. It doesn't suppress actual error messages if something + goes wrong. + +(R-OPTION NOSHOW) + This option prevents the recipient name, and anything it + expands to, from ever appearing in any header. It is really + an internal option; to get the effect of a BCC, use (R-OPTION BCC). + +(R-OPTION NOTDIST) + This only applies when one or more of the recipients for the + message is of type *MSG. All recipients without a NOTDIST + option will be included in the special DISTRIB: header line + given to the *MSG recipient. (which is normally a file on + .MSGS.;) + +(R-OPTION SHOWLIST) + This is used for EQV lists where one wants the + list itself seen in the message header, rather than the + name of the list itself, as would normally be the case. + If the list name itself wasn't going to be in the header + anyway, the list won't appear no matter what. + +(R-OPTION SMALL-CLI) + With this option, message notifications will be limited + to 2 lines, the first announcing "You have mail..." and + the second stating the message length. + +(R-OPTION SUPER-QUOTE) + Normally, when a message is written, a header is added to + the text and ^_'s (cntrl-underbar, 037 octal) are converted + to a up-arrow, underbar (2 char) representation, with a true + ^_ added to the end of the message. This option suppresses + all that; no header is added, no checking is done for ^_'s, + and no ^_ is added at the end. Otherwise, writing is as + for any other message, obeying the APPEND, NEW-FILE options, etc. + +RECIPIENT ATTRIBUTES WHICH AREN'T "R-OPTION" + +The following are also per recipient, but are attributes in themselves +rather than being R-OPTION values. + +(R-HEADER-FORCE ) Where = {NET, ITS, NULL} + This will try to have all your mail delivered to you + using the header format specified. NET indicates standard + network header, ITS the compact style we all know well, and + NULL prevents any header from appearing (possibly useful when + mailing cruft to a file or program - see (R-OPTION SUPER-QUOTE).) + NOTE: This doesn't yet work for incoming net mail, but will as + soon as the code for parsing same gets written. This may not + be for a long time, owing to the incredible variety of header + formats used by different sites. + +(R-MODE-MAIL ) + If mailing the message, this attribute governs how message + notifications are done. + Positive : Always notify regardless of other options. + Zero : Notify only as per other options. + Negative : Never notify regardless of other options. + NOTE - whether the message is actually mailed or not + can depend on the R-MODE-SEND attribute) + +(R-MODE-SEND ) + First, the existence of this attribute indicates the message + as a whole should be CLI'd to the recipient; that is, :SENT. + The numerical argument specifies 3 additional options: + Positive : Always mail message as well. + Zero : Mail only if the :SEND fails. + Negative : Don't mail at all. + + +RECIPIENT TYPES + + The TYPE attribute determines the interpretation of the +recipient name string, and can at present be any of the following: +NAME - Normal, the string is simply a recipient name, like "FOO". + This type is the default, but can be specified explicitly + just like any other. +FILE - The string is a filespec and the mail should be stored + in that file (appending or pushing as the case may be). + enclosing the string in square or curly brackets is a + shorthand way of doing this. Do NOT use host devices such as + such as ML:, MC:, etc.; it will break things. + Use (FILE [FOO;FILE NAME] @MC) instead. +*MSG - The string is an announcement-group name. Recipients of + this type will be given a special header and always written + to .MSGS. using the MSG-FN1 and MSG-FN2 attribs if given. +PGM - The string is a filespec of a program which should be started + and run, with the message text as JCL. See separate section + about "PGM" recipients. +@FILE - The string is a filespec to a file which is "indirected" + through; it should contain a list of recipient specs in + the same format as described here, separated by commas + or CRLF's. It acts like EQV-LIST, except that its arguments + live in a file and are dynamically read for each message. + + +MORE ABOUT THE "PGM" RECIPIENT TYPE + + Sending to a Program + + When mail arrives for a recipient of type PGM, its +is treated as a , and the specified file thereupon +loaded and started as an inferior job of the Comsat. The message +text will be passed on as JCL for the program, and any errors +can be reported to the appropriate person. + The default action, in the absence of specific directives, +is to let the job run for either 2 seconds run time or 1 minute +real time, whichever comes first, and then disown it. Hence, +the JCL must be read within a reasonable time after startup. + +In more detail: + The default device for loading the file is always DSK: since +the LOAD symbolic system call will not work otherwise. If +message text was present, the Comsat will set the OPTCMD bit in +the job's .OPTION variable, saying "I have JCL for you". +The job's XUNAME is also set to the name of the message sender, if +known. +Requests to read and write (clear) the JCL will be honored +in the same fashion as DDT; that is, the usual .BREAK 12,[5,,] +must be used. During execution, all fatal conditions except +.BREAK's to hack the JCL are handled by killing the inferior. +Unless stopped by a .BREAK 16, - the usual way for programs to +request DDT to kill them - an error message will be sent to +the program's maintainer, detailing the nature of the lossage. +In particular, things like .VALUE [ASCIZ /:KILL/] should +be avoided, as well as any .VALUE which is not intended to signify +an error. In general, it is a good idea to try .LOGOUT before +the .BREAK 16, in case the job was disowned before it decides +to kill itself. + The special attributes for handling PGM recipients are + +(R-PGM-MNTNR ) + This specifies where error messages pertaining to job +execution should be sent. If none is specified none is sent, +other than a standard copy to COMSAT-WIZARD. + +(R-PGM-USET ( )) + This (there may be any number) attribute allows arbitrary +user variables to be set before it is started. Unfortunately +until symbolic .USET arrives, the first value must be the numerical +value of the symbol to write the second value into. (Reading is +a useless operation in this context and is not attempted). + +For example: +(PGM [FOO;HACK BIN] (R-PGM-MNTNR KLH) (R-PGM-USET (400074 465757000000))) + Will run the program HACK BIN from FOO; and before +starting will set the XUNAME (see what DDT gives you when you +type something like .SXUNAME= at it) to the given value, which happens +to be FOO in left-justified sixbit. + +(R-PGM-DISOWN ) + As previously said, Comsat will stick to the job, serving +any JCL requests and handling interrupts, until either it has used +2 sec of run time or 1 minute of real time. These actions can +be modified with the R-PGM-DISOWN attribute, as follows: + + RH - corresponds to the ctl bits for the DISOWN +symbolic call, which will be used when and if the job is disowned. +These bits are all passed on directly, with the following +special actions: + +Bit 1.4 is ALWAYS complemented - i.e. you must specify it to avoid the + "default" of setting BUMRTL (system guns job if it does + nothing for 1/2 hr) +Bit 1.3 will cause immediate disowning. Obviously no JCL can be + supplied for this case, and the LH bits are ignored. + + LH - bits specify mailer actions. +Bit 3.1 Says job never wants JCL. This allows the mailer to proceed + asynchronously, handling interrupts as they occur. +Bit 3.2 Says job will want JCL again even after it manages to read + it all successfully. This forces mailer to "stick with" job + until it gets disowned. +Bit 3.3 Says if disowning is attempted, job should instead be KILLED + and an error reported. +Bit 3.4 Says that bits 4.9-4.1 contain the # secs of runtime job should + be allowed - real time is ignored. Dangerous!! +Bit 3.5 Says job should not be run if another already exists with + identical UNAME/JNAME. Note that this is checked BEFORE any + USET's are done (so setting JNAME that way will lose). JNAME is + FN1 unless that is "TS", in which case it's the FN2. +