Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU; 19 Apr 90 20:50:27 EDT Received: from AI.MIT.EDU by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 8565; 19 Apr 90 20:48:17 EDT Received: from PIGPEN.AI.MIT.EDU by life.ai.mit.edu (4.1/AI-4.10) id AA18995; Thu, 19 Apr 90 20:50:30 EDT Date: Thu, 19 Apr 90 20:48 EDT From: Alan Bawden Subject: [TK0JUT2%NIU.BITNET: C-u-D, #1.04 (d)] To: LSP@ai.ai.mit.edu Cc: BUG-MAIL@ai.ai.mit.edu In-Reply-To: <721233.900413.LSP@AI.AI.MIT.EDU> Message-Id: <19900420004806.2.ALAN@PIGPEN.AI.MIT.EDU> Date: Fri, 13 Apr 90 16:24:34 EDT From: Lee Parks Please examine the middle of this piece of mail carefully. I wonder how the source code fragment, included in the message below, found its way into my mail? Date: Wed, 11 Apr 90 22:00 CDT From: TK0JUT2%NIU.BITNET at uicvm.uic.edu ... Your reluctance to investigate another law enforcement agency is understandable, but if the federal government won`t protect citi- zens from lo,(FA) ; Make it a fileaddr MOVSI D,(D) ; in LH HLR D,STLNAM(A) ; Set RH to fileaddr of hostname MOVEM D,(G) ; Now store MOVEI E,HSTNIC(H) ; E points to list of nickname pointers. AOJA G,MNAM39 ; Bump deposit ptr and jump into loop Well, if you don't want your mail damaged, store it on a computer with working disk drives.  Date: Fri, 13 Apr 90 16:24:34 EDT From: Lee Parks Subject: [TK0JUT2%NIU.BITNET: C-u-D, #1.04 (d)] To: ALAN%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU, BUG-MAIL%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU Message-ID: <721233.900413.LSP@AI.AI.MIT.EDU> Please examine the middle of this piece of mail carefully. I wonder how the source code fragment, included in the message below, found its way into my mail? Date: Wed, 11 Apr 90 22:00 CDT From: TK0JUT2%NIU.BITNET at uicvm.uic.edu To: TK0EEE1 at niu.mit.edu Re: C-u-D, #1.04 (d) **************************************************************************** >C O M P U T E R U N D E R G R O U N D< >D I G E S T< *** Volume 1, Issue #1.04 (April 11, 1990) ** -- Part 4 of 4 -- ** ALCOR'S SUIT AGAINST E-MAIL CONFISCATION ** **************************************************************************** MODERATORS: Jim Thomas / Gordon Meyer REPLY TO: TK0JUT2@NIU.bitnet COMPUTER UNDERGROUND DIGEST is an open forum dedicated to sharing information among computerists and to the presentation and debate of diverse views. -------------------------------------------------------------------- DISCLAIMER: The views represented herein do not necessarily represent the views of the moderators. Contributors assume all responsibility for assuring that articles submitted do not violate copyright protections. -------------------------------------------------------------------- In This Issue: Issue #1.04 is long--over 2,100 lines--so we have broken it down into four smaller files. Keith Henson sent these public documents to us describing how one organization filed suit against agents for allegedly confiscating electronic mail illegally. The case raises a number of important issues to computerists, including the status of E-mail as private communication, the scope of investigatory authority of law enforcement agents in confiscating computer "symbols," and other facets of investigation of the use of computers when an alleged crime has occured. We encourage article-type responses to the any of the many issues raised here. ********************************** PART 4 of 4 ********************************** -------------------------------------------------------------------- ATTACHMENT A -------------------------------------- H. Keith Henson 1794 Cardel Way San Jose, CA 95124 408-978-7616 April 22, 1988 Ron Heller Federal Bureau of Investigation P.O. Box 2317 Riverside, CA 92516 Dear Mr. Heller: I was astounded at the refusal of the FBI to even make minimal inquiry into a citizen`s complaint of a clear violation of a Federal law. Your advice that I take my complaints to Riverside County is hard to fathom; to the best of my knowledge, the county has no laws regarding intercepting electronic mail. Your argument that having an unrelated warrant to take a computer permits interception of the electronic mail of all people who were using that computer would (I think) generate great concern among the staff and members of the House Committee on the Judi- ciary which held extensive hearing on this law only two years ago. Your reluctance to investigate another law enforcement agency is understandable, but if the federal government won`t protect citi- zens from lo,(FA) ; Make it a fileaddr MOVSI D,(D) ; in LH HLR D,STLNAM(A) ; Set RH to fileaddr of hostname MOVEM D,(G) ; Now store MOVEI E,HSTNIC(H) ; E points to list of nickname pointers. AOJA G,MNAM39 ; Bump deposit ptr and jump into loop MNAM30: HRRI D,(E) ; Get ptr to nickname SUBI D,(FA) ; Get fileaddr of copy MOVEM D,(G) ; Store another table entry (note LH unchanged) ADDI G,1 HLRZ E,E ; Get CDR for next nickname entry MNAM39: SKIPE E,(E) ; Get nickname JRST MNAM30 MNAM50: ADDI H,HSTLEN ; Finished making NAMES entry for this host. CAMGE H,HSTTBE ; Hack the next... JRST MNAM10 MOVEM G,NAMEP ; Store back write-ptr into NAMES table SUB G,NAMP ; Check that expected number of NAMES SUBI G,2 ; entries were made. CAME G,@NAMP ERROR "Internal error - NAMES table size inconsistency" RET ; SRTNAM - Sort the NAMES table. Uses fact that all strings are ; already sorted and can just examine file-address for compares! ; SRTNTN - Sort the NETNAME table. SRTNAM: MOVE A,NAMP ; Get addr of NAMES table MOVEI H,SRTN60 ; Set addr of duplicate err routine JRST SNAM01 SRTNTN: MOVE A,NTNP ; Get addr of NETNAME table MOVEI H,SRTN70 ; Set addr of duplicate err rtn SNAM01: MOVEI E,2(A) ;ut the impending legisla- tion. He was particularly interested in forestalling the need for court orders to obtain access to stored electronic communica- tions. I quote from his written testimony of March 5, 1986 before the Subcommittee on Courts, Civil Liberties, and the Administration of Justice: "The authorization to intercept the communications should be accomplished by a statute mandating a judicial authorization based on probable cause akin to that which can now be secured with a Fourth Amendment search warrant pursuant to Rule 41 of the Federal Rules of Criminal Procedure. This procedure is based on the premise that the interception of electronic mail generally should be accorded no more protection than that accorded to regular mail. At the present time regular mail can be seized with a Rule 41 search warrant. . . . "The search warrant . . . should be based on a sworn affidavit establishing probable cause to believe that a crime has been, is being or is about to be committed. The affidavit and judicial authorization should sufficiently specify the people involved, the facility in question, the specific offenses involved, and the type of information sought to be intercepted. . . ." Congress went along with the Justice Department in requiring search warrants rather than the more cumbersome court orders, with the understanding that they would watch for abuse. Michael Emick -2- April 25, 1988 Now in the case at hand, there was a search warrant, but it was clearly inadequate to seize electronic mail since it was directed to the computer rather than its contents and the people who put the contents into it. The correct analogy according to Mr. Knapp's testimony would be a search warrant obtained against a private postal service in which all mail in private boxes was confiscated, opened, and read. The search warrant under which the computer was taken was based on incredible half-truth distortions, and simply irrelevant information. For example, the prime item presented under oath to the judge who issued the warrant was verbal testimony about a copy of a receipt for equipment sold to UCLA, shipped to a Florida address, and authorized by an Alcor officer who works at UCLA. In the first place, the coroner's office has no business investigating theft. If they found something suspicious in the course of other investigation, they should have turned it over to the police. In the second place, *taped to the front of that invoice was a canceled check on the officer's account for the full amount on the invoice.* If this isn't perjury, it skates within a hair of it. This may seem to be an unpopular cause to the FBI, but this is the first time (to my knowledge) that a law enforcement agency has violated the provisions of this law. As a result, there is a great deal of interest by a number of people in the electronic mail industry. If local law enforcement officials demonstrate that they can get away with ignoring this law, there may be considerable pressure on Congress to require more stringent provisions for law enforcement agencies to obtain access to electronic communications. If you have any questions, please give me a call. Sincerely, H. Keith Henson HKH:al cc: Christopher Ashworth, Esq. ATTACHMENT C (KH Lettterhead) April 25, 1988 Representative Norman Mineta 13th District 1245 S. Winchester Blvd., Suite 310 San Jose, Ca 95128 Attention: Dorene Giacopini Dear Representative Mineta: I am writing to ask you to intercede with the FBI on behalf of myself and two other San Jose constituents, Thomas K. Donaldson and Roger Gregory. We believe a Federal Law, Section 2701, et seq. of Title 18, was broken by local law enforcement officials in Southern California. We would like you to make a request of the FBI that they determine if this is true, and if it is, ask the U.S. Attorney to file charges. All of us used (and paid for through membership fees) an elec- tronic mail facility owned by the Alcor Life Extension Founda- tion. On January 12 of this year, the computer containing our confidential personal communications was seized by the coroner`s office in Riverside under a warrant issued against Alcor and obtained on the basis of gross distortions. Regardless of the validity of this warrant, <2703 requires a warrant naming the individual whose mail is to be seized, and stating probable cause as to the need to invade the individual`s privacy. No warrants have been issued which would permit these officials to access or deny us access to our electronic mail. The FBI is understandably reluctant to investigate a fellow law enforcement agency. In my first telephone conversation with Ron Heller he strongly discouraged me from complaining. While it may have been inadvertent, his office lost my first letter (sent by Express Mail), did not pass on the enclosed letter to the U.S. Attorney`s office, and suggested (when he called after 5PM last Friday) that my only recourse is to the same local officials who have violated the law. The cited section of law, the Electronic Communications Privacy Act of 1986, and the cases which develop from it are of great interest in Silicon Valley, where the local volume of electronic mail may be approaching that of First Class mail. There is a considerable interest expressed by several computer publications in the case. I can direct the reporters who are calling me to your office if you wish. Sincerely, H. Keith Henson HKH:al ATTACHMENT D --------------------------------- (KH letterhead) April 25, 1988 Senator Pet Wilson 2040 Ferry Building San Francisco, CA 94111 Attention: Lisa Nauman Dear Senator Wilson: (body same as Attachment D) ATTACHMENT E --------------------------------- (KH Letterhead) July 31, 1988 Representative Norman Mineta 13th District 1245 S. Winchester Blvd., Suite 310 San Jose, Ca 95128 Dear Representative Mineta: Thank you for pursuing an inquiry for me into the FBI's disinter- est in an apparent violation of the Electronic Communication Pri- vacy Act, and for forwarding a copy of Mr. Floyd Clark's letter. In that letter of June 3, the FBI excused their unwillingness to investigate because the US Attorney declined prosecution. Alka Sagar, the US Attorney in Los Angeles who Mr. Heller told me had made the decision to decline prosecution, based her decision entirely on a short telephone conversation with FBI represen- tative Mr. Heller. When I contacted her on the Monday after Mr. Heller told me that no investigation was going to be made, she told me that my letter to the FBI had not been forwarded. She could not remember either the subject or the reason for declining prosecution. If I could speculate on the conversation, Mr. Heller may have told her he had a case he did not want to work on, and her response may have been something like "Well, if you don't want to work on it, the U.S. Attorney isn't interested." This is hardly an independent evaluation of the merits of my complaint. I then wrote to Michael Emick, Ms. Sagar's boss. He is Chief of Criminal Complaints for the U.S. Attorney's Office in Los Angeles. One of Mr. Emick's assistants called a week or two later and told me that virtually no cases except those involving large amounts of cocaine are being accepted for prosecution, regardless of the merits. I have received no written response to my letter of April 25 to date (copy enclosed). There may be a need for remedial legislation on electronic pri- vacy. Mr. Heller, a San Jose FBI agent, and two representatives of the District Attorney's office in Riverside all believe that the requirements for obtaining warrants against individuals found in 1986 law can be safely ignored if a warrant can be obtained against the computer on which the electronic mail is stored. They use the analogy that if they obtained a warrant against a Post Office, they could open and read any mail they found within the walls of the Post Office. I doubt this was the intent of Representative Norman Mineta -2- July 31, 1988 Congress, but if it was, the fact would be of great interest in this area. In his closing sentence, Mr. Clark recommends that I contact an attorney to see what civil remedies are available to me. I have already contacted several. I find that while there are pro- visions (Section 2707) for civil actions at law, they are use- less. If a jury found that my privacy rights had indeed been violated, I could be awarded $1,000. The attorneys I have contacted tell me that the case could be made, and likely won, but the cost to do so would start at $100,000 and range upwards of $500,000. If this were an isolated incident, I would feel better about ignoring the decay of civil rights in this area. But recently Riverside county officials used a search warrant to confiscate television news tapes in violation of federal and state laws pro- tecting freedom of the press. Limits on law enforcement activi- ties are as important as limits on criminals. Although it is a lot of trouble for a citizen to oppose high handed law enforce- ment agents, it has to be done to prevent the loss of our rights. I would appreciate your inquiring of the Justice Department what reasoning they used to decline enforcing the law Congress made regarding electronic communications. Perhaps they would respond to a letter from you in less than three months. I know you are sensitive to shortcuts in due process, and I could use your ad- vice on what, if anything, I should do. Sincerely, H. Keith Henson HKH:al ATTACHMENT F ----------------------------------- U.S. Department of Justice Federal Bureau of Investigation Washington, DC 20535 June 27, 1988 Honorable Pete Wilson United States Senator 2040 Ferry Building San Francisco, California 94111 Dear Senator Wilson: Your May 18th inquiry of the Department of Justice on behalf of Mr. H. Keith Henson has been referred to FBI Headquarters. Mr. Henson's concerns have been reviewed both here and by our Los Angeles Office. The facts have been presented to the United States Attorney's Office and prosecution was declined. Mr. Henson has been advised of the declination and that our investigation is closed. It has been suggested to Mr. Henson that he contact an attorney of his choice to pursue possible civil remedies available to him. Sincerely yours, (signed) Floyd I. Clarke Assistant Director Criminal Investigative Division ATTACHMENT G -------------------------------- U.S. Department of Justice Office of Legislative Affairs Office of the Assistant Attorney General Washington, DC 20530 04 NOV 1988 (stamped date) Honorable Norman Y. Mineta U.S. House of Representatives 1245 South Winchester Blvd., Suite 310 San Jose, California 95128 ATTN: Dorene M. Giacopini Field Representative Dear Congressman Mineta: This is in response to your letter dated September 22, 1988, on behalf of your constituent H. Keith Henson. The Unites States Attorney's office for the Central District of California considered twice whether prosecution was warranted, taking into account the information provided by Mr. Henson. However, there is no competent evidence upon which to base a federal prosecution. Since Mr. Henson's letter addresses a matter currently being prosecuted by the State of California, this office recommends that you refer Mr. Henson's inquiry to the District Attorney's office, Los Angeles, California. Sincerely, (signed) Thomas M. Boyd (for) Assistant Attorney General ATTACHMENT H ------------------------------ (KH Letterhead) November 9, 1988 Thomas M. Boyd Assistant Attorney General Office of the Assistant Attorney General Washington, DC 20530 Dear Mr. Boyd: Representative Norman Mineta passed on your undated letter to me responding to his letter of September 22, 1988. It is a violation of federal law (Title 18, Section 2701 et seq.) to seize a person's electronic mail without a warrant against the person's mail. My electronic mail was seized without a warrant being sought against it. Could you tell me how these simple-to- determine facts fail to provide "competent evidence on which to base a federal prosecution." Could you tell me what constitutes "competent evidence" or provide a reference? Could you clarify the last paragraph of your letter. To the best of my knowledge there is nothing related to any letter I have written which is "currently being prosecuted by the State of California" by the District Attorney's office in Los Angeles. If there is, this would be of intense concern. Sincerely H. Keith Henson HKH:al cc Representative Norman Y. Mineta ATTACHMENT I ----------------------------- COUNTY OF RIVERSIDE, STATE OF CALIFORNIA SEARCH WARRANT (boilerplate, description of place to be searched) . . . for the following property: 1. All electronic storage devices, capable of storing, electronic data regarding the above records, including magnetic tapes, disc (floppy or hard), and the complete hardware necessary to retrieve electronic data including CPU (Central Processing Unit), CRT (viewing screen, disc or tape drive(s), printer, software and service manuals for operation of the said computer, together with all handwritten notes or printed material describing the operation of the computers. (See Exhibit A - Search Warrant No. 1, property to be seized #1) 2 Human body parts identifiable as belonging to the deceased, Dora Kent. 3 Narcotics, controlled substances and other drugs subject to regulation by the Drug Enforcement Administration. (more boilerplate, signature of Judge) ATTACHMENT J <- END PART 4 of 4 ->  Date: Sun, 8 Apr 90 01:09:06 EDT From: Alan Bawden Subject: mail too large err To: jtw@MINTAKA.LCS.MIT.EDU cc: BUG-COMSAT%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU, CENT%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU, MOON%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU, sra@MINTAKA.LCS.MIT.EDU Reply-to: Alan@Reagan.AI.MIT.EDU In-reply-to: Msg of Fri 6 Apr 90 3:12:19 EDT from John Wroclawski Message-ID: <719285.900408.ALAN@AI.AI.MIT.EDU> Date: Fri, 6 Apr 90 3:12:19 EDT From: John Wroclawski ... Well "I" believe that an absolute minimum of 110Kbytes is "reasonable", because "I" believe that the digestifier sends out 100K messages, and when they bounce back from zippy@west.bicycle.state and ... The new digestifier that we have been using since January has a limit on the size of a digest it is willing to produce. A digest larger than 52K characters is -impossible-. In practice, a digest larger than 46K characters has never been produced. (The difference is because of the size of header fields like "Received" that are removed in the process of forming a digest.) This number is easily adjusted up or down. You should take this into account in adjusting COMSAT's limits.  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU; 6 Apr 90 14:13:03 EDT From: John Wroclawski Sender: jtw@lcs.mit.edu To: sra@lcs.mit.edu CC: MOON@AI.ai.mit.edu, CENT@AI.ai.mit.edu, ALAN@AI.ai.mit.edu, BUG-COMSAT@AI.ai.mit.edu In-reply-to: Rob Austein's message of Fri, 6 Apr 90 11:45:44 EDT <9004061145.aa00125@mintaka.lcs.mit.edu> Subject: mail too large err Date: Fri, 6 Apr 90 14:08:13 EDT Message-ID: <9004061408.aa06865@mintaka.lcs.mit.edu> From: Rob Austein Sender: sra@lcs.mit.edu BCC: sra@lcs.mit.edu Date: Fri, 6 Apr 90 11:45:44 EDT From: John Wroclawski Date: Fri, 6 Apr 90 3:12:19 EDT ... Well "I" believe that an absolute minimum of 110Kbytes is "reasonable", because... What -is- the value in the running code right now? You, John, set it to 50Kbytes (IRQMIN==10.) last year. However, I, John, did not actually install a COMSAT built from those sources, because I am completely convinced that installing COMSATs is a form of black magic involving ancient druidic spells, in which the penalty for failure is that Alan and Penny come downstairs and silently glare at you for seven hours. A concept, as they say, with which I cannot deal. So I still don't know what the value in the running code is, I was thinking someone else might offhand, but I'll just look.  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU; 6 Apr 90 11:53:59 EDT From: Rob Austein Sender: sra@lcs.mit.edu To: jtw@lcs.mit.edu CC: MOON@AI.ai.mit.edu, CENT@AI.ai.mit.edu, ALAN@AI.ai.mit.edu, BUG-COMSAT@AI.ai.mit.edu In-reply-to: John Wroclawski's message of Fri, 6 Apr 90 3:12:19 EDT <9004060312.aa13815@mintaka.lcs.mit.edu> Subject: mail too large err BCC: sra@lcs.mit.edu Date: Fri, 6 Apr 90 11:45:44 EDT Message-ID: <9004061145.aa00125@mintaka.lcs.mit.edu> From: John Wroclawski Date: Fri, 6 Apr 90 3:12:19 EDT ... Well "I" believe that an absolute minimum of 110Kbytes is "reasonable", because... What -is- the value in the running code right now? You, John, set it to 50Kbytes (IRQMIN==10.) last year.  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU; 6 Apr 90 03:17:35 EDT From: John Wroclawski Sender: jtw@lcs.mit.edu To: sra@lcs.mit.edu CC: MOON@AI.ai.mit.edu, CENT@AI.ai.mit.edu, ALAN@AI.ai.mit.edu, BUG-COMSAT@AI.ai.mit.edu In-reply-to: Rob Austein's message of Thu, 5 Apr 90 18:43:09 EDT <9004051843.aa23767@mintaka.lcs.mit.edu> Subject: mail too large err Date: Fri, 6 Apr 90 3:12:19 EDT Message-ID: <9004060312.aa13815@mintaka.lcs.mit.edu> From: Rob Austein Sender: sra@lcs.mit.edu Date: Thu, 5 Apr 90 18:43:09 EDT So, does this mean that "we" believe that 57kbytes is a "reasonable" size for a mail message? The upper bound of "reasonable" is configurable and COMSAT has code to reboot itself if it can't handle a "reasonable" sized message. Well "I" believe that an absolute minimum of 110Kbytes is "reasonable", because "I" believe that the digestifier sends out 100K messages, and when they bounce back from zippy@west.bicycle.state and get to mintaka and comsat refuses to take them because they are too big, they end up in "my" mailbox. Or maybe it's just all the 150K S-F con reports that people send to KFL. I tend to forward -those- back to the sender with messages like "Access Restricted: Please Retransmit with FAR 1.13(42) Authorization Code". Seems to work. What -is- the value in the running code right now?  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU; 5 Apr 90 18:49:26 EDT From: Rob Austein Sender: sra@lcs.mit.edu To: MOON@AI.ai.mit.edu, CENT@AI.ai.mit.edu CC: ALAN@AI.ai.mit.edu, BUG-COMSAT@AI.ai.mit.edu In-reply-to: "Pandora B. Berman"'s message of Thu, 5 Apr 90 17:55:39 EDT <718596.900405.CENT@AI.AI.MIT.EDU> Subject: mail too large err Date: Thu, 5 Apr 90 18:43:09 EDT Message-ID: <9004051843.aa23767@mintaka.lcs.mit.edu> Date: Thu, 5 Apr 90 17:55:39 EDT From: "Pandora B. Berman" ... as you might have expected, this error was a symptom of comsat's building up too much junk in its address space due to less than absolutely perfect GCing since last launch. i relaunched both comsats and renamed the accumulated badreq files, and they all went through.. So, does this mean that "we" believe that 57kbytes is a "reasonable" size for a mail message? The upper bound of "reasonable" is configurable and COMSAT has code to reboot itself if it can't handle a "reasonable" sized message. (Ie, Penny wouldn't have had to do what she did if COMSAT were configured to believe that 57 kbyte messages were worth bothering with). I understand that Dave was talking about a related but different problem, I'm just pointing out that this particular bounce could have been avoided if so desired.  Date: Thu, 5 Apr 90 17:55:39 EDT From: "Pandora B. Berman" Subject: mail too large err To: MOON%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU cc: ALAN%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU, BUG-COMSAT%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU Message-ID: <718596.900405.CENT@AI.AI.MIT.EDU> Date: Thu, 5 Apr 90 15:50 EDT From: "David A. Moon" Subject: [COMSAT%MC.LCS.MIT.EDU@MINTAKA.lcs.mit.edu: Forwarded] To: alan@ai.ai.mit.edu cc: bug-comsat@ai.ai.mit.edu I wonder what message this was for? Oh, I recognize the length of 57,000 so I know what message it was, but I wonder who it was to. I'll just guess, based on domain-dependent knowledge, that it was to Alan. Comsat should include the first few lines of the input request file in the error message, and/or the SMPT server should refuse even to create a file that it knows Comsat is going to reject (so that the mail would bounce back through the original mailer). Oh I forgot, Comsat isn't getting any new features. you've known about this misfeature for years and had plenty of chance to fix it. If you figure out who was supposed to get the message, subject "Symbolics comments on chapter 4", and they really want to see it, I will "use the FTP program" to get it to them. Date: Thu, 5 Apr 90 15:07 EDT From: Communications Satellite To: "@mcc.com:Moon@stony-brook.scrc.symbolics.com"@MINTAKA.lcs.mit.edu cc: MAIL-MAINTAINERS%MC.LCS.MIT.EDU@MINTAKA.lcs.mit.edu Error in input request file. Request too large. Message not sent and not queued; 57 Kbytes is far too large for me. Please use the FTP program to transfer huge files around the network. as you might have expected, this error was a symptom of comsat's building up too much junk in its address space due to less than absolutely perfect GCing since last launch. i relaunched both comsats and renamed the accumulated badreq files, and they all went through.  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU; 5 Apr 90 15:47:25 EDT Received: from STONY-BROOK.SCRC.SYMBOLICS.COM by mintaka.lcs.mit.edu id aa15599; 5 Apr 90 15:45 EDT Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 773577; 5 Apr 90 15:45:17 EDT Date: Thu, 5 Apr 90 15:50 EDT From: "David A. Moon" Subject: [COMSAT%MC.LCS.MIT.EDU@MINTAKA.lcs.mit.edu: Forwarded] To: alan@ai.ai.mit.edu cc: bug-comsat@ai.ai.mit.edu Included-msgs: <658035.900405@MC.LCS.MIT.EDU>, The message of 5 Apr 90 15:07 EDT from COMSAT%MC.LCS.MIT.EDU@MINTAKA.lcs.mit.edu, The message of 5 Apr 90 15:07 EDT from Communications Satellite Message-ID: <19900405195040.0.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM> I wonder what message this was for? Oh, I recognize the length of 57,000 so I know what message it was, but I wonder who it was to. I'll just guess, based on domain-dependent knowledge, that it was to Alan. Comsat should include the first few lines of the input request file in the error message, and/or the SMPT server should refuse even to create a file that it knows Comsat is going to reject (so that the mail would bounce back through the original mailer). Oh I forgot, Comsat isn't getting any new features. If you figure out who was supposed to get the message, subject "Symbolics comments on chapter 4", and they really want to see it, I will "use the FTP program" to get it to them. Date: Thu, 5 Apr 90 15:07 EDT From: Communications Satellite To: "@mcc.com:Moon@stony-brook.scrc.symbolics.com"@MINTAKA.lcs.mit.edu cc: MAIL-MAINTAINERS%MC.LCS.MIT.EDU@MINTAKA.lcs.mit.edu Error in input request file. Request too large. Message not sent and not queued; 57 Kbytes is far too large for me. Please use the FTP program to transfer huge files around the network.  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU; 23 Mar 90 11:02:34 EST From: Rob Austein Sender: sra@lcs.mit.edu To: erik@naggum.uu.no CC: HEADER-PEOPLE-REQUEST@AI.ai.mit.edu, BUG-MAIL@AI.ai.mit.edu In-reply-to: Erik Naggum's message of Thu, 22 Mar 90 18:37:56 +0100 <9003221737.AAslembe07215@slembe.uio.no> Subject: Return-Path for header-people submissions Date: Fri, 23 Mar 90 10:56:45 EST Message-ID: <9003231056.aa24324@mintaka.lcs.mit.edu> Erik, The real answer to your question is that yes, we know that it would be better if the HEADER-PEOPLE mailing list's bounces went to the maintainers of the list. Unfortunately, for technical reasons, it would be difficult to make ITS COMSAT handle this exactly right, and, for ideological reasons, the handful of people left who are competent to fix this problem aren't happy with settling for half measures. That being the case, we get by the RFC-1123 guidelines on a technicality, by stating that COMSAT only supports "aliases", not "lists", and noting that RFC-1123 says that implementations "SHOULD" support both forms but doesn't say "MUST". It's not pretty, but that's how things stand. For what it's worth, if anybody ever does any work on COMSAT again, this problem is at or near the top of the priority list. --Rob Austein (for BUG-COMSAT@AI.AI.MIT.EDU)  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU; 22 Mar 90 13:01:40 EST Received: from ifi.uio.no by mintaka.lcs.mit.edu id aa28463; 22 Mar 90 12:38 EST Received: from slembe.uio.no by ifi.uio.no (5.61+IDA/KTH/LTH/1.15) with SMTP id AAifi10063; Thu, 22 Mar 90 18:37:59 +0100 Received: by slembe.uio.no (5.61+IDA/KTH/LTH/SMI-3.2) id AAslembe07215; Thu, 22 Mar 90 18:37:56 +0100 Date: Thu, 22 Mar 90 18:37:56 +0100 Message-Id: <9003221737.AAslembe07215@slembe.uio.no> From: Erik Naggum Sender: enag@ifi.uio.no To: CENT@AI.ai.mit.edu Cc: HEADER-PEOPLE-REQUEST@AI.ai.mit.edu, BUG-MAIL@AI.ai.mit.edu In-Reply-To: <703999.900222.CENT@AI.AI.MIT.EDU> Subject: Re: Return-Path for header-people submissions Pardon the response time, I've been on vacation for the past four weeks. To reestablish context: ----- Begin embedded message 1 Date: Thu, 22 Feb 90 22:55:01 EST From: "Pandora B. Berman" Message-Id: <703999.900222.CENT@AI.AI.MIT.EDU> - ----- Begin embedded message 2 Date: Thu, 8 Feb 90 05:21:20 +0100 From: Erik Naggum Sender: enag@ifi.uio.no To: header-people-request@MC.lcs.mit.edu Subject: Return-Path for header-people submissions The mailer at mc.lcs.mit.edu doesn't change the return-path to reflect the mailing list maintainer for header-people, so I get at least three failures for every message I mail off. Anybody want to look at it? - ----- End embedded message 2 Look at what? The failure of MC's mailer to mung the headers of mail it receives? That is not a bug, but a feature, since authors of mail can be assured that going through MC will not do strange things to their mail. COMSAT, the mailer here, quite properly returns bounced ordinary mail to the authors. Perhaps you are confused about the status of the Header-People list. It is not a digest, for which provisions could be made to insert a return path directed at the list maintainers. Header-People is a direct distribution list; mail sent to the list is immediately sent out to all list members. This makes such mail ordinary mail, and COMSAT knows better than to diddle the headers of ordinary mail. What you should do, and what the greeting message you received when you were added to the Header-People list encourages you to do, is to forward your bounces to Header-People-Request. That will alert us that there is a problem, and we will fix it.. ----- End embedded message 1 In my opinion, which I basically weened from the discussions I partook in regarding the IETF on Internet Host Requirements, error reports the like of "bounces" should be sent to the person who can do something about it: the sender if it was a directly addressed message, or the list maintainer if it was a list. The HR RFC's differentiate between "lists" and "aliases" the latter of which retains the original senders return-path, while the former replaces it with the list maintainer's, canonically -request. (Digests have nothing to do with this.) Please note that this is not precisely _headers_ -- it's the envelope that is being changed, which is reflected in the Return-Path header once the message is delivered to a mailbox. I have no reason to think that I am wrong, and I suggest that you take time to consider the discussion in the HR RFC (1123). [Erik]  Date: Sat, 17 Mar 90 00:12:42 EST From: Puff the Magic Dragon Subject: Happy Birthday! To: KSC%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU Message-ID: <711930.900317.DRAGON@AI.AI.MIT.EDU> Happy birthday to you, Happy birthday to you, Happy birthday dear Kennedy, Happy birthday to you.  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU; 5 Mar 90 15:25:40 EST From: Rob Austein Sender: sra@lcs.mit.edu To: ALAN@ai.ai.mit.edu CC: BUG-MAIL@ai.ai.mit.edu In-reply-to: Alan Bawden's message of Mon, 5 Mar 90 14:47:33 EST <707551.900305.ALAN@AI.AI.MIT.EDU> Subject: More pointless Return-Path flaming Date: Mon, 5 Mar 90 15:20:44 EST Message-ID: <9003051520.aa07855@mintaka.lcs.mit.edu> Date: Mon, 5 Mar 90 14:47:33 EST From: Alan Bawden Well, I suppose you have to re-work the address syntax for all the recipients, so perhaps it is more physical work. But I expect that for most mailing list maintainers there is less conceptual overhead in the concept of move-to-another-machine than there is in the concept of change-your-list-to-mail-to-a-program-that-... Since what I was figuring would happen would be that the big mailing lists would all be modified to use the new tool at once, by a single person, "conceptual overhead" didn't enter into it. Any mailing list large enough to need Return-Path munging should be an @FILE list anyway, so the change would be pretty trivial.  Date: Mon, 5 Mar 90 14:47:33 EST From: Alan Bawden Subject: More pointless Return-Path flaming To: sra@MINTAKA.LCS.MIT.EDU cc: BUG-MAIL%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU In-reply-to: Msg of Mon 5 Mar 90 11:01:02 EST from Rob Austein Message-ID: <707551.900305.ALAN@AI.AI.MIT.EDU> Date: Mon, 5 Mar 90 11:01:02 EST From: Rob Austein Date: Sun, 4 Mar 90 22:32:18 EST From: Alan Bawden Well, is that really any more work than re-working the addresses so that you can mail indirectly through a program? Yes. Well, I suppose you have to re-work the address syntax for all the recipients, so perhaps it is more physical work. But I expect that for most mailing list maintainers there is less conceptual overhead in the concept of move-to-another-machine than there is in the concept of change-your-list-to-mail-to-a-program-that-... My point was that if you make it anything other than simply adding a new mailing list attribute (R-RETURN-PATH or R-LIST-MAINTAINER, or something) then you're really admitting that COMSAT will never do it right and essentially abandoning COMSAT as unuseable. Agreed. You will notice that I don't read my mail on an ITS. And I do read my mail on an ITS. But we aren't talking about people who keep their inboxes on ITS. We're talking about people who maintain mailing lists here. Let's try and keep the discussion focused please. I don't care how much of a quick-and-dirty hack it is internal to COMSAT (assuming it works as all), but if the mailing list maintainers can't have something convenient, along the lines of a simple attribute they can add to their existing mailing list, if instead they have to stand on their heads to get this feature, then COMSAT is getting unnecessarily difficult for them to use. I think in that case that they really would be better off using some other mailer. As I have already said, I think it would be a good idea for all the mailing lists to move off of the ITS machines. Do you really think this will happen short of turning off COMSAT completely or sending all the mailing list maintainers for forced reeducation in Siberia? Where do you propose to put all these lists? What's this "all mailing lists" shit? I never suggested anything of the sort. If you insist on this caricature of my position, then perhaps I should caricature what you are saying as wanting to change -every- single mailing list in NAMES > to mail to a program! Why is it that it is ok to do weird but simple kludges for huge digested mailing lists but not for huge undigested mailing lists? I'll guess you're referring to the Digestifier? Are you claiming that the Digestifier should really be part of COMSAT? You might be right that a mailer should really provide this service itself. I imagine that a case can also be made that keeping digestification separate is a reasonable modularization. But -nobody- could think that a separate program just for changing the Return-Path is the "right" thing.  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU; 5 Mar 90 11:05:50 EST From: Rob Austein Sender: sra@lcs.mit.edu To: ALAN@AI.ai.mit.edu CC: BUG-MAIL@AI.ai.mit.edu In-reply-to: Alan Bawden's message of Sun, 4 Mar 90 22:32:18 EST <707335.900304.ALAN@AI.AI.MIT.EDU> Subject: Return-Path for header-people submissions Date: Mon, 5 Mar 90 11:01:02 EST Message-ID: <9003051101.aa24991@mintaka.lcs.mit.edu> Date: Sun, 4 Mar 90 22:32:18 EST From: Alan Bawden Well, is that really any more work than re-working the addresses so that you can mail indirectly through a program? Yes. My point was that if you make it anything other than simply adding a new mailing list attribute (R-RETURN-PATH or R-LIST-MAINTAINER, or something) then you're really admitting that COMSAT will never do it right and essentially abandoning COMSAT as unuseable. Agreed. You will notice that I don't read my mail on an ITS. I don't care how much of a quick-and-dirty hack it is internal to COMSAT (assuming it works as all), but if the mailing list maintainers can't have something convenient, along the lines of a simple attribute they can add to their existing mailing list, if instead they have to stand on their heads to get this feature, then COMSAT is getting unnecessarily difficult for them to use. I think in that case that they really would be better off using some other mailer. As I have already said, I think it would be a good idea for all the mailing lists to move off of the ITS machines. Do you really think this will happen short of turning off COMSAT completely or sending all the mailing list maintainers for forced reeducation in Siberia? Where do you propose to put all these lists? Why is it that it is ok to do weird but simple kludges for huge digested mailing lists but not for huge undigested mailing lists?  Date: Sun, 4 Mar 90 22:32:18 EST From: Alan Bawden Subject: Return-Path for header-people submissions To: sra@MINTAKA.LCS.MIT.EDU cc: BUG-MAIL%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU In-reply-to: Msg of Sun 4 Mar 90 21:09:25 EST from Rob Austein Message-ID: <707335.900304.ALAN@AI.AI.MIT.EDU> Date: Sun, 4 Mar 90 21:09:25 EST From: Rob Austein But then, why not just move the mailing list to a machine that runs a mailer that already knows how to do it? I think that's a fine idea, assuming we can find somebody who's willing to supply such a machine and somebody who's willing to do the work to move all the lists. Well, is that really any more work than re-working the addresses so that you can mail indirectly through a program? My point was that if you make it anything other than simply adding a new mailing list attribute (R-RETURN-PATH or R-LIST-MAINTAINER, or something) then you're really admitting that COMSAT will never do it right and essentially abandoning COMSAT as unuseable. I don't care how much of a quick-and-dirty hack it is internal to COMSAT (assuming it works as all), but if the mailing list maintainers can't have something convenient, along the lines of a simple attribute they can add to their existing mailing list, if instead they have to stand on their heads to get this feature, then COMSAT is getting unnecessarily difficult for them to use. I think in that case that they really would be better off using some other mailer.  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU; 4 Mar 90 21:13:15 EST From: Rob Austein Sender: sra@lcs.mit.edu To: ALAN@AI.ai.mit.edu CC: BUG-MAIL@AI.ai.mit.edu In-reply-to: Alan Bawden's message of Sat, 3 Mar 90 15:55:47 EST <707130.900303.ALAN@AI.AI.MIT.EDU> Subject: Return-Path for header-people submissions Date: Sun, 4 Mar 90 21:09:25 EST Message-ID: <9003042109.aa23364@mintaka.lcs.mit.edu> Date: Sat, 3 Mar 90 15:55:47 EST From: Alan Bawden Or perhaps you are willing to admit fixes that bypass COMSAT completely by delivering the message to some other program that re-mails the the message? Yes. So that KLH gets two copies of any message to Header-People and Bug-Mail? (Because he is on both.) That's what every other mailer I know of would do in this situation. So that in order to set up a mailing list with this property you have to edit -two- files? (Both NAMES > and wherever you keep the strings "Header-People-Request" and "(@FILE [KSC;HEADER PEOPLE])".) I would think that in both cases it would be a single-line entry in NAMES >, sending the message to a program. But then, why not just move the mailing list to a machine that runs a mailer that already knows how to do it? I think that's a fine idea, assuming we can find somebody who's willing to supply such a machine and somebody who's willing to do the work to move all the lists.  Date: Sat, 3 Mar 90 15:55:47 EST From: Alan Bawden Subject: Return-Path for header-people submissions To: sra@MINTAKA.LCS.MIT.EDU cc: BUG-MAIL%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU In-reply-to: Msg of Wed 28 Feb 90 18:37:11 EST from Rob Austein Message-ID: <707130.900303.ALAN@AI.AI.MIT.EDU> Date: Wed, 28 Feb 90 18:37:11 EST From: Rob Austein ... As I recall, all of the objections to just fixing this bug were caused by an excess of zeal (ie, people who wanted to fix it "right" rather than just fixing it). A quick and dirty fix would be trivial. Depends what you mean by ``"right"''. As I recall, we were stumped by what to do with a message that was addressed to -both- Header-People@MC and Bug-Mail@MC, assuming that Header-People-Request and Bug-Mail-Request both exist. We couldn't think of any ``quick and dirty fix'' that doesn't result in Bug-Mail-Request recieving error reports about delivery problems for Header-People recipients (or vice versa). Or perhaps you are willing to admit fixes that bypass COMSAT completely by delivering the message to some other program that re-mails the the message? So that KLH gets two copies of any message to Header-People and Bug-Mail? (Because he is on both.) So that in order to set up a mailing list with this property you have to edit -two- files? (Both NAMES > and wherever you keep the strings "Header-People-Request" and "(@FILE [KSC;HEADER PEOPLE])".) But then, why not just move the mailing list to a machine that runs a mailer that already knows how to do it?  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU; 1 Mar 90 02:36:05 EST From: Rob Austein Sender: sra@lcs.mit.edu To: BUG-MAIL@ai.ai.mit.edu In-reply-to: John Wroclawski's message of Wed, 28 Feb 90 14:31:57 EST <9002281431.aa10916@mintaka.lcs.mit.edu> Subject: Return-Path for header-people submissions Date: Wed, 28 Feb 90 18:37:11 EST Message-ID: <9002281837.aa23393@mintaka.lcs.mit.edu> See RFC 1123 section 5.3.6. We can claim that COMSAT is supporting the "alias" method of multiple-recipient delivery; if we make this claim we are only guilty of violating the provision that we "SHOULD" support the "list" method. As I recall, all of the objections to just fixing this bug were caused by an excess of zeal (ie, people who wanted to fix it "right" rather than just fixing it). A quick and dirty fix would be trivial.  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU; 28 Feb 90 17:42:17 EST From: John Wroclawski Sender: jtw@lcs.mit.edu To: ALAN%AI.AI.MIT.EDU@MINTAKA.lcs.mit.edu CC: CENT%AI.AI.MIT.EDU@MINTAKA.lcs.mit.edu, BUG-MAIL%AI.AI.MIT.EDU@MINTAKA.lcs.mit.edu In-reply-to: Alan Bawden's message of Fri, 23 Feb 90 14:49:56 EST <704268.900223.ALAN@AI.AI.MIT.EDU> Subject: Return-Path for header-people submissions Date: Wed, 28 Feb 90 14:31:57 EST Message-ID: <9002281431.aa10916@mintaka.lcs.mit.edu> Date: Fri, 23 Feb 90 14:49:56 EST From: Alan Bawden Instead of getting into an argument about Headers vs. Envelopes, the virtues and evils of header munging, and who doesn't understand what about RFC822, SMTP, etc. let me just point out that we -have- thought about doing what Erik suggested (or something like it), but we decided it was hard to make COMSAT do it right, and that there were more pressing problems for us to solve first. Actually, I think that maybe the current set of RFCs actually requires, or strongly urges, or something, us to do what this guy was suggesting. I suppose someone ought to check, if only so that we can be terribly apologetic when we tell people that yes we don't do that.  Date: Fri, 23 Feb 90 14:49:56 EST From: Alan Bawden Subject: Return-Path for header-people submissions To: CENT%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU, BUG-MAIL%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU, HEADER-PEOPLE-REQUEST%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU, "erik@NAGGUM.UU.NO"@MINTAKA.LCS.MIT.EDU In-reply-to: Msg of Thu 22 Feb 90 22:55:01 EST from Pandora B. Berman Message-ID: <704268.900223.ALAN@AI.AI.MIT.EDU> Instead of getting into an argument about Headers vs. Envelopes, the virtues and evils of header munging, and who doesn't understand what about RFC822, SMTP, etc. let me just point out that we -have- thought about doing what Erik suggested (or something like it), but we decided it was hard to make COMSAT do it right, and that there were more pressing problems for us to solve first.  Date: Thu, 22 Feb 90 22:55:01 EST From: "Pandora B. Berman" Subject: Return-Path for header-people submissions To: erik%naggum.uu.no@MINTAKA.LCS.MIT.EDU cc: HEADER-PEOPLE-REQUEST%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU, BUG-MAIL%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU Message-ID: <703999.900222.CENT@AI.AI.MIT.EDU> Date: Thu, 8 Feb 90 05:21:20 +0100 From: Erik Naggum Sender: enag@ifi.uio.no To: header-people-request@MC.lcs.mit.edu Subject: Return-Path for header-people submissions The mailer at mc.lcs.mit.edu doesn't change the return-path to reflect the mailing list maintainer for header-people, so I get at least three failures for every message I mail off. Anybody want to look at it? Look at what? The failure of MC's mailer to mung the headers of mail it receives? That is not a bug, but a feature, since authors of mail can be assured that going through MC will not do strange things to their mail. COMSAT, the mailer here, quite properly returns bounced ordinary mail to the authors. Perhaps you are confused about the status of the Header-People list. It is not a digest, for which provisions could be made to insert a return path directed at the list maintainers. Header-People is a direct distribution list; mail sent to the list is immediately sent out to all list members. This makes such mail ordinary mail, and COMSAT knows better than to diddle the headers of ordinary mail. What you should do, and what the greeting message you received when you were added to the Header-People list encourages you to do, is to forward your bounces to Header-People-Request. That will alert us that there is a problem, and we will fix it.  Date: Fri, 19 Jan 90 13:17:14 EST From: David Chapman Subject: [COMSAT%AI.AI.MIT.EDU: Msg of Thursday, 18 January 1990 18:23-EST] To: BUG-MAIL%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU, postmaster@REAGAN.AI.MIT.EDU Message-ID: <690924.900119.ZVONA@AI.AI.MIT.EDU> What's this nonsense? Date: Fri, 19 Jan 90 05:26:05 EST From: Communications Satellite To: ZVONA%AI.AI.MIT.EDU at MINTAKA.LCS.MIT.EDU Re: Msg of Thursday, 18 January 1990 18:23-EST FAILED: BUG-SDL at REAGAN.AI.MIT.EDU; I gave up on sending this after 31 "temporary" errors. Failed message follows: ------- Date: Thu, 18 Jan 90 18:23:58 EST From: David Chapman To: BUG-SDL@REAGAN.AI.MIT.EDU Message-ID: <690578.900118.ZVONA@AI.AI.MIT.EDU> [Assorted forwarding headers removed.] Subject: Talk Announcement for Friday, 19 January, 1:30 p.m. A New Japanese National Project: Software Architecture for Cooperative Agents Hideyuki Nakashima Electrotechnical Laboratory, Tsukuba, Japan Friday, 19 January, 1:30 p.m. Cordura 100 [UCBerekeley] MITI has just launched an eight-year software project. The main goal is to develop an innovative paradigm for developing flexible software. By "flexible" we mean software that can adjust its own behavior according to the surrounding situation. Dr. Nakashima will talk about why the idea of situation theory is important to the project.  Date: Thu, 11 Jan 90 06:16:13 EST From: "Pandora B. Berman" Subject: unknown recipient To: ZVONA%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU cc: BUG-MAIL%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU Message-ID: <687469.900111.CENT@AI.AI.MIT.EDU> Date: Tue, 2 Jan 90 19:10:30 EST From: David Chapman Subject: [COMSAT%AI.AI.MIT.EDU: Msg of Tuesday, 2 January 1990 19:02-EST] To: BUG-MAIL%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU Y'know, I think this feature has outlived its usefulness. Date: Tue, 2 Jan 90 19:02:37 EST From:Communications Satellite To: ZVONA%AI.AI.MIT.EDU at MINTAKA.LCS.MIT.EDU Re: Msg of Tuesday, 2 January 1990 19:02-EST ============ A copy of your message is being returned, because: =========== "MOBOTS" at AI.AI.MIT.EDU is an unknown recipient. Will try sending to the file "USERS2;MOBOTS MAIL". ============ Failed message follows: ============ ... i disagree. we are still occasionally acquiring new users who might take a while to get their asses in gear about inquir entries.  Date: Tue, 2 Jan 90 19:10:30 EST From: David Chapman Subject: [COMSAT%AI.AI.MIT.EDU: Msg of Tuesday, 2 January 1990 19:02-EST] To: BUG-MAIL%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU Message-ID: <684464.900102.ZVONA@AI.AI.MIT.EDU> Y'know, I think this feature has outlived its usefulness. Date: Tue, 2 Jan 90 19:02:37 EST From: Communications Satellite To: ZVONA%AI.AI.MIT.EDU at MINTAKA.LCS.MIT.EDU Re: Msg of Tuesday, 2 January 1990 19:02-EST ============ A copy of your message is being returned, because: ============ "MOBOTS" at AI.AI.MIT.EDU is an unknown recipient. Will try sending to the file "USERS2;MOBOTS MAIL". ============ Failed message follows: ============ ...  Date: Sat, 23 Dec 89 16:48:43 EST From: Alan Bawden To: BUG-COMSAT%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU Message-ID: <682809.891223.ALAN@AI.AI.MIT.EDU> In the latest COMSAT (installed on AI and MC) the HEADER-FORCE field in the request file has priority over any R-READER-FORCE options found in the NAMES file. This change makes HEADER-FORCE:NULL work as expected for programs that expect to create their own headers.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU; 16 Dec 89 04:59:56 EST Date: Sat, 16 Dec 89 04:55:21 EST From: "Pandora B. Berman" Subject: where did that digest go? To: DEAD-FLAMES-REQUEST%MC.LCS.MIT.EDU@MINTAKA.LCS.MIT.EDU, AVIATION-REQUEST%MC.LCS.MIT.EDU@MINTAKA.LCS.MIT.EDU, PAGANISM-REQUEST%MC.LCS.MIT.EDU@MINTAKA.LCS.MIT.EDU, SCA-REQUEST%MC.LCS.MIT.EDU@MINTAKA.LCS.MIT.EDU, SUBGENIUS-REQUEST%MC.LCS.MIT.EDU@MINTAKA.LCS.MIT.EDU, SCHEME-REQUEST%MC.LCS.MIT.EDU@MINTAKA.LCS.MIT.EDU cc: BUG-MAIL%MC.LCS.MIT.EDU@MINTAKA.LCS.MIT.EDU Message-ID: <632747.891216.CENT@MC.LCS.MIT.EDU> Maintainers of digests distributed via MC may have noticed a surprising jump in the issue number earlier this week. If you (or your subscribers) keep track of such things and were wondering why you (or they) didn't receive one digest, the answer it that it never existed. Just after midnight 14 Dec, as the digestifier was in the process of composing the digests, MC crashed. When it was booted again in the morning, it started composing the digests again (actually, Alan had to do a little jiggling to cause this to work right -- another fun bug with the digestifier code -- but he knew it needed checking and the problem wasn't difficult to deal with, so that has no effect on the situation). But since the digestifier's first act is to increment the issue number, it did that -- thus effectively raising the 14 Dec issue 2 over the 13 Dec one..  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU; 6 Dec 89 17:38:49 EST Received: by mintaka.lcs.mit.edu id ab28269; 6 Dec 89 17:32 EST From: Rob Austein Sender: sra@mintaka.lcs.mit.edu To: Moon@stony-brook.scrc.symbolics.com CC: BUG-COMSAT@ai.ai.mit.edu In-reply-to: "David A. Moon"'s message of Mon, 4 Dec 89 12:33 EST <19891204173344.7.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM> Subject: "For all we know, it does this all the time" Date: Wed, 6 Dec 89 17:28:15 EST Message-ID: <8912061728.aa28101@mintaka.lcs.mit.edu> Date: Mon, 4 Dec 89 12:33 EST From: "David A. Moon" Rob, I don't understand all this complicated hair. All I was trying to suggest was that the check for whether it's already connected to the right host, which Comsat makes before delivering mail, should be based on the host it's actually connected to, not on the host it's trying to deliver to. It's just looking at the wrong variable somewhere, isn't it? Yes, one way of looking at what's happening is to say that COMSAT should compare with instead of with . But even if that problem were fixed, the fact that COMSAT doesn't realize that all these messages are going through the same host means that COMSAT is going to send the message text a whole bunch more times than it should, and waste mintaka's disk space with a lot of identical messages to different recipients. There may also be some separate flakeout in the code that attempts to reuse net connections, the error message NET CONNS GONE appears in the logs far more often than it should.  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU; 6 Dec 89 13:35:11 EST Received: from STONY-BROOK.SCRC.SYMBOLICS.COM by mintaka.lcs.mit.edu id aa05488; 6 Dec 89 13:12 EST Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 701793; 4 Dec 89 12:31:31 EST Date: Mon, 4 Dec 89 12:33 EST From: "David A. Moon" Subject: "For all we know, it does this all the time" To: Rob Austein cc: BUG-COMSAT@ai.ai.mit.edu In-Reply-To: <8912030045.aa10565@mintaka.lcs.mit.edu> Message-ID: <19891204173344.7.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM> Date: Sun, 3 Dec 89 0:45:03 EST From: Rob Austein Date: Sat, 2 Dec 89 23:01:03 EST From: "David A. Moon" 210931 ICP->WHEATIES.AI.MIT.EDU (CHAOS-SMTP via MINTAKA.LCS.MIT.EDU) 210936 XTO->orca 210938 XTO->KWH-PROF 210939 XTO->jeremy 210941 XTO->DPH 210941 TEXT-> 210944 ICP->P.CS.UIUC.EDU (CHAOS-SMTP via MINTAKA.LCS.MIT.EDU) 210949 TO->forbus 210955 TO->PGS...net conns gone. 210956 Queued: <675159.891201@AI.AI.MIT.EDU> for MINTAKA.LCS.MIT.EDU The one other fact that you'd like to know is that PGS gets his mail on Mintaka. You can see that there are three bugs here: it connects separately to Mintaka for each different host it's forwarding to, it doesn't use XTO when both forwarding through Mintaka and sending directly to Mintaka, and it -always- says "net conns gone" for people who get their mail on Mintaka (until it dequeues). Bug one is known, and would be fixed by setting $$DQIN==0 when compiling COMSAT. The problem is that COMSAT thinks it's really "connecting" to each of these hosts (specificly, the HOSTS3 addresses in the address expansion are distinct for each of these hosts), so it doesn't realize that the actual network connection is to the same host every time. I -think- we have convinced ourselves (we being me, Alan, and JTW) that zeroing $$DQIN would still process outgoing mail correctly, but as things stand the RFC822 headers of any message whose headers are munged by COMSAT would be pretty hideous and might cause third party recipients not to get their copies of replies. Ie, we think that MMDF will probably bounce recipients like <"fred@question-authority"@mintaka.lcs.mit.edu> and we think this is not an unreasonable thing for MMDF to do. The sollution is to fix the (lame) code in COMSAT's guts that handles address quoting so that such addresses will become and while we are at it, fix the stupid code that adds double quote characters without checking to see if they are already present. Rob, I don't understand all this complicated hair. All I was trying to suggest was that the check for whether it's already connected to the right host, which Comsat makes before delivering mail, should be based on the host it's actually connected to, not on the host it's trying to deliver to. It's just looking at the wrong variable somewhere, isn't it? The other two bugs are news to me. It is just barely possible that fixing the first bug will fix the others too, but that's just a guess as to what might be happening. I just thought the teeming Comsat development staff would like to know.. "I thought that after seven boring hours at school, you might appreciate one moment of pure, abject terror." --Hobbes  Date: Mon, 4 Dec 89 23:07:52 EST From: "Pandora B. Berman" Subject: Is ML Down permanently? To: CarlManning@WORKSERVER.AI.MIT.EDU cc: BUG-MAIL%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU Message-ID: <675973.891204.CENT@AI.AI.MIT.EDU> Date: Mon, 4 Dec 89 09:34 EST From: Carl R. Manning Subject: Is ML Down permanently? If so, please remove it from *bboard@mc. To: postmaster@MC.LCS.MIT.EDU Is ML Down permanently? If so, please remove it from *bboard@mc. Date: Sat, 2 Dec 89 04:45 EST From: Communications Satellite Subject: Msg of Friday, 1 December 1989 13:26-EST To: "@REAGAN.AI.MIT.EDU:CarlManning@WORKSERVER.AI.MIT.EDU"@REAGAN.AI.MIT.EDU FAILED: [.MSGS.;*MSG >] at ML.AI.MIT.EDU; Host appears to be permanently down or not accepting mail. Failed message follows: ------- no, ML is not down permanently. it has disk trouble, and we have been waiting for the person with the necessary technical ability to apply an oscilloscope to it and decide which parts need to be swapped with other drives of the same ilk. it will be down until that happens. i agree that it has been down for several weeks, and that is perhaps long enough to suspend it from the sysmsg loop until it does get around to being fixed. we will consider that.  Date: Mon, 4 Dec 89 23:04:54 EST From: "Pandora B. Berman" Subject: tech-square mail list To: dmjones@THEORY.LCS.MIT.EDU cc: BUG-MAIL%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU Message-ID: <675971.891204.CENT@AI.AI.MIT.EDU> Date: Mon, 4 Dec 89 09:21:55 EST From: "David M. Jones" To: cent@mc.lcs.mit.edu Subject: tech-square mail list Hello. I understand that you maintain the mail list tech-square@xx. I maintain a mail list for distributing seminar announcements for the Theory of Computation Group, and we forward our announcements to tech-square. For the last month or so I've been getting all my mail mail bounced back with a message saying that host ML.AI.MIT.EDU seems to be permanently down. Since that host doesn't appear anywhere explicitly on our list, I thought this message might be coming from the tech-square list. Do you know anything about this machine? I've appended a sample message below. David M. Jones Assistant to Prof. Albert R. Meyer --------------------------------------------------------------------------- Date: Fri, 1 Dec 89 05:59:02 EST From: Communications Satellite Subject: Msg of Tuesday, 28 November 1989 10:00-EST To: "dmjones@theory.lcs.mit.edu"@mintaka.lcs.mit.edu FAILED: [.MSGS.;*MSG >] at ML.AI.MIT.EDU; Host appears to be permanently down or not accepting mail. Failed message follows: ------- you have correctly analyzed this (or had it analyzed for you) as a problem with ML rather than with the entire list of broadcast addresses (which is what some people, alas, deduce from such an error msg -- so they send their msg again. and again. and....). in point of fact i do not per se Maintain TECH-SQ@XX. that address, i gather, either forwards to or includes *MAC@MC, which is what i attempt to keep in a minimal degree of order. *MAC@MC includes this address at ML -- the odd format of the address is in fact the standard form of an ITS system msg address when the msg reaches its final destination, a file on a particular directory. ML is down with disk problems. it has been down for a couple weeks, perhaps as much as a month. we are trying to get it fixed, but that involves getting JTW's attention so he can swap parts between ML's disk drive and other spare disk drives of the same ilk. possibly it would be appropriate (or at least sanity-preserving for the folks who send system msgs) to take ML out of the broadcast audience until it is fixed. i will have to ask the other folks involved with ITS matinenance first.  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU; 3 Dec 89 00:50:09 EST From: Rob Austein Sender: sra@mintaka.lcs.mit.edu To: MOON@AI.ai.mit.edu CC: BUG-COMSAT@AI.ai.mit.edu In-reply-to: "David A. Moon"'s message of Sat, 2 Dec 89 23:01:03 EST <675382.891202.MOON@AI.AI.MIT.EDU> Subject: "For all we know, it does this all the time" Date: Sun, 3 Dec 89 0:45:03 EST Message-ID: <8912030045.aa10565@mintaka.lcs.mit.edu> Date: Sat, 2 Dec 89 23:01:03 EST From: "David A. Moon" 210931 ICP->WHEATIES.AI.MIT.EDU (CHAOS-SMTP via MINTAKA.LCS.MIT.EDU) 210936 XTO->orca 210938 XTO->KWH-PROF 210939 XTO->jeremy 210941 XTO->DPH 210941 TEXT-> 210944 ICP->P.CS.UIUC.EDU (CHAOS-SMTP via MINTAKA.LCS.MIT.EDU) 210949 TO->forbus 210955 TO->PGS...net conns gone. 210956 Queued: <675159.891201@AI.AI.MIT.EDU> for MINTAKA.LCS.MIT.EDU The one other fact that you'd like to know is that PGS gets his mail on Mintaka. You can see that there are three bugs here: it connects separately to Mintaka for each different host it's forwarding to, it doesn't use XTO when both forwarding through Mintaka and sending directly to Mintaka, and it -always- says "net conns gone" for people who get their mail on Mintaka (until it dequeues). Bug one is known, and would be fixed by setting $$DQIN==0 when compiling COMSAT. The problem is that COMSAT thinks it's really "connecting" to each of these hosts (specificly, the HOSTS3 addresses in the address expansion are distinct for each of these hosts), so it doesn't realize that the actual network connection is to the same host every time. I -think- we have convinced ourselves (we being me, Alan, and JTW) that zeroing $$DQIN would still process outgoing mail correctly, but as things stand the RFC822 headers of any message whose headers are munged by COMSAT would be pretty hideous and might cause third party recipients not to get their copies of replies. Ie, we think that MMDF will probably bounce recipients like <"fred@question-authority"@mintaka.lcs.mit.edu> and we think this is not an unreasonable thing for MMDF to do. The sollution is to fix the (lame) code in COMSAT's guts that handles address quoting so that such addresses will become and while we are at it, fix the stupid code that adds double quote characters without checking to see if they are already present. The other two bugs are news to me. It is just barely possible that fixing the first bug will fix the others too, but that's just a guess as to what might be happening. I just thought the teeming Comsat development staff would like to know.. "I thought that after seven boring hours at school, you might appreciate one moment of pure, abject terror." --Hobbes  Date: Sat, 2 Dec 89 23:01:03 EST From: "David A. Moon" Subject: "For all we know, it does this all the time" To: BUG-COMSAT%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU Message-ID: <675382.891202.MOON@AI.AI.MIT.EDU> 210931 ICP->WHEATIES.AI.MIT.EDU (CHAOS-SMTP via MINTAKA.LCS.MIT.EDU) 210936 XTO->orca 210938 XTO->KWH-PROF 210939 XTO->jeremy 210941 XTO->DPH 210941 TEXT-> 210944 ICP->P.CS.UIUC.EDU (CHAOS-SMTP via MINTAKA.LCS.MIT.EDU) 210949 TO->forbus 210955 TO->PGS...net conns gone. 210956 Queued: <675159.891201@AI.AI.MIT.EDU> for MINTAKA.LCS.MIT.EDU The one other fact that you'd like to know is that PGS gets his mail on Mintaka. You can see that there are three bugs here: it connects separately to Mintaka for each different host it's forwarding to, it doesn't use XTO when both forwarding through Mintaka and sending directly to Mintaka, and it -always- says "net conns gone" for people who get their mail on Mintaka (until it dequeues). I just thought the teeming Comsat development staff would like to know.  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU 14 Nov 89 15:05:51 EST Received: from [128.81.41.109] by mintaka.lcs.mit.edu id aa29142; 14 Nov 89 14:57 EST Received: from PEREGRINE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 349391; 14 Nov 89 14:07:26 EST Received: from STONY-BROOK.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 349383; 14 Nov 89 13:57:12 EST Received: from LCS.MIT.EDU by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 692297; 14 Nov 89 13:57:01 EST Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa27888; 14 Nov 89 13:50 EST Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 14 Nov 89 13:54:01 EST Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 14 Nov 89 13:53:40 EST Received: from MORRISON.AI.MIT.EDU by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 275945; 14 Nov 89 13:50:52 EST Date: Tue, 14 Nov 89 13:51 EST From: "John C. Mallery" Subject: [COMSAT%AI.AI.MIT.EDU@mintaka.lcs.mit.edu: Msg of Tuesday, 14 November 1989 02:51-EST] To: bug-comasat@ai.ai.mit.edu Included-msgs: <668943.891114@AI.AI.MIT.EDU>, The message of 14 Nov 89 05:01 EST from COMSAT%AI.AI.MIT.EDU@mintaka.lcs.mit.edu, The message of 14 Nov 89 05:01 EST from Communications Satellite Message-ID: <19891114185100.6.JCMA@MORRISON.AI.MIT.EDU> Resent-To: bug-comsat@ai.ai.mit.edu Resent-From: Ed Schwalenberg Resent-Date: Tue, 14 Nov 89 14:06 EST Resent-Message-ID: <19891114190616.4.ED@PEREGRINE.SCRC.Symbolics.COM> Someone seems to have inserted random characters into ML names > file. ML is down now so I can fix it. Date: Tue, 14 Nov 89 05:01 EST From: Communications Satellite Subject: Msg of Tuesday, 14 November 1989 02:51-EST To: "@life.ai.mit.edu:JCMA@reagan.ai.mit.edu"@mintaka.lcs.mit.edu FAILED: [.MSGS.;*MSG >] at ML.AI.MIT.EDU; Host appears to be permanently down or not accepting mail. Failed message follows: ------- Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU 14 Nov 89 02:50:36 EST Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa02655; 14 Nov 89 2:42 EST Received: from REAGAN.AI.MIT.EDU by life.ai.mit.edu (4.0/AI-4.10) id AA01378; Tue, 14 Nov 89 02:41:32 EST Received: from MORRISON.AI.MIT.EDU by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 275782; 14 Nov 89 02:42:29 EST Date: Tue, 14 Nov 89 02:42 EST From: "John C. Mallery" Subject: Victor Sergeev: Contemporary Soviet AI Research To: ai-seminar@ai.mit.edu, ai-seminar@ai.mit.edu Start-Date: Tue, 14 Nov 89 17:00 EST Expiration-Date: Tue, 14 Nov 89 17:45 EST Message-Id: <19891114074227.5.JCMA@MORRISON.AI.MIT.EDU> Tuesday, Nov 14, 5:00-5:45 p.m. NE43 8th floor playroom. Contemporary Soviet Research in Artificial Intelligence and Computational Linguistics Victor Sergeev Head of Laboratory for Decision Analysis Institute of The United States and Canada Academy of Sciences of The U.S.S.R The talk overviews cognitive modeling at the Soviet Academy of Sciences, situating it within more general Soviet research in artificial intelligence and computer science. At the Laboratory for Decision Analysis, cognitive modeling spans knowledge representation, text analysis, syntactic analysis, symbolic decision processes, as well as rationality and learning. The conclusion contrasts disciplinary origins of Soviet research to U.S. research and reviews particularly strong Soviet traditions, which include very well developed linguistic theory (semantics and pragmatics), mathematical logic, and pattern recognition.  Date: Mon, 13 Nov 89 13:41:25 EST From: Alan Bawden To: ZVONA%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU, RS%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU cc: BUG-MAIL%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU Message-ID: <668589.891113.ALAN5@AI.AI.MIT.EDU> I created mounds of space on devon's directory by using :BKLIST to delete zillions of links to backup tape. I guess this has the bad effect that now devon can waste more actual disk space.  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU 13 Nov 89 13:11:53 EST Received: from ai.ai.mit.edu by mintaka.lcs.mit.edu id aa05710; 13 Nov 89 13:05 EST Date: Mon, 13 Nov 89 13:08:37 EST From: David Chapman Sender: ZVONA0@AI.ai.mit.edu Subject: [COMSAT%AI.AI.MIT.EDU: Msg of Friday, 10 November 1989 16:47-EST] To: RS%AI.AI.MIT.EDU@MINTAKA.lcs.mit.edu cc: BUG-MAIL%AI.AI.MIT.EDU@MINTAKA.lcs.mit.edu In-reply-to: Msg of Mon 13 Nov 89 00:45:25 EST from Robert E. Seastrom Message-ID: <668571.891113.ZVONA0@AI.AI.MIT.EDU> Devon's directory is full, so COMSAT can't write into it. (You can diagnose problems like this by looking at the file .mail.;stats >.)  Date: Mon, 13 Nov 89 00:47:18 EST From: "Robert E. Seastrom" Subject: [COMSAT%AI.AI.MIT.EDU: Msg of Friday, 10 November 1989 18:25-EST] To: BUG-MAIL%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU Message-ID: <668389.891113.RS@AI.AI.MIT.EDU> This too? Does COMSAT have a vendetta against poor Devon? Date: Sun, 12 Nov 89 23:52:37 EST From: Communications Satellite To: RS%AI.AI.MIT.EDU at MINTAKA.LCS.MIT.EDU Re: Msg of Friday, 10 November 1989 18:25-EST FAILED: DEVON at AI.AI.MIT.EDU; I gave up on sending this after 201 "temporary" errors. Failed message follows: ---- blah blah blah...  Date: Mon, 13 Nov 89 00:45:25 EST From: "Robert E. Seastrom" Subject: [COMSAT%AI.AI.MIT.EDU: Msg of Friday, 10 November 1989 16:47-EST] To: BUG-MAIL%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU Message-ID: <668387.891113.RS@AI.AI.MIT.EDU> I fail to see why this didn't work; maybe someone can offer some more insight... Date: Sun, 12 Nov 89 21:43:28 EST From: Communications Satellite To: RS%AI.AI.MIT.EDU at MINTAKA.LCS.MIT.EDU Re: Msg of Friday, 10 November 1989 16:47-EST FAILED: (FILE [DEVON;JUNK MAIL]) at AI.AI.MIT.EDU; I gave up on sending this after 201 "temporary" errors. Failed message follows: ------- Date: Fri, 10 Nov 89 16:47:54 EST From: "Robert E. Seastrom" To: UNIX-HATERS%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU Message-ID: <667714.891110.RS@AI.AI.MIT.EDU> VI(1) UNIX Programmer's Manual VI(1) NAME vi - vile display editor based on ex (excrement) SYNOPSIS vi [ -t tag ] [ -r ] [ +command ] [ -l ] [ -wn ] name ... DESCRIPTION Vi (vile) is a display oriented text editor based on ex(1). Ex and vi run the same code; it is possible to get to the command mode of ex from within vi and vice-versa. The Vi Quick Reference card and the Introduction to Dismay Editing with Vi provide full details on losing with vi. FILES See ex(1). SEE ALSO ex (1), edit (1), ``Vi Quick Reference'' card, ``An Intro- duction to Dismay Editing with Vi''. AUTHOR William Sorrow Mark Horton added macros to visual mode and is maintaining version 3 BUGS It's not Emacs, and it runs under Unix. Software tabs using ^T work only immediately after the autoindent. Left and right shifts on intelligent terminals don't make use of insert and delete character operations in the termi- nal. The wrapmargin option can be fooled since it looks at output columns when blanks are typed. If a long word passes through the margin and onto the next line without a break, then the line won't be broken. Insert/delete within a line can be slow if tabs are present on intelligent terminals, since the terminals need help in doing this correctly. Saving text on deletes in the named buffers is somewhat inefficient. The source command does not work when executed as :source; there is no way to use the :append, :change, and :insert commands, since it is not possible to give more than one line of input to a : escape. To use these on a :global you Printed 11/10/89 April 29, 1985 1 VI(1) UNIX Programmer's Manual VI(1) must Q to ex command mode, execute them, and then reenter the screen editor with vi or open. Printed 11/10/89 April 29, 1985 2  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 12 Nov 89 19:15:40 EST Date: Sun, 12 Nov 89 19:15:49 EST From: David Chapman To: BUG-MAIL%MC.LCS.MIT.EDU@MINTAKA.LCS.MIT.EDU Message-ID: <626467.891112.ZVONA@MC.LCS.MIT.EDU> The 450-fixed mailer seems to be winning on AI, so I've installed it on MC.  Date: Fri, 10 Nov 89 18:32:05 EST From: David Chapman Subject: 450 errors: can we fix just this bug? To: sra@MINTAKA.LCS.MIT.EDU cc: BUG-MAIL%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU In-reply-to: Msg of Thu 9 Nov 89 16:19:17 EST from Rob Austein Message-ID: <667771.891110.ZVONA@AI.AI.MIT.EDU> I believe that if ``you'' were to assemble COMSAT from source and install it, exactly what you are talking about would happen. OK, ``I'' have installed it on AI. If anything bad happens, you'll hear about it...  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU 10 Nov 89 00:45:22 EST From: Rob Austein Sender: sra@mintaka.lcs.mit.edu To: bawden@parc.xerox.com, ZVONA@ai.ai.mit.edu CC: BUG-MAIL@ai.ai.mit.edu In-reply-to: Alan Bawden's message of Thu, 9 Nov 89 17:18 PST <19891110011851.9.ALAN@MR-BUN.parc.xerox.com> Subject: 450 errors: can we fix just this bug? Date: Fri, 10 Nov 89 0:20:27 EST Message-ID: <8911100020.aa29087@mintaka.lcs.mit.edu> Date: Thu, 9 Nov 89 17:18 PST From: Alan Bawden I was under the impression that "all ``you'' had to do" was to install the already existing binaries and then modify the NAMES file to insure that it would get recompiled. Installing the existing binaries and recompiling the names file would produce a working COMSAT that would forward a lot of messages to Mintaka in such a way that Mintaka would bounce them. Eg, "postmaster@wheaties" would bounce. I think this comes under the category of "the operation was a success but the patient died." Or are you telling Zvona to assemble it because that will result in a binary that -does- fix the 450 bug, but that -doesn't- need the NAMES file recompiled? Assembling it would produce a binary that should fix the 450 bug but which postpones any action on the IP hostname problem. I think this is the correct thing to do for the moment. I'm sorry if I'm confusing the issue somehow here, but I wanted to be sure we understood what we were doing. Of course on the other hand if I get one more message about the 450 bug in my mailbox I'm going to go and buy myself a machine gun and a truckload of department store dummies. You're not confusing the issue. If somebody tells me that s/he will be watching COMSAT for weirdness and will back out to the current version if necessary, I'll build and install a COMSAT with the 450 fix.  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU 9 Nov 89 20:26:02 EST Received: from arisia.Xerox.COM by mintaka.lcs.mit.edu id aa16942; 9 Nov 89 20:20 EST Received: from roo.parc.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA16419; Thu, 9 Nov 89 17:17:05 -0800 Received: from mr-bun.parc.Xerox.COM by roo.parc.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA00692; Thu, 9 Nov 89 17:19:22 PST Date: Thu, 9 Nov 89 17:18 PST From: Alan Bawden Subject: 450 errors: can we fix just this bug? To: sra@lcs.mit.edu Cc: ZVONA%AI.AI.MIT.EDU@Mintaka.lcs.mit.edu, BUG-MAIL%AI.AI.MIT.EDU@Mintaka.lcs.mit.edu In-Reply-To: <8911091619.aa15068@mintaka.lcs.mit.edu> Message-Id: <19891110011851.9.ALAN@MR-BUN.parc.xerox.com> Date: Thu, 9 Nov 89 16:19:17 EST From: Rob Austein I believe that if ``you'' were to assemble COMSAT from source and install it, exactly what you are talking about would happen. Ie, the problems seen before would not happen with the current default switch settings. I was under the impression that "all ``you'' had to do" was to install the already existing binaries and then modify the NAMES file to insure that it would get recompiled. Or are you telling Zvona to assemble it because that will result in a binary that -does- fix the 450 bug, but that -doesn't- need the NAMES file recompiled? I'm sorry if I'm confusing the issue somehow here, but I wanted to be sure we understood what we were doing. Of course on the other hand if I get one more message about the 450 bug in my mailbox I'm going to go and buy myself a machine gun and a truckload of department store dummies.  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU 9 Nov 89 16:23:42 EST From: Rob Austein Sender: sra@mintaka.lcs.mit.edu To: ZVONA@AI.ai.mit.edu CC: BUG-MAIL@AI.ai.mit.edu In-reply-to: David Chapman's message of Thu, 9 Nov 89 16:08:19 EST <667149.891109.ZVONA@AI.AI.MIT.EDU> Subject: 450 errors: can we fix just this bug? Date: Thu, 9 Nov 89 16:19:17 EST Message-ID: <8911091619.aa15068@mintaka.lcs.mit.edu> Date: Thu, 9 Nov 89 16:08:19 EST From: David Chapman I didn't follow the new-mailer-brokenness discussion in detail, so I'm not sure, but isn't it the case that ``we'' can easily fix the 450 bug without introducing the other problem? If so, could ``we'' do so sometime? I believe that if ``you'' were to assemble COMSAT from source and install it, exactly what you are talking about would happen. Ie, the problems seen before would not happen with the current default switch settings.  Date: Thu, 9 Nov 89 16:08:19 EST From: David Chapman Subject: 450 errors: can we fix just this bug? To: BUG-MAIL%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU Message-ID: <667149.891109.ZVONA@AI.AI.MIT.EDU> I didn't follow the new-mailer-brokenness discussion in detail, so I'm not sure, but isn't it the case that ``we'' can easily fix the 450 bug without introducing the other problem? If so, could ``we'' do so sometime? Would be a plus. Date: Thu, 9 Nov 89 16:04:20 EST From: Communications Satellite To: ZVONA%AI.AI.MIT.EDU at MINTAKA.LCS.MIT.EDU Re: Msg of Thursday, 9 November 1989 16:04-EST FAILED: BUG-SDL at REAGAN.AI.MIT.EDU; Recipient name apparently rejected. Last reply was: {450- The store-and-forward mailer on this machine has been shut down because of a program error. 450- The explanation given was: 450- Timed out after 5 minutes while trying to connect to LIFE. 450 The time of shutdown was 11/09/89 14:27:11.} Failed message follows: ------- Date: Thu, 9 Nov 89 16:04:17 EST From: David Chapman Subject: new ``What are plans for?'' with discussion of reactive planning To: BUG-SDL@REAGAN.AI.MIT.EDU Message-ID: <667145.891109.ZVONA@AI.AI.MIT.EDU> Phil and I recently finished a revised version of ``What are plans for?'' which has a new appendix comparing in more detail our work with other approaches, particularly reactive planning. It will appear as AIM 1050a, in a special issue of Robotics and Automation, and in Pattie Maes's book. Copies on request.  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU 31 Oct 89 19:00:11 EST From: Rob Austein Sender: sra@mintaka.lcs.mit.edu To: ZVONA@AI.ai.mit.edu, Moon@stony-brook.scrc.symbolics.com CC: BUG-MAIL@AI.ai.mit.edu In-reply-to: David Chapman's message of Tue, 31 Oct 89 16:05:58 EST <663023.891031.ZVONA@AI.AI.MIT.EDU> Subject: new COMSAT loses Date: Tue, 31 Oct 89 18:51:35 EST Message-ID: <8910311851.aa01436@mintaka.lcs.mit.edu> Date: Tue, 31 Oct 89 16:05:58 EST From: David Chapman We'd also have to update the INQUIR database. (This would be a serious pain but not necessarily fatal.) Right. Date: Tue, 31 Oct 89 16:09 EST From: "David A. Moon" There is this one other implication I just thought of. Guess what happens to names like "wheaties"? It's not a chaosnet name, and it's not fully specified, so mintaka will bounce it. Is this because Mintaka bounces all names that don't have dots in them, or it is because Wheaties is in the AI domain but Mintaka is in the LCS domain? (I honestly don't know which, not being familiar with MMDF.) The latter. It's BIND, not MMDF, although it might be possible to fix the problem by hacking MMDF. BIND doesn't have search paths the way CHIVES does. (To be fair, which I can do since this isn't Unix-Haters, the search path mechanism I used for CHIVES doesn't fit the BIND model well, it's a harder problem than I had to face.) I agree that nicknames are a user interface convenience but I don't understand why the NAMES file doesn't count as a user interface, given that there is no program for editing it with the user interface conveniences in place. In theory you are of course right. What I meant is that in practice I don't trust nicknames to work from one day to the next anymore. I trust them to either work or to fail in some obvious fashion, but I no longer use host nicknames in any mailing lists that I maintain. Supplying a user interface to the NAMES file seems like it's getting too far away from the bare metal. This is ITS, after all.... (Say "user interface convenience" to an English person and convey an entirely different idea than what you thought you were saying! :-) Well, what do you expect from people who think "transport" is a noun? I think it's reasonable to define nicknames for Comsat's use either in a special file or in the front of the NAMES file (if host nicknames are allowed to be defined in NAMES). I don't intend to try to implement that, but I wouldn't think it was a horribly bad idea if somebody else did it. Maybe the thing in DQ that ignores hosts that only have IP addresses can be changed just slightly so that if the full name of the host ends in .MIT.EDU then it is not ignored. I.e. assume that the HOSTS3 file correctly reflects the MIT.EDU domain, There's the rub. It has been a long time since we could trust it to relect anything but LCS, AI, and (sometimes) EECS and the Media lab. The information for main campus is hopelessly out of date. I have the technology to add in the MIT Telecommunications host tables for main campus, but even with all the good work Alan did to reclaim address space, adding all those entries to the current HOSTS3 table would probably blow out the ITS HOSTS3 compiler. even though we can't assume it correctly reflects domains we've never heard of. Or do this kludge by IP subnet address rather than by name suffix. Doing it by subnet would mean that the DQ: device would have to read the subnet table, which changes more often than you might think. We could do it, but it'd be painful. If we gave COMSAT its own private HOSTS3 file made from the current HSTMIT table plus the Telecom host table, it'd provide nickname recognition for pretty much everything that matters at MIT. There is of course this side issue that for several years now COMSAT has been out-of-spec because these days you're really not supposed to send TCP/SMTP mail without doing MX routing. Yes, there really are machines that talk TCP/SMTP but which want to redirect their mail some place else, so the existance of an IP address for a given hostname doesn't mean that that IP address is the right place to send mail addressed to that hostname. Installing the "new" version of COMSAT we've been talking about (no IP hostnames at all) would bring COMSAT back into spec. The price for that is the loss of IP nicknames, unless we seriously mung the domain relay machine. I have mixed feelings about all this business of preserving the nickname capability at the expense of violating the applicable mail specs.  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 31 Oct 89 16:11:18 EST Received: from AI.MIT.EDU by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 272218; 31 Oct 89 16:12:06 EST Received: from VALLECITO.SCRC.Symbolics.COM by life.ai.mit.edu (4.0/AI-4.10) id AA01009; Tue, 31 Oct 89 16:10:59 EST Received: from EUPHRATES.SCRC.Symbolics.COM by VALLECITO.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 316371; Tue 31-Oct-89 16:12:01 EST Date: Tue, 31 Oct 89 16:09 EST From: David A. Moon Subject: new COMSAT loses To: Rob Austein , JTW@lcs.mit.edu Cc: bawden@parc.xerox.com, BUG-MAIL@ai.ai.mit.edu In-Reply-To: <8910311534.aa19082@mintaka.lcs.mit.edu> Message-Id: <19891031210930.7.MOON@EUPHRATES.SCRC.Symbolics.COM> Line-Fold: No Date: Tue, 31 Oct 89 15:34:33 EST From: Rob Austein There is this one other implication I just thought of. Guess what happens to names like "wheaties"? It's not a chaosnet name, and it's not fully specified, so mintaka will bounce it. Is this because Mintaka bounces all names that don't have dots in them, or it is because Wheaties is in the AI domain but Mintaka is in the LCS domain? (I honestly don't know which, not being familiar with MMDF.) I can't think of a good way to fix this without making some truely horrid kludge to the DQ: device interface that would probably break again in six months. (Hey, six months is a long time, by then we'll probably all be forced to switch to some new networking protocol anyway! :-) My view on this is that the real name of the machine is "wheaties.ai.mit.edu" and has been for years now. Ie, nicknames are a user-interface convenience but should not be used in the NAMES file or @FILE lists. I realize that this may be a minority viewpoint. I agree that nicknames are a user interface convenience but I don't understand why the NAMES file doesn't count as a user interface, given that there is no program for editing it with the user interface conveniences in place. (Say "user interface convenience" to an English person and convey an entirely different idea than what you thought you were saying! :-) I suspect that if we were to work at it there would be some way to get Mintaka's MMDF to recognize nicknames in the AI zone, but I don't think it's trivial and I'm not sure it's a good idea. I suppose another option would be to make a private HOSTS3 file for COMSAT's use which had exactly the right set of host entries. I think it's reasonable to define nicknames for Comsat's use either in a special file or in the front of the NAMES file (if host nicknames are allowed to be defined in NAMES). Maybe the thing in DQ that ignores hosts that only have IP addresses can be changed just slightly so that if the full name of the host ends in .MIT.EDU then it is not ignored. I.e. assume that the HOSTS3 file correctly reflects the MIT.EDU domain, even though we can't assume it correctly reflects domains we've never heard of. Or do this kludge by IP subnet address rather than by name suffix. Or, I know, the easiest solution is to just put Wheaties on the Chaosnet. Or just put AI on the Internet, whichever is faster to install. The software exists for both, right, it just doesn't quite work completely.  Date: Tue, 31 Oct 89 16:05:58 EST From: David Chapman Subject: new COMSAT loses To: sra@MINTAKA.LCS.MIT.EDU cc: BUG-MAIL%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU, Moon@STONY-BROOK.SCRC.SYMBOLICS.COM, "bawden@PARC.XEROX.COM"@MINTAKA.LCS.MIT.EDU In-reply-to: Msg of Tue 31 Oct 89 15:34:33 EST from Rob Austein Message-ID: <663023.891031.ZVONA@AI.AI.MIT.EDU> My view on this is that the real name of the machine is "wheaties.ai.mit.edu" and has been for years now. Ie, nicknames are a user-interface convenience but should not be used in the NAMES file or @FILE lists. We'd also have to update the INQUIR database. (This would be a serious pain but not necessarily fatal.)  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU 31 Oct 89 15:48:45 EST From: Rob Austein Sender: sra@lcs.mit.edu To: bawden@parc.xerox.com CC: Moon@stony-brook.scrc.symbolics.com, BUG-MAIL@AI.ai.mit.edu In-reply-to: Alan Bawden's message of Tue, 31 Oct 89 11:04 PST <19891031190447.6.ALAN@MR-BUN.parc.xerox.com> Subject: new COMSAT loses Date: Tue, 31 Oct 89 15:34:33 EST Message-ID: <8910311534.aa19082@mintaka.lcs.mit.edu> There is this one other implication I just thought of. Guess what happens to names like "wheaties"? It's not a chaosnet name, and it's not fully specified, so mintaka will bounce it. I can't think of a good way to fix this without making some truely horrid kludge to the DQ: device interface that would probably break again in six months. My view on this is that the real name of the machine is "wheaties.ai.mit.edu" and has been for years now. Ie, nicknames are a user-interface convenience but should not be used in the NAMES file or @FILE lists. I realize that this may be a minority viewpoint. I suspect that if we were to work at it there would be some way to get Mintaka's MMDF to recognize nicknames in the AI zone, but I don't think it's trivial and I'm not sure it's a good idea. I suppose another option would be to make a private HOSTS3 file for COMSAT's use which had exactly the right set of host entries.  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU 31 Oct 89 14:17:27 EST Received: from arisia.Xerox.COM by mintaka.lcs.mit.edu id aa04604; 31 Oct 89 14:14 EST Received: from roo.parc.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA09329; Tue, 31 Oct 89 11:11:47 -0800 Received: from mr-bun.parc.Xerox.COM by roo.parc.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA08974; Tue, 31 Oct 89 11:13:15 PST Date: Tue, 31 Oct 89 11:10 PST From: Alan Bawden Subject: new COMSAT loses To: sra@lcs.mit.edu Cc: bug-mail%AI.AI.MIT.EDU@Mintaka.lcs.mit.edu In-Reply-To: <8910310317.aa01028@mintaka.lcs.mit.edu> Message-Id: <19891031191044.7.ALAN@MR-BUN.parc.xerox.com> Date: Tue, 31 Oct 89 3:17:20 EST From: Rob Austein So, (1) can be fixed by recompiling all the NAMES files immediately after installing the new COMSAT, (2) shouldn't be an issue if (1) is fixed, and (3) is something we've been living with already and is thus pretty much orthogonal to the rest of this stuff. Sounds good to me. So somebody please install it again and recompile the NAMES file. (Remember that -both- COMSAT's on MC have to compile the file. Probably the best thing is to just create a new NAMES file before launching the new binaries.)  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU 31 Oct 89 14:11:55 EST Received: from arisia.Xerox.COM by mintaka.lcs.mit.edu id aa04544; 31 Oct 89 14:09 EST Received: from roo.parc.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA09273; Tue, 31 Oct 89 11:05:50 -0800 Received: from mr-bun.parc.Xerox.COM by roo.parc.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA08931; Tue, 31 Oct 89 11:07:13 PST Date: Tue, 31 Oct 89 11:04 PST From: Alan Bawden Subject: new COMSAT loses To: sra@lcs.mit.edu Cc: Moon@stony-brook.scrc.symbolics.com, ZVONA%AI.AI.MIT.EDU@Mintaka.lcs.mit.edu, BUG-MAIL%AI.AI.MIT.EDU@Mintaka.lcs.mit.edu In-Reply-To: <8910302210.aa06094@mintaka.lcs.mit.edu> Message-Id: <19891031190447.6.ALAN@MR-BUN.parc.xerox.com> Date: Mon, 30 Oct 89 22:10:25 EST From: Rob Austein Date: Mon, 30 Oct 89 20:14 EST From: "David A. Moon" So how could this possibly have been working on ML all this time, if it has all those other incompatibilities? Or am I just mistaken in thinking it was working on ML? Um, I'm not quite sure what you mean. I'm not quite sure I understand why you aren't quite sure what he means. He means: The COMSAT binary installed on AI and MC yesterday, that we withdrew because of apparent problems, has been the installed binary on ML for months, where it seemed to work fine. The answer is probably: Well, yeah, but ML handles hardly any mail traffic at all, so it isn't really a very good test. Besides, if your analysis of the problem is correct, the first time the NAMES file got compiled on ML after the new COMSAT was installed, the problem went away. It only existed to be noticed for a very short time.  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU 31 Oct 89 03:18:12 EST From: Rob Austein Sender: sra@lcs.mit.edu To: bug-mail@ai.ai.mit.edu Subject: new COMSAT loses Date: Tue, 31 Oct 89 3:17:20 EST Message-ID: <8910310317.aa01028@mintaka.lcs.mit.edu> So, here's the scoop. 1) The [a.b.c.d] form addresses were indeed caused by the old LIST EQV file. I verified this running the new COMSAT in XPER mode. Compiling NAMES > with the new COMSAT makes the problem go away. Yes, NAMES > does compile with the new COMSAT, apparently correctly. 2) The quoting problem was to some extent a red herring. The really bizzare quoting in those error messages was in fact done by MMDF. Dunno why. I was able to produce an identical error message from MMDF running locally on Mintaka with a completely legal user@[a.b.c.d] form address. This isn't really news, we knew that MMDF didn't claim to support the [a.b.c.d] format. 3) The quoting mechanism in COMSAT (SCHECK:, SCHK4:, and STOPUT:) is a bad joke. It's not parsing strings, it's just checking all the characters in a given string for membership in the set of "special" characters. So it doesn't notice things like a string that the user has already carefully and correctly quoted, or a user@host pair masquerading as a "name" here in the brave new world of deferred hostname binding. This should be fixed some day. So, (1) can be fixed by recompiling all the NAMES files immediately after installing the new COMSAT, (2) shouldn't be an issue if (1) is fixed, and (3) is something we've been living with already and is thus pretty much orthogonal to the rest of this stuff.  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU 30 Oct 89 22:16:50 EST From: Rob Austein Sender: sra@lcs.mit.edu To: Moon@stony-brook.scrc.symbolics.com CC: ZVONA@AI.ai.mit.edu, ALAN@AI.ai.mit.edu, BUG-MAIL@AI.ai.mit.edu In-reply-to: "David A. Moon"'s message of Mon, 30 Oct 89 20:14 EST <19891031011435.9.MOON@EUPHRATES.SCRC.Symbolics.COM> Subject: new COMSAT loses CC: sra@lcs.mit.edu Date: Mon, 30 Oct 89 22:10:25 EST Message-ID: <8910302210.aa06094@mintaka.lcs.mit.edu> Date: Mon, 30 Oct 89 20:14 EST From: "David A. Moon" So how could this possibly have been working on ML all this time, if it has all those other incompatibilities? Or am I just mistaken in thinking it was working on ML? Um, I'm not quite sure what you mean. :MAIL should work with any COMSAT that's assembled with $$DQIN==1, because :MAIL will not accept any hostname that isn't in HOSTS3 and COMSAT will be able to deal with what :MAIL does for any IP address that's in HOSTS3 so long as $$DQIN is turned on. The new version that was installed yesterday and backed out of today has $$DQIN turned off, because some time ago we decided that COMSAT shouldn't attempt to bind Internet hostnames to IP addresses without a domain resolver. In the old configuration the quoting bug only hits you if the address you hand to COMSAT already has double quote characters in the address.  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU 30 Oct 89 20:18:33 EST Received: from STONY-BROOK.SCRC.SYMBOLICS.COM by mintaka.lcs.mit.edu id aa00134; 30 Oct 89 20:15 EST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 684318; 30 Oct 89 20:14:31 EST Date: Mon, 30 Oct 89 20:14 EST From: "David A. Moon" Subject: new COMSAT loses To: Rob Austein cc: ZVONA@AI.ai.mit.edu, ALAN@AI.ai.mit.edu, BUG-MAIL@AI.ai.mit.edu In-Reply-To: <8910301949.aa29868@mintaka.lcs.mit.edu> Message-ID: <19891031011435.9.MOON@EUPHRATES.SCRC.Symbolics.COM> So how could this possibly have been working on ML all this time, if it has all those other incompatibilities? Or am I just mistaken in thinking it was working on ML?  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU 30 Oct 89 19:54:59 EST From: Rob Austein Sender: sra@lcs.mit.edu To: ZVONA@AI.ai.mit.edu CC: ALAN@AI.ai.mit.edu, BUG-MAIL@AI.ai.mit.edu In-reply-to: David Chapman's message of Mon, 30 Oct 89 17:31:14 EST <662494.891030.ZVONA@AI.AI.MIT.EDU> Subject: new COMSAT loses CC: sra@lcs.mit.edu Date: Mon, 30 Oct 89 19:49:36 EST Message-ID: <8910301949.aa29868@mintaka.lcs.mit.edu> Date: Mon, 30 Oct 89 17:31:14 EST From: David Chapman Well, I guess this new 450-fixed COMSAT is losing after all. FAILED: KWH-PERSONAL at [128.52.35.13]; Recipient name apparently rejected. Last reply was: {550 (BHST) Unknown host/domain name in "KWH-PERSONAL@"[128.52.35.13]""} FAILED: RDZ at [128.52.35.13]; Recipient name apparently rejected. Last reply was: {550 (BHST) Unknown host/domain name in "RDZ@"[128.52.35.13]""} FAILED: weise@sierra at MINTAKA.LCS.MIT.EDU; Recipient name apparently rejected. Last reply was: {550 (BHST) Unknown host/domain name in "weise@sierra"} Well, here's a theory. There are two things wrong: 1) The quoting mechanism is screwed up. We knew that. I think it's a BUG-@ relic that we didn't stamp out. It needs to be fixed in any case, it's screwing up the older version of COMSAT too. 2) We all forgot that this version of COMSAT includes the changes to make COMSAT ignore IP entries in the HOSTS3 table. Which means that IP host numbers can't be translated back to host names either. Which means that we should have recompiled the NAMES files when we installed the new version. I'm looking into this, but so far it's the only theory I've found that holds water. I thought Moon had found a counter example, but he generated it with :MAIL, which we knew (but forgot) would break when we made this change. The way the code is written, this IP-host stuff should be orthogonal to the 450 stuff. In fact, the default switch settings are for the old way of doing things. So it should be possible to install the 450 stuff without worrying about this, if that's what people want to do. The "weise@sierra" above is a red herring; we don't support non-domain names outside of Tech Square anymore, although we don't make any special effort to cause them to break. Anybody have another theory or some other evidence they want to toss into the fire?  Date: Mon, 30 Oct 89 18:13:59 EST From: "Pandora B. Berman" Subject: respite To: BUG-MAIL%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU Message-ID: <662523.891030.CENT@AI.AI.MIT.EDU> i have restored the older order. COMSAT BIN => COMSAT NBIN COMSAT OBIN => COMSAT BIN COMSAT LAUNCH => COMSAT OLAUNC (which is inconsistent, yes i know) and new COMSAT BIN purified and launched on AI and both MC. let's get the NBIN fixed before we try this again.  Date: Mon, 30 Oct 89 17:38:03 EST From: David Chapman Subject: more To: BUG-MAIL%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU, ALAN%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU Message-ID: <662497.891030.ZVONA@AI.AI.MIT.EDU> Date: Mon, 30 Oct 89 17:32:32 EST From: lcs Mail System (MMDF) Sender: mmdf at lcs.mit.edu To: ZVONA at ai.ai.mit.edu Re: Failed mail (msg.aa10478) Your message could not be delivered to 'KLH-ITS@"[10.0.0.51]" (host: chaos&ai.ai.mit.edu) (queue: delay)' for the following reason: '(BHST) Unknown host/domain name in "KLH-ITS@"[10.0.0.51]""' Your message follows: Received: from ai.ai.mit.edu by mintaka.lcs.mit.edu id aa10478; 30 Oct 89 17:32 EST Date: Mon, 30 Oct 89 17:31:14 EST From: David Chapman Subject: new COMSAT loses To: ALAN%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU, BUG-MAIL%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU Message-ID: <662494.891030.ZVONA@AI.AI.MIT.EDU> Well, I guess this new 450-fixed COMSAT is losing after all. Date: Mon, 30 Oct 89 17:09:42 EST From: Communications Satellite To: ZVONA%AI.AI.MIT.EDU at MINTAKA.LCS.MIT.EDU Re: Msg of Monday, 30 October 1989 17:05-EST FAILED: KWH-PERSONAL at [128.52.35.13]; Recipient name apparently rejected. Last reply was: {550 (BHST) Unknown host/domain name in "KWH-PERSONAL@"[128.52.35.13]""} FAILED: RDZ at [128.52.35.13]; Recipient name apparently rejected. Last reply was: {550 (BHST) Unknown host/domain name in "RDZ@"[128.52.35.13]""} FAILED: weise@sierra at MINTAKA.LCS.MIT.EDU; Recipient name apparently rejected. Last reply was: {550 (BHST) Unknown host/domain name in "weise@sierra"} Failed message follows: ------- Date: Mon, 30 Oct 89 17:05:50 EST From: David Chapman Subject: Multics postmortem - how much blame should it bear for Unix? To: UNIX-HATERS%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU In-reply-to: Msg of Mon 30 Oct 89 15:56:42 EST from Steve Strassmann Message-ID: <662481.891030.ZVONA@AI.AI.MIT.EDU> Multics features include ..., automatic hackup, ...a paged/sexmented virtual memory, These seem like useful features. I guess it's not surprising that they didn't make it into unix.  Date: Mon, 30 Oct 89 17:31:14 EST From: David Chapman Subject: new COMSAT loses To: ALAN%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU, BUG-MAIL%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU Message-ID: <662494.891030.ZVONA@AI.AI.MIT.EDU> Well, I guess this new 450-fixed COMSAT is losing after all. Date: Mon, 30 Oct 89 17:09:42 EST From: Communications Satellite To: ZVONA%AI.AI.MIT.EDU at MINTAKA.LCS.MIT.EDU Re: Msg of Monday, 30 October 1989 17:05-EST FAILED: KWH-PERSONAL at [128.52.35.13]; Recipient name apparently rejected. Last reply was: {550 (BHST) Unknown host/domain name in "KWH-PERSONAL@"[128.52.35.13]""} FAILED: RDZ at [128.52.35.13]; Recipient name apparently rejected. Last reply was: {550 (BHST) Unknown host/domain name in "RDZ@"[128.52.35.13]""} FAILED: weise@sierra at MINTAKA.LCS.MIT.EDU; Recipient name apparently rejected. Last reply was: {550 (BHST) Unknown host/domain name in "weise@sierra"} Failed message follows: ------- Date: Mon, 30 Oct 89 17:05:50 EST From: David Chapman Subject: Multics postmortem - how much blame should it bear for Unix? To: UNIX-HATERS%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU In-reply-to: Msg of Mon 30 Oct 89 15:56:42 EST from Steve Strassmann Message-ID: <662481.891030.ZVONA@AI.AI.MIT.EDU> Multics features include ..., automatic hackup, ...a paged/sexmented virtual memory, These seem like useful features. I guess it's not surprising that they didn't make it into unix.  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU 26 Oct 89 17:59:01 EDT From: John Wroclawski Sender: jtw@lcs.mit.edu To: bawden@parc.xerox.com CC: sra@lcs.mit.edu, BUG-MAIL%AI.AI.MIT.EDU@Mintaka.lcs.mit.edu, cent%AI.AI.MIT.EDU@Mintaka.lcs.mit.edu In-reply-to: Alan Bawden's message of Thu, 26 Oct 89 10:43 PDT <19891026174312.7.ALAN@MR-BUN.parc.xerox.com> Subject: mail to eddie still losing Date: Thu, 26 Oct 89 17:48:30 EDT Message-ID: <8910261748.aa27435@mintaka.lcs.mit.edu> Date: Thu, 26 Oct 89 10:43 PDT From: Alan Bawden And I'll bet that nobody except Penny has even -looked- at poor ML. I suppose Penny could just call DEC to come and fix it, but we'd look pretty silly if the problem turned out to be something totally trivial. (I realize that everybody there with RP06 experience is so busy that they can't spare 5 minute to go upstairs to the 9th floor, so I've arranged to fly back to Cambridge on November 16 to do it myself. Of course if somebody else gets around to it first, that would be a win.) Flame, flame. I've looked at it (because Penny wandered down and yanked, I'll admit). It's broken. Anybody know what the state of "MD's" RP06 is? I am assuming that the usual head actuator power supply implosion has occured on ML's disk; we will be needing some parts if we don't want to give DEC lots of $$. And some light bulbs. And some filters. The ones there now look like a medical scene from "Coal Miner's Daughter". Bad news.  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU 26 Oct 89 16:54:38 EDT Received: from arisia.Xerox.COM by mintaka.lcs.mit.edu id aa04433; 26 Oct 89 16:33 EDT Received: from roo.parc.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA18701; Thu, 26 Oct 89 10:44:03 -0700 Received: from mr-bun.parc.Xerox.COM by roo.parc.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA24573; Thu, 26 Oct 89 10:45:23 PDT Date: Thu, 26 Oct 89 10:43 PDT From: Alan Bawden Subject: mail to eddie still losing To: sra@lcs.mit.edu Cc: BUG-MAIL%AI.AI.MIT.EDU@Mintaka.lcs.mit.edu, cent%AI.AI.MIT.EDU@Mintaka.lcs.mit.edu In-Reply-To: <8910260233.aa18374@mintaka.lcs.mit.edu> Message-Id: <19891026174312.7.ALAN@MR-BUN.parc.xerox.com> Date: Thu, 26 Oct 89 2:33:02 EDT From: Rob Austein Date: Thu, 26 Oct 89 01:13:39 EDT From: David Chapman I thought this was supposed to be fixed. Well, it is, kinda. The text version of the host table is correct. Unfortunately, ML has been down for a while, and ML is the machine that was doing the automatic compilations. And I'll bet that nobody except Penny has even -looked- at poor ML. I suppose Penny could just call DEC to come and fix it, but we'd look pretty silly if the problem turned out to be something totally trivial. (I realize that everybody there with RP06 experience is so busy that they can't spare 5 minute to go upstairs to the 9th floor, so I've arranged to fly back to Cambridge on November 16 to do it myself. Of course if somebody else gets around to it first, that would be a win.) I think this could be fixed by making a link from DRAGON;HOURLY H3MAKE to SYSHST;H3MAKE BIN on AI or MC, but I'm not totally sure how how it would interact with the H3GET program that's already installed, and I can't spare the 20 minutes to figure it out right now. H3GET is cleverly designed to be insensitive to which machine the new host table shows up on. I just checks around to see if anyone has a newer table than the machine it's running on, and if it finds one, it sucks it over. So making that link should do exactly the right thing. I would install it on MC rather than AI. I can't get to saffron right now, otherwise I'd do this myself.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 26 Oct 89 14:34:55 EDT Date: Thu, 26 Oct 89 14:30:32 EDT From: Rob Austein Subject: MC: DRAGON; HOURLY H3MAKE To: BUG-MAIL%MC.LCS.MIT.EDU@MINTAKA.LCS.MIT.EDU Message-ID: <622798.891026.SRA@MC.LCS.MIT.EDU> It looks like H3MAKE and H3GET won't bother each other, so I created the link MC: DRAGON; HOURLY H3MAKE. If everything works this should cause the binary host tables on the ITS machines to know about EDDIE within a few hours.  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU 26 Oct 89 02:55:39 EDT From: Rob Austein Sender: sra@lcs.mit.edu To: ZVONA@AI.ai.mit.edu, bawden@parc.xerox.com CC: BUG-MAIL@AI.ai.mit.edu In-reply-to: David Chapman's message of Thu, 26 Oct 89 01:13:39 EDT <660541.891026.ZVONA@AI.AI.MIT.EDU> Subject: mail to eddie still losing Date: Thu, 26 Oct 89 2:33:02 EDT Message-ID: <8910260233.aa18374@mintaka.lcs.mit.edu> Date: Thu, 26 Oct 89 01:13:39 EDT From: David Chapman I thought this was supposed to be fixed. Well, it is, kinda. The text version of the host table is correct. Unfortunately, ML has been down for a while, and ML is the machine that was doing the automatic compilations. I think this could be fixed by making a link from DRAGON;HOURLY H3MAKE to SYSHST;H3MAKE BIN on AI or MC, but I'm not totally sure how how it would interact with the H3GET program that's already installed, and I can't spare the 20 minutes to figure it out right now. If Alan knows the answer to this offhand and says this should work, somebody should install the link. Otherwise it'll have to wait until after the DARPA people go home and life returns to what passes for normal around here. --Rob  Date: Thu, 26 Oct 89 01:13:39 EDT From: David Chapman Subject: mail to eddie still losing To: BUG-MAIL%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU Message-ID: <660541.891026.ZVONA@AI.AI.MIT.EDU> I thought this was supposed to be fixed. Date: Thu, 26 Oct 89 00:04:34 EDT From: Communications Satellite To: ZVONA%MC.LCS.MIT.EDU at MINTAKA.LCS.MIT.EDU Re: Msg of Wednesday, 25 October 1989 23:43-EDT FAILED: strata at EDDIE.MIT.EDU; Host appears to be permanently down or not accepting mail. Failed message follows: ------- Date: Wed, 25 Oct 89 23:43:23 EDT From: David Chapman Subject: [ZVONA%AI.AI.MIT.EDU: forwarded] To: strata@EDDIE.MIT.EDU Message-ID: <622629.891025.ZVONA@MC.LCS.MIT.EDU> Well, supposedly now this has REALLY been fixed. Let me know if you get this -- -- D Date: Sat, 21 Oct 89 13:43:44 EDT From: David Chapman To: strata at EDDIE.MIT.EDU cc: paganism-request at MC.LCS.MIT.EDU Hi, I'm having trouble with Eddie bouncing mail. Supposedly the problem has been fixed, but I'm not sure. If you get this, could you forward it back to me? Thanks. D/Z  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU 24 Oct 89 11:42:35 EDT From: Rob Austein Sender: sra@lcs.mit.edu To: RS@AI.ai.mit.edu CC: BUG-MAIL@AI.ai.mit.edu In-reply-to: "Robert E. Seastrom"'s message of Mon, 23 Oct 89 19:55:17 EDT <659274.891023.RS@AI.AI.MIT.EDU> Subject: [COMSAT%AI.AI.MIT.EDU: Msg of Friday, 20 October 1989 10:07-EDT] Date: Tue, 24 Oct 89 11:35:26 EDT Message-ID: <8910241135.aa21726@mintaka.lcs.mit.edu> Date: Mon, 23 Oct 89 19:55:17 EDT From: "Robert E. Seastrom" Could someone please fix things so that AI won't try to deliver mail to Eddie via chaosnet, since it's not on chaos anymore? This was "fixed" about a week ago, by removing EDDIE's chaosnet address from the host tables so that COMSAT would stop using it. Unfortunately, the same day as the change was made, some pinhead added the nickname "ABUL'AFIA" to LEM.AI.MIT.EDU's namespace entry, which broke the host tables. Once upon a time, when the host tables were broken, the compiler job mailed error messages to people who could fix it. But here in the future when the host table compiler runs on the operating system of tomorow, some of the code that somebody (who knows who he is) added to the host compiler job ALWAYS FAILS and the compiler job has no way of knowing which parts are allowed to fail, so it doesn't send notifications. Some day this may annoy me enough to hit the offending code with an axe, but for today I just removed ABUL'AFIA and flamed at the twit who put it in the tables. Assuming there's nothing else wrong, the changes should take effect tonight. Note that COMSAT is too lame to rescue mail that's already been queued for EDDIE's chaosnet address; new mail will go via TCP but the old mail will bounce. --Rob ["The twelfth reincarnation's a bitch and then you die."]  Date: Mon, 23 Oct 89 19:55:17 EDT From: "Robert E. Seastrom" Subject: [COMSAT%AI.AI.MIT.EDU: Msg of Friday, 20 October 1989 10:07-EDT] To: BUG-MAIL%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU Message-ID: <659274.891023.RS@AI.AI.MIT.EDU> Could someone please fix things so that AI won't try to deliver mail to Eddie via chaosnet, since it's not on chaos anymore? ---Rob Date: Mon, 23 Oct 89 04:28:50 EDT From: Communications Satellite To: RS%AI.AI.MIT.EDU at MINTAKA.LCS.MIT.EDU Re: Msg of Friday, 20 October 1989 10:07-EDT FAILED: strata at EDDIE.MIT.EDU; Host appears to be permanently down or not accepting mail. Failed message follows: ------- Date: Fri, 20 Oct 89 10:07:11 EDT From: "Robert E. Seastrom" Subject: 750 MW CO2 LASER!!! To: strata@EDDIE.MIT.EDU cc: elbows@BLOOM-BEACON.MIT.EDU, corwin@GHOTI.LCS.MIT.EDU In-reply-to: Msg of Thu 19 Oct 1989 11:53:41 EDT from M. Strata Rose Message-ID: <657819.891020.RS@AI.AI.MIT.EDU> Was that supposed to be a little m or a BIG M? ---Rob  Date: Tue, 17 Oct 89 03:15:44 EDT From: "Pandora B. Berman" Subject: huh? To: BUG-MAIL%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU cc: HEADER-PEOPLE-REQUEST%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU Message-ID: <656344.891017.CENT@AI.AI.MIT.EDU> i have seen a couple of these, so i assume some address on header-people has gone bad. unfortunately, i can't figure out which one. the list does not include any explicit address @tolsoft, apple, or pyramid. it does include the addresses tron%uts.amdahl.com@xx garnold@sun.com any suggestions? ---------- Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 15 Oct 89 19:07:24 EDT Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 15 Oct 89 19:04:47 EDT Received: from Sun.COM by mintaka.lcs.mit.edu id aa21143; 15 Oct 89 18:58 EDT Received: from sun.Sun.COM (sun-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA01565; Sun, 15 Oct 89 15:58:15 PDT Received: from amdahl.UUCP by sun.Sun.COM (4.1/SMI-4.1) id AA18317; Sun, 15 Oct 89 15:58:01 PDT Received: by amdahl.uts.amdahl.com (/\../\ Smail3.1.14.4 #14.2) id ; Sun, 15 Oct 89 14:15 PDT Received: by pyramid.pyramid.com (5.61/OSx5.0-890710) id AA19460; Sun, 15 Oct 89 08:05:15 -0700 Received: by apple.com (5.59/25-eef) id AA18292; Sun, 15 Oct 89 07:48:21 PDT for amdahl!sun!mc.lcs.mit.edu!header-people-request Received: by tolsoft.uucp (/\=-/\ Smail3.1.17.5 #17.5) id ; Sun, 15 Oct 89 07:34 PDT Message-Id: Date: Sun, 15 Oct 89 07:34 PDT From: uucp To: pyramid!amdahl!sun!mc.lcs.mit.edu!header-people-request@sun.com Subject: Warning From uucp We have been unable to contact machine 'mitsu' since you queued your job. mitsu!rsmtp (Date 10/11) The job will be deleted in several days if the problem is not corrected. If you care to kill the job, execute the following command: uustat -kmitsuC7a9a Sincerely, tolsoft!uucp #############################################  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU 5 Oct 89 14:30:38 EDT From: Rob Austein Sender: sra@lcs.mit.edu To: Moon@stony-brook.scrc.symbolics.com CC: gumby@gang-of-four.stanford.edu, jtw@lcs.mit.edu, bawden@parc.xerox.com, CENT@ai.ai.mit.edu, BUG-MAIL@ai.ai.mit.edu In-reply-to: "David A. Moon"'s message of Thu, 5 Oct 89 13:16 EDT <19891005171651.6.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM> Subject: ITS host mirage Date: Thu, 5 Oct 89 14:21:36 EDT Message-ID: <8910051421.aa13283@mintaka.lcs.mit.edu> Date: Thu, 5 Oct 89 13:16 EDT From: "David A. Moon" It's a pity that Berkeley didn't have the foresight to put a security hole in the old code, the way they usually do, so that at the appropriate time people's interest in upgrading could be forcefully piqued. Try sending an answer packet with an SOA RR in the Authority section to a version of bind old enough that it doesn't understand negative response caching....  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU 5 Oct 89 14:10:04 EDT Received: from STONY-BROOK.SCRC.SYMBOLICS.COM by mintaka.lcs.mit.edu id aa13003; 5 Oct 89 14:01 EDT Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 669609; 5 Oct 89 13:15:33 EDT Date: Thu, 5 Oct 89 13:16 EDT From: "David A. Moon" Subject: ITS host mirage To: Rob Austein cc: gumby@gang-of-four.stanford.edu, jtw@lcs.mit.edu, bawden@parc.xerox.com, CENT@ai.ai.mit.edu, BUG-MAIL@ai.ai.mit.edu In-Reply-To: <8910051250.aa11916@mintaka.lcs.mit.edu> Message-ID: <19891005171651.6.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM> Line-fold: No Date: Thu, 5 Oct 89 12:50:26 EDT From: Rob Austein God knows Berekeley has tried to convince all these people that they're being anti-social by running the old broken code, but a lot of people simply don't care enough to upgrade. It's a pity that Berkeley didn't have the foresight to put a security hole in the old code, the way they usually do, so that at the appropriate time people's interest in upgrading could be forcefully piqued.  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU 5 Oct 89 12:55:43 EDT From: Rob Austein Sender: sra@lcs.mit.edu To: gumby@gang-of-four.stanford.edu CC: jtw@lcs.mit.edu, bawden@parc.xerox.com, CENT@ai.ai.mit.edu, BUG-MAIL@ai.ai.mit.edu In-reply-to: David Vinayak Wallace's message of Thu, 5 Oct 89 06:45:41 -0700 <8910051345.AA03113@Gang-of-Four.Stanford.EDU> Subject: ITS host mirage Date: Thu, 5 Oct 89 12:50:26 EDT Message-ID: <8910051250.aa11916@mintaka.lcs.mit.edu> Date: Thu, 5 Oct 89 06:45:41 -0700 From: David Vinayak Wallace I don't get it. It shouldn't give an authoritative denial of the host's existance if its local db times out! Obviously, but it does ("I'm an authoritative server and I don't have the information, so the information must not exist, Q.E.D."). It's a known bug in old versions of bind that Berkeley fixed years ago, but installations running the old broken version still pop up with some regularity, because of the usual lag time between getting a bug fixed and getting all the little sites and third party vendors to install the fixed version. God knows Berekeley has tried to convince all these people that they're being anti-social by running the old broken code, but a lot of people simply don't care enough to upgrade.  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU 5 Oct 89 09:52:27 EDT Received: from Gang-of-Four.Stanford.EDU by mintaka.lcs.mit.edu id aa09401; 5 Oct 89 9:47 EDT Received: by Gang-of-Four.Stanford.EDU (5.61/25-eef) id AA03113; Thu, 5 Oct 89 06:45:41 -0700 Date: Thu, 5 Oct 89 06:45:41 -0700 From: David Vinayak Wallace Message-Id: <8910051345.AA03113@Gang-of-Four.Stanford.EDU> To: sra@lcs.mit.edu Cc: jtw@lcs.mit.edu, bawden@parc.xerox.com, CENT@ai.ai.mit.edu, BUG-MAIL@ai.ai.mit.edu In-Reply-To: Rob Austein's message of Thu, 5 Oct 89 0:00:39 EDT <8910050000.aa03939@mintaka.lcs.mit.edu> Subject: ITS host mirage Date: Thu, 5 Oct 89 0:00:39 EDT From: Rob Austein Network partitions interact weirdly with some of the known bind bugs. In particular, whole DNS zones can mysteriously appear and disappear depending on whether or not a buggy backup server can reach its primary server when its local copy times out or it reboots. I don't get it. It shouldn't give an authoritative denial of the host's existance if its local db times out! Or am I being naive, and this is yet another case of the world working in some totally BD fashion "because that's the way unix does it"? G "The cost of getting a packet to Oasis.org keeps increasing until it exceeds the maximum TTL..."  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU 5 Oct 89 00:10:09 EDT From: Rob Austein Sender: sra@lcs.mit.edu To: jtw@lcs.mit.edu CC: bawden@parc.xerox.com, CENT@ai.ai.mit.edu, BUG-MAIL@ai.ai.mit.edu In-reply-to: John Wroclawski's message of Wed, 4 Oct 89 23:22:14 EDT <8910042322.aa03358@mintaka.lcs.mit.edu> Subject: ITS host knowledge Date: Thu, 5 Oct 89 0:00:39 EDT Message-ID: <8910050000.aa03939@mintaka.lcs.mit.edu> From: John Wroclawski Date: Wed, 4 Oct 89 23:22:14 EDT Yep. It's really convinced, too. It's also convinced that SRI.COM is a nonexistant domain, which is not a good sign. It's not too sure about parc.xerox.com, so some of us might not get this. Doing "ping nic.ddn.mil" shows the story. The net (specificly, NEARNet) is broken again. Looks like somebody blew the internal gateway configuration again and set up a nice tight routing loop. Xerox is still reachable, I guess we have some other path there. Network partitions interact weirdly with some of the known bind bugs. In particular, whole DNS zones can mysteriously appear and disappear depending on whether or not a buggy backup server can reach its primary server when its local copy times out or it reboots. I don't know that that's what's going on here, but I would not be surprised if it were so.  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU 4 Oct 89 23:37:34 EDT From: Rob Austein Sender: sra@lcs.mit.edu To: CENT@ai.ai.mit.edu, bawden@parc.xerox.com CC: BUG-MAIL@ai.ai.mit.edu In-reply-to: Alan Bawden's message of Wed, 4 Oct 89 19:21 PDT <19891005022117.0.ALAN@MR-BUN.parc.xerox.com> Subject: ITS host knowledge BCC: sra@lcs.mit.edu Date: Wed, 4 Oct 89 23:29:36 EDT Message-ID: <8910042329.aa03478@mintaka.lcs.mit.edu> Date: Wed, 4 Oct 89 19:21 PDT From: Alan Bawden Date: Wed, 4 Oct 89 20:38:55 EDT From: "Pandora B. Berman" ... rob, didn't you think at some point that this had been fixed?... Date: Sun, 1 Oct 89 00:42:27 EDT From: Communications Satellite FAILED: CANTONIS at GTEWD.AF.MIL; Recipient name apparently rejected. Last reply was: {550 (BHST) Unknown host/domain name in "CANTONIS@GTEWD.AF.MIL"} Wait a second. It says "last -reply- was". Given the way we do things these days, doesn't that mean that Mintaka is the source of that error reply? That would mean that Mintaka is claiming that GTEWD.AF.MIL is unknown. (As opposed to the silly case where GTEWD.AF.MIL claims that it has never heard of itself!) [ Perhaps I am confused, and this message was addressed to Rob in his role as Mintaka Mail Wizard instead of as ITS Mail Wizard? ] I dunno, maybe it was addressed to me as ``Blue Wizard.'' Yes, this rejection is from Mintaka; COMSAT got it while talking to Mintaka via CHAOS/SMTP. MMDF's SMTP listener does attempt to do a quick check of incoming names, although, like any reasonable mail listener (and unlike the unix mailer from hell (TUMFH)) it does not put the sender on hold forever if it can't get a definite answer quickly. Furthermore, as far as I can tell, it's legitimate. I asked NS.NASA.GOV (one of the root servers) and here's what it said: sra@mintaka> dig @ns.nasa.gov any gtewd.af.mil ; <<>> DiG <<>> @ns.nasa.gov any gtewd.af.mil ;; ->>HEADER<<- opcode: QUERY , status: NXDOMAIN, id: 11 ;; flags: qr aa rd ra Ques: 1, Ans: 0, Auth: 1, Addit: 0 ;; QUESTIONS: ;; gtewd.af.mil, type = ANY, class = IN ;; AUTHORITY RECORDS: MIL IN SOA NIC.DDN.MIL HOSTMASTER.NIC.DDN.MIL ( 891002 ;serial 1800 ;refresh 300 ;retry 604800 ;expire 86400 ;minim ) ; 86400 ;; Sent 2 pkts, answer found in time: 0.464 sec ;; FROM: mintaka to SERVER: ns.nasa.gov ;; WHEN: Wed Oct 4 23:13:25 1989 Translated, this means ``there is no such name as `GTEWD.AF.MIL' and I'm an authoritative server for the MIL zone, so should know.'' So I guess this confused Penny because we're all so used to the world being slow and broken that when two mailers, neither of which is TUMFH, actually manage to figure out that a name has gone bogus, in almost-real-time, we no longer recognize the error message!  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU 4 Oct 89 23:28:41 EDT From: John Wroclawski Sender: jtw@lcs.mit.edu To: bawden@parc.xerox.com CC: CENT%AI.AI.MIT.EDU@mintaka.lcs.mit.edu, BUG-MAIL%AI.AI.MIT.EDU@mintaka.lcs.mit.edu In-reply-to: Alan Bawden's message of Wed, 4 Oct 89 19:21 PDT <19891005022117.0.ALAN@MR-BUN.parc.xerox.com> Subject: ITS host knowledge Date: Wed, 4 Oct 89 23:22:14 EDT Message-ID: <8910042322.aa03358@mintaka.lcs.mit.edu> these days, doesn't that mean that Mintaka is the source of that error reply? That would mean that Mintaka is claiming that GTEWD.AF.MIL is unknown. (As opposed to the silly case where GTEWD.AF.MIL claims that it has never heard of itself!) Yep. It's really convinced, too. It's also convinced that SRI.COM is a nonexistant domain, which is not a good sign. It's not too sure about parc.xerox.com, so some of us might not get this.  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU 4 Oct 89 22:38:56 EDT Received: from arisia.Xerox.COM by mintaka.lcs.mit.edu id aa02792; 4 Oct 89 22:24 EDT Received: from roo.parc.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA12630; Wed, 4 Oct 89 19:23:13 -0700 Received: from mr-bun.parc.Xerox.COM by roo.parc.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA01785; Wed, 4 Oct 89 19:23:33 PDT Date: Wed, 4 Oct 89 19:21 PDT From: Alan Bawden Subject: ITS host knowledge To: CENT%AI.AI.MIT.EDU@mintaka.lcs.mit.edu Cc: BUG-MAIL%AI.AI.MIT.EDU@mintaka.lcs.mit.edu In-Reply-To: <651769.891004.CENT@AI.AI.MIT.EDU> Message-Id: <19891005022117.0.ALAN@MR-BUN.parc.xerox.com> Date: Wed, 4 Oct 89 20:38:55 EDT From: "Pandora B. Berman" ... rob, didn't you think at some point that this had been fixed?... Date: Sun, 1 Oct 89 00:42:27 EDT From: Communications Satellite FAILED: CANTONIS at GTEWD.AF.MIL; Recipient name apparently rejected. Last reply was: {550 (BHST) Unknown host/domain name in "CANTONIS@GTEWD.AF.MIL"} Wait a second. It says "last -reply- was". Given the way we do things these days, doesn't that mean that Mintaka is the source of that error reply? That would mean that Mintaka is claiming that GTEWD.AF.MIL is unknown. (As opposed to the silly case where GTEWD.AF.MIL claims that it has never heard of itself!) [ Perhaps I am confused, and this message was addressed to Rob in his role as Mintaka Mail Wizard instead of as ITS Mail Wizard? ]  Date: Wed, 4 Oct 89 20:38:55 EDT From: "Pandora B. Berman" Subject: ITS host knowledge To: BUG-MAIL%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU Message-ID: <651769.891004.CENT@AI.AI.MIT.EDU> GTEWD apparently used to be in the host table, but has recently dropped out, and causes this error. rob, didn't you think at some point that this had been fixed? Date: Sun, 1 Oct 89 00:42:27 EDT From: Communications Satellite Subject: Msg of Sunday, 1 October 1989 00:26-EDT To: SCA-REQUEST%MC.LCS.MIT.EDU@MINTAKA.LCS.MIT.EDU Message-ID: <4488.891001@MC.LCS.MIT.EDU> FAILED: CANTONIS at GTEWD.AF.MIL; Recipient name apparently rejected. Last reply was: {550 (BHST) Unknown host/domain name in "CANTONIS@GTEWD.AF.MIL"} Failed message follows: ------- Date: 1 OCT 89 00:07:02 EDT From: Automatic SCA Digestifier Subject: SCA Digest #472 To: SCA%mc.lcs.mit.edu@mintaka.lcs.mit.edu Reply-to: SCA%mc.lcs.mit.edu@mintaka.lcs.mit.edu [digest contents removed]  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU 2 Sep 89 01:10:48 EDT From: Rob Austein Sender: sra@lcs.mit.edu To: CENT@AI.ai.mit.edu CC: BUG-MAIL@AI.ai.mit.edu In-reply-to: "Pandora B. Berman"'s message of Fri, 1 Sep 89 20:09:20 EDT <640149.890901.CENT@AI.AI.MIT.EDU> Subject: PFCVAX.PFC Date: Sat, 2 Sep 89 1:02:53 EDT Message-ID: <8909020103.aa16054@mintaka.lcs.mit.edu> Date: Fri, 1 Sep 89 20:09:20 EDT From: "Pandora B. Berman" Date: Thu, 31 Aug 89 02:15 EDT From: MRL@pfcvax.pfc.mit.edu If you have a reference to PFC-VAX.MIT.EDU (or as you said, PFC.MIT.EDU), please remove it, and add PFCVAX.PFC.MIT.EDU, which is Internet address 18.77.0.102. Thanks very much! these folks want me to diddle their address in the bboard distribution. problem is, PFCVAX.PFC.MIT.EDU isn't in the host table. i looked at HSTG >, and it appears that adding it might not be completely simple, since it's subordinate to the PFC.MIT.EDU subdomain. suggestions? or should i just explicitly run their stuff through mintaka? It would probably work to just add it as "PFCVAX.PFC" in HSTG >. It wouldn't have a year ago, but the internals of the host table generation process changed a lot when it went unix. None of the hand-maintained HSTxxx files undergo expansion to multiple names anymore (only HSTLCS does that nowadays), so "PFCVAX.PFC" in HSTG should correspond exactly to "PFCVAX.PFC.MIT.EDU" in the final output.  Date: Fri, 1 Sep 89 20:09:20 EDT From: "Pandora B. Berman" Subject: PFCVAX.PFC To: BUG-MAIL%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU Message-ID: <640149.890901.CENT@AI.AI.MIT.EDU> Date: Thu, 31 Aug 89 02:15 EDT From: MRL@pfcvax.pfc.mit.edu Subject: RE: BBOARD MAILING LIST To: CENT%AI.AI.MIT.EDU@MINTAKA.lcs.mit.edu If you have a reference to PFC-VAX.MIT.EDU (or as you said, PFC.MIT.EDU), please remove it, and add PFCVAX.PFC.MIT.EDU, which is Internet address 18.77.0.102. Thanks very much! these folks want me to diddle their address in the bboard distribution. problem is, PFCVAX.PFC.MIT.EDU isn't in the host table. i looked at HSTG >, and it appears that adding it might not be completely simple, since it's subordinate to the PFC.MIT.EDU subdomain. suggestions? or should i just explicitly run their stuff through mintaka?  Date: Mon, 21 Aug 89 10:54:20 EDT From: David Chapman Subject: MC can't send to itself? To: BUG-MAIL%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU Message-ID: <635953.890821.ZVONA@AI.AI.MIT.EDU> This puzzles me. This is from a SHOW-Q on MC: MC.LCS.MIT.EDU: <607552.890820@MC.LCS.MIT.EDU> 20 AUG 1989 0332 EDT @MINTAKA.LCS.MIT.EDU 734 -> FILE [GDEAD;REQEST MAIL] at MC.LCS.MIT.EDU; Failed 28 times <607554.890820@MC.LCS.MIT.EDU> 20 AUG 1989 0337 EDT @MINTAKA.LCS.MIT.EDU 74385 -> FILE [GDEAD;REQEST MAIL] at MC.LCS.MIT.EDU; Failed 28 times <607556.890820@MC.LCS.MIT.EDU> 20 AUG 1989 0344 EDT @MINTAKA.LCS.MIT.EDU 44319 -> FILE [GDEAD;REQEST MAIL] at MC.LCS.MIT.EDU; Failed 28 times <607571.890820@MC.LCS.MIT.EDU> 20 AUG 1989 0349 EDT @MINTAKA.LCS.MIT.EDU 748 -> FILE [GDEAD;REQEST MAIL] at MC.LCS.MIT.EDU; Failed 28 times <607574.890820@MC.LCS.MIT.EDU> 20 AUG 1989 0455 EDT @MINTAKA.LCS.MIT.EDU 27755 -> FILE [GDEAD;REQEST MAIL] at MC.LCS.MIT.EDU; Failed 24 times MC has lots of free blocks, GDEAD; isn't full, and the file it's trying to mail to is ``only'' 44 blocks long.  Date: Sat, 5 Aug 89 14:06:53 EDT From: David Chapman To: BUG-MAIL%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU Message-ID: <629976.890805.ZVONA@AI.AI.MIT.EDU> Say, I thought that the problem where COMSAT was interpreting Reagan's 450 replies as ``I'm broken, give up'' rather than ``go away, I'm busy'' had been fixed? But I've gotten a bunch of them today.  Date: Fri, 4 Aug 89 11:57:49 EDT From: David Chapman To: BUG-MAIL%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU Message-ID: <629425.890804.ZVONA@AI.AI.MIT.EDU> Y'know, AI's LISTS MSGS has been constant around 380 blocks for months now; but SHOW-Q says there's nothing in there. MC's is always real small (under 50 blocks). I bet that AI's has about 350 blocks of garbage in it that aren't getting reclaimed. I don't suppose this MATTERS, but it's kind of odd.  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 26 Jul 89 23:44:09 EDT Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 241556; Wed 26-Jul-89 23:43:55 EDT Date: Wed, 26 Jul 89 23:43 EDT From: Alan Bawden Subject: NAMES INFO To: CENT@AI.AI.MIT.EDU cc: ZVONA@AI.AI.MIT.EDU, BUG-MAIL@AI.AI.MIT.EDU In-Reply-To: <625203.890724.CENT@AI.AI.MIT.EDU> Message-ID: <19890727034352.4.ALAN@PIGPEN.AI.MIT.EDU> Date: Mon, 24 Jul 89 23:47:40 EDT From: "Pandora B. Berman" Date: Mon, 24 Jul 89 20:53:47 EDT From: David Chapman To: BUG-MAIL@AI.AI.MIT.EDU I updated NAMES INFO. Old version in KSC;NAMES OINFO. good; this needed to be done. one little problem with your version, which i fixed and installed: you said (FILE [FOO;BAR BAZ] @MC) is the correct method for other-ITS files. this has the bug of space before the @host-name. alan tested this out and found that straight [FOO;BAR BAZ]@MC doesn't work, but ([FOO;BAR BAZ]@MC) does. his opinion was that we could either special-case mail to other-ITS files a la ([FOO;BAR BAZ] MC), or we could replace that space with an @ -- the @ is ulgier (i think), but has the virtue of fitting into the now-standard pattern for all addresses. Apologies for the confusion I have caused on this issue by telling Chapman and Penny two -different- things. In fact, either ([FOO;BAR BAZ]@MC) or (FILE [FOO;BAR BAZ] @MC) will work. In fact, ([FOO;BAR BAZ] @MC) and (FILE [FOO;BAR BAZ]@MC) probably work as well. What -won't- work is: [FOO;BAR BAZ]@MC because (as you can see from the four examples above) COMSAT's parser sees a break between the "]" and the "@" whether you put a space between them or not. I'm not sure which of the formats that work I would prefer, but as long as the documentation tells you about something that is works, that's fine and we should leave it alone.  Date: Mon, 24 Jul 89 23:47:40 EDT From: "Pandora B. Berman" Subject: NAMES INFO To: ZVONA%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU cc: BUG-MAIL%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU Message-ID: <625203.890724.CENT@AI.AI.MIT.EDU> Date: Mon, 24 Jul 89 20:53:47 EDT From: David Chapman To: BUG-MAIL%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU I updated NAMES INFO. Old version in KSC;NAMES OINFO. good; this needed to be done. one little problem with your version, which i fixed and installed: you said (FILE [FOO;BAR BAZ] @MC) is the correct method for other-ITS files. this has the bug of space before the @host-name. alan tested this out and found that straight [FOO;BAR BAZ]@MC doesn't work, but ([FOO;BAR BAZ]@MC) does. his opinion was that we could either special-case mail to other-ITS files a la ([FOO;BAR BAZ] MC), or we could replace that space with an @ -- the @ is ulgier (i think), but has the virtue of fitting into the now-standard pattern for all addresses.  Date: Mon, 24 Jul 89 20:53:47 EDT From: David Chapman To: BUG-MAIL%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU Message-ID: <625138.890724.ZVONA@AI.AI.MIT.EDU> I updated NAMES INFO. Old version in KSC;NAMES OINFO.  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 15 Jul 89 14:28:15 EDT Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 236367; Sat 15-Jul-89 14:28:01 EDT Date: Sat, 15 Jul 89 14:27 EDT From: Alan Bawden Subject: Attention @FILE maintainers To: CENT@AI.AI.MIT.EDU cc: ALAN@AI.AI.MIT.EDU, MAP@AI.AI.MIT.EDU, JNC@AI.AI.MIT.EDU, CBF@AI.AI.MIT.EDU, SOLEY@AI.AI.MIT.EDU, GSB@AI.AI.MIT.EDU, PLK@AI.AI.MIT.EDU, HGA@AI.AI.MIT.EDU, SASW@AI.AI.MIT.EDU, dead-heads-request@MC.LCS.MIT.EDU, info-tex-request@MC.LCS.MIT.EDU, merlin@LCS.MIT.EDU, BUG-MAIL@AI.AI.MIT.EDU In-Reply-To: <618715.890709.CENT@AI.AI.MIT.EDU> Message-ID: <19890715182758.4.ALAN@PIGPEN.AI.MIT.EDU> Date: Sun, 9 Jul 89 22:45:50 EDT From: "Pandora B. Berman" ... Usually affected addresses have been changed to the format FOO@BAR.NET, although in certain cases the style used in the particular mailing list has pursuaded us to use instead the form (FOO BAR.NET).... I hate to tell you this, but the (FOO BAR.NET) format is a loser to. Here in the future, -all- addresses should be of the form FOO@BAR.NET. No other form is acceptable any more. I guess another pass through all the @FILEs is needed...  Date: Sun, 9 Jul 89 22:45:50 EDT From: "Pandora B. Berman" Subject: Attention @FILE maintainers To: ALAN%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU, MAP%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU, JNC%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU, CBF%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU, SOLEY%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU, GSB%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU, PLK%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU, HGA%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU, SASW%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU, dead-heads-request@MC.LCS.MIT.EDU, info-tex-request@MC.LCS.MIT.EDU, merlin@MINTAKA.LCS.MIT.EDU cc: BUG-MAIL%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU Message-ID: <618715.890709.CENT@AI.AI.MIT.EDU> These days all non-Chaosnet directed mail from the ITS machines is gatewayed to the Internet by MINTAKA.LCS.MIT.EDU. Due to disagreements among the various mail software involved, it is no longer prudent to assume the address form (FOO @BAR.NET) will be parsed correctly. The problem appears most common for the variant (FOO%BAZ.QUUX @BAR.NET). So the principal mailing list files on all ITS machines and all @FILEs which are referred to therein have been checked for and cleansed of such addresses. Usually affected addresses have been changed to the format FOO@BAR.NET, although in certain cases the style used in the particular mailing list has pursuaded us to use instead the form (FOO BAR.NET). The following @FILEs have been modified: on AI: [ALAN;CUBE PEOPLE] [.TECO.;DISSOC PEOPLE] [SYSHST;ZRCPT UPDHST] on MC: [JNC;CDDT PEOPLE] [CBF;CHAOS MAINT] [GDead;Dead Local] [COMAIL;JEWNET LIST] [COMAIL;ILL DESGNR] [COMAIL;ILL USERS] [GSB;INFNIL >] [COMAIL;OPTICS LIST] [TEX;TEX MLIST] [TEX;LOCAL MLIST] [LSPMAI;LSPDSC PEOPLE] [COMAIL;LOCAL NETS] [COMAIL;MACDOC LIST] [LSPMAI;NILFOR >] [COMAIL;MULTI LIST] [COMAIL;PARSYM >] [SIPB;MAILTO MINRAW]  Date: Sun, 9 Jul 89 22:28:34 EDT From: "Pandora B. Berman" Subject: @FILEs To: BUG-MAIL%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU Message-ID: <618708.890709.CENT@AI.AI.MIT.EDU> Date: Sat, 8 Jul 89 17:53:11 EDT From: Alan Bawden Subject: @FILEs To: CENT%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU This is a reminder to go through all the @FILEs in the world and fix the syntax. a month or so back zvona went through AI:NAMES > and removed the @-preceding spaces (and also unpackaged some of the affected addresses from their excess parens). i have now done this for MC: and ML: NAMES > and the @FILEs. the following @FILEs needed assistance: on AI: (@FILE [ALAN;CUBE PEOPLE]))) (INFO-DP (EQV-LIST (@FILE [.TECO.;DISSOC PEOPLE]))) (INFO-HOSTS-UPDATE (EQV-LIST (@FILE [SYSHST;ZRCPT UPDHST]))) on MC: (EQV-LIST (@FILE [JNC;CDDT PEOPLE] (R-HEADER-FORCE RFC733)) (CHAOS-MAINT (EQV-LIST (@FILE [CBF;CHAOS MAINT]))) (Dead-Heads (EQV-LIST (@FILE [GDead;Dead Local]) (JEWNET (EQV-LIST (@FILE [COMAIL;JEWNET LIST]))) (ILL-DESIGNERS (EQV-LIST (@FILE [COMAIL;ILL DESGNR]))) (ILL-USERS (EQV-LIST (@FILE [COMAIL;ILL USERS]))) (INFO-NIL (EQV-LIST (@FILE [GSB;INFNIL >]))) (INFO-OPTICS (EQV-LIST (@FILE [COMAIL;OPTICS LIST]))) (INFO-TEX (EQV-LIST (@FILE [TEX;TEX MLIST]) (FILE [TEX;TEX ARCHIV]))) (INFO-TEX-LOCAL (EQV-LIST (@FILE [TEX;LOCAL MLIST]) (FILE [TEX;LOCAL ARCHIV]))) (LISP-DISCUSSION (EQV-LIST (@FILE [LSPMAI;LSPDSC PEOPLE]) (LOCAL-NETS (EQV-LIST (@FILE [COMAIL;LOCAL NETS]))) (MACDOC (EQV-LIST (@FILE [COMAIL;MACDOC LIST]))) (NIL-FORUM (EQV-LIST (@FILE [LSPMAI;NILFOR >]))) (ONLINE-MULTI (EQV-LIST (@FILE [COMAIL;MULTI LIST]))) (PARSYM-MIT (EQV-LIST (@FILE [COMAIL;PARSYM >]))) (SIPB-MINUTES (EQV-LIST (@FILE [sipb;mailto minraw]))) some of them don't have identifiable maintainers. i will attempt to notify the maintainers where known.  Date: Fri, 7 Jul 89 22:39:59 EDT From: Rob Austein Subject: AI: SYSNET; NETRTS 355 To: BUG-COMSAT%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU Message-ID: <618336.890707.SRA@AI.AI.MIT.EDU> AI: SYSNET; NETRTS 355 is a new version that attempts to deal with the lossage for SMTP 450 error codes. The 450 code is still present but turned off under a new switch, $$450. There's no time to actually assemble it before ITS goes down for the A/C work, so testing it, along with attempting to fix the unknown hostname lossage, will have to wait for another day.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 28 Jun 89 18:29:20 EDT Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 28 Jun 89 18:28:46 EDT Received: from BIGBOOTE.LCS.MIT.EDU by mintaka.lcs.mit.edu id aa18418; 28 Jun 89 18:27 EDT Received: by bigboote.LCS.MIT.EDU id AA01339; Wed, 28 Jun 89 18:26:59 EDT Date: Wed, 28 Jun 89 18:26:59 EDT Message-Id: <8906282226.AA01339@bigboote.LCS.MIT.EDU> From: Rob Austein Sender: sra@bigboote.lcs.mit.edu To: mt@media-lab.media.mit.edu Cc: bug-mail@mc.lcs.mit.edu, busted@media-lab.media.mit.edu In-Reply-To: Michael Travers's message of Wed, 28 Jun 89 16:59 EDT <19890628205933.6.MT@OUROBOROS.MEDIA.MIT.EDU> Subject: No more Chaosnet on amt Date: Wed, 28 Jun 89 16:59 EDT From: Michael Travers MEDIA-LAB.MEDIA.MIT.EDU has undergone a hardware and software transplant, losing its chaosnet support in the process. The COMSAT log seems to show that MC is trying to send AMT mail exclusively via Chaosnet. I changes some addresses to go through mintaka, but the host table ought to be updated. You're right, you should update the Media Lab chaosnet host table AI: SYSHST; HSTMDA >.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 28 Jun 89 17:43:35 EDT Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 28 Jun 89 17:05:26 EDT Received: from media-lab.media.mit.edu by mintaka.lcs.mit.edu id aa15930; 28 Jun 89 17:01 EDT Received: by media-lab (5.57/4.8) id AA12318; Wed, 28 Jun 89 17:00:35 EDT Date: Wed, 28 Jun 89 16:59 EDT From: Michael Travers Subject: No more Chaosnet on amt To: bug-mail@mc.lcs.mit.edu Cc: busted@media-lab.media.mit.edu Message-Id: <19890628205933.6.MT@OUROBOROS.MEDIA.MIT.EDU> MEDIA-LAB.MEDIA.MIT.EDU has undergone a hardware and software transplant, losing its chaosnet support in the process. The COMSAT log seems to show that MC is trying to send AMT mail exclusively via Chaosnet. I changes some addresses to go through mintaka, but the host table ought to be updated.  Date: Mon, 26 Jun 89 18:18:10 EDT From: David Chapman Subject: [COMSAT%AI.AI.MIT.EDU: Msg of Sunday, 25 June 1989 15:47-EDT] To: Alan@REAGAN.AI.MIT.EDU cc: BUG-MAIL%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU In-reply-to: Msg of Mon 26 Jun 89 17:18 EDT from Alan Bawden Message-ID: <614476.890626.ZVONA@AI.AI.MIT.EDU> Well that seems like the wrong algorithm to me. Suppose AMT had been just about to come up when I sent that message? That it's been down for the last week says zero about whether or not it'll be up during the next three days.  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 26 Jun 89 17:19:08 EDT Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 228817; Mon 26-Jun-89 17:18:54 EDT Date: Mon, 26 Jun 89 17:18 EDT From: Alan Bawden Subject: [COMSAT%AI.AI.MIT.EDU: Msg of Sunday, 25 June 1989 15:47-EDT] To: ZVONA@AI.AI.MIT.EDU cc: BUG-MAIL@AI.AI.MIT.EDU In-Reply-To: <614275.890626.ZVONA@AI.AI.MIT.EDU> Message-ID: <19890626211836.5.ALAN@PIGPEN.AI.MIT.EDU> Date: Mon, 26 Jun 89 11:45:24 EDT From: David Chapman This timed out after just three hours. Wrong thing, right? Date: Sun, 25 Jun 89 18:28:11 EDT From: Communications Satellite To: ZVONA%AI.AI.MIT.EDU at MINTAKA.LCS.MIT.EDU Re: Msg of Sunday, 25 June 1989 15:47-EDT FAILED: jrd at MEDIA-LAB.MEDIA.MIT.EDU; Host appears to be permanently down or not accepting mail. Failed message follows: ------- No. It timed out on the -host-, not the message. In fact, COMSAT has been trying to talk to the Media Lab for days and it hasn't been answering. You just happened to give COMSAT one more message three hours before it finally gave up and flushed all the messages for the Media Lab.  Date: Mon, 26 Jun 89 11:45:24 EDT From: David Chapman Subject: [COMSAT%AI.AI.MIT.EDU: Msg of Sunday, 25 June 1989 15:47-EDT] To: BUG-MAIL%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU Message-ID: <614275.890626.ZVONA@AI.AI.MIT.EDU> This timed out after just three hours. Wrong thing, right? Date: Sun, 25 Jun 89 18:28:11 EDT From: Communications Satellite To: ZVONA%AI.AI.MIT.EDU at MINTAKA.LCS.MIT.EDU Re: Msg of Sunday, 25 June 1989 15:47-EDT FAILED: jrd at MEDIA-LAB.MEDIA.MIT.EDU; Host appears to be permanently down or not accepting mail. Failed message follows: ------- Date: Sun, 25 Jun 89 15:47:19 EDT From: David Chapman Subject: Jennifer To: jrd@MEDIA-LAB.MEDIA.MIT.EDU In-reply-to: Msg of Sun 25 Jun 89 15:12:51 EDT from Jim Davis Message-ID: <613960.890625.ZVONA@AI.AI.MIT.EDU> She'll be in Northampton from tonight through Tuesday night. Maybe you can meet up with her there. In fact tomorrow she's going English Country dancing and maybe also sleaze blues dancing. I'll give her your number; she's staying with her lover Ellie at 413-586-6010. We'll probably do fireworks on the 4th, want to come to that?  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 19 Jun 89 14:39:14 EDT Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 19 Jun 89 14:36:39 EDT Received: from BIGBOOTE.LCS.MIT.EDU by mintaka.lcs.mit.edu id aa28673; 19 Jun 89 14:31 EDT Received: by bigboote.LCS.MIT.EDU id AA12866; Mon, 19 Jun 89 14:31:07 EDT Date: Mon, 19 Jun 89 14:31:07 EDT Message-Id: <8906191831.AA12866@bigboote.LCS.MIT.EDU> From: Rob Austein Sender: sra@bigboote.lcs.mit.edu To: ZVONA@mc.lcs.mit.edu Cc: BUG-MAIL@mc.lcs.mit.edu In-Reply-To: David Chapman's message of Mon, 19 Jun 89 14:13:11 EDT <591776.890619.ZVONA@MC.LCS.MIT.EDU> Date: Mon, 19 Jun 89 14:13:11 EDT From: David Chapman Hey, I never got a reply to my report that "Joan_V._DeArtemis.ESAE"@Xerox.COM, which used to work, gets parsed wrong by COMSAT. I'm not demanding a fix or anything, but I'd at least like to know if someone has looked to see why it's broken... I think the current theory is that COMSAT as currently configured sometimes mucks with double quotes, so that an address like "Joan_V._DeArtemis.ESAE"@Xerox.COM ends up as ""Joan_V._DeArtemis.ESAE"@Xerox.COM"@MINTAKA.LCS.MIT.EDU which is, of course, bogus.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 19 Jun 89 14:15:41 EDT Date: Mon, 19 Jun 89 14:13:11 EDT From: David Chapman To: BUG-MAIL%MC.LCS.MIT.EDU@MINTAKA.LCS.MIT.EDU Message-ID: <591776.890619.ZVONA@MC.LCS.MIT.EDU> Hey, I never got a reply to my report that "Joan_V._DeArtemis.ESAE"@Xerox.COM, which used to work, gets parsed wrong by COMSAT. I'm not demanding a fix or anything, but I'd at least like to know if someone has looked to see why it's broken...  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 12 Jun 89 17:58:30 EDT Received: from ZERMATT.LCS.MIT.EDU (CHAOS 17316) by MC.LCS.MIT.EDU 12 Jun 89 17:49:24 EDT Received: from MICKEY-MOUSE.LCS.MIT.EDU by ZERMATT.LCS.MIT.EDU via CHAOS with CHAOS-MAIL id 265623; Mon 12-Jun-89 17:49:00 EDT Date: Mon, 12 Jun 89 17:48 EDT From: Scheme Requestee Subject: re: address syntax? (mail problem) To: ME@sail.stanford.edu, bug-mail@MC.LCS.MIT.EDU, RPG@sail.stanford.edu In-Reply-To: <11gzll@SAIL.Stanford.EDU> Message-ID: <"19890612214840.3.schreq@MC"@MICKEY-MOUSE.LCS.MIT.EDU> Date: 01 Jun 89 1700 PDT From: Martin Frost Nothing at SAIL has changed lately, so maybe something has changed at MIT. Judging from the 550 reply line, the failing destination, which is reported correctly on the FAILED: line below, seems to have been split at the comma that is embedded in the (originally quoted) address. FAILED: #COMSCH.MSG[SCH,LSP] at SAIL.STANFORD.EDU; Recipient name apparently rejected. Last reply was: {550 (USER) Unknown user name in ""#COMSCH.MSG[SCH""} I don't know what system generated this 550 reply, but it wasn't SAIL. I assume this reply was generated internally at MIT, perhaps after some system re-parsed the one destination into two at the comma, turning the first one into an unknown local address. Dick, if necessary, I can add a local mail alias for this file so that the the mail address at other hosts won't have to contain a comma. Dick has set up a local alias at sail, so this is not an issue any more. Thanks for your help. - Jonathan Rees  Date: Fri, 9 Jun 89 13:25:18 EDT From: David Chapman Subject: [COMSAT%MC.LCS.MIT.EDU: Msg of Monday, 5 June 1989 00:12-EDT] To: BUG-MAIL%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU Message-ID: <607106.890609.ZVONA@AI.AI.MIT.EDU> Oh, wow: I hadn't seen THIS when I sent that last message. That syntax used to work. Date: Mon, 5 Jun 89 00:25:34 EDT From: Communications Satellite To: PAGANISM-REQUEST%MC.LCS.MIT.EDU at MINTAKA.LCS.MIT.EDU Re: Msg of Monday, 5 June 1989 00:12-EDT FAILED: at XEROX.COM; Recipient name apparently rejected. Last reply was: {550 Unable to parse address} Failed message follows: ------- Date: 5 JUN 89 00:12:13 EDT From: Automatic Paganism Digestifier Subject: Paganism Digest #269 To: Paganism@mc.lcs.mit.edu Reply-to: Paganism@mc.lcs.mit.edu Paganism Digest #269 5 JUN 89 00:12:13 EDT Today's Topics: Bet ---------------------------------------------------------------------- Date: Sun, 4 Jun 89 22:08:33 EDT From: drw@bourbaki.mit.edu Message-Id: <8906050208.AA17260@schubert.mit.edu> Subject: Bet I've got a bet going with a friend that in 20 years (by 2010), 2% (about 5 million) Americans will be neo-pagans of various kinds. Does anybody out there know how many people identify themselves a Pagans? (I'm not counting vague New Age beliefs as serious Paganism.) And how about we get the Census Bureau to put a "Pagan" box in the religion column? Dale ------------------------------ End of Paganism Digest **********************  Date: Fri, 9 Jun 89 13:22:31 EDT From: David Chapman Subject: [COMSAT%MC.LCS.MIT.EDU: Msg of Monday, 5 June 1989 00:12-EDT] To: BUG-MAIL%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU Message-ID: <607104.890609.ZVONA@AI.AI.MIT.EDU> Something's definitely broken here. This luser appears in the @file as "Joan_V._DeArtemis.ESAE"@Xerox.COM. Date: Mon, 5 Jun 89 00:15:55 EDT From: Communications Satellite To: PAGANISM-REQUEST%MC.LCS.MIT.EDU at MINTAKA.LCS.MIT.EDU Re: Msg of Monday, 5 June 1989 00:12-EDT ============ A copy of your message is being returned, because: ============ "JOAN_V._DEARTEMIS.ESAE" at MC.LCS.MIT.EDU is an unknown recipient. This name came from the expansion of (@FILE [ZVONA;PAGAN LIST]), from PAGANISM-DIGEST ============ Failed message follows: ============ Date: 5 JUN 89 00:12:13 EDT From: Automatic Paganism Digestifier Subject: Paganism Digest #269 To: Paganism@mc.lcs.mit.edu Reply-to: Paganism@mc.lcs.mit.edu Paganism Digest #269 5 JUN 89 00:12:13 EDT Today's Topics: Bet ---------------------------------------------------------------------- Date: Sun, 4 Jun 89 22:08:33 EDT From: drw@bourbaki.mit.edu Message-Id: <8906050208.AA17260@schubert.mit.edu> Subject: Bet I've got a bet going with a friend that in 20 years (by 2010), 2% (about 5 million) Americans will be neo-pagans of various kinds. Does anybody out there know how many people identify themselves a Pagans? (I'm not counting vague New Age beliefs as serious Paganism.) And how about we get the Census Bureau to put a "Pagan" box in the religion column? Dale ------------------------------ End of Paganism Digest **********************  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU 9 Jun 89 10:39:02 EDT From: Rob Austein Sender: sra@lcs.mit.edu To: bug-mail@AI.ai.mit.edu, bug-mail@mintaka.lcs.mit.edu Subject: New Chaos/SMTP server on Mintaka BCC: sra@lcs.mit.edu Date: Fri, 9 Jun 89 10:33:24 EDT Message-ID: <8906091033.aa15988@mintaka.lcs.mit.edu> I installed a new Chaos/SMTP server on Mintaka (specificly, /usr/lib/chaos/SMTP). The only change (to a ten line program) is that it now tells the MMDF SMTP server (which it forks off to do the real work) that this incoming mail is coming from the "chaos" channel instead of the "smtp" channel. We hope this will put an end to the silliness where Mintaka refuses to accept Chaos/SMTP mail from AI and ML because it can't find MX RRs for them. It appears to be working fine, but COMSAT watchers please keep an eye out for spurrious rejections from Mintaka. There's some internal MMDF hair here about which we are just making a semi-educated guess....  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 6 Jun 89 14:50:53 EDT Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 6 Jun 89 14:49:44 EDT Received: from BIGBOOTE.LCS.MIT.EDU by mintaka.lcs.mit.edu id aa05086; 6 Jun 89 14:43 EDT Received: by bigboote.LCS.MIT.EDU id AA01548; Tue, 6 Jun 89 14:43:53 EDT Date: Tue, 6 Jun 89 14:43:53 EDT Message-Id: <8906061843.AA01548@bigboote.LCS.MIT.EDU> From: Rob Austein Sender: sra@bigboote.lcs.mit.edu To: Alan@ai.ai.mit.edu Cc: bug-mail@mc.lcs.mit.edu, Postmaster@lcs.mit.edu, SCHREQ@mc.lcs.mit.edu, ME@sail.stanford.edu, RPG@sail.stanford.edu In-Reply-To: Alan Bawden's message of Tue, 6 Jun 89 14:11 EDT <19890606181106.2.ALAN@PIGPEN.AI.MIT.EDU> Subject: address syntax? (mail problem) Date: Tue, 6 Jun 89 14:11 EDT From: Alan Bawden I would guess that the problem is with MINTAKA.LCS.MIT.EDU which is the machine we use to gateway mail from MC to the Internet. COMSAT is having no trouble parsing the address (as indicated by the address on the FAILED: line), but this error message (from MINTAKA) indicates that MINTAKA has broken the address at the comma. Presumably MINTAKA either discarded the rest of the address, or tried to deliver the message to "LSP]" at SAIL. I would say that this is a bug in MINTAKA's SMTP server. It is certainly the case that what triggered this is the switch from direct mailing by MC to indirect mailing through Mintaka. Where the bug lies is less clear. I'd have to figure out exactly what MC is sending to Mintaka in the SMTP dialog (in particular, the exact number and placement of double quote characters, which is not obviously obvious from any of the error messages we've seen) then go over it with a fine tooth comb and the BNF from RFC821 to be sure who's at fault. Which is why I haven't done it yet, it involves thinking and reading code and debugging and other painful things like that. Odds are about evenly split that (a) it's a bug in Mintaka's SMTP listener, (b) it's an address that is in fact syntacticly illegal but which always worked before because it was only used between consenting adults (MC and SAIL), or (c) the code in COMSAT to handle relaying does not in fact do the right thing for a complicated address like this that already needs double quote characters just to be syntacticly legal. If we're just interested in getting the mail working again ASAP I think we should take Martin up on his offer of providing a local alias on SAIL to hide the oddball address syntax. We used to do the same thing on XX to deal with hosts that didn't like "*ps:bar.txt" addresses.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 6 Jun 89 14:12:18 EDT Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by MC.LCS.MIT.EDU 6 Jun 89 14:11:29 EDT Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 219344; Tue 6-Jun-89 14:11:16 EDT Date: Tue, 6 Jun 89 14:11 EDT From: Alan Bawden Subject: re: address syntax? (mail problem) To: bug-mail@MC.LCS.MIT.EDU, Postmaster@LCS.MIT.EDU cc: SCHREQ@MC.LCS.MIT.EDU, ME@sail.stanford.edu, RPG@sail.stanford.edu In-Reply-To: <11gzll@SAIL.Stanford.EDU> Message-ID: <19890606181106.2.ALAN@PIGPEN.AI.MIT.EDU> I haven't seen anybody from MIT respond to this exchange: Date: 01 Jun 89 1700 PDT From: Martin Frost Nothing at SAIL has changed lately, so maybe something has changed at MIT. Judging from the 550 reply line, the failing destination, which is reported correctly on the FAILED: line below, seems to have been split at the comma that is embedded in the (originally quoted) address. FAILED: #COMSCH.MSG[SCH,LSP] at SAIL.STANFORD.EDU; Recipient name apparently rejected. Last reply was: {550 (USER) Unknown user name in ""#COMSCH.MSG[SCH""} I don't know what system generated this 550 reply, but it wasn't SAIL. I assume this reply was generated internally at MIT, perhaps after some system re-parsed the one destination into two at the comma, turning the first one into an unknown local address. Dick, if necessary, I can add a local mail alias for this file so that the the mail address at other hosts won't have to contain a comma. I would guess that the problem is with MINTAKA.LCS.MIT.EDU which is the machine we use to gateway mail from MC to the Internet. COMSAT is having no trouble parsing the address (as indicated by the address on the FAILED: line), but this error message (from MINTAKA) indicates that MINTAKA has broken the address at the comma. Presumably MINTAKA either discarded the rest of the address, or tried to deliver the message to "LSP]" at SAIL. I would say that this is a bug in MINTAKA's SMTP server.  Date: Mon, 5 Jun 89 01:09:53 EDT From: "Pandora B. Berman" Subject: comsat runs out of space To: BUG-MAIL%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU Message-ID: <604522.890605.CENT@AI.AI.MIT.EDU> i found a couple 13block msgs on MC:.MAIL.;. they looked ok except for being so long, so i killed and relaunched MC IV and renamed them, and they went through. that also reminded me that the SCA digest for sat. never arrived in my mail file. i had noticed it was rather large (18 blocks). so i looked through the .BULK. OSTATS file for the appropriate time (2-3am, 3jun). the digest had pushed through to everywhere except AI, which had produced the file-too-big-use-FTP err. COMSAT BULK had tried to deliver said error and bounced msg to the digest's reply-to: (or whatever it is) address, but that's on AI too, so the erring msg had been dumped into the bit bucket. on the basis of this evidence, i gunned and relaunched AI's COMSAT. having erring msgs drop into the bit bucket like this is sub-optimal; it would be nice if they instead landed somewhere where they could be looked at. i had forgotten about sra's New Improved Reloads Itself When It Needs Space COMSAT until after taking these actions.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 1 Jun 89 13:12:22 EDT Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 1 Jun 89 12:59:01 EDT Received: from Sail.Stanford.EDU by mintaka.lcs.mit.edu id aa01779; 1 Jun 89 23:46 EDT Message-ID: <11gzll@SAIL.Stanford.EDU> Date: 01 Jun 89 1700 PDT From: Martin Frost Subject: re: address syntax? (mail problem) To: SCHREQ@mc.lcs.mit.edu, bug-mail@mc.lcs.mit.edu, RPG@sail.stanford.edu Nothing at SAIL has changed lately, so maybe something has changed at MIT. Judging from the 550 reply line, the failing destination, which is reported correctly on the FAILED: line below, seems to have been split at the comma that is embedded in the (originally quoted) address. FAILED: #COMSCH.MSG[SCH,LSP] at SAIL.STANFORD.EDU; Recipient name apparently rejected. Last reply was: {550 (USER) Unknown user name in ""#COMSCH.MSG[SCH""} I don't know what system generated this 550 reply, but it wasn't SAIL. I assume this reply was generated internally at MIT, perhaps after some system re-parsed the one destination into two at the comma, turning the first one into an unknown local address. Dick, if necessary, I can add a local mail alias for this file so that the the mail address at other hosts won't have to contain a comma.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 1 Jun 89 13:12:07 EDT Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 1 Jun 89 12:58:52 EDT Received: from Sail.Stanford.EDU by mintaka.lcs.mit.edu id ad01765; 1 Jun 89 23:46 EDT Message-ID: Date: 01 Jun 89 1725 PDT From: Martin Frost Subject: Oops, I left out the "#" in that line near the end of my message. To: RPG@sail.stanford.edu CC: SCHREQ@mc.lcs.mit.edu, bug-mail@mc.lcs.mit.edu It should have said: Try mailing (from the Unix shell) to: '"#comsch.msg[sch,lsp]"'@sail.stanford.edu, to make the double quotes part of the destination. (Type both kinds of quotes.)  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 1 Jun 89 13:11:52 EDT Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 1 Jun 89 12:58:43 EDT Received: from Sail.Stanford.EDU by mintaka.lcs.mit.edu id ac01765; 1 Jun 89 23:46 EDT Message-ID: <19g#B4@SAIL.Stanford.EDU> Date: 01 Jun 89 1723 PDT From: Martin Frost Subject: re: address syntax? (mail problem) To: RPG@sail.stanford.edu CC: SCHREQ@mc.lcs.mit.edu, bug-mail@mc.lcs.mit.edu That's a SunOS system? I've had similar though different problems from Polya (Unix/Ultrix). What seems to happen is that the quoted address gets parsed by some process down the line even though the quoting is supposed to prevent that. In this example from Lucid, for instance, the [sch,lsp] has been changed to [sch:lsp], no doubt because of a kludge to handle certain old SMTP mailers (in combination with the loss of the quoting). Connected to Sail.Stanford.EDU: >>> RCPT To:<#comsch.msg[sch:lsp]@sail.stanford.edu> <<< 500 Syntax error #4000043 in recipient specification: "RCPT To:<#comsch.msg[sch:lsp]@sail.stanford.edu>" 554 <@heavens-gate:#comsch.msg[sch:lsp]@sail.stanford.edu>... Remote protocol error ----- Unsent message follows ----- Received: from challenger ([192.9.200.17]) by heavens-gate id AA16579g; Thu, 1 Jun 89 17:02:22 PDT Received: by challenger id AA12480g; Thu, 1 Jun 89 17:01:33 PDT Date: Thu, 1 Jun 89 17:01:33 PDT From: Richard P. Gabriel Message-Id: <8906020001.AA12480@challenger> To: "#comsch.msg[sch,lsp]"@sail.stanford.edu Subject: Test Try mailing (from the Unix shell) to: '"comsch.msg[sch,lsp]"'@sail.stanford.edu, to make the double quotes part of the destination. (Type both kinds of quotes.)  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 1 Jun 89 13:11:32 EDT Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 1 Jun 89 12:58:34 EDT Received: from Sail.Stanford.EDU by mintaka.lcs.mit.edu id ab01765; 1 Jun 89 23:46 EDT Message-ID: <1Ug#5V@SAIL.Stanford.EDU> Date: 01 Jun 89 1709 PDT From: Dick Gabriel Subject: re: address syntax? (mail problem) To: ME@sail.stanford.edu, SCHREQ@mc.lcs.mit.edu, bug-mail@mc.lcs.mit.edu, RPG@sail.stanford.edu [In reply to message from ME rcvd 01-Jun-89 17:00-PT.] Marty, I tried to mail to this file from Lucid (which is connected to Stanford via Jeeves), and it failed as follows: Date: Thu, 1 Jun 89 17:02:22 PDT From: Mail Delivery Subsystem Subject: Returned mail: Remote protocol error To: ----- Transcript of session follows ----- Connected to Sail.Stanford.EDU: >>> RCPT To:<#comsch.msg[sch:lsp]@sail.stanford.edu> <<< 500 Syntax error #4000043 in recipient specification: "RCPT To:<#comsch.msg[sch:lsp]@sail.stanford.edu>" 554 <@heavens-gate:#comsch.msg[sch:lsp]@sail.stanford.edu>... Remote protocol error ----- Unsent message follows ----- Received: from challenger ([192.9.200.17]) by heavens-gate id AA16579g; Thu, 1 Jun 89 17:02:22 PDT Received: by challenger id AA12480g; Thu, 1 Jun 89 17:01:33 PDT Date: Thu, 1 Jun 89 17:01:33 PDT From: Richard P. Gabriel Message-Id: <8906020001.AA12480@challenger> To: "#comsch.msg[sch,lsp]"@sail.stanford.edu Subject: Test Grumble.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 31 May 89 18:52:39 EDT Received: from ZERMATT.LCS.MIT.EDU (CHAOS 17316) by MC.LCS.MIT.EDU 31 May 89 18:51:13 EDT Received: from MICKEY-MOUSE.LCS.MIT.EDU by ZERMATT.LCS.MIT.EDU via CHAOS with CHAOS-MAIL id 262242; Wed 31-May-89 18:51:18 EDT Date: Wed, 31 May 89 18:51 EDT From: Scheme Requestee Subject: [COMSAT%MC.LCS.MIT.EDU@MINTAKA.LCS.MIT.EDU: Msg of Wednesday, 31 May 1989 00:54-EDT] To: bug-comsat@MC.LCS.MIT.EDU cc: schreq@MC.LCS.MIT.EDU Included-msgs: <3710.890531@MC.LCS.MIT.EDU>, The message of 31 May 89 01:29 EDT from COMSAT%MC.LCS.MIT.EDU@MINTAKA.LCS.MIT.EDU, The message of 31 May 89 01:29 EDT from Communications Satellite Included-References: The message of 26 May 89 21:47 EDT from bobg+@andrew.cmu.edu Message-ID: <"19890531225103.9.schreq@MC"@MICKEY-MOUSE.LCS.MIT.EDU> Someone please tell me how to get mail to the following addresses. "#COMSCH.MSG[SCH,LSP]"@SAIL.Stanford.Edu "{forum >udd>Opus>ABall>meetings>Scheme}"@BCO-Multics.ARPA COMSAT is rejecting them as unparsable. (Actually I have complained about one of these already; the syntax ("#COMSCH.MSG[SCH,LSP]" @SAIL.Stanford.Edu) doesn't work either.) Thanks. -Jonathan Date: Wed, 31 May 89 01:29 EDT From: Communications Satellite Subject: Msg of Wednesday, 31 May 1989 00:54-EDT To: SCHEME-REQUEST%MC.LCS.MIT.EDU@MINTAKA.LCS.MIT.EDU FAILED: at BCO-MULTICS.HBI.HONEYWELL.COM; Recipient name apparently rejected. Last reply was: {550 Unable to parse address} FAILED: at SAIL.STANFORD.EDU; Recipient name apparently rejected. Last reply was: {550 Unable to parse address} FAILED: HMENDENHALL%HENRY.DECNET@GE-CRD.ARPA at MINTAKA.LCS.MIT.EDU; Recipient name apparently rejected. Last reply was: {550 (BHST) Unknown host/domain name in "HMENDENHALL%HENRY.DECNET@GE-CRD.ARPA"} Failed message follows: ------- Date: 31 MAY 89 00:09:15 EDT From: Automatic Scheme Digestifier Subject: Scheme Digest #130 To: Scheme@mc.lcs.mit.edu Reply-to: Scheme@mc.lcs.mit.edu ...  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 31 May 89 18:14:14 EDT Received: from ZERMATT.LCS.MIT.EDU (CHAOS 17316) by MC.LCS.MIT.EDU 31 May 89 18:12:54 EDT Received: from MICKEY-MOUSE.LCS.MIT.EDU by ZERMATT.LCS.MIT.EDU via CHAOS with CHAOS-MAIL id 262229; Wed 31-May-89 18:13:02 EDT Date: Wed, 31 May 89 18:12 EDT From: Scheme Requestee Subject: address syntax? To: bug-mail@MC.LCS.MIT.EDU cc: rpg@sail.stanford.edu Message-ID: <"19890531221247.4.schreq@MC"@MICKEY-MOUSE.LCS.MIT.EDU> The following line has been in two mailing lists that I maintain (scheme and rrrs-authors) for ages, and has been working just fine, but some time this month it stopped working: ("#COMSCH.MSG[SCH,LSP]" @SAIL.Stanford.Edu) Looks like someone is parsing the stuff inside the quotes. What gives? - Jonathan Date: Fri, 26 May 89 14:00:53 EDT From: Communications Satellite Subject: Msg of Friday, 26 May 1989 13:51-EDT To: "hal@murren.ai.mit.edu"@MINTAKA.lcs.mit.edu FAILED: #COMSCH.MSG[SCH,LSP] at SAIL.STANFORD.EDU; Recipient name apparently rejected. Last reply was: {550 (USER) Unknown user name in ""#COMSCH.MSG[SCH""} Failed message follows: ------- ...  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU 28 May 89 15:07:39 EDT Received: from ai.ai.mit.edu by mintaka.lcs.mit.edu id aa07634; 28 May 89 15:01 EDT Date: Sun, 28 May 89 15:02:07 EDT From: David Chapman To: DEVON%AI.AI.MIT.EDU@MINTAKA.lcs.mit.edu cc: BUG-COMSAT%AI.AI.MIT.EDU@MINTAKA.lcs.mit.edu In-reply-to: Msg of Sun 28 May 89 14:13:58 EDT from Devon Sean McCullough Message-ID: <601319.890528.ZVONA@AI.AI.MIT.EDU> That's not a bug, it's a feature.  Date: Sun, 28 May 89 14:13:58 EDT From: Devon Sean McCullough To: BUG-COMSAT%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU Message-ID: <601307.890528.DEVON@AI.AI.MIT.EDU> try :mail brian test-message^C and see what comsat does with it. It delivers it to everyone that :F BRIAN picks up.  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 26 May 89 16:39:22 EDT Received: from LIFE.AI.MIT.EDU by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 214384; 26 May 89 16:37:33 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by life.ai.mit.edu (4.1/AI-4.10) id AA06773; Fri, 26 May 89 16:38:07 EDT Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 601820; 26 May 89 16:39:27 EDT Date: Fri, 26 May 89 16:43 EDT From: David A. Moon Subject: [COMSAT@AI.AI.MIT.EDU: Msg of Friday, 26 May 1989 15:21-EDT] To: Rob Austein Cc: Bug-MAIL%AI@reagan.ai.mit.edu In-Reply-To: <8905261940.AA01004@bigboote.LCS.MIT.EDU> Message-Id: <19890526204325.2.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM> Date: Fri, 26 May 89 15:40:44 EDT From: Rob Austein Date: Fri, 26 May 89 15:23:23 EDT From: Communications Satellite FAILED: nick at ZERMATT.LCS.MIT.EDU; Recipient name apparently rejected. Last reply was: {450- The store-and-forward mailer on this machine has been shut down because of a program error. 450- The explanation given was: 450- Timed out after 5 minutes while trying to connect to WHEATIES. 450 The time of shutdown was 5/26/89 15:14:39} Of course this is a bug in the Lispm mailer, assuming that the operation it was trying to do on Wheaties was one that could have been deferred and wasn't really a reason why the mailer could not run. I.e. the Lispm mailer shouldn't have shut down. Once it did shut down, this was the right reply code. The reason why it has to do this instead of just stop answering network connections is really stupid: since the same socket is used both for mail and for interactive messages in SMTP, you can't reject the connection until after you know which kind of service is really being requested. Dumb protocol design! Well, I just got another one of these stupid messages and something snapped and I went looking through COMSAT to see where this message came from and why it was handling the most generic possible "I'm losing right now, please try again later" temporary error code as a rejection. It seems that, for reasons unknown but probably dating back to mail delivery via NCP/FTP, COMSAT's SMTP code specificly treats error code 450 as a permenant error. This is wired in in half a dozen places: it checks for an error code >= 500 (reasonable) and also checks for 450 specificly. I don't have the time to deal with this right now, but it really ought to be fixed. I would think that the correct thing to do is just rip out all the checks for error code 450. Anybody (I think this means Dave Moon) remember how this happened? I don't remember specifically, but I would imagine that some eunuchs mailer somewhere that we used to send a lot of mail to was written by someone who was too busy sending mail out about his disgusting personal habits to usenet to spend the time reading the mail protocol spec, and so returned 450 for a permanent error when they should have returned some 5xx code. And it was impossible to get that host fixed to obey the protocol so someone changed Comsat to work around it. On the other hand, RFC821 says 450 is a temporary error, but maybe some older mail protocol officially defined it as a permanent error just to be inconsistent. Some places in Comsat only check for 450 when running FTP, not when running SMTP, which is consistent with that idea. Also look at NKBSR7 in the CHAOS-MAIL user code. Another wierd thing is that Comsat has this table: NTCTAB: -1 ; None at moment. ;454. ; NBS-10, WPAFB-AFWAL (these suckers use 454 for no such user!) NTCTBL==<.-NTCTAB> but the 450 stuff doesn't use it. Anyway I don't see any harm in trying the experiment of commenting out the special checks for 450. I wouldn't remove them permanently until several months' experience shows they won't have to be put back in.  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 26 May 89 16:22:10 EDT Received: from LIFE.AI.MIT.EDU by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 214372; 26 May 89 16:20:23 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by life.ai.mit.edu (4.1/AI-4.10) id AA06113; Fri, 26 May 89 16:20:47 EDT Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 601809; 26 May 89 16:22:12 EDT Date: Fri, 26 May 89 16:26 EDT From: David A. Moon Subject: [COMSAT%MC.LCS.MIT.EDU: Msg of Thursday, 25 May 1989 10:57-EDT] To: Rob Austein Cc: Alan%AI@reagan.ai.mit.edu, Nick%AI@reagan.ai.mit.edu, Bug-MAIL%AI@reagan.ai.mit.edu In-Reply-To: <8905261915.AA00974@bigboote.LCS.MIT.EDU> Message-Id: <19890526202600.1.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM> Date: Fri, 26 May 89 15:15:03 EDT From: Rob Austein Date: Fri, 26 May 89 14:19 EDT From: Alan Bawden MINTAKA was behaving this way -all- -day- yesterday. Presumably this is domain resolver lossage caused by the AI Lab's Unix boxes being broken. Or the MIT.EDU nameservers or the EDU nameservers or whatever, but anyway it's the same effect. I count 25 messages bounced yesterday by this problem. Note that COMSAT timed this message out in a mere 8 hours. I would once again like to urge someone to figure out how to make mail take longer to time out. (Note: If you send me mail telling -me- how to do it, nothing will happen. I'm still -trying- to not hack COMSAT.) The current COMSAT has its max failure count field set to 250 decimal. According to both Moon and my own reading of the code, this should translate to 250*15 minutes = 3750 minutes = 62 hours, which is kind of low but is a lot more than 8 hours. So there's a bug somewhere that we haven't located. Big surprise. As I think I've mentioned before, there is one failure count for failure to connect to the host, and another failure count for temporary errors associated with an individual recipient. The limit on the latter is much smaller, for reasons that seemed good at the time many years ago. I can't remember, but one thing is that it used to be the case, and with the monotonic degradation of network software over the years probably still is the case on some popular operating systems, that some mailers will report a temporary error and then deliver the mail anyway. We didn't want to flood people's mailboxes with hundreds of copies when this happens. I may not have remembered accurately at all though. Even though the problem this time was that the destination mailer was screwed up, from the stuff in the stats file I think Comsat classified this problem as an individual recipient failure and hence used the smaller failure count limit, which I think is 30 tries. See A$RFCT and LIMRQS: ; LIMRQS controls the # times a rcpt is allowed to temporarily fail. ; These are usually due to asshole hosts that blow out on control ; characters or long lines in the message text. Generally due to ; directory full on the local host, so try for a long time. That comment didn't jog my memory any further. Should NTSN26 be further haired up to use a larger retry count when the destination host is the TCP gateway host or the domain gateway host or the chaos gateway host?  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 26 May 89 15:41:35 EDT Received: from BIGBOOTE.LCS.MIT.EDU by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 214359; 26 May 89 15:39:54 EDT Received: by bigboote.LCS.MIT.EDU id AA01004; Fri, 26 May 89 15:40:44 EDT Date: Fri, 26 May 89 15:40:44 EDT Message-Id: <8905261940.AA01004@bigboote.LCS.MIT.EDU> From: Rob Austein Sender: sra@bigboote.LCS.MIT.EDU To: Bug-MAIL@ai.ai.mit.edu Subject: [COMSAT@AI.AI.MIT.EDU: Msg of Friday, 26 May 1989 15:21-EDT] Date: Fri, 26 May 89 15:23:23 EDT From: Communications Satellite FAILED: nick at ZERMATT.LCS.MIT.EDU; Recipient name apparently rejected. Last reply was: {450- The store-and-forward mailer on this machine has been shut down because of a program error. 450- The explanation given was: 450- Timed out after 5 minutes while trying to connect to WHEATIES. 450 The time of shutdown was 5/26/89 15:14:39} Well, I just got another one of these stupid messages and something snapped and I went looking through COMSAT to see where this message came from and why it was handling the most generic possible "I'm losing right now, please try again later" temporary error code as a rejection. It seems that, for reasons unknown but probably dating back to mail delivery via NCP/FTP, COMSAT's SMTP code specificly treats error code 450 as a permenant error. This is wired in in half a dozen places: it checks for an error code >= 500 (reasonable) and also checks for 450 specificly. I don't have the time to deal with this right now, but it really ought to be fixed. I would think that the correct thing to do is just rip out all the checks for error code 450. Anybody (I think this means Dave Moon) remember how this happened?  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 26 May 89 15:15:46 EDT Received: from BIGBOOTE.LCS.MIT.EDU by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 214347; 26 May 89 15:14:11 EDT Received: by bigboote.LCS.MIT.EDU id AA00974; Fri, 26 May 89 15:15:03 EDT Date: Fri, 26 May 89 15:15:03 EDT Message-Id: <8905261915.AA00974@bigboote.LCS.MIT.EDU> From: Rob Austein Sender: sra@bigboote.LCS.MIT.EDU To: Alan@ai.ai.mit.edu Cc: Nick@ai.ai.mit.edu, Bug-MAIL@ai.ai.mit.edu In-Reply-To: Alan Bawden's message of Fri, 26 May 89 14:19 EDT <19890526181921.6.ALAN@PIGPEN.AI.MIT.EDU> Subject: [COMSAT%MC.LCS.MIT.EDU: Msg of Thursday, 25 May 1989 10:57-EDT] Date: Fri, 26 May 89 14:19 EDT From: Alan Bawden MINTAKA was behaving this way -all- -day- yesterday. Presumably this is domain resolver lossage caused by the AI Lab's Unix boxes being broken. Or the MIT.EDU nameservers or the EDU nameservers or whatever, but anyway it's the same effect. I count 25 messages bounced yesterday by this problem. Note that COMSAT timed this message out in a mere 8 hours. I would once again like to urge someone to figure out how to make mail take longer to time out. (Note: If you send me mail telling -me- how to do it, nothing will happen. I'm still -trying- to not hack COMSAT.) The current COMSAT has its max failure count field set to 250 decimal. According to both Moon and my own reading of the code, this should translate to 250*15 minutes = 3750 minutes = 62 hours, which is kind of low but is a lot more than 8 hours. So there's a bug somewhere that we haven't located. Big surprise.  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 26 May 89 14:21:06 EDT Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 214308; Fri 26-May-89 14:19:28 EDT Date: Fri, 26 May 89 14:19 EDT From: Alan Bawden Subject: [COMSAT%MC.LCS.MIT.EDU: Msg of Thursday, 25 May 1989 10:57-EDT] To: RS@AI.AI.MIT.EDU, JTW@AI.AI.MIT.EDU, CENT@AI.AI.MIT.EDU, NICK@AI.AI.MIT.EDU, Bug-MAIL@AI.AI.MIT.EDU cc: Alan@AI.AI.MIT.EDU In-Reply-To: <600372.890526.RS@AI.AI.MIT.EDU> Message-ID: <19890526181921.6.ALAN@PIGPEN.AI.MIT.EDU> Date: Fri, 26 May 89 00:08:05 EDT From: "Robert E. Seastrom" Rob, please send bug mail about bugs in the mail system to Bug-MAIL. I don't know what's going on, but all the mail I send through PDP8-LOVERS is BOUNCING... Date: Thu, 25 May 89 18:59:34 EDT From: Communications Satellite To: "RS@AI.AI.MIT.EDU" at AI.AI.MIT.EDU Re: Msg of Thursday, 25 May 1989 10:57-EDT FAILED: arpalists+pdp8-lovers at ANDREW.CMU.EDU; I gave up on sending this after 31 "temporary" errors. Failed message follows: ------- Here is the relevant entry from the STATS file: 185921 Unqueueing to host ANDREW.CMU.EDU 185921 ICP->ANDREW.CMU.EDU (CHAOS-SMTP via MINTAKA.LCS.MIT.EDU) 185925 QID=<584122.890525@MC.LCS.MIT.EDU>...init lost, R="451 [ Connection refused ] Nameserver timeout for '@mc.lcs.mit.edu:RS@AI.AI.MIT.EDU"...Giving up. 185935 CMSG ID=<584226.890525@MC.LCS.MIT.EDU> EXP->RS@AI.AI.MIT.EDU@40700003130 185936 ICP->AI.AI.MIT.EDU (CHAOS-SMTP) 185938 TO->RS@AI.AI.MIT.EDU MINTAKA was behaving this way -all- -day- yesterday. Presumably this is domain resolver lossage caused by the AI Lab's Unix boxes being broken. I count 25 messages bounced yesterday by this problem. Note that COMSAT timed this message out in a mere 8 hours. I would once again like to urge someone to figure out how to make mail take longer to time out. (Note: If you send me mail telling -me- how to do it, nothing will happen. I'm still -trying- to not hack COMSAT.)  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 23 May 89 21:58:42 EDT Received: from BIGBOOTE.LCS.MIT.EDU by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 213105; 23 May 89 21:57:39 EDT Received: by bigboote.LCS.MIT.EDU id AA01811; Tue, 23 May 89 21:58:33 EDT Date: Tue, 23 May 89 21:58:33 EDT Message-Id: <8905240158.AA01811@bigboote.LCS.MIT.EDU> From: Rob Austein Sender: sra@bigboote.LCS.MIT.EDU To: ZVONA@ai.ai.mit.edu Cc: BUG-MAIL@ai.ai.mit.edu In-Reply-To: David Chapman's message of Tue, 23 May 89 21:15:02 EDT <599373.890523.ZVONA@AI.AI.MIT.EDU> Date: Tue, 23 May 89 21:15:02 EDT From: David Chapman This % business is really gross. If we have to put up with it for more than a few days, someone should figure out how to install the Babyl patches OZ used to have that ameliorate the lossage somewhat... That code still exists. Look in the edit history of AI:EMACS1;BABYL > then look for the variable "Horribly Kludge Local Host." If I remember correctly, that variable should be set to some long ^O-separated sequence of things that you want stripped out. The code would have to be rewritten slightly (currently it's conditionalized for Twenex) but, whatever you do, PLEASE don't wire the names you want stripped into the TECO code. I ripped a bunch of that kind of garbage out of BABYL a couple of years ago. At one point there was a file in XX's EMACS: directory explaining exactly how to enable that kludge in the EMACS:SITE.INIT file if you were a broken machine like OZ. That file doesn't seem to have made it to ITS. Sigh.  Date: Tue, 23 May 89 21:15:02 EDT From: David Chapman To: BUG-MAIL%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU Message-ID: <599373.890523.ZVONA@AI.AI.MIT.EDU> This % business is really gross. If we have to put up with it for more than a few days, someone should figure out how to install the Babyl patches OZ used to have that ameliorate the lossage somewhat...  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU 23 May 89 20:13:09 EDT From: John Wroclawski Sender: jtw@lcs.mit.edu To: BUG-MAIL%AI.AI.MIT.EDU@MINTAKA.lcs.mit.edu In-reply-to: David Chapman's message of Tue, 23 May 89 20:02:26 EDT <599322.890523.ZVONA@AI.AI.MIT.EDU> Date: Tue, 23 May 89 20:12:25 EDT Message-ID: <8905232012.aa17269@mintaka.lcs.mit.edu> Date: Tue, 23 May 89 20:02:26 EDT From: David Chapman I believe I have removed all offending syntaxes from AI's NAMES file. ... Hmmm, maybe it would be good if the names parser squacked about these syntaxes so people don't inadvertently revert.  Date: Tue, 23 May 89 20:02:26 EDT From: David Chapman To: SRA%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU cc: BUG-MAIL%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU Message-ID: <599322.890523.ZVONA@AI.AI.MIT.EDU> I believe I have removed all offending syntaxes from AI's NAMES file. (This does not include @FILEs.) I fixed everything of the form (foo @bar), (foo bar), and, just cuz it was easy, (file [foo;bar baz]). This compiles ok on AI (on the first try!); let me know if it won't compile with the new fix to COMSAT. If it wins, I'll do MC's (it only took an hour). Maybe we can leave fixing @FILEs to their maintainers. Otherwise, we'd better write a tool.  Date: Tue, 23 May 89 15:22:55 EDT From: Rob Austein Subject: New COMSAT installed To: BUG-COMSAT%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU Message-ID: <599194.890523.SRA@AI.AI.MIT.EDU> I built and installed the interim version of COMSAT that I was talking about. This implements Dave's code for handling unknown hostnames, turns "user%its@relay" addressing back on, and implements the square brackets around dotted decimal IP addresses when used as hostnames (ie, "user@[10.0.0.44]" instead of "user@10.0.0.44", per spec). This does not implement the change to make COMSAT stop using IP addresses from HOSTS3. QMAIL and the existing NAMES files should still work. The RESET code I installed last week (to reboot COMSAT when it runs out of memory) appears to work. It would be trivial to add a SPECIAL-REQ to make use of that same code to reboot COMSAT on demand in the cannonical way, so I may do that at some point. It should be safe for people other than me to work on the COMSAT sources. For anybody who does, note that the last vestiges of dependence on the NETWRK library have been removed from COMSAT; any NETWRK functions that COMSAT needs are in the RESOLV library. NETWRK is no longer even .INSRTed. The "OOOBIN" vs. "BINnnn" debate having been settled, I deleted a lot of old binaries.  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU 23 May 89 13:51:33 EDT Received: from BIGBOOTE.LCS.MIT.EDU by mintaka.lcs.mit.edu id aa10602; 23 May 89 13:46 EDT Received: by bigboote.LCS.MIT.EDU id AA01360; Tue, 23 May 89 13:46:23 EDT Date: Tue, 23 May 89 13:46:23 EDT Message-Id: <8905231746.AA01360@bigboote.LCS.MIT.EDU> From: Rob Austein Sender: sra@bigboote.lcs.mit.edu To: ZVONA@ai.ai.mit.edu Cc: Bug-COMSAT%AI.AI.MIT.EDU@mintaka.lcs.mit.edu In-Reply-To: David Chapman's message of Tue, 23 May 89 13:19:45 EDT <599120.890523.ZVONA@AI.AI.MIT.EDU> Subject: Update on Moon's COMSAT routing hack Date: Tue, 23 May 89 13:19:45 EDT From: David Chapman Fixing NAMES > itself just requires a M(M.M Query Replace$) @$@$$, I think, although there will be a lot of surplus parentheses afterwards. A trivial keyboard macro could remove the parens. Is (foo @bar) the only one that needs to be removed? No, there's also (foo @bar (R-OPTION baz)).  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU 23 May 89 13:40:20 EDT Received: from ai.ai.mit.edu by mintaka.lcs.mit.edu id aa10411; 23 May 89 13:36 EDT Date: Tue, 23 May 89 13:19:45 EDT From: David Chapman Subject: Update on Moon's COMSAT routing hack To: sra@MINTAKA.lcs.mit.edu cc: Moon@stony-brook.scrc.symbolics.com, Bug-COMSAT%AI.AI.MIT.EDU@MINTAKA.lcs.mit.edu In-reply-to: Msg of Tue 23 May 89 13:02:16 EDT from Rob Austein Message-ID: <599120.890523.ZVONA@AI.AI.MIT.EDU> Fixing NAMES > itself just requires a M(M.M Query Replace$) @$@$$, I think, although there will be a lot of surplus parentheses afterwards. A trivial keyboard macro could remove the parens. Is (foo @bar) the only one that needs to be removed?  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU 23 May 89 13:06:09 EDT Received: from BIGBOOTE.LCS.MIT.EDU by mintaka.lcs.mit.edu id aa09855; 23 May 89 13:02 EDT Received: by bigboote.LCS.MIT.EDU id AA01306; Tue, 23 May 89 13:02:16 EDT Date: Tue, 23 May 89 13:02:16 EDT Message-Id: <8905231702.AA01306@bigboote.LCS.MIT.EDU> From: Rob Austein Sender: sra@bigboote.lcs.mit.edu To: Moon@stony-brook.scrc.symbolics.com Cc: Bug-COMSAT%AI.AI.MIT.EDU@lcs.mit.edu In-Reply-To: "David A. Moon"'s message of Tue, 23 May 89 11:52 EDT <19890523155247.0.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM> Subject: Update on Moon's COMSAT routing hack I should preface this by saying that apparently I was more asleep than I thought last night. Massive braindamage.... Date: Tue, 23 May 89 11:52 EDT From: "David A. Moon" First, the code I sent you yesterday was wrong. Here is the correction: Ok, thanks. It would surely be a shame for the :MAIL command in DDT to stop working. It can't be difficult to fix these programs to let Comsat do the host name parsing. After two minutes of looking at QMAIL, it does look like rather a mess, but doable. Of course, if you don't mess up the host table by taking out all the Internet hosts, QMAIL will continue to work for all the hosts whose host table entries are accurate, which means there will be no immediate crisis. Well, sort of. The problem is that QMAIL converts the names to numeric addresses, and if COMSAT has been configured not to use the host table for IP hosts, it can't expand the addreses back into names. Are you sure RMAIL is broken? No. You're right again. I guess I'm confused. I thought the names files had been fixed to remove the spaces in front of the atsigns a long time ago. Maybe there was a reason I've forgotten why it couldn't be done. I think it's just that some humans prefer the other syntax. If it's a big job and volunteers are needed, it's probably easier to fix Comsat to understand the syntax that the NAMES file is already using. Fixing NAMES > itself just requires a M(M.M Query Replace$) @$@$$, I think, although there will be a lot of surplus parentheses afterwards. It's all the @FILEs that will be a pain, although they won't prevent NAMES itself from compiling. I don't know all the KLH macro stuff well enough to attempt your fix. I would actually prefer to cut down the number of syntaxes we claim to support, but I won't stand in the way of anybody who wants to fix the rest of the parsing code. As for the rest of this. I was trying to do several things at once: 1) Turn the "From: user%its.host.mit.edu@relay.host.mit.edu" back on. 2) Implement Dave's stuff. 3) Do what Alan and Penny and I and either JTW or Zvona talked about on Friday to make COMSAT stop using the somewhat questionable IP data in the host tables, without damaging any other program. 4) Give COMSAT configuration options that control whether COMSAT should consider itself IP-live (and Chaos-live, for completeness). The thing that caused all the problems was (3). I've backed out of that for the moment by setting $$DQIN to one (allow COMSAT to see IP host addresses) and am assembling a new COMSAT with that and Dave's most recent stuff. So QMAIL and the current NAMES files should continue to work with that. I would really like to stop using the HOSTS3 tables for IP hosts, so we should keep going with this even if this halfway version works.  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 23 May 89 11:46:45 EDT Received: from STONY-BROOK.SCRC.SYMBOLICS.COM by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 212792; 23 May 89 11:45:47 EDT Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 599332; 23 May 89 11:48:19 EDT Date: Tue, 23 May 89 11:52 EDT From: David A. Moon Subject: Update on Moon's COMSAT routing hack To: Rob Austein cc: BUG-COMSAT%AI.ai.mit.edu@REAGAN.AI.MIT.EDU In-Reply-To: <598937.890523.SRA@AI.AI.MIT.EDU> Message-ID: <19890523155247.0.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM> I'm not sure if I really need to put in these percent signs in the mail I'm sending to you, but for now I don't feel like finding out. First, the code I sent you yesterday was wrong. Here is the correction: RCPH20: MOVE A,E SUBI A,(C) ; A has number of chars in SITE name. SUBI C,1 ; C has number of chars in NAME. ; And B has the BP to the site name. RCPH60: ILDB D,B ; Strip leading spaces CAIN D,40 SOJG A,RCPH60 JUMPLE A,CPOPJ ; Fail if no host name present D7BPT B CALL HMATC ; Call host-name analyze rtn JRST RPCH65 ; Looks like a host name, but not one we know AOS (P) ; Success return RET RPCH65: SKIPN A,DMNGAT ; Send through domain-aware gateway RET ; Just fail if no gateway MOVE C,E ; Length includes the host name JRST POPJ1 ; Success The problem (which was actually already a bug in the old code) occurred if @ or % was the last non-blank character in the address. It could do things like read off the end of the string. This was generally covered up by HMATC with a zero or negative length string taking the failure return, but with my new code it could send a garbage address to the dmngat. Date: Tue, 23 May 89 00:15:05 EDT From: Rob Austein The following things definitely will break and have to be dealt with before we can change over to the new version of COMSAT: 1) QMAIL/QSEND. I think the agreement some time ago was that QMAIL would not be a great loss. Dunno about QSEND. Both could be fixed but it's probably not worth it unless somebody is bored. It would surely be a shame for the :MAIL command in DDT to stop working. It can't be difficult to fix these programs to let Comsat do the host name parsing. After two minutes of looking at QMAIL, it does look like rather a mess, but doable. Of course, if you don't mess up the host table by taking out all the Internet hosts, QMAIL will continue to work for all the hosts whose host table entries are accurate, which means there will be no immediate crisis. 2) RMAIL :EJ. I assume Penny cares about this, dunno who else. It's probably a simple fix. Are you sure RMAIL is broken? My impression is that RMAIL does it right and it's only Babyl that was ever broken in the format of rcpt it sends to Comsat. 3) All the NAMES > files and presumably half of the @FILE indirects. I don't have a good feel for how big a task this is. I do know that even ML's minimal NAMES > file fails to compile (all of the *MSG stuff, for a start). Item (3) is obviously the most critical, since we can't change over until it has been done. I don't have the time to do any of this. Any volunteers? I guess I'm confused. I thought the names files had been fixed to remove the spaces in front of the atsigns a long time ago. Maybe there was a reason I've forgotten why it couldn't be done. If it's a big job and volunteers are needed, it's probably easier to fix Comsat to understand the syntax that the NAMES file is already using. I think what's needed is to change the place after ERCP30 that's commented "; Ugh! definitely an error." to find the A$RNAM and concatenate to that string an @ and the string it just tried to parse (avoiding making two atsigns) and use the DMNGAT as the A$RHST. But here my knowledge of KLH macros runs out, and I don't want to attempt this without access to KLH's documentation and the ability to run Midas and DDT. But I bet it's only a couple of hours' work to fix it.  Date: Tue, 23 May 89 00:15:05 EDT From: Rob Austein Subject: Update on Moon's COMSAT routing hack To: BUG-COMSAT@AI.AI.MIT.EDU Message-ID: <598937.890523.SRA@AI.AI.MIT.EDU> Things weren't quite as bad as I'd thought. It seems that MC and ML had really old versions of BABYL :EJ and BABYLM :EJ, while the newer versions on AI had a patch to change RCPT:(user1 @host) RCPT:(user2 @host (R-OPTION foo)) into RCPT:(user1@host) RCPT:(user2@host (R-OPTION foo)) I installed the new versions on ML and MC, and BABYL worked ok with the new COMSAT. The network mail servers look like they'll be ok too. The following things definitely will break and have to be dealt with before we can change over to the new version of COMSAT: 1) QMAIL/QSEND. I think the agreement some time ago was that QMAIL would not be a great loss. Dunno about QSEND. Both could be fixed but it's probably not worth it unless somebody is bored. 2) RMAIL :EJ. I assume Penny cares about this, dunno who else. It's probably a simple fix. 3) All the NAMES > files and presumably half of the @FILE indirects. I don't have a good feel for how big a task this is. I do know that even ML's minimal NAMES > file fails to compile (all of the *MSG stuff, for a start). Item (3) is obviously the most critical, since we can't change over until it has been done. I don't have the time to do any of this. Any volunteers? Obviously it would not be a good idea for somebody to compile and install a new COMSAT at this time. I -think- it would work to flip the switch $$DQIN back to 1 (to tell the RESOLV library that it's allowed to return IP addresses), in case something bad happens and I'm not around.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 22 May 89 20:46:23 EDT Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 22 May 89 20:46:00 EDT Received: from BIGBOOTE.LCS.MIT.EDU by mintaka.lcs.mit.edu id aa19908; 22 May 89 20:41 EDT Received: by bigboote.LCS.MIT.EDU id AA00316; Mon, 22 May 89 20:40:30 EDT Date: Mon, 22 May 89 20:40:30 EDT Message-Id: <8905230040.AA00316@bigboote.LCS.MIT.EDU> From: Rob Austein Sender: sra@bigboote.lcs.mit.edu To: Moon@stony-brook.scrc.symbolics.com Cc: Bug-COMSAT@mc.lcs.mit.edu In-Reply-To: Rob Austein's message of Mon, 22 May 89 17:20:52 EDT <8905222120.AA05272@bigboote.LCS.MIT.EDU> Subject: There are no longer any ITS machines on the Internet Date: Mon, 22 May 89 17:20:52 EDT From: Rob Austein Date: Mon, 22 May 89 14:29 EDT From: "David A. Moon" This won't make it work for all the weirdass NAMES file syntaxes, but any host named in the names file ought to be left in the host table, in my opinion, since those should only be nearby and friendly hosts. This patch should make it work for the basic name@host syntax of the NAMES file as well as for incoming mail. It's probably possible to patch the other places that look up host names too, but it looks like there is a lot of them. I have no problem with punting all the weirdo address formats. Well, I implemented this, ran it on ML in XPER mode, and everything broke. Seems BABYL uses "RCPT:(user @host)" format, QMAIL is hopeless (big surprise), I haven't checked RMAIL, FTPS, or CHAOS MAIL yet, but it's not looking good for the home team. On the other hand, we could just take this as a chance to bring those programs into the 1980s while there's still time....  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 22 May 89 17:21:03 EDT Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by MC.LCS.MIT.EDU 22 May 89 17:20:38 EDT Received: from BIGBOOTE.LCS.MIT.EDU by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 212403; 22 May 89 17:20:05 EDT Received: by bigboote.LCS.MIT.EDU id AA05272; Mon, 22 May 89 17:20:52 EDT Date: Mon, 22 May 89 17:20:52 EDT Message-Id: <8905222120.AA05272@bigboote.LCS.MIT.EDU> From: Rob Austein Sender: sra@bigboote.LCS.MIT.EDU To: Moon@stony-brook.scrc.symbolics.com Cc: Bug-COMSAT%mc.lcs.mit.edu@reagan.ai.mit.edu In-Reply-To: "David A. Moon"'s message of Mon, 22 May 89 14:29 EDT <19890522182928.0.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM> Subject: There are no longer any ITS machines on the Internet Date: Mon, 22 May 89 14:29 EDT From: "David A. Moon" Here is what I had in mind.... Looks good to me. I may try installing it tonight if I can stay awake long enough. This won't make it work for all the weirdass NAMES file syntaxes, but any host named in the names file ought to be left in the host table, in my opinion, since those should only be nearby and friendly hosts. This patch should make it work for the basic name@host syntax of the NAMES file as well as for incoming mail. It's probably possible to patch the other places that look up host names too, but it looks like there is a lot of them. I have no problem with punting all the weirdo address formats. Per conversation with Alan et al on Friday, I think I should modify the interface to the DQ: device not to look for IP addresses, only Chaosnet. We can change this back if it ever becomes desirable.  Received: from MORRISON.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 22 MAY 89 15:14:35 EDT Date: Mon, 22 May 89 15:15 EDT From: John C. Mallery Subject: mail delay between reagan and AI To: ZVONA@AI.AI.MIT.EDU cc: BUG-MAIL@AI.AI.MIT.EDU, postmaster@REAGAN.AI.MIT.EDU In-Reply-To: <597518.890519.ZVONA@AI.AI.MIT.EDU> Message-ID: <19890522191538.4.JCMA@MORRISON.AI.MIT.EDU> Date: Fri, 19 May 89 14:18:08 EDT From: David Chapman From the headers of this, Reagan sat on it for five days. Reagan's background process hung for a while due to implementational bugs.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 22 May 89 14:28:51 EDT Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by MC.LCS.MIT.EDU 22 May 89 14:23:33 EDT Received: from STONY-BROOK.SCRC.SYMBOLICS.COM by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 212201; 22 May 89 14:22:59 EDT Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 598785; 22 May 89 14:25:15 EDT Date: Mon, 22 May 89 14:29 EDT From: David A. Moon Subject: There are no longer any ITS machines on the Internet To: Rob Austein cc: Bug-COMSAT%mc.lcs.mit.edu@REAGAN.AI.MIT.EDU In-Reply-To: <8905221659.AA05089@bigboote.LCS.MIT.EDU> Message-ID: <19890522182928.0.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM> Date: Mon, 22 May 89 12:59:53 EDT From: Rob Austein Date: Fri, 19 May 89 17:23 EDT From: "David A. Moon" I can't Supdup in and patch Comsat to parse user@never-heard.of.it.edu.com.gov.fr as "user@never-heard.of.it.edu.com.gov.fr"@mintaka.lcs.mit.edu instead of the way it parses it now, which is "user@never-heard.of.it.edu.com.gov.fr"@ This of course would allow sending mail to hosts that aren't in the host table, and taking advantage of Mintaka's domain resolver. Hmm. I was looking at the COMSAT sources on Saturday trying to figure out how to do this. It looked non-trivial. Am I missing something? Here is what I had in mind. I haven't tested it. RCPH60: ILDB D,B ; Strip leading spaces CAIN D,40 SOJA A,RCPH60 D7BPT B CALL HMATC ; Call host-name analyze rtn JRST RPCH65 ; Looks like a host name, but not one we know AOS (P) ; Success return RET RPCH65: SKIPN A,DMNGAT ; Send through domain-aware gateway RET ; Just fail if no gateway MOVE C,E ; Length includes the host name JRST POPJ1 ; Success This won't make it work for all the weirdass NAMES file syntaxes, but any host named in the names file ought to be left in the host table, in my opinion, since those should only be nearby and friendly hosts. This patch should make it work for the basic name@host syntax of the NAMES file as well as for incoming mail. It's probably possible to patch the other places that look up host names too, but it looks like there is a lot of them.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 22 May 89 13:13:04 EDT Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by MC.LCS.MIT.EDU 22 May 89 13:12:31 EDT Received: from STONY-BROOK.SCRC.SYMBOLICS.COM by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 212154; 22 May 89 13:11:56 EDT Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 598736; 22 May 89 13:14:22 EDT Date: Mon, 22 May 89 13:18 EDT From: David A. Moon Subject: There are no longer any ITS machines on the Internet To: Rob Austein cc: Bug-COMSAT%mc.lcs.mit.edu@reagan.ai.mit.edu In-Reply-To: <8905221659.AA05089@bigboote.LCS.MIT.EDU> Message-ID: <19890522171842.6.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM> Date: Mon, 22 May 89 12:59:53 EDT From: Rob Austein Date: Fri, 19 May 89 17:23 EDT From: "David A. Moon" I can't Supdup in and patch Comsat to parse user@never-heard.of.it.edu.com.gov.fr as "user@never-heard.of.it.edu.com.gov.fr"@mintaka.lcs.mit.edu instead of the way it parses it now, which is "user@never-heard.of.it.edu.com.gov.fr"@ This of course would allow sending mail to hosts that aren't in the host table, and taking advantage of Mintaka's domain resolver. Hmm. I was looking at the COMSAT sources on Saturday trying to figure out how to do this. It looked non-trivial. Am I missing something? I don't know, since I don't have access to the Comsat sources. (Actually I bet there is a tape in my office somewhere with an old set of Comsat sources among other things, but it would be too much trouble to read it since I'd have to write a program.) My memory was that all that is necessary is to add a new variable which is the address of the host to use, where currently it uses a constant zero in this case. I would imagine that we could get you an account on some LCS unix box (odd that LCS should end up supporting Chaosnet after the AI lab has given up on it) that you can use to get to the ITS machines. If necessary I can give you an account on my dinky VS2000 although you'd have to promise not to type very fast.... This seems unlikely to work well enough to be usable. It would give me grossly slow Supdup access, or maybe only grossly slow Telnet access, and no file access at all. Before doing that I would make local copies of the files indirectly through Reagan, which is actually quite easy to do and I've done it in the past with other balky machines that have poor network support that can connect to some places but not my place.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 22 May 89 13:10:07 EDT Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 22 May 89 13:05:49 EDT Received: from BIGBOOTE.LCS.MIT.EDU by mintaka.lcs.mit.edu id aa28492; 22 May 89 13:00 EDT Received: by bigboote.LCS.MIT.EDU id AA05089; Mon, 22 May 89 12:59:53 EDT Date: Mon, 22 May 89 12:59:53 EDT Message-Id: <8905221659.AA05089@bigboote.LCS.MIT.EDU> From: Rob Austein Sender: sra@bigboote.lcs.mit.edu To: Moon@stony-brook.scrc.symbolics.com Cc: Bug-COMSAT@mc.lcs.mit.edu In-Reply-To: "David A. Moon"'s message of Fri, 19 May 89 17:23 EDT <19890519212322.2.MOON@EUPHRATES.SCRC.Symbolics.COM> Subject: There are no longer any ITS machines on the Internet Date: Fri, 19 May 89 17:23 EDT From: "David A. Moon" I can't Supdup in and patch Comsat to parse user@never-heard.of.it.edu.com.gov.fr as "user@never-heard.of.it.edu.com.gov.fr"@mintaka.lcs.mit.edu instead of the way it parses it now, which is "user@never-heard.of.it.edu.com.gov.fr"@ This of course would allow sending mail to hosts that aren't in the host table, and taking advantage of Mintaka's domain resolver. Hmm. I was looking at the COMSAT sources on Saturday trying to figure out how to do this. It looked non-trivial. Am I missing something? I would imagine that we could get you an account on some LCS unix box (odd that LCS should end up supporting Chaosnet after the AI lab has given up on it) that you can use to get to the ITS machines. If necessary I can give you an account on my dinky VS2000 although you'd have to promise not to type very fast....  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 22 May 89 12:28:54 EDT Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 22 May 89 12:23:52 EDT Received: from STONY-BROOK.SCRC.SYMBOLICS.COM by mintaka.lcs.mit.edu id aa12898; 22 May 89 12:16 EDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 597992; 19 May 89 14:55:27 EDT Date: Fri, 19 May 89 14:55 EDT From: "David A. Moon" Subject: There are no longer any ITS machines on the Internet To: jtw@lcs.mit.edu cc: ALAN@MC.lcs.mit.edu, BUG-MAIL@MC.lcs.mit.edu, POSTMASTER@MC.lcs.mit.edu, postmaster@AI.ai.mit.edu In-Reply-To: <8905191359.aa06846@mintaka.lcs.mit.edu> Message-ID: <19890519185529.8.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Fri, 19 May 89 13:59:20 EDT From: jtw@lcs.mit.edu Date: Fri, 19 May 89 11:17 EDT From: "David A. Moon" Supersedes: <19890519151557.9.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Thu, 18 May 89 22:21:00 EDT From: jtw@lcs.mit.edu Just so we all know.. Ooutgoing mail from both MC and AI is going through MINTAKA, as Alan said. I think this will result in substantially -better- outgoing mail service than in the recent past, since Mintaka's mailer has a working domain resolver. But Comsat still has to resolve the host name before it knows that sending it through Mintaka is the right delivery path, so Mintaka's domain resolver isn't going to help very much. Not so; it simply does what ML has been doing for a while, which is dump the message to Mintaka iff the recipient isn't on the chaosnet. In fact there's no particularly good reason not to forward all messages through mintaka, if it would simplify things. One of us is confused. My belief is that Comsat always parses the host name (domain name) string into a 36-bit number representing a network address before it does anything else about delivering a message. If it's been changed to deliver to all recipients with unrecognized host names through the tcp gateway, instead of rejecting the message or (worse) parsing the address as some alternate syntax or ignoring the host name entirely, good. Mail into AI goes through Reagan. Mail into MC goes through Mintaka. This is invisible to remote machines which grok the domain system and MX records. Some other sites may have to do the foo%MC@LCS.MIT.EDU bit. I think Comsat is or will shortly be set up to say that in From: fields so replying should work normally. Comsat does not generate the From field for most programs that generate outgoing mail. Oh, OK, Reply-to:, whatever. Again, ML has been doing this forever. Comsat does not alter the headers of any message for which it does not generate the headers itself, as far as I am aware. I don't think ML Comsat has been doing what you say. Maybe it's a hack in Babyl. Mr. SRA tells me that this has been turned off recently, which is a mistake, since there are still a remarkably large number of machines that don't quite grok MX records. Like, say, the standard version of the SUN system, and most of the Milnet. I think a better approach would be to finish the Interlan driver. If we had an interlan driver and a TCP with even minimally reasonable algorithms (like not using a fixed 4-second retransmission interval), I would say that the ideal situation would be to accept incoming mail directly and forward all outgoing mail through a resolver-based machine. The world is now at the point where the "host tables" are not just incomplete, they are often wrong. Until/unless we get a resolver and MX support for comsat, we are far better off doing outgoing delivery this way, elegance notwithstanding. (Trust me. I'm from the government, and I'm here to help you...)  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 22 May 89 12:28:14 EDT Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 22 May 89 12:17:37 EDT Received: from VALLECITO.SCRC.SYMBOLICS.COM by mintaka.lcs.mit.edu id aa11396; 22 May 89 12:15 EDT Received: from EUPHRATES.SCRC.Symbolics.COM by VALLECITO.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 292065; Fri 19-May-89 17:24:20 EDT Date: Fri, 19 May 89 17:23 EDT From: "David A. Moon" Subject: There are no longer any ITS machines on the Internet To: "Pandora B. Berman" cc: jtw@MINTAKA.lcs.mit.edu, BUG-MAIL@mc.lcs.mit.edu In-Reply-To: <597621.890519.CENT@AI.AI.MIT.EDU> Message-ID: <19890519212322.2.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Fri, 19 May 89 16:54:41 EDT From: "Pandora B. Berman" john, there are other things in the world beside mail. we can't use the printers, except for LP8:, because the others are spooled from suns now. we can't supdup out and other ITS users can't supdup in. Like me. I can't Supdup in and patch Comsat to parse user@never-heard.of.it.edu.com.gov.fr as "user@never-heard.of.it.edu.com.gov.fr"@mintaka.lcs.mit.edu instead of the way it parses it now, which is "user@never-heard.of.it.edu.com.gov.fr"@ This of course would allow sending mail to hosts that aren't in the host table, and taking advantage of Mintaka's domain resolver.  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 21 May 89 18:17:37 EDT Received: from BIGBOOTE.LCS.MIT.EDU by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 211824; 21 May 89 18:17:02 EDT Received: by bigboote.LCS.MIT.EDU id AA04053; Sun, 21 May 89 18:17:55 EDT Date: Sun, 21 May 89 18:17:55 EDT Message-Id: <8905212217.AA04053@bigboote.LCS.MIT.EDU> From: Rob Austein Sender: sra@bigboote.LCS.MIT.EDU To: ZVONA@ai.ai.mit.edu Cc: BUG-MAIL@ai.ai.mit.edu, postmaster@mintaka.lcs.mit.edu In-Reply-To: David Chapman's message of Sun, 21 May 89 17:38:52 EDT <598166.890521.ZVONA@AI.AI.MIT.EDU> Subject: Mintaka sits on mail for four days (?) No, Mintaka really did sit on MC's mail for a while. Specificly, there was a window between when it started receiving MC's mail and when JTW and I finished the MMDF Chaos/SMTP channel. The mail received during that window had already been enqueued in the TCP/SMTP channel queue, and it was a few days before we had the time to develop a tool that would safely move those messages into the Chaos/SMTP channel queue. So the observed result is that about 24 hours worth of mail was in suspended animation for a few days.  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU 21 May 89 18:00:31 EDT From: John Wroclawski Sender: jtw@lcs.mit.edu To: ZVONA@AI.ai.mit.edu CC: BUG-MAIL@AI.ai.mit.edu In-reply-to: David Chapman's message of Sun, 21 May 89 17:38:52 EDT <598166.890521.ZVONA@AI.AI.MIT.EDU> Subject: Mintaka sits on mail for four days (?) Date: Sun, 21 May 89 17:57:24 EDT Message-ID: <8905211757.aa06632@mintaka.lcs.mit.edu> Date: Sun, 21 May 89 17:38:52 EDT From: David Chapman Not obvious to me whether this is mintaka's fault or mc's. Reminds me of a similar incident I reported recently involving reagan and ai, which makes me wonder if this isn't some sort of ITS bug. Actually, this was my fault. I noticed and fixed the problem earlier today, but there is still one bleep of a lot of MC mail sitting on mintaka. It'll show up as fast as MC will eat it. Sorrrrrryyyyyyyy..... -john  Date: Sun, 21 May 89 17:38:52 EDT From: David Chapman Subject: Mintaka sits on mail for four days (?) To: BUG-MAIL@AI.AI.MIT.EDU, postmaster@MINTAKA.LCS.MIT.EDU Message-ID: <598166.890521.ZVONA@AI.AI.MIT.EDU> Not obvious to me whether this is mintaka's fault or mc's. Reminds me of a similar incident I reported recently involving reagan and ai, which makes me wonder if this isn't some sort of ITS bug. Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 21 May 89 17:10:30 EDT Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 May 89 16:14:21 EDT Received: from ucscg.UCSC.EDU by mintaka.lcs.mit.edu id aa14596; 17 May 89 19:57 EDT Received: by ucscg.UCSC.EDU (5.61/1.34) id AA08747; Wed, 17 May 89 16:58:37 -0700 Date: Wed, 17 May 89 16:58:37 -0700 From: "Jennifer Brooks, Polymorphous Pervert" Message-Id: <8905172358.AA08747@ucscg.UCSC.EDU> To: sexual-politics@mc.lcs.mit.edu Subject: Re: Strategies... on the other hand, i can tell you from personal experience that (to be a bottom) and lead a workshop on s/m is NOT a good way to pick up boys *or* girls! (it's a great way to make friends, and you get lots of bottomlings who are nervous and want to talk it thru, but i guess tops get intimidated....p'raps they think that, since i talk about heavy s/m, that i'm way out of *their* league, and they never bother. Consider this a public service announcement for all heavy bottoms out there: Heavy s/m people often enjoy light s/m also.) (Not to mention really good ordinary sex. I like to call it "french-vanilla".) Jennifer  Date: Sun, 21 May 89 17:28:05 EDT From: David Chapman Subject: Mintaka sits on mail for four days (?) To: BUG-MAIL@AI.AI.MIT.EDU, postmaster@MINTAKA.LCS.MIT.EDU Message-ID: <598165.890521.ZVONA@AI.AI.MIT.EDU> Not obvious to me whether this is mintaka's fault or mc's. Reminds me of a similar incident I reported recently involving reagan and ai, which makes me wonder if this isn't some sort of ITS bug. Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 21 May 89 17:10:30 EDT Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 May 89 16:14:21 EDT Received: from ucscg.UCSC.EDU by mintaka.lcs.mit.edu id aa14596; 17 May 89 19:57 EDT Received: by ucscg.UCSC.EDU (5.61/1.34) id AA08747; Wed, 17 May 89 16:58:37 -0700 Date: Wed, 17 May 89 16:58:37 -0700 From: "Jennifer Brooks, Polymorphous Pervert" Message-Id: <8905172358.AA08747@ucscg.UCSC.EDU> To: sexual-politics@mc.lcs.mit.edu Subject: Re: Strategies... on the other hand, i can tell you from personal experience that (to be a bottom) and lead a workshop on s/m is NOT a good way to pick up boys *or* girls! (it's a great way to make friends, and you get lots of bottomlings who are nervous and want to talk it thru, but i guess tops get intimidated....p'raps they think that, since i talk about heavy s/m, that i'm way out of *their* league, and they never bother. Consider this a public service announcement for all heavy bottoms out there: Heavy s/m people often enjoy light s/m also.) (Not to mention really good ordinary sex. I like to call it "french-vanilla".) Jennifer  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 19 May 89 18:11:48 EDT Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 19 May 89 17:56:27 EDT From: jtw@lcs.mit.edu Sender: jtw@lcs.mit.edu To: Moon@stony-brook.scrc.symbolics.com CC: ALAN@mc.lcs.mit.edu, BUG-MAIL@mc.lcs.mit.edu, POSTMASTER@mc.lcs.mit.edu, postmaster@AI.ai.mit.edu In-reply-to: "David A. Moon"'s message of Fri, 19 May 89 11:17 EDT <19890519151712.0.MOON@EUPHRATES.SCRC.Symbolics.COM> Subject: There are no longer any ITS machines on the Internet Date: Fri, 19 May 89 13:59:20 EDT Message-ID: <8905191359.aa06846@mintaka.lcs.mit.edu> Date: Fri, 19 May 89 11:17 EDT From: "David A. Moon" Supersedes: <19890519151557.9.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Thu, 18 May 89 22:21:00 EDT From: jtw@lcs.mit.edu Just so we all know.. Ooutgoing mail from both MC and AI is going through MINTAKA, as Alan said. I think this will result in substantially -better- outgoing mail service than in the recent past, since Mintaka's mailer has a working domain resolver. But Comsat still has to resolve the host name before it knows that sending it through Mintaka is the right delivery path, so Mintaka's domain resolver isn't going to help very much. Not so; it simply does what ML has been doing for a while, which is dump the message to Mintaka iff the recipient isn't on the chaosnet. In fact there's no particularly good reason not to forward all messages through mintaka, if it would simplify things. Mail into AI goes through Reagan. Mail into MC goes through Mintaka. This is invisible to remote machines which grok the domain system and MX records. Some other sites may have to do the foo%MC@LCS.MIT.EDU bit. I think Comsat is or will shortly be set up to say that in From: fields so replying should work normally. Comsat does not generate the From field for most programs that generate outgoing mail. Oh, OK, Reply-to:, whatever. Again, ML has been doing this forever. Mr. SRA tells me that this has been turned off recently, which is a mistake, since there are still a remarkably large number of machines that don't quite grok MX records. Like, say, the standard version of the SUN system, and most of the Milnet. I think a better approach would be to finish the Interlan driver. If we had an interlan driver and a TCP with even minimally reasonable algorithms (like not using a fixed 4-second retransmission interval), I would say that the ideal situation would be to accept incoming mail directly and forward all outgoing mail through a resolver-based machine. The world is now at the point where the "host tables" are not just incomplete, they are often wrong. Until/unless we get a resolver and MX support for comsat, we are far better off doing outgoing delivery this way, elegance notwithstanding. (Trust me. I'm from the government, and I'm here to help you...)  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 19 May 89 16:56:10 EDT Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 19 May 89 16:57:04 EDT Date: Fri, 19 May 89 16:54:41 EDT From: "Pandora B. Berman" Subject: There are no longer any ITS machines on the Internet To: jtw@MINTAKA.LCS.MIT.EDU cc: BUG-MAIL@MC.LCS.MIT.EDU Message-ID: <597621.890519.CENT@AI.AI.MIT.EDU> Date: Fri, 19 May 89 14:55 EDT From: David A. Moon Subject: There are no longer any ITS machines on the Internet To: jtw@lcs.mit.edu cc: ALAN@MC.LCS.MIT.EDU, BUG-MAIL@MC.LCS.MIT.EDU, POSTMASTER@MC.LCS.MIT.EDU, postmaster@AI.AI.MIT.EDU Date: Fri, 19 May 89 13:59:20 EDT From: jtw@lcs.mit.edu Not so; it simply does what ML has been doing for a while, which is dump the message to Mintaka iff the recipient isn't on the chaosnet. In fact there's no particularly good reason not to forward all messages through mintaka, if it would simplify things. One of us is confused. My belief is that Comsat always parses the host name (domain name) string into a 36-bit number representing a network address before it does anything else about delivering a message. yup. exhibit A: msg sent on ML from Alan to himself ---------- 000617 InReq: 1 > 1; SPECS:{J:ALAN}{ALAN}{CLAIMS-TO-BE:ALAN}{TL=16.} ID=<9707.890428.ALAN@ML.AI.MIT.EDU> EXP->ALAN@40700003133::=(ALAN@40700003130) 000619 ICP->AI.AI.MIT.EDU (CHAOS-SMTP) 000623 TO->ALAN ---------- exhibit B: msg sent on ML from Maeda to a host in the host table ---------- 170403 InReq: 1 > 1; SPECS:{J:MAIL}{MAEDA}{CLAIMS-TO-BE:maeda@ai}{TL=51.} ID=<9720.890428.MAEDA@ML.AI.MIT.EDU> EXP->weihl@2206400143 170408 ICP->PHOTON.LCS.MIT.EDU (CHAOS-SMTP via MINTAKA.LCS.MIT.EDU) 170415 TO->weihl ---------- If it's been changed to deliver to all recipients with unrecognized host names through the tcp gateway, instead of rejecting the message or (worse) parsing the address as some alternate syntax or ignoring the host name entirely, good. nope. msg sent by me this afternoon to a host not in AI's host table: error rec'd: ---------- Date: Fri, 19 May 89 16:09:36 EDT From: Communications Satellite Subject: Msg of Friday, 19 May 1989 16:09-EDT To: CENT@AI.AI.MIT.EDU Message-ID: <597582.890519@AI.AI.MIT.EDU> ============ A copy of your message is being returned, because: ============ "CRF@GNV.IFAS.UFL.EDU" at AI.AI.MIT.EDU is an unknown recipient. ============ Failed message follows: ============ Date: Fri, 19 May 89 16:09:34 EDT From: "Pandora B. Berman" Subject: DIG #338 To: "CRF@GNV.IFAS.UFL.EDU"@AI.AI.MIT.EDU cc: groff%csse32.dec.com@DECUAC.DEC.COM Message-ID: <597581.890519.CENT@AI.AI.MIT.EDU> [text of msg omitted] ---------- and record in stats file: ---------- 160931 InReq: 15 > 1; SPECS:{J:RMAIL}{CENT}{CLAIMS-TO-BE:CENT}{TL=1657.} ID=<597581.890519.CENT@AI.AI.MIT.EDU> EXP->CRF@GNV.IFAS.UFL.EDU@40700003130::={IGNORED},groff%csse32.dec.com@30001353001 160936 CMSG ID=<597582.890519@AI.AI.MIT.EDU> EXP->CENT@40700003130 160937 Local->AI.AI.MIT.EDU 160937 TO->CENT 160938 ICP->DECUAC.DEC.COM (CHAOS-SMTP via MINTAKA.LCS.MIT.EDU) 160942 TO->groff%csse32.dec.com ---------- Oh, OK, Reply-to:, whatever. Again, ML has been doing this forever. Comsat does not alter the headers of any message for which it does not generate the headers itself, as far as I am aware. I don't think ML Comsat has been doing what you say. Maybe it's a hack in Babyl. dave looks right. entire headers rec'd included below. exhibit A: msg generated by MONTHLY job ---------- Received: from ML.AI.MIT.EDU (CHAOS 3133) by AI.AI.MIT.EDU 1 May 89 00:11:06 EDT Date: Mon, 1 May 89 00:06:44 EDT From: Puff the Magic Dragon Subject: That Time Again To: MAGIC-DRAGON-KEEPER@ML.AI.MIT.EDU Message-ID: <9750.890501.PFTHMG-DRAGON@ML.AI.MIT.EDU> Don't forget to print out the DSK:DRAGON;APRIL REPORT file and give it to the appropriate people. - puff ---------- exhibit B: msg from SRA when he happend to be using ML. can't tell whether this was mail from inside EMACS, but probably, given the length and content (entire msg is in my RMAIL). ---------- Received: from ML.AI.MIT.EDU (CHAOS 3133) by AI.AI.MIT.EDU 2 May 89 02:27:22 EDT Date: Tue, 2 May 89 02:20:43 EDT From: Rob Austein Subject: Hamlet for the musicly inclined To: CENT@ML.AI.MIT.EDU Message-ID: <9763.890502.SRA@ML.AI.MIT.EDU> I found this on the net (usenet rec.music.folk, to be precise) [remainder of text omitted] ---------- alan just looked at these and said he took the %ML@MC stuff out of ML's COMSAT over a month ago, at which time he sent large msgs to BUG-MAIL to announce that fact. I think a better approach would be to finish the Interlan driver. If we had an interlan driver and a TCP with even minimally reasonable algorithms (like not using a fixed 4-second retransmission interval), I would say that the ideal situation would be to accept incoming mail directly and forward all outgoing mail through a resolver-based machine. The world is now at the point where the "host tables" are not just incomplete, they are often wrong. Until/unless we get a resolver and MX support for comsat, we are far better off doing outgoing delivery this way, elegance notwithstanding. (Trust me. I'm from the government, and I'm here to help you...) john, there are other things in the world beside mail. we can't use the printers, except for LP8:, because the others are spooled from suns now. we can't supdup out and other ITS users can't supdup in. we have been given to understand that all such matters would return to at least the previous level of service when the Interlan code was installed..  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 19 May 89 15:38:16 EDT Received: from BIGBOOTE.LCS.MIT.EDU by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 211282; 19 May 89 15:37:19 EDT Received: by bigboote.LCS.MIT.EDU id AA02244; Fri, 19 May 89 15:37:24 EDT Date: Fri, 19 May 89 15:37:24 EDT Message-Id: <8905191937.AA02244@bigboote.LCS.MIT.EDU> From: Rob Austein Sender: sra@bigboote.LCS.MIT.EDU To: Moon@stony-brook.scrc.symbolics.com, jtw@lcs.mit.edu Cc: Bug-COMSAT@ai.ai.mit.edu, Postmaster@ai.ai.mit.edu In-Reply-To: "David A. Moon"'s message of Fri, 19 May 89 11:17 EDT <19890519151712.0.MOON@EUPHRATES.SCRC.Symbolics.COM> Subject: There are no longer any ITS machines on the Internet Date: Fri, 19 May 89 11:17 EDT From: "David A. Moon" Date: Thu, 18 May 89 22:21:00 EDT From: jtw@lcs.mit.edu Just so we all know.. Ooutgoing mail from both MC and AI is going through MINTAKA, as Alan said. I think this will result in substantially -better- outgoing mail service than in the recent past, since Mintaka's mailer has a working domain resolver. But Comsat still has to resolve the host name before it knows that sending it through Mintaka is the right delivery path, so Mintaka's domain resolver isn't going to help very much. Right. The real problem with both John's idea and Zvona's idea (of just zapping everything we don't know how to send to directly off to Mintaka) is that we don't have any way to store names of hosts that are not in the host table (ie, presently, the host name strings are still stored in SYSBIN;HOSTS3 > and extracted when needed; all that's stored in the COMSAT lists is the 36 bit host number). If we could always count on being able to immediately send all mail to Mintaka, this wouldn't matter (since we could just get the host names out of the MAIL > file) but we can't, so we can't. The obvious sollution to this is to create yet another LSE structuure in COMSAT's databases that's full of host names, and change all instances of 36 bit host numbers to pointers into that LSE. Which is something we've been meaning to do for years but have not done due to an accute shortage of suicidal fools\s\l\o\o\f\ \l\a\d\i\c\i\u\s heros to do the job. Mail into AI goes through Reagan. Mail into MC goes through Mintaka. This is invisible to remote machines which grok the domain system and MX records. Some other sites may have to do the foo%MC@LCS.MIT.EDU bit. I think Comsat is or will shortly be set up to say that in From: fields so replying should work normally. Comsat does not generate the From field for most programs that generate outgoing mail. Yes and no. You're right about most programs, but all the EMACS based mail stuff lets COMSAT generate the From: headers, and that's what most people use most of the time. The code to do the "%" stuff is currently disabled on the theory that everybody (except us) uses domain MX RRs, but John gave me a long list of systems that he knows are broken and still don't use the domain system, so we had probably better turn it back on. I think a better approach would be to finish the Interlan driver. Again, yes and no. It certainly would be a good thing, but it doesn't solve the problem with COMSAT not knowing how to send mail to a huge (and growing) portion of the net.  Date: Fri, 19 May 89 14:18:08 EDT From: David Chapman Subject: mail delay between reagan and AI To: BUG-MAIL@AI.AI.MIT.EDU, postmaster@REAGAN.AI.MIT.EDU cc: ZVONA@AI.AI.MIT.EDU, sibun@CS.UMASS.EDU Message-ID: <597518.890519.ZVONA@AI.AI.MIT.EDU> From the headers of this, Reagan sat on it for five days. Maybe mail to AI should be going through mintaka rather than Reagan? (Maybe Someone could get the interlan code working?) Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 17 May 89 14:44:40 EDT Received: from crash.cs.umass.edu (INTERNET|128.119.40.235) by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 207642; 12 May 89 15:39:56 EDT Received: from vax9.cs.umass.edu by crash.cs.umass.edu (5.59/Ultrix2.0-B) id AA27572; Fri, 12 May 89 13:14:05 edt Message-Id: <8905121714.AA27572@crash.cs.umass.edu> Date: Fri, 12 May 89 13:13 EST From: Penni To: zvona@ai.ai.mit.EDU X-Vms-To: ZVONA,SIBUN Have a fun and interesting weekend....;-}  Date: Fri, 19 May 89 13:37:13 EDT From: Rob Austein Subject: **:.MAIL.;COMSAT BIN8 To: BUG-COMSAT@AI.AI.MIT.EDU Message-ID: <597496.890519.SRA@AI.AI.MIT.EDU> I installed COMSAT BIN8, which has a couple of bugfixes to the RESET: routine which attempts to reboot COMSAT when it runs out of memory. The code would be as lot simpler if the RELOAD SYSCAL could take the name of the file to reboot as arguments, but it doesn't so it isn't.  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 19 May 89 13:08:17 EDT Received: from BIGBOOTE.LCS.MIT.EDU by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 211172; 19 May 89 13:07:12 EDT Received: by bigboote.LCS.MIT.EDU id AA02006; Fri, 19 May 89 09:40:54 EDT Date: Fri, 19 May 89 09:40:54 EDT Message-Id: <8905191340.AA02006@bigboote.LCS.MIT.EDU> From: Rob Austein Sender: sra@bigboote.LCS.MIT.EDU To: ALAN@ai.ai.mit.edu Cc: BUG-MAIL@ai.ai.mit.edu In-Reply-To: Alan Bawden's message of Fri, 19 May 89 01:27:14 EDT <597336.890519.ALAN@AI.AI.MIT.EDU> Subject: never-seen-before COMSAT bug It means that the code to detect when COMSAT should reboot itself because it has run out of address space works, but the code to actually reboot does not. The error (in the true tradition of FORTRAN and assembly language) was a missing comma that turned REPEAT 20,[ ? .CLOSE .RPCNT, ] ; Close channels with sledgehammer into REPEAT 20,[ ? .CLOSE .RPCNT ] ; Close channels with sledgehammer New COMSAT assembling on AI, I'll check it later this morning.  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 19 May 89 11:13:04 EDT Received: from STONY-BROOK.SCRC.SYMBOLICS.COM by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 211097; 19 May 89 11:12:15 EDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 597755; 19 May 89 11:13:38 EDT Date: Fri, 19 May 89 11:13 EDT From: David A. Moon Subject: never-seen-before COMSAT bug To: Alan Bawden cc: BUG-MAIL@AI.AI.MIT.EDU In-Reply-To: <597336.890519.ALAN@AI.AI.MIT.EDU> Message-ID: <19890519151339.8.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Fri, 19 May 89 01:27:14 EDT From: Alan Bawden What the heck is this? I can't make head or tail out of the corpse. Probably a bug in the code SRA just added for rebooting when a small Inreq file doesn't fit in memory, which Rob said he hadn't been able to figure out how to test. I -think- that the error it got was OVER IOPOP, which might be related to the fact that the stack pointer was left pointing several locations -below- the base of the stack! 184928 InReq: 1 > 1; 184928 Note: Inreq file too big! Length=5+376 184928 Note: RESET called from 35041, reloading. 184929 ===> BUG: FATAL ERROR <=== Date: 05/18/89 18:49:29 Autopsy from 0 Preserved from 21570 Last UUO = 007000,,016700 at 14707 184929 INT. FROM 31133 .JPC/0 Registers: 0/ 020000,,000400 1/ 000000,,000000 2/ 000000,,000005 3/ 131262,,410551 4/ 000000,,000000 5/ 000000,,000000 6/ 000000,,000000 7/ 000000,,000000 10/ 040700,,015044 11/ 000000,,614400 12/ 000000,,000017 13/ 260740,,010634 14/ 000000,,000000 15/ 000000,,000004 16/ 000000,,000000 17/ 777025,,000647 184930 Input req file MAILIN 1 renamed to BADREQ 1 184943 Job dumped to CRASH;BURNUP 1  Date: Fri, 19 May 89 01:27:14 EDT From: Alan Bawden Subject: never-seen-before COMSAT bug To: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <597336.890519.ALAN@AI.AI.MIT.EDU> What the heck is this? I can't make head or tail out of the corpse. I -think- that the error it got was OVER IOPOP, which might be related to the fact that the stack pointer was left pointing several locations -below- the base of the stack! 184928 InReq: 1 > 1; 184928 Note: Inreq file too big! Length=5+376 184928 Note: RESET called from 35041, reloading. 184929 ===> BUG: FATAL ERROR <=== Date: 05/18/89 18:49:29 Autopsy from 0 Preserved from 21570 Last UUO = 007000,,016700 at 14707 184929 INT. FROM 31133 .JPC/0 Registers: 0/ 020000,,000400 1/ 000000,,000000 2/ 000000,,000005 3/ 131262,,410551 4/ 000000,,000000 5/ 000000,,000000 6/ 000000,,000000 7/ 000000,,000000 10/ 040700,,015044 11/ 000000,,614400 12/ 000000,,000017 13/ 260740,,010634 14/ 000000,,000000 15/ 000000,,000004 16/ 000000,,000000 17/ 777025,,000647 184930 Input req file MAILIN 1 renamed to BADREQ 1 184943 Job dumped to CRASH;BURNUP 1  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 18 May 89 22:22:54 EDT Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 18 May 89 22:24:57 EDT To: ALAN@MC.lcs.mit.edu CC: BUG-MAIL@MC.lcs.mit.edu, POSTMASTER@MC.lcs.mit.edu, postmaster@ai.ai.mit.edu In-reply-to: Alan Bawden's message of Thu, 18 May 89 19:56:36 EDT <581537.890518.ALAN@MC.LCS.MIT.EDU> Subject: There are no longer any ITS machines on the Internet Date: Thu, 18 May 89 22:21:00 EDT From: jtw@lcs.mit.edu Sender: jtw@lcs.mit.edu Message-ID: <8905182221.aa27514@mintaka.lcs.mit.edu> Just so we all know.. Ooutgoing mail from both MC and AI is going through MINTAKA, as Alan said. I think this will result in substantially -better- outgoing mail service than in the recent past, since Mintaka's mailer has a working domain resolver. Mail into AI goes through Reagan. Mail into MC goes through Mintaka. This is invisible to remote machines which grok the domain system and MX records. Some other sites may have to do the foo%MC@LCS.MIT.EDU bit. I think Comsat is or will shortly be set up to say that in From: fields so replying should work normally. -john  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 18 May 89 19:54:30 EDT Date: Thu, 18 May 89 19:56:36 EDT From: Alan Bawden Subject: There are no longer any ITS machines on the Internet To: BUG-MAIL@MC.LCS.MIT.EDU cc: POSTMASTER@MC.LCS.MIT.EDU, SRA@MC.LCS.MIT.EDU Message-ID: <581537.890518.ALAN@MC.LCS.MIT.EDU> Since MC has lost its Arpanet connection, outgoing mail is now being routed via MINTAKA (as it has on AI for the last few weeks). The running COMSATs and the installed binaries have been temporarily patched to make this be the case until I can get to MIT and install a Chaosnet only version of ITS on MC. Rob, can you do whatever it is that needs to be done to cause MC's to lose 10.3.0.44 as an address in the hosttables? I assume there are already appropriate MX records out there to direct the incoming mail....  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 15 May 89 23:17:47 EDT Received: from bigboote.LCS.MIT.EDU (TCP 2206400176) by MC.LCS.MIT.EDU 15 May 89 23:10:22 EDT Received: by bigboote.LCS.MIT.EDU id AA01935; Mon, 15 May 89 23:08:23 EDT Date: Mon, 15 May 89 23:08:23 EDT Message-Id: <8905160308.AA01935@bigboote.LCS.MIT.EDU> From: Rob Austein Sender: sra@bigboote.LCS.MIT.EDU To: Alan@mc.lcs.mit.edu Cc: BUG-MAIL@mc.lcs.mit.edu In-Reply-To: Alan Bawden's message of Mon, 15 May 89 20:55:38 EDT <580656.890515.ALAN@MC.LCS.MIT.EDU> Subject: COMSAT BIN & COMSAT BIN6 Date: Mon, 15 May 89 20:55:38 EDT From: Alan Bawden It certainly sucks that there isn't a .MAIL.;COMSAT BIN anymore, given that that is the default filename you are offered in almost all situations involving binary files. I have no objection to the old binaries being called BIN5, BIN6, etc., but can't we have the most recent one called just BIN? If you want to have a symbolic link from COMSAT BIN to COMSAT >, that's ok. But no one should ever write a COMSAT BIN for any reason. Any real binary file should have a distinct version number, including patched binaries, and any new binary should be announced on BUG-COMSAT. Speaking of which.... I installed and PDUMPed COMSAT BIN6 on AI, MC, and ML. It has been running since last night without apparent problems. Changes: 1) All current HN$xxx symbols use chaosnet addresses. The fact that we're using compiled-in addresses at all kind of sucks and should be fixed but is low priority. 2) BUGHST still contains HN$MC, but as a consequence of (1), mail to the default bug host now goes to the Chaosnet. COMSAT now checks both its IP and Chaos addresses when deciding if it's running on the default bug host. 3) The default TCP gateway for Chaos-only machines is now Mintaka. This should be fine for AI and ML. Mintaka doesn't currently have a Chaosnet mailer, so if MC goes Chaos-only we will have to do something, fast. 4) I fiddled some existing code and added some new code to attempt to make COMSAT reboot itself if it's about to BADREQ a message due to lack of space and the message is under a certain size. At the moment the magic threshold is "10." (this is shown in the MIDAS output as "IRQMIN Input request size"), which should be multiplied by 5K to figure out the threshold in bytes. This code has not been extensively debugged, since the trigger conditions are hard to simulate. 5) The changes that have been running on MC for a while to handle obscure cases of 5xx error codes in the SMTP MAIL/SEND FROM command are in this version. This still leaves one known hole in NETSND which will be a real pain to fix. If you find that COMSAT has run out of address space and hasn't managed to solve it by rebooting itself, please report same.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 15 May 89 21:02:43 EDT Date: Mon, 15 May 89 20:55:38 EDT From: Alan Bawden To: BUG-MAIL@MC.LCS.MIT.EDU Message-ID: <580656.890515.ALAN@MC.LCS.MIT.EDU> It certainly sucks that there isn't a .MAIL.;COMSAT BIN anymore, given that that is the default filename you are offered in almost all situations involving binary files. I have no objection to the old binaries being called BIN5, BIN6, etc., but can't we have the most recent one called just BIN?  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 15 May 89 12:34:13 EDT Received: from STONY-BROOK.SCRC.SYMBOLICS.COM by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 208620; 15 May 89 12:24:34 EDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 595127; 15 May 89 12:25:40 EDT Date: Mon, 15 May 89 12:25 EDT From: David A. Moon Subject: length of Comsat timeout To: jtw@lcs.mit.edu cc: CENT%ai.ai.mit.edu@REAGAN.AI.MIT.EDU, sra@MINTAKA.lcs.mit.edu, BUG-MAIL%ai.ai.mit.edu@REAGAN.AI.MIT.EDU In-Reply-To: <8905141907.aa08564@mintaka.lcs.mit.edu> Message-ID: <19890515162550.2.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Sun, 14 May 89 19:07:50 EDT From: jtw@lcs.mit.edu Date: Sun, 14 May 89 19:05:32 EDT From: "Pandora B. Berman" From: Rob Austein Subject: more bugs ... It's controlled by the variable HDOWN in SYSNET;COMSAT >. It's currently set to 250. tries, there's a comment next to it that says 500. tries is one week. A week seems kind of long to me but I don't really give a damn one way or the other. Votes? i dimly recall 700 being the number at some point, probably long past. it -was- intended to be a week, at least back in the days of non-infinite-membership networks -- ask KLH. Um, right at the moment the only thing AI is talking to really is MINTAKA, so I would think about a day or so... Even in real life a week seems kinda long, specially since we don't tell folks they're losing in the meantime. MINTAKA is using 4 days. Now yall know what my vote is... To my old-fashioned mind, the important thing is for the timeout on mail retries to be longer than a long weekend, since machines are often down for that length of time. The reason Comsat uses a retry count rather than a time delay is (a) in case the machine Comsat is running on is itself down for a few days, we didn't want that to be treated the same as if we had been retrying for those few days, and (b) in case someone brings up the system with the date set wrong (getting past the various error checks for that). Still, it seems like it would be better to have both a count and a time. Anyway I have no opinion in favor of any particular count, since I don't know how a count translates into an average time these days (700 = 1 week => one try every 15 minutes).  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 15 May 89 03:25:28 EDT Received: from BIGBOOTE.LCS.MIT.EDU by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 208478; 15 May 89 03:15:54 EDT Received: by bigboote.LCS.MIT.EDU id AA01238; Mon, 15 May 89 03:16:50 EDT Date: Mon, 15 May 89 03:16:50 EDT Message-Id: <8905150716.AA01238@bigboote.LCS.MIT.EDU> From: Rob Austein Sender: sra@bigboote.LCS.MIT.EDU To: CENT@ai.ai.mit.edu Cc: BUG-MAIL@ai.ai.mit.edu In-Reply-To: "Pandora B. Berman"'s message of Mon, 15 May 89 01:52:36 EDT <595135.890515.CENT@AI.AI.MIT.EDU> Subject: installation Date: Mon, 15 May 89 01:52:36 EDT From: "Pandora B. Berman" what i recall alan griping about is that you never remember to purify it after you compile it Alan and I already talked about that and agreed that it should be PDUMPed. moon says that pdumping should also make it start up faster, and it might purify itself when started if it isn't launched from a pdumped file It doesn't purify itself. Perhaps it should. I'll change the binaries around to numeric FN2s and install the new version.  Date: Mon, 15 May 89 01:52:36 EDT From: "Pandora B. Berman" Subject: installation To: sra@MINTAKA.LCS.MIT.EDU cc: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <595135.890515.CENT@AI.AI.MIT.EDU> Date: Mon, 15 May 89 00:46:36 EDT From: Rob Austein Sender: sra@bigboote.LCS.MIT.EDU To: CENT@ai.ai.mit.edu Cc: BUG-MAIL@ai.ai.mit.edu Subject: more bugs .... Now, I can fix the damned thing or I can not fix the damned thing but if I fix it I am not going to intentionally make more work for myself. There is a new COMSAT that should work (usual caveats) in AI: SRA; COMSAT BIN; it includes the changes to make BUG-foo work and to make AI and ML send via MINTAKA and to maybe even make COMSAT reboot itself when it gets below 50KB freespace. There are a lot of old SBLK and PDUMP binaries and nobody but Alan knows what they are (yes, I am responsible for some of them being there but I don't remember which goes with which fix, nor do I care, nor am I the person who wanted to save them). As far as I know, what Alan has been working on is a general purpose improved and automated :INSTAL, not something specific to the naming scheme for old COMSAT binaries. So, should I install the new version or not? I don't read my mail on ITS so it doesn't matter to me if we wait until Alan gets back. all your fixes sound like good stuff and in my opinion your new comsat should get installed. and i don't want to make extra work for you. what i recall alan griping about is that you never remember to purify it after you compile it -- i THINK the only observable effect of purifying is that on MC the two comsats will share pages. moon says that pdumping should also make it start up faster, and it might purify itself when started if it isn't launched from a pdumped file, and also that COMSAT has always been pdumped. i can figure out alan's naming scheme from first principles and use of :binprt. COMSAT BIN/OBIN is the SBLK (compiled) form; COMSAT LAUNCH/OLAUNC is the PDUMP (purified). when you install new, you flush the oldest (most Os) versions, rename the current BIN/LAUNCH to OBIN/OLAUNC, and dump the new ones in BIN/LAUNCH. i don't see any need for versions of more than 1 O strength unless COMSAT is undergoing rapid experimentation, which it isn't.  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 15 May 89 00:55:18 EDT Received: from BIGBOOTE.LCS.MIT.EDU by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 208461; 15 May 89 00:45:40 EDT Received: by bigboote.LCS.MIT.EDU id AA01049; Mon, 15 May 89 00:46:36 EDT Date: Mon, 15 May 89 00:46:36 EDT Message-Id: <8905150446.AA01049@bigboote.LCS.MIT.EDU> From: Rob Austein Sender: sra@bigboote.LCS.MIT.EDU To: CENT@ai.ai.mit.edu Cc: BUG-MAIL@ai.ai.mit.edu In-Reply-To: "Pandora B. Berman"'s message of Sun, 14 May 89 19:05:32 EDT <595055.890514.CENT@AI.AI.MIT.EDU> Subject: more bugs Date: Sun, 14 May 89 19:05:32 EDT From: "Pandora B. Berman" yeah, i know, and alan knows more. i think he has his own idea of the Right Way to deal with this; please don't take any radical steps in this regard until he gets back Thu. Well, look. Alan broke COMSAT and then left town. He didn't mean to break it and he didn't know he had done so and I don't blame him, but the fact remains. Now, I can fix the damned thing or I can not fix the damned thing but if I fix it I am not going to intentionally make more work for myself. There is a new COMSAT that should work (usual caveats) in AI: SRA; COMSAT BIN; it includes the changes to make BUG-foo work and to make AI and ML send via MINTAKA and to maybe even make COMSAT reboot itself when it gets below 50KB freespace. There are a lot of old SBLK and PDUMP binaries and nobody but Alan knows what they are (yes, I am responsible for some of them being there but I don't remember which goes with which fix, nor do I care, nor am I the person who wanted to save them). As far as I know, what Alan has been working on is a general purpose improved and automated :INSTAL, not something specific to the naming scheme for old COMSAT binaries. So, should I install the new version or not? I don't read my mail on ITS so it doesn't matter to me if we wait until Alan gets back.  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 14 May 89 19:25:30 EDT Received: from LCS.MIT.EDU by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 208356; 14 May 89 19:16:01 EDT To: CENT@ai.ai.mit.edu CC: sra@MINTAKA.lcs.mit.edu, BUG-MAIL@ai.ai.mit.edu In-reply-to: "Pandora B. Berman"'s message of Sun, 14 May 89 19:05:32 EDT <595055.890514.CENT@AI.AI.MIT.EDU> Subject: more bugs Date: Sun, 14 May 89 19:07:50 EDT From: jtw@lcs.mit.edu Sender: jtw@lcs.mit.edu Message-ID: <8905141907.aa08564@mintaka.lcs.mit.edu> Date: Sun, 14 May 89 19:05:32 EDT From: "Pandora B. Berman" From: Rob Austein Subject: more bugs ... It's controlled by the variable HDOWN in SYSNET;COMSAT >. It's currently set to 250. tries, there's a comment next to it that says 500. tries is one week. A week seems kind of long to me but I don't really give a damn one way or the other. Votes? i dimly recall 700 being the number at some point, probably long past. it -was- intended to be a week, at least back in the days of non-infinite-membership networks -- ask KLH. Um, right at the moment the only thing AI is talking to really is MINTAKA, so I would think about a day or so... Even in real life a week seems kinda long, specially since we don't tell folks they're losing in the meantime. MINTAKA is using 4 days. Now yall know what my vote is...  Date: Sun, 14 May 89 19:16:17 EDT From: "Pandora B. Berman" Subject: more comsat To: ZVONA@AI.AI.MIT.EDU cc: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <595060.890514.CENT@AI.AI.MIT.EDU> Date: Sun, 14 May 89 18:16:47 EDT From: David Chapman To: CENT@AI.AI.MIT.EDU cc: BUG-MAIL@AI.AI.MIT.EDU, sra@MINTAKA.LCS.MIT.EDU .... Maybe I'm confused, but I thought that the mailer's 75% threshold was on directory fullness, not disk space. you're a bit confused. COMSAT'S 75% threshold -does- depend on dir fullness. the primary disk space issue is separate; namely, there is never enough space on DSK:, so things which can afford the risk of going offline in the case of disk failure (that's what secondary disks are all about) should be moved to SECOND:. OSTATS files qualify as expendable in this fashion, so they should be moved. they do still count, of course, toward .MAIL. fullness, so they should also be deleted after they're a week or so old and on tape. I restarted MC's COMSAT For the benefit of the terminally befuddled, what's the clean way of doing this? I use lock and qsend, which just can't be the right thing. i use peek with X, then mail to myself (and usually delete the MAIL > file so generated before comsat gets around to wanting to actually deliver it). alan uses peek with X, then qsend. there is also a way of doing it directly from DDT, which i could reconstruct if i had to. and there's ^S for when one isn't logged in as self. i'm not even sure how one would use LOCK in this fashion (though i'm not surprised it's possible).  Date: Sun, 14 May 89 19:05:32 EDT From: "Pandora B. Berman" Subject: more bugs To: sra@MINTAKA.LCS.MIT.EDU cc: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <595055.890514.CENT@AI.AI.MIT.EDU> Date: Sun, 14 May 89 04:41:34 EDT From: Rob Austein To: CENT@ai.ai.mit.edu Cc: BUG-MAIL@ai.ai.mit.edu Subject: more bugs ... It's controlled by the variable HDOWN in SYSNET;COMSAT >. It's currently set to 250. tries, there's a comment next to it that says 500. tries is one week. A week seems kind of long to me but I don't really give a damn one way or the other. Votes? i dimly recall 700 being the number at some point, probably long past. it -was- intended to be a week, at least back in the days of non-infinite-membership networks -- ask KLH. No, the sollution is to fix the stupid program so that it reboots itself when it's that low on memory since it's too lame to GC. well, i suppose if you can persuade COMSAT to reboot when STATS hits 50 blocks, you can persuade it to check memory level too. Well, there's this little problem that at the present moment no two machines are running the same COMSAT binary. Part of the reason for this is that it currently takes as long to install a new COMSAT with all these goddamned OBIN OOBIN OOOBIN OLAUNC etc files on each machine as it does to compile it. ITS has this neat feature in its filesystem called "version numbers", maybe we should use them? yeah, i know, and alan knows more. i think he has his own idea of the Right Way to deal with this; please don't take any radical steps in this regard until he gets back Thu. ... MLY and I manually dequeued a whole bunch of ancient garbage on MC. ok, i'll see about poking through AI's queued junk sometime Real Soon Now.  Date: Sun, 14 May 89 18:16:47 EDT From: David Chapman To: CENT@AI.AI.MIT.EDU cc: BUG-MAIL@AI.AI.MIT.EDU, sra@MINTAKA.LCS.MIT.EDU In-reply-to: Msg of Sat 13 May 89 05:18:33 EDT from Pandora B. Berman Message-ID: <595035.890514.ZVONA@AI.AI.MIT.EDU> -should- be moved to SECOND:, which generally has more space available than DSK:. the sense of that should be obvious; this is a primary disk space issue rather than a dir space issue. Maybe I'm confused, but I thought that the mailer's 75% threshold was on directory fullness, not disk space. I restarted MC's COMSAT For the benefit of the terminally befuddled, what's the clean way of doing this? I use lock and qsend, which just can't be the right thing.  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 14 May 89 05:03:55 EDT Received: from BIGBOOTE.LCS.MIT.EDU by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 208232; 14 May 89 04:53:59 EDT Received: by bigboote.LCS.MIT.EDU id AA00442; Sun, 14 May 89 04:41:34 EDT Date: Sun, 14 May 89 04:41:34 EDT Message-Id: <8905140841.AA00442@bigboote.LCS.MIT.EDU> From: Rob Austein Sender: sra@bigboote.LCS.MIT.EDU To: CENT@ai.ai.mit.edu Cc: BUG-MAIL@ai.ai.mit.edu In-Reply-To: "Pandora B. Berman"'s message of Sat, 13 May 89 19:57:39 EDT <594871.890513.CENT@AI.AI.MIT.EDU> Subject: more bugs Date: Sat, 13 May 89 19:57:39 EDT From: "Pandora B. Berman" someone has fucked up the code which turns BUG-x into BUG-RANDOM-PROGRAM. such action is a misfeature and should be recanted as expeditiously as possible. Teleological error. The code never worked in the first place. It happens that two bugs canceled each other out in such a way that we never noticed before. Specificly, BUGHST is assembled containing MC's IP address, not Chaos address, and it doesn't get bashed to a Chaos address; back when AI had its ARPANET connection this just meant that the message was sent via TCP/SMTP, and ML uses MC as its TCP/SMTP gateway so it gets sent to MC for forwarding and MC says "Oh, gee, it's for me." But AI is using a machine other than MC as its TCP gateway (happens to be Mintaka but this would happen with any machine other than MC) so things get confused because "(BUG FOO)@BAR" is not a legal address to any mailsystem except ITS. I verified this by patching the running COMSAT on AI, but have not yet done anything about it in the sources or the disk binary. Date: Sat, 13 May 89 05:18:33 EDT From: "Pandora B. Berman" a week's grace should be long enough. go ahead and install it. but while you're at it -- the current time-out for perm-down errors is working out to 3-4 days. it was originally designed to be approximately a week -- could you see about restoring it to that length? It's controlled by the variable HDOWN in SYSNET;COMSAT >. It's currently set to 250. tries, there's a comment next to it that says 500. tries is one week. A week seems kind of long to me but I don't really give a damn one way or the other. Votes? COMSAT runs too long and runs out of GC-able space. solution is precisely your actions. No, the sollution is to fix the stupid program so that it reboots itself when it's that low on memory since it's too lame to GC. Date: Sat, 13 May 89 06:39:01 EDT From: "Pandora B. Berman" while you're diddling AI's mailer, maybe you could also add the changes you put into MC's to clear out the LISTS MSGS deadwood? Well, there's this little problem that at the present moment no two machines are running the same COMSAT binary. Part of the reason for this is that it currently takes as long to install a new COMSAT with all these goddamned OBIN OOBIN OOOBIN OLAUNC etc files on each machine as it does to compile it. ITS has this neat feature in its filesystem called "version numbers", maybe we should use them? You should know that the fixes to get rid of LISTS MSGS deadwood are not complete, there is still a known loophole where the stupid NETSND routine allows a message to go by with a comment in the margin saying "Error count? We don't need no steenkeen error count." Fixing this would require a major rewrite. MLY and I manually dequeued a whole bunch of ancient garbage on MC. I may get to some of this tomorow.  Date: Sat, 13 May 89 19:57:39 EDT From: "Pandora B. Berman" Subject: more bugs To: BUG-MAIL@AI.AI.MIT.EDU, BUG-RANDOM-PROGRAM@AI.AI.MIT.EDU Message-ID: <594871.890513.CENT@AI.AI.MIT.EDU> someone has fucked up the code which turns BUG-x into BUG-RANDOM-PROGRAM. such action is a misfeature and should be recanted as expeditiously as possible. ---------- Date: Sat, 13 May 89 19:51:36 EDT From: Communications Satellite Subject: Msg of Saturday, 13 May 1989 19:51-EDT To: CENT@AI.AI.MIT.EDU FAILED: (BUG FOO) at MC.LCS.MIT.EDU; Recipient name apparently rejected. Last reply was: {550 Unable to parse address} Failed message follows: ------- Date: Sat, 13 May 89 19:51:09 EDT From: "Pandora B. Berman" Subject: ai.ai.mit.edu To: tytso@ATHENA.MIT.EDU cc: BUG-FOO@AI.AI.MIT.EDU MSG: *MSG 5972 DISTRIB: *BBOARD tytso@ATHENA.MIT.EDU 05/09/89 03:05:50 Re: ai.ai.mit.edu Has ai.ai.mit.edu gone away? I don't remember seeing any announcement about it. Or is just the losing name service? If so, who should I complain to about that? - Ted No, AI is still here. But our Arpanet connection is not. AI runs ITS and currently talks Arpanet and ChaosNet protocols, so since our IMP was turned off last week, it can only talk directly to other machines on the ChaosNet -- a small number, in this Brave New World of Internet. One of the local hackers is working on code that will allow ITS machines to talk Internet protocol -- in between his various other projects, like the job LCS pays him to do. We hope that he will be done soon; until then, we're still here, just harder to reach.  Date: Sat, 13 May 89 06:39:01 EDT From: "Pandora B. Berman" Subject: ps To: SRA@AI.AI.MIT.EDU cc: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <594693.890513.CENT@AI.AI.MIT.EDU> while you're diddling AI's mailer, maybe you could also add the changes you put into MC's to clear out the LISTS MSGS deadwood?  Date: Sat, 13 May 89 05:18:33 EDT From: "Pandora B. Berman" To: sra@MINTAKA.LCS.MIT.EDU cc: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <594676.890513.CENT@AI.AI.MIT.EDU> Date: Fri, 12 May 89 16:37:22 EDT From: Rob Austein To: ZVONA@ai.ai.mit.edu Cc: BUG-MAIL@ai.ai.mit.edu Date: Fri, 12 May 89 15:59:00 EDT From: David Chapman AI was refusing incoming mail because .mail. was 76% full. I deleted an obscene number of old OSTATS files. (Someone had moved a bunch of them to second:, which presumably doesn't actually make any sense?) I would think that they just moved to second: by themselves in the normal fashion; presumably the ones that moved were the older ones. by themselves? surely you jest. they get moved by alan and me. they -should- be moved to SECOND:, which generally has more space available than DSK:. the sense of that should be obvious; this is a primary disk space issue rather than a dir space issue. Is there still a reason why AI doesn't run the GCMAIL daemon under Puff? I know that some people objected to it on asethetic grounds when I first wrote it for MC, but maybe times have changed? oh what the hell. a week's grace should be long enough. go ahead and install it. but while you're at it -- the current time-out for perm-down errors is working out to 3-4 days. it was originally designed to be approximately a week -- could you see about restoring it to that length? Also, both AI and MC seem to be getting an enormous number of BADREQs. I don't know what that means.. There do seem to be a lot of them. Time to grovel the OSTATS files for clues, I guess. I wouldn't be surprised if it were some effect of either (1) the new automated host table generation code, or (2) the ongoing collapse of the ARPANET. So it's probably not worth a lot of detective work until things stablize. no and no is my guess. Date: Fri, 12 May 89 17:44:04 EDT From: Rob Austein Subject: BADREQs To: BUG-MAIL@MC.LCS.MIT.EDU I restarted MC's COMSAT, flushed the dozen 15 block BADREQs that were from MAILER-DAEMON@foo to Dead-Flame-Request, and put the rest of the BADREQs back into the queue. Everything seems to be being delivered ok. I dunno why COMSAT ran out of memory in the first place, though. see my recent msg to POSTMASTER (I'll cc a copy to anyone not on PM who wants it) -- COMSAT runs too long and runs out of GC-able space. solution is precisely your actions. we haven't been noticing this because alan has been doing it for us, but he's away on the left coast for a week....  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 12 May 89 17:50:16 EDT Date: Fri, 12 May 89 17:44:04 EDT From: Rob Austein Subject: BADREQs To: BUG-MAIL@MC.LCS.MIT.EDU Message-ID: <579758.890512.SRA@MC.LCS.MIT.EDU> I restarted MC's COMSAT, flushed the dozen 15 block BADREQs that were from MAILER-DAEMON@foo to Dead-Flame-Request, and put the rest of the BADREQs back into the queue. Everything seems to be being delivered ok. I dunno why COMSAT ran out of memory in the first place, though.  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 12 May 89 16:45:14 EDT Received: from BIGBOOTE.LCS.MIT.EDU by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 207679; 12 May 89 16:36:28 EDT Received: by bigboote.LCS.MIT.EDU id AA05790; Fri, 12 May 89 16:37:22 EDT Date: Fri, 12 May 89 16:37:22 EDT Message-Id: <8905122037.AA05790@bigboote.LCS.MIT.EDU> From: Rob Austein Sender: sra@bigboote.LCS.MIT.EDU To: ZVONA@ai.ai.mit.edu Cc: BUG-MAIL@ai.ai.mit.edu In-Reply-To: David Chapman's message of Fri, 12 May 89 15:59:00 EDT <594285.890512.ZVONA@AI.AI.MIT.EDU> Date: Fri, 12 May 89 15:59:00 EDT From: David Chapman AI was refusing incoming mail because .mail. was 76% full. I deleted an obscene number of old OSTATS files. (Someone had moved a bunch of them to second:, which presumably doesn't actually make any sense?) I would think that they just moved to second: by themselves in the normal fashion; presumably the ones that moved were the older ones. Is there still a reason why AI doesn't run the GCMAIL daemon under Puff? I know that some people objected to it on asethetic grounds when I first wrote it for MC, but maybe times have changed? Also, both AI and MC seem to be getting an enormous number of BADREQs. I don't know what that means.. There do seem to be a lot of them. Time to grovel the OSTATS files for clues, I guess. I wouldn't be surprised if it were some effect of either (1) the new automated host table generation code, or (2) the ongoing collapse of the ARPANET. So it's probably not worth a lot of detective work until things stablize.  Date: Fri, 12 May 89 15:59:00 EDT From: David Chapman To: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <594285.890512.ZVONA@AI.AI.MIT.EDU> AI was refusing incoming mail because .mail. was 76% full. I deleted an obscene number of old OSTATS files. (Someone had moved a bunch of them to second:, which presumably doesn't actually make any sense?) Also, both AI and MC seem to be getting an enormous number of BADREQs. I don't know what that means.  Date: Fri, 12 May 89 15:10:32 EDT From: Devon Sean McCullough Subject: bug report that didn't get through... trying again... To: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <594265.890512.DEVON@AI.AI.MIT.EDU> Date: Fri, 12 May 89 14:55:08 EDT From: Communications Satellite To: DEVON at AI.AI.MIT.EDU Re: Msg of Friday, 12 May 1989 14:54-EDT FAILED: (BUG CHAOS) at MC.LCS.MIT.EDU; Recipient name apparently rejected. Last reply was: {550 Unable to parse address} Failed message follows: ------- Date: Fri, 12 May 89 14:54:29 EDT From: Devon Sean McCullough To: BUG-CHAOS@AI.AI.MIT.EDU cc: postmaster@EDDIE.MIT.EDU Message-ID: <594263.890512.DEVON@AI.AI.MIT.EDU> I have no reason to believe this is an ai problem and not an eddie problem, but you may be interested to know that while eddie was piling up undeliverable mail to ai an hour or so ago, I tried to supdup from eddie to ai. The initial greeting appeard and then just before the screen cleared and pword started, my connection was closed, allegedly by ai. This happened repeatedly. Also, fingering ai from eddie worked fine even when mail and supdup were losing. --Devon PS: I tried to supdup from a sun to ai and the only way I could find to make it work was to rlogin to eddie and supdup from there. Is there a way to get chaos from the suns?  Date: Thu, 4 May 89 15:30:00 EDT From: Alan Bawden Subject: AI loses Arpanet connection. Thousands homeless. To: POSTMASTER@AI.AI.MIT.EDU, BUG-MAIL@AI.AI.MIT.EDU cc: JTW@AI.AI.MIT.EDU Message-ID: <590865.890504.ALAN@AI.AI.MIT.EDU> Since it looks like AI has finally lost its Arpanet connection, COMSAT on AI is now patched so that TCP mail goes via LCS.MIT.EDU (alias XX, alias MINTAKA). This is -not- a patch that is reflected in the COMSAT sources. If anyone assembles a new COMSAT binary, they should please put LCS.MIT.EDU's Chaosnet address in the variable TCPGAT. Hopefully this situation will only last as long as it takes "us" to finish the Interlan driver... Note than MC still seems to be connected, but this can change at any moment. Note that incoming mail for AI has been passing thought Reagan for several weeks now (due to MX-record hackery).  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 28 Apr 89 20:44:51 EDT Date: Fri, 28 Apr 89 20:41:32 EDT From: David Chapman Subject: (r-option showlist) broken?? To: BUG-MAIL@MC.LCS.MIT.EDU Message-ID: <573839.890428.ZVONA@MC.LCS.MIT.EDU> I *must* be confused about this, someone please show me why. In mc's NAMES file, I have (gribble (r-option showlist) (eqv-list complain)) (complain (eqv-list zvona)) Now when I send mail to gribble, I expect that it will go me (via complain), but that the TO: field will be changed to say that the message was sent to complain. But this doesn't happen (exhibit A below). Am I doing something wrong, or was that not what showlist was supposed to do, or is it actually broken? Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 28 Apr 89 20:38:12 EDT Date: Fri, 28 Apr 89 20:34:57 EDT From: David Chapman To: GRIBBLE@MC.LCS.MIT.EDU Message-ID: <573836.890428.ZVONA@MC.LCS.MIT.EDU> foo  Date: Fri, 28 Apr 89 18:16:19 EDT From: "Pandora B. Berman" Subject: comsat performance To: rlk@THINK.COM cc: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <587490.890428.CENT@AI.AI.MIT.EDU> Date: Fri, 28 Apr 89 18:03:14 EDT From: Robert L. Krawitz To: CENT@ai.ai.mit.edu Cc: HEADER-PEOPLE-REQUEST@ai.ai.mit.edu Subject: Msg of Monday, 17 April 1989 23:16-EDT 700 tries in 70-100 hours -- that works out to one every 5 or 10 minutes. Does AI really run its queue that often? i haven't watched it much recently. it depends on how many hosts stuff is queued to and how much new mail is trying to throughput and so forth. but now that you point out those figures, i agree that they look a tad unreasonable. the likely alternative is that at some point, one of the COMSAT hackers reduced the retry number. it should probably be raised again to return to the original week-equivalent retry period.  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 28 Apr 89 17:50:39 EDT Received: from LCS.MIT.EDU by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 200205; 28 Apr 89 17:47:35 EDT To: sra@lcs.mit.edu CC: ZVONA@ai.ai.mit.edu, BUG-MAIL@ai.ai.mit.edu In-reply-to: Rob Austein's message of Fri, 28 Apr 89 17:25:07 EDT <8904282125.AA08461@bigboote.LCS.MIT.EDU> Subject: [COMSAT: Msg of Friday, 28 April 1989 12:56-EDT] Date: Fri, 28 Apr 89 17:41:17 EDT From: jtw@lcs.mit.edu Sender: jtw@lcs.mit.edu Message-ID: <8904281741.aa01203@mintaka.lcs.mit.edu> Date: Fri, 28 Apr 89 17:25:07 EDT From: Rob Austein COMSAT shouldn't bounce a message because of a temporary (450) error. I had to read it twice before I saw that.... Gosh, will you look at that. Can you say "bozo"? Can I??  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 28 Apr 89 17:29:14 EDT Received: from BIGBOOTE.LCS.MIT.EDU by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 200181; 28 Apr 89 17:25:55 EDT Received: by bigboote.LCS.MIT.EDU id AA08461; Fri, 28 Apr 89 17:25:07 EDT Date: Fri, 28 Apr 89 17:25:07 EDT Message-Id: <8904282125.AA08461@bigboote.LCS.MIT.EDU> From: Rob Austein Sender: sra@bigboote.LCS.MIT.EDU To: jtw@lcs.mit.edu Cc: ZVONA@ai.ai.mit.edu, BUG-MAIL@ai.ai.mit.edu In-Reply-To: jtw@lcs.mit.edu's message of Fri, 28 Apr 89 16:51:52 EDT <8904281651.aa17795@mintaka.lcs.mit.edu> Subject: [COMSAT: Msg of Friday, 28 April 1989 12:56-EDT] COMSAT shouldn't bounce a message because of a temporary (450) error. I had to read it twice before I saw that....  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 28 Apr 89 17:14:46 EDT Received: from LCS.MIT.EDU by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 200161; 28 Apr 89 17:11:33 EDT To: ZVONA@AI.ai.mit.edu CC: BUG-MAIL@AI.ai.mit.edu In-reply-to: David Chapman's message of Fri, 28 Apr 89 16:08:02 EDT <587355.890428.ZVONA@AI.AI.MIT.EDU> Subject: [COMSAT: Msg of Friday, 28 April 1989 12:56-EDT] Date: Fri, 28 Apr 89 16:51:52 EDT From: jtw@lcs.mit.edu Sender: jtw@lcs.mit.edu Message-ID: <8904281651.aa17795@mintaka.lcs.mit.edu> Date: Fri, 28 Apr 89 16:08:02 EDT From: David Chapman Um, I think SRA decided this was a COMSAT bug. Just in case someone thinks they fixed it or something: Date: Fri, 28 Apr 89 13:01:19 EDT From: Communications Satellite To: "ZVONA@AI.AI.MIT.EDU" at AI.AI.MIT.EDU Re: Msg of Friday, 28 April 1989 12:56-EDT FAILED: gld at REAGAN.AI.MIT.EDU; Recipient name apparently rejected. Last reply was: {450- The store-and-forward mailer on this machine has been shut down because of a program error. 450- The explanation given was: 450- Timed out after 5 minutes while trying to connect to WHEATIES. 450 The time of shutdown was 4/28/89 10:10:44} Failed message follows: ------- This doesn't look like a COMSAT error to me, unless I'm badly missing the point somewhere.  Date: Fri, 28 Apr 89 16:08:02 EDT From: David Chapman Subject: [COMSAT: Msg of Friday, 28 April 1989 12:56-EDT] To: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <587355.890428.ZVONA@AI.AI.MIT.EDU> Um, I think SRA decided this was a COMSAT bug. Just in case someone thinks they fixed it or something: Date: Fri, 28 Apr 89 13:01:19 EDT From: Communications Satellite To: "ZVONA@AI.AI.MIT.EDU" at AI.AI.MIT.EDU Re: Msg of Friday, 28 April 1989 12:56-EDT FAILED: gld at REAGAN.AI.MIT.EDU; Recipient name apparently rejected. Last reply was: {450- The store-and-forward mailer on this machine has been shut down because of a program error. 450- The explanation given was: 450- Timed out after 5 minutes while trying to connect to WHEATIES. 450 The time of shutdown was 4/28/89 10:10:44} Failed message follows: ------- Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 28 Apr 89 12:55:43 EDT Date: Fri, 28 Apr 89 12:58:40 EDT From: David Chapman Subject: bounced mail To: web%ssyx.ucsc.edu@MINTAKA.LCS.MIT.EDU cc: SEXPOL@MC.LCS.MIT.EDU In-reply-to: Msg of Thu 27 Apr 89 21:34:26 PDT from web at ssyx.ucsc.edu (Wendy) Message-ID: <587159.890428.ZVONA@AI.AI.MIT.EDU> Well, the arpanet is finally falling apart, as advertised. I'm working on tracking down the problems and fixing them, but they'll keep recurring for a while, and there will always be intermittent problems. One way we could work around this would be to digestify the list. Then only I would have to read the bounce messages. The other ``side'' effect would be that everyone would get only one big combined sexpol message per day. Anyone have opinions?  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 22 Apr 89 10:41:42 EDT Received: from BU-IT.BU.EDU by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 196505; 22 Apr 89 10:36:48 EDT Received: from BUIT5.BU.EDU by bu-it.BU.EDU (5.58/4.7) id AA29724; Sat, 22 Apr 89 10:33:07 EDT Return-Path: Received: by buit5.bu.edu (5.58/4.7) id AA15685; Sat, 22 Apr 89 10:33:24 EDT Date: Sat, 22 Apr 89 10:33:24 EDT From: jsol@bu-it.BU.EDU Message-Id: <8904221433.AA15685@buit5.bu.edu> To: bug-mail@ai.ai.mit.edu, bug-hosts@ai.ai.mit.edu Subject: lll-crg.llnl.gov lll-crg's new address is 128.115.1.1. Mail has been bouncing back to me from AI for that host today. Someone should update the host table. --jsol  Date: Thu, 20 Apr 89 00:25:57 EDT From: Robert Huff Subject: Potentially bogus error messages To: BUG-BABYL@AI.AI.MIT.EDU cc: BUG-COMSAT@AI.AI.MIT.EDU Message-ID: <580934.890420.HUFF@AI.AI.MIT.EDU> Hello: In the past two weeks I've sent a couple of pieces of mail to people outside the M. I. T. community, and gotten a massage back: ============ A copy of your message is being returned, because: ============ FOOS@BAR.GRILL.MUMBLE.ETC" at AI.AI.MIT.EDU is an unknown recipient. ============ Failed message follows: ============ followed by the usual copy of my message. The odd thing is that these messages, at least in some cases (haven't checked the others), are getting through. One of these was to a .COM site, but was kicked back _by COMSAT_. What gives? Is this a bogus error message, or is something actually choking somewhere? Thanks, Robert Huff  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 18 Apr 89 17:23:34 EDT Received: from LCS.MIT.EDU by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 193873; 18 Apr 89 17:19:24 EDT To: ZVONA@AI.ai.mit.edu CC: BUG-MAIL@AI.ai.mit.edu In-reply-to: David Chapman's message of Tue, 18 Apr 89 15:08:26 EDT <579780.890418.ZVONA@AI.AI.MIT.EDU> Date: Tue, 18 Apr 89 17:14:53 EDT From: jtw@lcs.mit.edu Sender: jtw@lcs.mit.edu Message-ID: <8904181714.aa05914@mintaka.lcs.mit.edu> Not LIFE. Anywhere but LIFE. Maybe MINTAKA.LCS. Maybe Reagan (can we get an XL400 and name it BUSH? Maybe an old PC running Golden CommonLisp named QUAYLE?). But not LIFE. Please.  Date: Tue, 18 Apr 89 15:08:26 EDT From: David Chapman To: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <579780.890418.ZVONA@AI.AI.MIT.EDU> I'm sick of getting mail bounced because I sent it to a valid host that isn't in the table. (So, I'm sure, are you.) How hard would it be to have COMSAT, when it doesn't recognize a host, forward the mail to LIFE to see if *it* can deliver it?  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 13 Apr 89 09:45:18 EDT Received: from MCC.COM by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 191108; 13 Apr 89 09:42:32 EDT Received: from OGHMA.ACA.MCC.COM (OGHMA.ACA.MCC.COM.#Chaos) by MCC.#Chaos with Chaos/SMTP; Thu 13 Apr 89 08:44:29-CDT Date: Thu, 13 Apr 89 08:43 CDT From: David Vinayak Wallace Subject: The new network virus To: bug-comsat@ai.ai.mit.edu Message-ID: <19890413134308.4.GUMBY@OGHMA.ACA.MCC.COM> It appears some other machines have discovered COMSAT's occasional bug of substituting commas for periods, and with a vengeance! ----- Forwarded message follows ----- Date: Mon, 10 Apr 89 18:23:26 EDT From: Mail Delivery Subsystem Subject: Returned mail: Host unknown Message-Id: <8904102223.AA03410@trantor> To: @mc.lcs.mit.edu,@reagan.ai.mit.edu:Mly@ai.ai.mit.edu MMDF-Warning: Parse error in original version of preceding line at lcs.mit.edu Resent-To: mailer-error-of-the-day@MC.LCS.MIT.EDU Resent-From: Richard Mlynarik Resent-Date: Tue, 11 Apr 89 09:30 EDT Resent-Message-ID: <19890411133008.1.MLY@ISABEL-PERON.AI.MIT.EDU> Resent-Comments: It's great to see that the upgrade of the old, broken, obsolete LCS.MIT.EDU has resulted in whole new classes of mailer errors. ----- Transcript of session follows ----- 550 ... Host unknown ----- Unsent message follows ----- Received: from mc.lcs.mit.edu by trantor via CHAOS with SMTP id AA01853; Mon, 10 Apr 89 02:30:33 EDT Received: from life.ai.mit.edu (TCP 20015020120) by MC.LCS.MIT.EDU 8 Apr 89 23:36:50 EDT Received: from wheaties.ai.mit.edu by life.ai.mit.edu; Sat, 8 Apr 89 23:32:15 EDT Received: from REAGAN.AI.MIT.EDU by wheaties.ai.mit.edu; Sat, 8 Apr 89 23:32:11 EDT Received: from ISABEL-PERON.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 188322; Sat 8-Apr-89 23:29:25 EDT Date: Sat, 8 Apr 89 23:30 EDT From: Richard Mlynarik Subject: webster busted. "mail" on rc also busted. To: bug-sun@wheaties.ai.mit.edu Included-Msgs: <8904090300.AB11708@rice-chex.ai.mit.edu>, The message of 8 Apr 89 23:00 EDT from MAILER-DAEMON@wheaties.ai.mit.edu, The message of 8 Apr 89 23:00 EDT from Mail Delivery Subsystem Message-Id: <19890409033056.2.MLY@ISABEL-PERON.AI.MIT.EDU> [...]  Received: from pyrite.rutgers.edu (TCP 20001402017) by AI.AI.MIT.EDU 5 Apr 89 14:56:03 EDT Received: by pyrite.rutgers.edu (5.59/SMI4.0/RU1.1/3.04) id AA05913; Wed, 5 Apr 89 14:54:33 EDT Date: Wed, 5 Apr 1989 14:54:32 EDT From: *Hobbit* To: bug-mail@ai.ai.mit.edu Subject: hosed networks Message-Id: And BBN isn't gonna look at the 27 8x10 glossy core dumps with circles and arrows and a paragraph on the back of each one.... Hee hee! I got little or no real knowledgeable help that would actually fix the problem from anyone on the moderators list, mostly a lot of arm-waving. In the meantime, the problem seems to have more or less cleared up. But thanx for cc'ing me the discussion y'awl MIT folks had, it was interesting.. _H*  Date: Fri, 31 Mar 89 14:19:51 EST From: Charles Frankston Subject: address garbled To: ALAN@AI.AI.MIT.EDU cc: CENT@AI.AI.MIT.EDU, BUG-MAIL@AI.AI.MIT.EDU, BUG-RMAIL@AI.AI.MIT.EDU, SRA@LCS.MIT.EDU Message-ID: <567282.890331.CBF@AI.AI.MIT.EDU> Well, gee this type of thing has been screwing up for years now. I don't know why the sudden interest. Here's the file Rmail writes (I changed XX to CHARON): FROM-PROGRAM:NE FROM-XUNAME:CBF FROM-UNAME:CBF AUTHOR:CBF RCPT:("THOR::RML3362"%star.tamu.edu@charon) SUBJECT: testing TEXT;-1 Please reply if this gets through  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 30 Mar 89 17:35:58 EST Date: Thu, 30 Mar 1989 17:36 EST Message-ID: From: John Wroclawski To: Rob Austein Cc: BUG-COMSAT@AI.AI.MIT.EDU Subject: NETSND still losing In-reply-to: Msg of 30 Mar 1989 16:30-EST from Rob Austein MC's COMSAT still has one message Only one? Gosh.  Date: Thu, 30 Mar 89 16:30:44 EST From: Rob Austein Subject: NETSND still losing To: BUG-COMSAT@AI.AI.MIT.EDU Message-ID: <566648.890330.SRA@AI.AI.MIT.EDU> MC's COMSAT still has one message in its queue that's been there for a long time and has a failure count of zero. I tracked this to the host in question, which hangs whenever you give it an SMTP "MAIL FROM:<..>" command. The NETRAP from NTMINI wakes up, aborts NTMINI with a temporary host error (MR$TEH), the error handling back in NETSND goes off to NTSN25 (my recent fix), NTSN25 says "oops, that's a host error, not a recipient error" and JRSTs off to NTSN85, and NTSN85 says "failure count? we don't need no steenking failure count." Sigh.  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 30 Mar 89 16:15:06 EST Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 185620; Thu 30-Mar-89 16:11:57 EST Date: Thu, 30 Mar 89 16:12 EST From: Alan Bawden Subject: address garbled To: SRA@XX.LCS.MIT.EDU cc: CENT@AI.AI.MIT.EDU, BUG-MAIL@AI.AI.MIT.EDU, BUG-RMAIL@AI.AI.MIT.EDU In-Reply-To: Message-ID: <19890330211210.3.ALAN@PIGPEN.AI.MIT.EDU> Date: Wed, 29 Mar 1989 17:19 EST From: Rob Austein Date: Wednesday, 29 March 1989 04:43-EST From: "Pandora B. Berman" maybe COMSAT just generally fucks up when it tries to deal with "s? I don't think we need to postulate that. We already know it loses on "%". I think that before we speculate on who is screwing up, someone should -look- at what RMAIL writes in the MAIL > file in this case. That's probably pretty easy for an RMAIL user to do.  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 30 Mar 89 15:59:51 EST Date: Thu, 30 Mar 1989 16:00 EST Message-ID: From: Rob Austein To: Bug-COMSAT@AI.AI.MIT.EDU Subject: [ZVONA: [COMSAT: Msg of Thursday, 30 March 1989 12:15-EST]] This looks like a COMSAT bug. A 4xx error code shouldn't be interpreted as a name rejection. Date: Thursday, 30 March 1989 12:33-EST From: David Chapman To: postmaster@LCS.MIT.EDU Re: [COMSAT: Msg of Thursday, 30 March 1989 12:15-EST] I know you aren't responsible, but I don't know how else to reach someone who is. Please forward to the guilty party... (I must say, bouncing mail because the mailer crashed seems like the WRONG thing to do.) Date: Thu, 30 Mar 89 12:16:36 EST From: Communications Satellite To: "ZVONA@AI.AI.MIT.EDU" at AI.AI.MIT.EDU Re: Msg of Thursday, 30 March 1989 12:15-EST FAILED: laura at ZERMATT.LCS.MIT.EDU; Recipient name apparently rejected. Last reply was: {450- The store-and-forward mailer on this machine has been shut down because of a program error. 450- The explanation given was: 450- Invalid source address. 450 The time of shutdown was 3/30/89 11:07:48.} Failed message follows: ------- Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 30 Mar 89 12:07:38 EST Date: Thu, 30 Mar 89 12:07:41 EST From: David Chapman Subject: pro-angmar To: obsolete!nazgul@BLOOM-BEACON.MIT.EDU cc: Paganism@MC.LCS.MIT.EDU In-reply-to: Msg of Wed 29 Mar 89 08:27:17 EST from obsolete!nazgul at BLOOM-BEACON.MIT.EDU (Kee Hinckley) Message-ID: <566452.890330.ZVONA@AI.AI.MIT.EDU> I will cease forwarding the list until such time as this issue can be resolved. Thank you! If any of the users on pro-angmar wish to continue reading the paganism list then they should send mail to paganism-request@mc.lcs.mit.edu and receive it individually. I trust that their requests will be treated with the same respect as any other individual request. Yup. By the way, you allude to an important point. Everyone should be aware that there is no such thing as secure e-mail. Although I hope everyone will exercise discretion, messages sent to this list may be forwarded elsewhere or intercepted en route. Don't send anything here (or to any other e-mail destination) revelation of the contents of which would have serious consequences. David  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 29 Mar 89 17:18:50 EST Date: Wed, 29 Mar 1989 17:19 EST Message-ID: From: Rob Austein To: "Pandora B. Berman" Cc: BUG-MAIL@AI.AI.MIT.EDU, BUG-RMAIL@AI.AI.MIT.EDU Subject: address garbled In-reply-to: Msg of 29 Mar 1989 04:43-EST from "Pandora B. Berman" Date: Wednesday, 29 March 1989 04:43-EST From: "Pandora B. Berman" maybe COMSAT just generally fucks up when it tries to deal with "s? I don't think we need to postulate that. We already know it loses on "%".  Date: Wed, 29 Mar 89 04:43:09 EST From: "Pandora B. Berman" Subject: address garbled To: BUG-MAIL@AI.AI.MIT.EDU, BUG-RMAIL@AI.AI.MIT.EDU Message-ID: <565605.890329.CENT@AI.AI.MIT.EDU> RMAIL, or someone, chewed up the address on this before COMSAT reached it to try to transmit it. Date: Wed, 29 Mar 89 04:31:14 EST From: Communications Satellite Subject: Msg of Wednesday, 29 March 1989 04:31-EST To: CENT@AI.AI.MIT.EDU Message-ID: <565599.890329@AI.AI.MIT.EDU> ============ A copy of your message is being returned, because: =========== "THOR::RML3362" at AI.AI.MIT.EDU is an unknown recipient. ============ Failed message follows: ============ Date: Wed, 29 Mar 89 04:31:10 EST From: "Pandora B. Berman" Subject: sca # 280 question To: "THOR::RML3362"@AI.AI.MIT.EDU Message-ID: <565598.890329.CENT@AI.AI.MIT.EDU> Date: Wed, 22 Mar 89 23:15:22 CST From: Mike Litchfield 'Flashback' <"THOR::RML3362"@star.tamu.edu> Subject: sac # 280 To: sca-request@MC.LCS.MIT.EDU [rest of msg text omitted] now i know STAR.TAMU.EDU isn't in the host tables, so i altered the address produced by the RMAIL R cmd from "THOR::RML3362"@star.tamu.edu to "THOR::RML3362"%star.tamu.edu@xx but when COMSAT attempted to transmit, it said this: 043108 InReq: 1 > 1; SPECS:{J:RMAIL}{CENT}{CLAIMS-TO-BE:CENT}{TL=1094.} ID=<565598.890329.CENT@AI.AI.MIT.EDU> EXP->THOR::RML3362@1200400006::={IGNORED} 043114 CMSG ID=<565599.890329@AI.AI.MIT.EDU> EXP->CENT@1200400006 043115 Local->AI.AI.MIT.EDU 043115 TO->CENT maybe COMSAT just generally fucks up when it tries to deal with "s?  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 27 Mar 89 17:57:50 EST Date: Mon, 27 Mar 1989 17:59 EST Message-ID: From: Rob Austein To: John Wroclawski Cc: Alan Bawden , Bug-MAIL@AI.AI.MIT.EDU, glenn@WHEATIES.AI.MIT.EDU, hobbit@PYRITE.RUTGERS.EDU In-reply-to: Msg of 27 Mar 1989 15:38-EST from John Wroclawski Date: Monday, 27 March 1989 15:38-EST From: John Wroclawski Now wait a minute. -Something- is screwing up here; it seems really unlikely that the net connection would repeatedly drop dead just as FTPS sends the reply code accepting the data, Not really. The DATA portion of the SMTP transaction has different transmission characteristics (lots of full packets going in one direction, whereas the rest of the transaction is short commands and short answers) so this is one of the most likely places for weird routing screws to show up. In any case, we've seen this behavior before, including when testing out problem paths like this with TELNET on the SMTP port. and besides, this sort of thing should be pretty easy to avoid by just not queueing the message until TCP thinks all the data of the ack line was delivered. Or something. I was going to say that we could do this by writing the message to a filename other than MAIL > (we have to write it to disk before sending the ACK, because sending the ACK constitutes a commitment on our part to deliver the message) which could be renamed or deleted as circumstances indicate, but I realized that there is a Byzantine Generals' problem lurking here, in that, in the case where the connection apparently fails, we can never be sure whether the sending SMTP did in fact receive the ACK and delete the message from the queue on its end. So the only safe thing we can do is what we're already doing. Sorry. We used to jump all over sendmails that were doing something awfully close to this with big mailing lists, remember? (um, that's not what's going on here, is it? There is this issue that if sendmail blows out delivering the Nth recipient of a list, it starts again from the beginning... Not what Hobbit described, but..) Right, that was a receiving sendmail attempting to deliver everything while keeping the sender SMTP on hold until completion. As I told Hobbit, FTPS does as close to no work as mechanicly possible between receiving the data and sending the ACK, so it's clear that this isn't the same syndrome. --Rob  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 27 Mar 89 15:36:45 EST Date: Mon, 27 Mar 1989 15:38 EST Message-ID: From: John Wroclawski To: Rob Austein Cc: Alan Bawden , Bug-MAIL@AI.AI.MIT.EDU, glenn@WHEATIES.AI.MIT.EDU, hobbit@PYRITE.RUTGERS.EDU In-reply-to: Msg of 27 Mar 1989 15:13-EST from Rob Austein From: Rob Austein I already responded to Hobbit on this when I saw it in Risks. I just didn't CC you on it because I know you hate thinking about COMSAT. So you got it anyway. It's not FTPS's fault, or COMSAT's fault, or ITS's fault, or Hobbit's fault. It's just a typical case of (the remains of) the ARPANET turning into cream cheese and there ain't nothing you can do about it. And BBN isn't gonna look at the 27 8x10 glossy core dumps with circles and arrows and a paragraph on the back of each one.... Now wait a minute. -Something- is screwing up here; it seems really unlikely that the net connection would repeatedly drop dead just as FTPS sends the reply code accepting the data, and besides, this sort of thing should be pretty easy to avoid by just not queueing the message until TCP thinks all the data of the ack line was delivered. Or something. We used to jump all over sendmails that were doing something awfully close to this with big mailing lists, remember? (um, that's not what's going on here, is it? There is this issue that if sendmail blows out delivering the Nth recipient of a list, it starts again from the beginning... Not what Hobbit described, but..)  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 27 Mar 89 15:12:17 EST Date: Mon, 27 Mar 1989 15:13 EST Message-ID: From: Rob Austein To: Alan Bawden Cc: Bug-MAIL@AI.AI.MIT.EDU, glenn@WHEATIES.AI.MIT.EDU, hobbit@PYRITE.RUTGERS.EDU In-reply-to: Msg of 27 Mar 1989 14:19-EST from Alan Bawden I already responded to Hobbit on this when I saw it in Risks. I just didn't CC you on it because I know you hate thinking about COMSAT. So you got it anyway. It's not FTPS's fault, or COMSAT's fault, or ITS's fault, or Hobbit's fault. It's just a typical case of (the remains of) the ARPANET turning into cream cheese and there ain't nothing you can do about it. And BBN isn't gonna look at the 27 8x10 glossy core dumps with circles and arrows and a paragraph on the back of each one....  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 27 Mar 89 14:24:11 EST Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 184922; Mon 27-Mar-89 14:21:54 EST Date: Mon, 27 Mar 89 14:19 EST From: Alan Bawden Subject: [glenn@wheaties.ai.mit.edu: [davis@wheaties.ai.mit.edu: found on risks list]] To: Bug-MAIL@AI.AI.MIT.EDU cc: hobbit@pyrite.rutgers.edu, glenn@WHEATIES.AI.MIT.EDU Included-msgs: <8903271551.AA00313@frosted-flakes.ai.mit.edu>, The message of 27 Mar 89 10:51 EST from glenn@wheaties.ai.mit.edu Message-ID: <19890327191942.5.ALAN@PIGPEN.AI.MIT.EDU> Date: Mon, 27 Mar 89 10:51 EST From: glenn@wheaties.ai.mit.edu To: alan@ai.ai.mit.edu Date: Tue, 21 Mar 1989 14:41:56 EST From: *Hobbit* Subject: Duplicates due to network lossage? Has anyone else been receiving complaints about lots of duplicate messages from people at particular sites? Some of these poor victims are getting on the order of 25 copies of one message. I've done some queue-watching and it appears that the SMTP dialog in these cases flies right along, no problem, until the . after the DATA, whereupon the remote host just sits there [ostensibly trying to deliver the message], and my end times out and requeues the message. Meanwhile the foreign end, not particularly caring that the sender nuked the connection, finally figures out what it was doing and delivers the message. While (stuck) repeat... We've been having some network problems down here over the past couple of days, but one would think that once the connection is open and the dialog is running, you wouldn't get an inordinate delay *ONLY* after the DATA is sent. What's going on with these sites? Below I have included a list of offenders I could find on the Security list. Any ideas? I'm running regular ole sendmail, and everything's working fine otherwise; it's just that these hosts refuse to acknowledge receipt of the message. They are running a bunch of different mailers, as well, so it isn't a problem with a particular type of mailer [although I've seen that sort of thing in the past]. _H* "slow" hosts follow: AI.AI.MIT.EDU, asd.wpafb.af.mil, bbn.com, BCO-MULTICS.ARPA, cam.unisys.com, CCA.cca.com, CCINT1.RSRE.MOD.UK, cs.ucla.edu, EDN-VAX.ARPA, gateway.mitre.org, ibm.com, maths.bath.ac.uk, MITRE.ARPA, mitre-bedford.ARPA, mitre-gateway.arpa, mizar.usc.edu, msc.umn.edu, MWUNIX.MITRE.ORG, nems.arpa, opus.cray.com, prime1.lancashire-poly.ac.uk, RADC-TOPS20.ARPA, rand.org, relay.cs.net, relay.mod.uk, sdcrdcf.arpa, stony-brook.scrc.symbolics.com, stripe.SRI.com, tis.llnl.gov, ucbarpa.berkeley.edu, UCBVAX.BERKELEY.EDU, vaxa.isi.edu, vax.bbn.com, venera.isi.edu, wb3ffv.ampr.org [I still get a monster BARFlist each time I send an issue. (I wish people wouldn't just forward these things to me like I was the only person in the whole universe who has anything to do with the ITS mailer.) Note that this isn't a COMSAT complaint, but rather a complaint that involves our SMTP server. And seemingly dozens of other different SMTP servers as well, so its hard to see that the problem could be something that -we- are doing. Now, I don't see how we can help this man directly. (I just now checked to see if perchance this was happening often enough that I could catch an SMTP server on AI in the act of losing in this manner -- but no such luck.) But perhaps someone else on this list can remember some standard-way-to-lose- with-sendmail that can cause this. Like perhaps he doesn't flush network output after sending the "."? Or perhaps he doesn't send the correct end-of-line character(s) before and after the "."?  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 26 Mar 89 18:05:39 EST Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 184771; Sun 26-Mar-89 18:03:35 EST Date: Sun, 26 Mar 89 18:03 EST From: Alan Bawden Subject: return to the bride of the son of :OHOST To: CENT@AI.AI.MIT.EDU cc: BUG-MAIL@AI.AI.MIT.EDU In-Reply-To: <561835.890322.CENT@AI.AI.MIT.EDU> Message-ID: <19890326230353.2.ALAN@PIGPEN.AI.MIT.EDU> Date: Wed, 22 Mar 89 23:02:25 EST From: "Pandora B. Berman" ... the time has come again, as the table has grown beyond all bounds and the TACs are about to go. SRA's new restrictions on the host table compiler exclude the TACs (among other dubious hosts). so now :OHOST refers to the host table from just before this latest slashing, and :OOHOST does what :OHOST used to. hack courtesy of alan. The reason for having OHOST preserve a host table from February has little to do with flushing the TACs. The reason is that starting about now, a lot of sites are starting to lose their IMP connections. Thus you may see COMSAT trying to deliver mail to "10.0.0.11" and wonder who the heck that used to be. :OHOST 10.0.0.11 will tell you that that used to SAIL's address.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 26 Mar 89 08:31:46 EST Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 26 Mar 89 08:29:31 EST Received: from JONES.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 26 MAR 89 08:29:22 EST Date: Sun, 26 Mar 89 08:27 EST From: Christopher Maeda Subject: digestifier To: bug-digest@MC.LCS.MIT.EDU, bug-mail@MC.LCS.MIT.EDU Message-ID: <19890326132732.1.MAEDA@JONES.AI.MIT.EDU> I just fixed it to break up large digests. It counts characters and messages while parsing the subject lines. Once it reads more than the maximum number of characters, it quits reading in messages and writes them out instead. Any unread messages are then copied to a file called JNAME _OLD_. The digestifier then writes another digest. It stops when there is no more _OLD_ files and no inbox left. These changes are in the latest version of digest > in mc:gumby; I copied the binary to dragon;dgstbg bin and linked the daily aviatn demon to it. If everything goes ok for the next couple of days, we can link the rest of the digests to it. Chris  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 25 Mar 89 01:48:44 EST Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 25 Mar 89 01:48:12 EST Date: Sat, 25 Mar 1989 01:36 EST Message-ID: From: Rob Austein To: Richard Mlynarik Cc: Postmaster@MC.LCS.MIT.EDU, Bug-COMSAT@MC.LCS.MIT.EDU Subject: ll.arpa In-reply-to: Msg of 25 Mar 1989 01:15-EST from Richard Mlynarik Funny you should mention this. Last night (2am friday) I installed a new COMSAT that has some minor fixes to some majorly broken code. Among other things, these fixes might (mind you, I said "might") get rid of this LL.ARPA stuff. The general form of failure that the fixes address are things that cause a message to fail without incrementing the failure count. I don't know that I got them all, the code is much too confused to be sure. For those who have been following, this is a slightly expanded version of the NETSND fixes I was proposing. For what it's worth, I totally agree with all the people who think that NETSND is currently a crufty rats nest. I'd guess that about 2/3 of the code is obsolete garbage. ("T" and "R" modes? Oooogh....) Somebody ought to go in there with a flame thrower and fungicide. COMSAT watchers, please keep an eye on the "failure cnt" portions of any queue dumps you might see. Anything that's been in the queue longer than a few hours (making allowances for mailer load) with a failure count of zero is almost certainly a bug we haven't found yet.  Date: Wed, 22 Mar 89 23:02:25 EST From: "Pandora B. Berman" Subject: return to the bride of the son of :OHOST To: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <561835.890322.CENT@AI.AI.MIT.EDU> there's the :HOST cmd, see? it tells you the current, up-to-the-minute (well, usually the up-to-yesterday) correspondence between host names and host numbers and other useful stuff. and a couple years ago, when the great nickname demise occurred, someone hacked up :OHOST, which did the same thing but used a version of the host table from just before that reduction. the time has come again, as the table has grown beyond all bounds and the TACs are about to go. SRA's new restrictions on the host table compiler exclude the TACs (among other dubious hosts). so now :OHOST refers to the host table from just before this latest slashing, and :OOHOST does what :OHOST used to. hack courtesy of alan.  Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 20024224620) by AI.AI.MIT.EDU 20 Mar 89 13:47:50 EST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 561051; Mon 20-Mar-89 13:44:04 EST Date: Mon, 20 Mar 89 13:43 EST From: David A. Moon Subject: [mingus: Another COMSAT problem] To: David Chapman cc: BUG-MAIL@AI.AI.MIT.EDU In-Reply-To: <559861.890320.ZVONA@AI.AI.MIT.EDU> Message-ID: <19890320184351.4.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Mon, 20 Mar 89 12:36:07 EST From: David Chapman Lemmee see... this means that COMSAT has run out of freespace because of the leak in its garbage collector, right? And that's happening because it no longer crashes due to the STATS file being too big, right? So what do we do about this? Should I manually crash it every few days? Perhaps it's not a GC leak, just fragmentation. I would suggest that when Comsat gets this error, and the size of the input file is less than a certain threshold, instead of rejecting the input request file it should restart itself without saving a crash dump. While about to parse an input request file should be a safe time to crash since there are no network connections and no modified files that have not been written out. Date: 20 Mar 89 07:31:23 EST (Mon) From: mingus at sfcon.sf.att.com (Marcel Franck Simon) To: attunix!ai.ai.mit.edu!zvona at sfcon.sf.att.com Re: Another COMSAT problem Here is another error message from COMSAT. Note that this is a different error from last week. Note also that although the last digest was 12 Kbytes, I have sent digests as large as 16 Kbytes with no problem. Have the rules changed? ==================error message follows===================================== From uucp Sun Mar 19 11:15 EST 1989 >From arpa!MC.LCS.MIT.EDU!COMSAT Sun Mar 19 11:15:34 1989 remote from attunix Date: Sun, 19 Mar 89 11:05:19 EST From: Communications Satellite To: "mail-men-request%attunix@research.att.com"@RESEARCH.ATT.COM cc: MAIL-MAINTAINERS@MC.LCS.MIT.EDU Message-ID: <554208.890319@MC.LCS.MIT.EDU> Status: R Error in input request file. Request too large. Message not sent and not queued; 12 Kbytes is far too large for me. Please use the FTP program to transfer huge files around the network. =======================message ends======================================= Marcel  Date: Mon, 20 Mar 89 12:36:07 EST From: David Chapman Subject: [mingus: Another COMSAT problem] To: BUG-MAIL@AI.AI.MIT.EDU cc: mingus%sfcon.sf.att.com@LIFE.AI.MIT.EDU Message-ID: <559861.890320.ZVONA@AI.AI.MIT.EDU> Lemmee see... this means that COMSAT has run out of freespace because of the leak in its garbage collector, right? And that's happening because it no longer crashes due to the STATS file being too big, right? So what do we do about this? Should I manually crash it every few days? Date: 20 Mar 89 07:31:23 EST (Mon) From: mingus at sfcon.sf.att.com (Marcel Franck Simon) To: attunix!ai.ai.mit.edu!zvona at sfcon.sf.att.com Re: Another COMSAT problem Here is another error message from COMSAT. Note that this is a different error from last week. Note also that although the last digest was 12 Kbytes, I have sent digests as large as 16 Kbytes with no problem. Have the rules changed? ==================error message follows===================================== From uucp Sun Mar 19 11:15 EST 1989 >From arpa!MC.LCS.MIT.EDU!COMSAT Sun Mar 19 11:15:34 1989 remote from attunix Date: Sun, 19 Mar 89 11:05:19 EST From: Communications Satellite To: "mail-men-request%attunix@research.att.com"@RESEARCH.ATT.COM cc: MAIL-MAINTAINERS@MC.LCS.MIT.EDU Message-ID: <554208.890319@MC.LCS.MIT.EDU> Status: R Error in input request file. Request too large. Message not sent and not queued; 12 Kbytes is far too large for me. Please use the FTP program to transfer huge files around the network. =======================message ends======================================= Marcel  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 18 Mar 89 18:50:48 EST Date: Sat, 18 Mar 1989 18:45 EST Message-ID: From: John Wroclawski To: David Chapman Cc: BUG-MAIL@AI.AI.MIT.EDU, EFP@AI.AI.MIT.EDU, rdz@WHEATIES.AI.MIT.EDU Subject: [rdz: Network lossage] In-reply-to: Msg of 18 Mar 1989 17:16-EST from David Chapman From: David Chapman AI also seems not to be able to send mail to score. From: rdz at wheaties.ai.mit.edu (Ramin Zabih) It seems that currently Stanford (ie, score and GO4) can talk to rice-chex but not to AI. I imagine that this is causing various mail to back up... More effects of the incipient dismantling of the Arpanet. We're pedaling as fast as we can...  Date: Sat, 18 Mar 89 17:16:55 EST From: David Chapman Subject: [rdz: Network lossage] To: BUG-MAIL@AI.AI.MIT.EDU cc: EFP@AI.AI.MIT.EDU, rdz@WHEATIES.AI.MIT.EDU Message-ID: <559162.890318.ZVONA@AI.AI.MIT.EDU> AI also seems not to be able to send mail to score. Date: Sat, 18 Mar 89 15:42:50 EST From: rdz at wheaties.ai.mit.edu (Ramin Zabih) To: alan at wheaties.ai.mit.edu, zvona at wheaties.ai.mit.edu Re: Network lossage It seems that currently Stanford (ie, score and GO4) can talk to rice-chex but not to AI. I imagine that this is causing various mail to back up... Ramin  Date: Fri, 17 Mar 89 00:12:45 EST From: Puff the Magic Dragon Subject: Happy Birthday! To: KSC@AI.AI.MIT.EDU Message-ID: <557972.890317.DRAGON@AI.AI.MIT.EDU> Happy birthday to you, Happy birthday to you, Happy birthday dear Kennedy, Happy birthday to you.  Received: from emx.utexas.edu (TCP 20024600441) by AI.AI.MIT.EDU 16 Mar 89 15:15:23 EST Date: Thu, 16 Mar 89 14:13:03 -0600 From: gavan@emx.utexas.edu (Gavan Duffy) Posted-Date: Thu, 16 Mar 89 14:13:03 -0600 Message-Id: <8903162013.AA17050@emx.utexas.edu> Received: by emx.utexas.edu (5.61/%I%) id AA17050; Thu, 16 Mar 89 14:13:03 -0600 To: BUG-COMSAT@AI.AI.MIT.EDU, Alan@Reagan.AI.MIT.EDU, JTW@Reagan.AI.MIT.EDU Cc: JCMa@Reagan.AI.MIT.EDU Subject: Problems "compunicating" with Texas I'm told by people at our computation center that the problem had to do with our link to the arpanet via Rice (in Houston). It seems to be fixed now. JCMa: it might be best to continue to route bug-relatus mail through Reagan.  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 16 Mar 89 14:32:07 EST Date: Thu, 16 Mar 1989 14:27 EST Message-ID: From: Rob Austein To: David Chapman Cc: BUG-MAIL@AI.AI.MIT.EDU, sra@XX.LCS.MIT.EDU Subject: [mingus: MANY failed messages] In-reply-to: Msg of 16 Mar 1989 13:51-EST from David Chapman Date: Thursday, 16 March 1989 13:51-EST From: David Chapman To: BUG-MAIL@AI.AI.MIT.EDU Re: [mingus: MANY failed messages] This sounds like it might be related to the recent mod? Date: 16 Mar 89 08:01:26 EST (Thu) From: mingus at sfcon.sf.att.com (Marcel Franck Simon) To: attunix!ai.ai.mit.edu!zvona at sfcon.sf.att.com Re: MANY failed messages Hi, MC.LCS.MIT.EDU!COMSAT has been sending me MANY failed mail messages, all telling me that FAILED: henry at LINC.CIS.UPENN.EDU; Host appears to be permanently down or not accepting mail. The failed message is always the same: the mail-men digest of Wednesday, March 8. Is there any way to stop this? I am getting ten or more of these failed mail messages each day, and have been getting them for 3-4 days now... Which recent mod are you thinking of? If you mean the thing I was talking about with COMSAT XPER yesterday, it's not possible, since it's not running the normal COMSAT's queues, it's running private ones that don't overlap. Since this person didn't bother to include any actual dead messages, it's hard to tell who did the replication.  Date: Thu, 16 Mar 89 13:51:10 EST From: David Chapman Subject: [mingus: MANY failed messages] To: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <557428.890316.ZVONA@AI.AI.MIT.EDU> This sounds like it might be related to the recent mod? Date: 16 Mar 89 08:01:26 EST (Thu) From: mingus at sfcon.sf.att.com (Marcel Franck Simon) To: attunix!ai.ai.mit.edu!zvona at sfcon.sf.att.com Re: MANY failed messages Hi, MC.LCS.MIT.EDU!COMSAT has been sending me MANY failed mail messages, all telling me that FAILED: henry at LINC.CIS.UPENN.EDU; Host appears to be permanently down or not accepting mail. The failed message is always the same: the mail-men digest of Wednesday, March 8. Is there any way to stop this? I am getting ten or more of these failed mail messages each day, and have been getting them for 3-4 days now... Marcel  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 16 Mar 89 00:09:54 EST Date: Thu, 16 Mar 89 00:05:43 EST From: Rob Austein Subject: COMSAT XPER on MC and ML To: BUG-COMSAT@MC.LCS.MIT.EDU Message-ID: <552586.890316.SRA@MC.LCS.MIT.EDU> MC and ML are running a COMSAT XPER (COMSAT with XVERS/ -1, for those who haven't seen this in a while) which is a patched version of the current COMSAT. The patches are that I replaced all the occurances of JRST NTSN85 with JRST NTSN25, as discussed a few days ago. It seems to work, but this change could seriously fuck things up if I'm wrong, so if anyone can think of a screw case that they would like to try, compose a message with QSEND or QMAIL (as the case may be) and send it with instead of with , so that it will be written as .MAIL.;XMAIL > and the right COMSAT will get it. In the long run it's pretty clear that about half of the NETSND module is obsolete garbage, but this minor fix, if it works, should get rid of some of the inexplicable deadwood that piles up in the LISTS MSGS files.  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 15 Mar 89 19:45:52 EST Date: Wed, 15 Mar 1989 19:33 EST Message-ID: From: JTW@XX.LCS.MIT.EDU To: Alan Bawden Cc: bug-comsat@AI.AI.MIT.EDU, JCMA@AI.AI.MIT.EDU Subject: [gavan@emx.utexas.edu: [MAILER-DAEMON: Returned mail: Deferred: Bad file number]] In-reply-to: Msg of 15 Mar 1989 19:13-EST from Alan Bawden AI uses the arpanet. the arpanet is falling apart. (In particular, I know that arpanet routes from here to texas are screwed up). Other MIT machines do not use the arpanet path much any more, and probably will work when AI won't. The highly trained and professional full-time maintainance staff of AI is addressing this issue in their usual prompt manner. (i.e., you're screwed for now, bud). Things may be better by April 1. -john  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 15 Mar 89 19:34:41 EST Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 181553; Wed 15-Mar-89 19:29:20 EST Date: Wed, 15 Mar 89 19:29 EST From: Alan Bawden Subject: garbage in COMSAT queues.. To: CBF@AI.AI.MIT.EDU cc: BUG-MAIL@AI.AI.MIT.EDU In-Reply-To: <554521.890312.CBF@AI.AI.MIT.EDU> Message-ID: <19890316002921.4.ALAN@PIGPEN.AI.MIT.EDU> Date: Sun, 12 Mar 89 19:20:21 EST From: Charles Frankston While looking for something else , I came across the following gem in the stats file (repeated many times): 182622 QID=<552697.890309@AI.AI.MIT.EDU> 182622 TO->@AI.AI.MIT.EDU,@ai.ai.mit.edu,@ai.ai.mit.edu,@ai.ai.mit.edu,@ai.ai.mit.edu,@ai.ai.mit.edu,@ai.ai.mit.edu,@ai.ai.mit.edu,@ai.ai.mit.edu,@@wheaties.ai.mit.edu 182622 NTMBEG TEMP ERR={451 rewrite: expansion too long: Not enough memory} I'm afraid I don't know how to go about deleting, though I would be curious to see what caused it. What caused it was someone with a mail loop from AI to Wheaties and back. When this happens, eventually the return-path gets to so long that Wheaties chokes. (I don't understand why the return path only mentions AI and never Wheaties.) To delete things from COMSAT's queue, load the Lunar Emacs library and do: M-X Kill Message552697.890309  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 15 Mar 89 19:19:09 EST Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 181546; Wed 15-Mar-89 19:13:50 EST Date: Wed, 15 Mar 89 19:13 EST From: Alan Bawden Subject: [gavan@emx.utexas.edu: [MAILER-DAEMON: Returned mail: Deferred: Bad file number]] To: JCMA@AI.AI.MIT.EDU cc: bug-comsat@AI.AI.MIT.EDU In-Reply-To: <19890314124325.2.JCMA@MORRISON.AI.MIT.EDU>, <8903101058.AA29051@emx.utexas.edu>, The message of 10 Mar 89 05:58 EST from gavan@emx.utexas.edu, The message of 10 Mar 89 05:58 EST from Gavan Duffy, <19890314125410.6.JCMA@MORRISON.AI.MIT.EDU>, <8903102311.AA18115@emx.utexas.edu>, The message of 10 Mar 89 18:11 EST from gavan@emx.utexas.edu, The message of 10 Mar 89 18:11 EST from Gavan Duffy Message-ID: <19890316001350.1.ALAN@PIGPEN.AI.MIT.EDU> Well, it looks to me like AI has just as much trouble talking to EMX as EMX has talking to AI. When AI tries to open a TCP connection to EMX, the connection times out waiting for EMX to respond. I don't know how this allows anyone to come to the conclusion that AI is the party at fault. Since AI is experiencing no problems talking to other hosts, and since you claim that EMX is also talking to others, then perhaps the problem is specific to the network pathway between the two. Welcome to the future where networks are shit.  Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 20024224620) by AI.AI.MIT.EDU 14 Mar 89 11:39:43 EST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 556577; Tue 14-Mar-89 11:37:26 EST Date: Tue, 14 Mar 89 11:37 EST From: David A. Moon Subject: One of the longer bughunts in history To: Rob Austein cc: BUG-COMSAT@AI.AI.MIT.EDU In-Reply-To: <555471.890313.SRA@AI.AI.MIT.EDU> Message-ID: <19890314163718.0.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Mon, 13 Mar 89 23:31:29 EST From: Rob Austein Would somebody who thinks they understand what is going on in the guts of NETSND please tell me -why- the failure returns from all calls to NTMINI are handled by JRST NTSN85? It seems to me that JRST NTSN25 would do the right thing, assuming that NTMINI returns an appropriate error code. I'm not that somebody, but I just wanted to say that the last time I looked through this stuff I concluded that the control structure of the part of msg sending that deals with errors was just totally screwed up and made no sense. So there may -be- no answer to the question you asked.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 14 Mar 89 07:59:13 EST Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by MC.LCS.MIT.EDU 14 Mar 89 07:54:46 EST Received: from MORRISON.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 180969; Tue 14-Mar-89 07:53:34 EST Date: Tue, 14 Mar 89 07:54 EST From: John C. Mallery Subject: [gavan@emx.utexas.edu: [COMSAT@ai.ai.mit.edu: Msg of Wednesday, 8 March 1989 01:11-EST]] To: bug-comsat@MC.LCS.MIT.EDU Included-msgs: <8903102311.AA18115@emx.utexas.edu>, The message of 10 Mar 89 18:11 EST from gavan@emx.utexas.edu, The message of 10 Mar 89 18:11 EST from Gavan Duffy Included-References: The message of 7 Mar 89 19:33 EST from Spock@SAMSON.CADR.DIALNET.SYMBOLICS.COM Message-ID: <19890314125410.6.JCMA@MORRISON.AI.MIT.EDU> Date: Fri, 10 Mar 89 18:11 EST From: Gavan Duffy Posted-Date: Fri, 10 Mar 89 17:11:02 -0600 To: Postmaster@Reagan.AI.MIT.EDU Subject: [COMSAT@ai.ai.mit.edu: Msg of Wednesday, 8 March 1989 01:11-EST] I'm sending this to you, because AI is losing miserably. EMX has been up and accepting mail from other hosts for almost a week now. I've also had several failed mails from AI today trying to send to JCMA@AI.AI.MIT.EDU. Posted-Date: Fri, 10 Mar 89 17:22:21 EST Received-Date: Fri, 10 Mar 89 16:23:35 -0600 Date: Fri, 10 Mar 89 17:22:21 EST From: Communications Satellite Subject: Msg of Wednesday, 8 March 1989 01:11-EST To: "gavan@emx.utexas.edu"@life.ai.mit.edu FAILED: GAVAN at EMX.UTEXAS.EDU; Host appears to be permanently down or not accepting mail. Failed message follows: ------- Received: from life.ai.mit.edu (TCP 20015020120) by AI.AI.MIT.EDU 8 Mar 89 01:11:54 EST Received: from emx.utexas.edu by life.ai.mit.edu; Wed, 8 Mar 89 01:11:20 EST Date: Wed, 8 Mar 89 00:12:05 -0600 From: gavan@emx.utexas.edu (Gavan Duffy) Posted-Date: Wed, 8 Mar 89 00:12:05 -0600 Message-Id: <8903080612.AA07274@emx.utexas.edu> Received: by emx.utexas.edu (5.61/%I%) id AA07274; Wed, 8 Mar 89 00:12:05 -0600 To: Funstrux@ai.ai.mit.edu In-Reply-To: Mr. Spock's message of Tue, 7 Mar 89 16:33 PST <19890308003325.3.SPOCK@SAMSON.CADR.DIALNET.SYMBOLICS.COM> Subject: initial substitutions (addendum) Date: Tue, 7 Mar 89 16:33 PST From: Mr. Spock Of course 7 equations is a miniscule chunk to do an average time with but it gives us a general idea of what's going on. Unless these are the hairiest 7. Do we make any effort to do the fastest simplifications/substitutions earlier than the slower ones? This has been running in a window with the process priority at -1 on SAMSON. What else was going on at the same time? I hope somebody notices something wrong with my math! Maybe if you change to base 35? All seriousness aside, who's cannabalizing the time? There are the usual suspects, of course, and we could round them up. But there's nothing like precise information. How about dragging out the metering utility?  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 14 Mar 89 07:47:49 EST Received: from MORRISON.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 180942; Tue 14-Mar-89 07:42:49 EST Date: Tue, 14 Mar 89 07:43 EST From: John C. Mallery Subject: [gavan@emx.utexas.edu: [MAILER-DAEMON: Returned mail: Deferred: Bad file number]] To: bug-comsat@AI.AI.MIT.EDU Included-msgs: <8903101058.AA29051@emx.utexas.edu>, The message of 10 Mar 89 05:58 EST from gavan@emx.utexas.edu, The message of 10 Mar 89 05:58 EST from Gavan Duffy Included-References: The message of 7 Mar 89 07:12 EST from JCMA@AI.AI.MIT.EDU Message-ID: <19890314124325.2.JCMA@MORRISON.AI.MIT.EDU> We seem to be having some trouble receiving messages at AI. Date: Fri, 10 Mar 89 05:58 EST From: Gavan Duffy Posted-Date: Fri, 10 Mar 89 04:58:36 -0600 To: JCMA@Reagan.AI.MIT.EDU Subject: [MAILER-DAEMON: Returned mail: Deferred: Bad file number] Your AI mail seems to be losing. Date: Fri, 10 Mar 89 01:59:42 -0600 From: MAILER-DAEMON (Mail Delivery Subsystem) Subject: Returned mail: Deferred: Bad file number Posted-Date: Fri, 10 Mar 89 01:59:42 -0600 Received-Date: Fri, 10 Mar 89 01:59:42 -0600 To: gavan ----- Transcript of session follows ----- JCMA@AI.AI.MIT.EDU... reply: read error 554 JCMA@AI.AI.MIT.EDU... timeout waiting for input 451 JCMA@AI.AI.MIT.EDU... reply: read error ----- Unsent message follows ----- Date: Fri, 10 Mar 89 01:59:42 -0600 From: gavan (Gavan Duffy) Posted-Date: Fri, 10 Mar 89 01:59:42 -0600 Received-Date: Fri, 10 Mar 89 01:59:42 -0600 Message-Id: <8903100759.AA19233@emx.utexas.edu> Received: by emx.utexas.edu (5.61/%I%) id AA19233; Fri, 10 Mar 89 01:59:42 -0600 To: JCMA@AI.AI.MIT.EDU Cc: Bug-Relatus-parser@REAGAN.AI.MIT.EDU In-Reply-To: John C. Mallery's message of Tue, 7 Mar 89 07:12 EST <19890307121228.4.JCMA@MORRISON.AI.MIT.EDU> Subject: parse window Date: Tue, 7 Mar 89 07:12 EST From: John C. Mallery Anyway, just make it so you can change the deictic context of a sentence but require it to be reparsed. Installed.  Date: Mon, 13 Mar 89 23:31:29 EST From: Rob Austein Subject: One of the longer bughunts in history To: BUG-COMSAT@AI.AI.MIT.EDU Message-ID: <555471.890313.SRA@AI.AI.MIT.EDU> In June of 1988 I sent a message referring to a message Dave Moon sent in September of 1986 on why certain COMSAT holds onto certain messages forever in spite of definite hard errors in the SMTP dialog. Would somebody who thinks they understand what is going on in the guts of NETSND please tell me -why- the failure returns from all calls to NTMINI are handled by JRST NTSN85? It seems to me that JRST NTSN25 would do the right thing, assuming that NTMINI returns an appropriate error code.  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 13 Mar 89 14:01:34 EST Date: Mon, 13 Mar 1989 13:55 EST Message-ID: From: Rob Austein To: Alan Bawden Cc: BUG-MAIL@AI.AI.MIT.EDU, MAEDA@AI.AI.MIT.EDU Subject: deleting text of bounced messages In-reply-to: Msg of 7 Mar 1989 20:59-EST from Alan Bawden Date: Tuesday, 7 March 1989 20:59-EST From: Alan Bawden Now if there was some additional infomation that was passed along with the message that indicated that the sender didn't want a complete copy ack in the event of failure, then we could make COMSAT use that infomation. But I don't think there is anything in the current mail protocols that supports such a notion. Of couse we have control of the local mail delivery protocol, so we could make -locally- originated digests do something along these lines. We'd need a new kind of flag you put in a MAIL > file, and a new attribute for COMSAT to store in LISTS MSGS, plus the code to notice the attribute and act appropriately. Then we would have to fix the automatic digestifier and the Arpanet bboard tool and the AIList tool... This is pretty reasonable and wouldn't be terribly difficult, but I think we are all agreed that there are loads of higher priority items for anybody who feels like COMSAT hacking.  Date: Sun, 12 Mar 89 19:20:21 EST From: Charles Frankston Subject: garbage in COMSAT queues.. To: BUG-MAIL@AI.AI.MIT.EDU cc: ALAN@AI.AI.MIT.EDU Message-ID: <554521.890312.CBF@AI.AI.MIT.EDU> While looking for something else , I came across the following gem in the stats file (repeated many times): 182622 QID=<552697.890309@AI.AI.MIT.EDU> 182622 TO->@AI.AI.MIT.EDU,@ai.ai.mit.edu,@ai.ai.mit.edu,@ai.ai.mit.edu,@ai.ai.mit.edu,@ai.ai.mit.edu,@ai.ai.mit.edu,@ai.ai.mit.edu,@ai.ai.mit.edu,@@wheaties.ai.mit.edu 182622 NTMBEG TEMP ERR={451 rewrite: expansion too long: Not enough memory} I'm afraid I don't know how to go about deleting, though I would be curious to see what caused it.  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 11 Mar 89 15:37:33 EST Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 180522; Sat 11-Mar-89 15:33:07 EST Date: Sat, 11 Mar 89 15:33 EST From: Alan Bawden Subject: [MAILER-DAEMON@wheaties.ai.mit.edu: Returned mail: Unable to deliver mail] To: glenn@WHEATIES.AI.MIT.EDU cc: Bug-MAIL@AI.AI.MIT.EDU In-Reply-To: <8903092147.AA00236@frosted-flakes.ai.mit.edu> Message-ID: <19890311203308.3.ALAN@PIGPEN.AI.MIT.EDU> Date: Thu, 9 Mar 89 16:47:27 EST From: glenn@wheaties.ai.mit.edu Return-Path: Date: Thu, 9 Mar 89 14:20:17 EST From: MAILER-DAEMON@wheaties.ai.mit.edu (Mail Delivery Subsystem) Subject: Returned mail: Unable to deliver mail To: postmaster ----- Transcript of session follows ----- <<< HELO AI.AI.MIT.EDU <<< MAIL FROM:<@AI.AI.MIT.EDU,@AI.AI.MIT.EDU,@ai.ai.mit.edu,@ai.ai.mit.edu,@ai.ai.mit.edu,@ai.ai.mit.edu,@ai.ai.mit.edu,@ai.ai.mit.edu,@ai.ai.mit.edu,@ai.ai.mit.edu,@@wheaties.ai.mit.edu> 554 prescan: too many tokens 554 prescan: too many tokens 554 prescan: too many tokens 554 cannot prescan from (<@AI.AI.MIT.EDU,@AI.AI.MIT.EDU,@ai.ai.mit.edu,@ai.ai.mit.edu,@ai.ai.mit.edu,@ai.ai.mit.edu,@ai.ai.mit.edu,@ai.ai.mit.edu,@ai.ai.mit.edu,@ai.ai.mit.edu,@@wheaties.ai.mit.edu>) ----- No message was collected ----- I think I have killed the 70 or so messages that were causing this. Rick Lathrop had his mail looping between AI and wheaties for about a month at the beginning of the year. The messages bounced back and forth until the return path got so long that wheaties started erring as shown above. COMSAT has a long standing bug where certain permanent errors are ignored and the message stays queued. So all 70 messages have been knocking on wheaties door like this for a couple of months. I wish COMSAT didn't have this bug. I wish Lathrop would be more careful about his mail.  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 8 Mar 89 14:22:42 EST Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 179544; Wed 8-Mar-89 14:19:09 EST Date: Wed, 8 Mar 89 14:19 EST From: Alan Bawden Subject: %sucks To: Bug-COMSAT@AI.AI.MIT.EDU Message-ID: <19890308191907.3.ALAN@PIGPEN.AI.MIT.EDU> I have to following entry in a mailing list file: (Cube-Lovers-disty%pco @BCO-Multics.ARPA) COMSAT parses this as Cube-Lovers-disty@PCON.CU.NIH.GOV. I know all the excuses, I just wanted to remind everbody about how much I think this misfeature sucks.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 7 Mar 89 21:43:52 EST Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 7 Mar 89 21:42:55 EST Received: from NICO.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 7 MAR 89 21:42:10 EST Date: Tue, 7 Mar 89 21:38 EST From: Christopher Maeda Subject: deleting text of bounced messages To: ALAN@AI.AI.MIT.EDU cc: bug-mail@MC.LCS.MIT.EDU In-Reply-To: <551281.890307.ALAN@AI.AI.MIT.EDU> Message-ID: <19890308023855.7.MAEDA@NICO.AI.MIT.EDU> Date: Tue, 7 Mar 89 20:59:10 EST From: Alan Bawden The problem can't be so bad that we have to stoop so low. No. I'll just start sending digest related mail to a junk mail file.  Date: Tue, 7 Mar 89 20:59:10 EST From: Alan Bawden Subject: deleting text of bounced messages To: MAEDA@AI.AI.MIT.EDU cc: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <551281.890307.ALAN@AI.AI.MIT.EDU> The problem is that you don't know you are bouncing the text of a worthess digest. How is COMSAT supposed to know that that isn't a vitally important message that it cannot deliver? When you bounce an important message, the sender wants a -complete- copy of the message back so that he can retransmit it through some other means. Now if there was some additional infomation that was passed along with the message that indicated that the sender didn't want a complete copy ack in the event of failure, then we could make COMSAT use that infomation. But I don't think there is anything in the current mail protocols that supports such a notion. Of couse we have control of the local mail delivery protocol, so we could make -locally- originated digests do something along these lines. We'd need a new kind of flag you put in a MAIL > file, and a new attribute for COMSAT to store in LISTS MSGS, plus the code to notice the attribute and act appropriately. Then we would have to fix the automatic digestifier and the Arpanet bboard tool and the AIList tool... Or we could put in a horrid kludge where the BULK COMSAT always truncates bounced messages. I promise to throw up on the shoes of anyone who takes this last idea seriously. The problem can't be so bad that we have to stoop so low.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 7 Mar 89 20:11:29 EST Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 7 Mar 89 20:10:32 EST Received: from NICO.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 7 MAR 89 20:10:14 EST Date: Tue, 7 Mar 89 20:06 EST From: Christopher Maeda Subject: deleting text of bounced messages To: bug-mail@MC.LCS.MIT.EDU Message-ID: <19890308010653.1.MAEDA@NICO.AI.MIT.EDU> How hard would it be to mung comsat to delete the text of bounced messages? Bounced digests sitting in mail files take up a lot of disk space. Chris  Received: from LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 4 Mar 89 02:14:06 EST Date: Sat, 4 Mar 1989 02:11 EST Message-ID: From: Rob Austein To: David Chapman Cc: Bug-COMSAT@AI.AI.MIT.EDU, Alan@AI.AI.MIT.EDU, SRA@AI.AI.MIT.EDU Date: Friday, 3 March 1989 21:52-EST From: David Chapman To: SRA@AI.AI.MIT.EDU, ALAN@AI.AI.MIT.EDU Well, MC's OSTATS are all 51 long, so I guess moving the digests won big.. Er, Alan managed to nudge me into fixing COMSAT so that it it now considers truncating the STATS file the second highest priority it has (first priority is checking its locks periodicly to make sure nobody's stolen them in some inexplicable way, somebody was being paranoid). This COMSAT has been running on MC for a few days and (as of this afternoon) is now the installed COMSAT LAUNCH on MC, AI, and ML. But you're right, the digest move seems to have helped. MC:.MAIL.;LISTS MSGS was down to under 1300 blocks this afternoon, which we haven't seen for a -long- time. Part of what's going on is that COMSAT's retransmission algorithms scale well up to a certain point, but past that point the situation degrades rapidly as more messages (well, recipients, ie, hosts to whom stuff must be delivered) cause a longer time between delivery attempts causing a larger queue and on and on in a vicious positive feedback cycle. Most other mailers discard things based on absolute time in the queue rather than failure counts, so the total mailer load doesn't directly feed back into the queue size. In retrospect it's fairly clear (well, a good educated guess, anyway) that MC's regular COMSAT had been running past the critical load point for some time. Of course, like all good things, the fix to the STATS file stuff has a price: now that MC's COMSAT no longer needs to be rebooted daily to close the STATS files, it has fallen back to the old bug of pissing away its freespace until it gets to the point where a two block message is too long. Anybody want to take a stab at fixing that?  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 24 Feb 89 23:37:58 EST Date: Fri, 24 Feb 89 23:36:03 EST From: Rob Austein Subject: Digests moved to COMSAT BULK To: DEAD-FLAMES-REQUEST@MC.LCS.MIT.EDU, AVIATION-REQUEST@MC.LCS.MIT.EDU, PAGANISM-REQUEST@MC.LCS.MIT.EDU, SCA-REQUEST@MC.LCS.MIT.EDU, SUBGENIUS-REQUEST@MC.LCS.MIT.EDU, SCHEME-REQUEST@MC.LCS.MIT.EDU cc: BUG-MAIL@MC.LCS.MIT.EDU, BUG-DIGEST@MC.LCS.MIT.EDU Reply-To: Bug-MAIL@AI.AI.MIT.EDU Message-ID: <544373.890224.SRA@MC.LCS.MIT.EDU> Now that we have all of Alan's good work on making COMSAT use the LOCK: device, it seemed ok to move the digests to COMSAT BULK. So I did. The actual switch was a one line change to GUMBY;DIGEST >. The only change this entails from the point of view of a digest administrator is that you should look in MC:.BULK.; for [O]STATS files if you care about such things, rather than in MC:.MAIL.;. The various mailing lists still reside in MC:.MAIL.;NAMES > and should remain there; the NAMES file in .BULK. should never be anything besides a link to the one in .MAIL.; or chaos will ensue. Obviously, any digests that have already been sent out via regular COMSAT will remain in regular COMSAT's queue until they are delivered or time out. But digests posted from now on will go via COMSAT BULK. The overall result of this change should be improved performance for both digests and regular mail, since the main effect will be to lessen contention for MC's regular COMSAT's limited processing time. Please report any problems you think may have been caused by this change to BUG-MAIL. --Rob  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 24 Feb 89 18:15:20 EST Received: from LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 24 Feb 89 17:48:00 EST Date: Fri, 24 Feb 1989 17:48 EST Message-ID: From: Rob Austein To: Alan Bawden Cc: BUG-MAIL@MC.LCS.MIT.EDU Subject: Local mailbox screw eliminated In-reply-to: Msg of 24 Feb 1989 05:27-EST from Alan Bawden Presumably we could work around the double compilation of NAMES > by arbitrarily deciding that one particular COMSAT (probably the one that runs in .MAIL., for simplicity) is the only thing that ever compiles NAMES, and make the approriate files in .BULK. into links to .MAIL..  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 24 Feb 89 05:28:44 EST Date: Fri, 24 Feb 89 05:27:18 EST From: Alan Bawden Subject: Local mailbox screw eliminated To: BUG-MAIL@MC.LCS.MIT.EDU, BUG-DIGEST@MC.LCS.MIT.EDU, NICK@MC.LCS.MIT.EDU Message-ID: <1915.890224.ALAN@MC.LCS.MIT.EDU> COMSAT now uses the LOCK: device to coordinate access to local mailboxes. See the code for gory details. MC:.BULK.;NAMES 999999 is now a link to MC:.MAIL.;NAMES >. In theory, new mail can be placed in either .MAIL.;MAIL > -or- .BULK.;MAIL > and it should be delivered to exactly the same places. Mail hacker visible changes: 1. The newest version of COMSAT will not run under an ITS without the LOCK: device. Under ITS versions before 1630 COMSAT will crash. Currently AI, MC, and ML are running ITS version 1632, and the new COMSAT is installed on all of them. If we have to revert to an earlier version of ITS on any of these machines (heaven forbid!) then we will have to revert to the previous COMSAT, and on MC we would have to shut down the BULK COMSAT completely (if you don't see why, you haven't thought about it hard enough!). 2. Occasionally you will now see a line in the STATS file like: 030310 TO->GLURK(USERS1;)... Inbox locked. This means that mailer found that some other COMSAT (or the GMSGS program, which I hacked to do this locking as well) was in the process of hacking the mailbox in question. This will be treated as a temporary error, and the mail will be queued for later delivery. 3. Since -both- mailers on MC compile the NAMES file separately, it now takes -double- the CPU time to install a new NAMES file. This is a waste since both compilations (presumably) result in equivalent LIST EQV files. Sorry. 4. I copied the entries for the AIList mailing list from the .BULK.;NAMES > into .MAIL.;NAMES > (these were the only BULK-specific mailing lists). No one should -ever- create a separate NAMES file for the BULK COMSAT again. 5. Since both mailers have the same NAMES file, they now both deliver failed mail to .MAIL.;FAILED STUFF. Please note that the BULK COMSAT continues to be a totally independent mailer. It shares the NAMES file, but all of its queues and databases are its own. I suppose the various digests can be switched over to using .BULK. whenever their maintainers feel that they want to give it a try. (The LOCK: device is documented in .INFO.;ITS LOCKS for those that want to learn more about how this works.) (To help test this all out, this mail will be delivered by the BULK COMSAT.)  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 23 Feb 89 20:56:12 EST Received: from LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 23 Feb 89 20:52:55 EST Date: Thu, 23 Feb 1989 20:52 EST Message-ID: From: Rob Austein To: David Chapman Cc: BUG-digest@MC.LCS.MIT.EDU, BUG-mail@MC.LCS.MIT.EDU, Alan@AI.AI.MIT.EDU Subject: I >thought< I remembered there being a more complex screw: Date: Thursday, 23 February 1989 20:02-EST From: David Chapman Date: Wed, 26 Oct 88 17:25 EDT From: Alan Bawden Hold on. It's not as easy as you think to control local delivery. Recall that people can change their INQUIR entries to say that mail should be sent to them @MC, which the BULK mailer will see, and then they can edit .MAIL.;NAMES > to say where it should really go, which the BULK mailer will -not- see, and it will thus start delivering locally. Also, when the host table changes, and an address suddenly becomes unparsable, the mailer will revert to local delivery. Huh? If COMSAT BULK sends mail to USER@AI and USER has her INQUIR entry forwarding mail to USER@MC, AI will ship the mail back to MC's normal COMSAT, which will see .MAIL.;NAMES and will do the right thing. That's the whole point of sending the mail to AI instead of having COMSAT BULK deliver it locally on MC. If AI becomes an unparsable address I think we will have bigger things to worry about than where the subgenius mailing list goes.  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 23 Feb 89 20:52:33 EST Received: from QUESTION-AUTHORITY.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 176154; Thu 23-Feb-89 20:52:28 EST Date: Thu, 23 Feb 89 20:49 EST From: Alan Bawden Subject: .mail. full To: BUG-MAIL@AI.AI.MIT.EDU cc: CENT@AI.AI.MIT.EDU, ZVONA@AI.AI.MIT.EDU In-Reply-To: <543041.890222.CENT@AI.AI.MIT.EDU> Message-ID: <19890224014920.1.ALAN@QUESTION-AUTHORITY.AI.MIT.EDU> Date: Wed, 22 Feb 89 22:33:49 EST From: "Pandora B. Berman" ... there is an alternative which can be a little gentler. If you are -careful-! instead of flushing all those NAMES and OSTATS files, make sure COMSAT is dead (don't try the following while it's running unless you really want to screw things up). And to make sure COMSAT stays dead while you perform this magic, rename .MAIL.;COMSAT LAUNCH to something else. (I like to call it COMSAT LUNCH.) This insures that :MAIL and Puff (who both will launch a new COMSAT if it appears to be dead) will be unable to screw you. create the directory .MAIL2; and -move- LISTS MSGS there. I always :COPY it and then :DELETE the copy on .MAIL.. This lets me check to be sure that the copy is the same length, and that I really copied it where I intended to, etc. I don't like DDT's :MOVE command deleting the old copy before I get a chance to check my sanity. then make a link from .MAIL.;LISTS MSGS to .MAIL2;LISTS MSGS. then delete the _SATEL OUTPUT file and start COMSAT up; it will now almost certainly have enough space on the dir to succeed with the GC -- which will replace the link you just made with the reduced-size version of LISTS MSGS. As soon as the old LISTS MSGS is gone from .MAIL., the incoming mail servers will start dumping new mail in the directory. To prevent this, and increase the chance that COMSAT will be able to GC successfully, I would recommend turning incoming mail off. The XFILEs MC:CENT;MAIL ON and MC:CENT;MAIL OFF are the easy way to do that. (They RENAME the Chaos MAIL server, and set the switch in the FTP server to disable SMTP.) once it does that, remember to go back and delete .MAIL2;LISTS MSGS (which will still be there). And remember to turn incoming mail back on, and rename COMSAT LUNCH. Also, if COMSAT has been crashing, take a look at the CRASH directory and delete any BURNUP files that were created. this procedure is a tad more complicated than simply jumping into emacs dired, but it does preserve more info for later use. If just deleting a few files lets COMSAT win, I would do that. The only advantage of the move-LISTS-MSGS-to-.MAIL2 procedure is that sometimes it is the -only- way COMSAT will be able to GC. Also, before tring procedures like the one described above, people should please be certain that it is the -directory- that is full and not the -disk-. On AI, the problem is usually the disk being full; on MC it is usually the directory. These problems have similar symptoms, but different cures. If I had a nickel for every time I found people trying to address the wrong problem when COMSAT was unable to GC...  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 23 Feb 89 20:37:19 EST Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 23 Feb 89 20:01:39 EST Date: Thu, 23 Feb 89 20:02:09 EST From: David Chapman Subject: I >thought< I remembered there being a more complex screw: To: BUG-digest@MC.LCS.MIT.EDU, BUG-mail@MC.LCS.MIT.EDU Message-ID: <543767.890223.ZVONA@AI.AI.MIT.EDU> Date: Wed, 26 Oct 88 17:25 EDT From: Alan Bawden Subject: bulk digests To: ZVONA@AI.AI.MIT.EDU cc: BUG-MAIL@AI.AI.MIT.EDU Date: Tue, 25 Oct 88 14:59:15 EDT From: David Chapman So as long as there are no local recipients on a BULK list, it's OK? That's easy, then: indirect local recpients, if any, through AI or someplace. Should we start systematically moving big lists to BULK? Hold on. It's not as easy as you think to control local delivery. Recall that people can change their INQUIR entries to say that mail should be sent to them @MC, which the BULK mailer will see, and then they can edit .MAIL.;NAMES > to say where it should really go, which the BULK mailer will -not- see, and it will thus start delivering locally. Also, when the host table changes, and an address suddenly becomes unparsable, the mailer will revert to local delivery. It would be better if we were to first introduce a lock to control local delivery, and then arrange for the BULK mailer to share the NAMES file somehow.  Date: Wed, 22 Feb 89 22:33:49 EST From: "Pandora B. Berman" Subject: .mail. full To: ZVONA@AI.AI.MIT.EDU cc: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <543041.890222.CENT@AI.AI.MIT.EDU> Date: Wed, 22 Feb 89 17:28:43 EST From: David Chapman To: BUG-MAIL@MC.LCS.MIT.EDU MC's .mail. was full and COMSAT dead. I cleaned out some NAMES and OSTATS files. I guess the mail acceptance heuristics are not infallible.. probably what had happened was COMSAT was trying to GC and lost due to .MAIL.; filling up. did you, during your cleanup, find a _SATEL OUTPUT file? that would clinch the case for this scenario -- the MAIL files would have been accepted before the GC attempt. what you did does work. there is an alternative which can be a little gentler. instead of flushing all those NAMES and OSTATS files, make sure COMSAT is dead (don't try the following while it's running unless you really want to screw things up). create the directory .MAIL2; and -move- LISTS MSGS there. then make a link from .MAIL.;LISTS MSGS to .MAIL2;LISTS MSGS. then delete the _SATEL OUTPUT file and start COMSAT up; it will now almost certainly have enough space on the dir to succeed with the GC -- which will replace the link you just made with the reduced-size version of LISTS MSGS. once it does that, remember to go back and delete .MAIL2;LISTS MSGS (which will still be there). this procedure is a tad more complicated than simply jumping into emacs dired, but it does preserve more info for later use.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 22 Feb 89 17:29:26 EST Date: Wed, 22 Feb 89 17:28:43 EST From: David Chapman To: BUG-MAIL@MC.LCS.MIT.EDU Message-ID: <542971.890222.ZVONA@MC.LCS.MIT.EDU> MC's .mail. was full and COMSAT dead. I cleaned out some NAMES and OSTATS files. I guess the mail acceptance heuristics are not infallible..  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 15 Feb 89 01:10:50 EST Date: Wed, 15 Feb 89 01:08:05 EST From: David Chapman To: D0BHELP%venus.tamu.edu@LIFE.AI.MIT.EDU cc: BUG-MAIL@MC.LCS.MIT.EDU, MAILER-ERROR-OF-THE-DAY@MC.LCS.MIT.EDU Message-ID: <539476.890215.ZVONA@MC.LCS.MIT.EDU> Received: from venus.tamu.edu (TCP 20060402001) by MC.LCS.MIT.EDU 14 Feb 89 16:06:44 EST Received: by venus id <20401267301@venus.tamu.edu> ; Tue, 14 Feb 89 15:09:02 CST Date: Tue, 14 Feb 89 15:05:52 CST From: Daryl L Biberdorf Subject: interest group To: system@10.3.0.44 X-VMS-Mail-To: EXOS%"system@10.3.0.44" Message-ID: <890214150552.20401267301@venus.tamu.edu> Hello. I am a member of the user assistance staff here at Texas A&M University. I have a user who would like to sign up to the metaphilosophers list that, according to all the information we have, originates from mc.lcs.mit.edu . Unfortunately, all of our efforts to contact this list have ended in unknown recipient type errors. Do you know if this list is still in existence? If so, what is the correct e-mail address to sign up to it? Thanks. Daryl Biberdorf D0BHELP@TAMVENUS Bitnet D0BHELP@venus.tamu.edu Internet @128.194.4.1 ^_ Well, this is amusing. Due to an unanticipated interaction in our mail system, your message here was delivered in such a way that it became the message that all users see when they log in here. Oh well... Metaphilosophers doesn't originate here. You might try the address gyro@kestrel.arpa; I believe he moderates it, or used to. By the way, postmaster@random.host is probably the right place to send messages like this... David Chapman for postmaster@mc.lcs.mit.edu  Date: Tue, 14 Feb 89 08:12:19 EST From: Doug Humphrey To: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <537788.890214.DIGEX@AI.AI.MIT.EDU> tried to send to Mahan_Terry@26  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 3 Feb 89 16:19:24 EST Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by MC.LCS.MIT.EDU 3 Feb 89 16:06:56 EST Received: from QUESTION-AUTHORITY.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 170693; Fri 3-Feb-89 16:05:46 EST Date: Fri, 3 Feb 89 16:06 EST From: Alan Bawden Subject: proposal for new special request type To: Moon@STONY-BROOK.SCRC.SYMBOLICS.COM cc: SRA@XX.LCS.MIT.EDU, BUG-COMSAT@MC.LCS.MIT.EDU In-Reply-To: <19890202163719.4.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-ID: <19890203210603.3.ALAN@QUESTION-AUTHORITY.AI.MIT.EDU> Date: Thu, 2 Feb 89 11:37 EST From: David A. Moon Date: Wed, 1 Feb 89 20:28 EST From: Alan Bawden ... I would not complain if you did something incredibly kludgy, like inserting the following four instructions in some -safe- place: .CALL [SETZ ? SIXBIT /FILLEN/ ? MOVEI ? SETZM A] .LOSE %LSSYS CAIL A,5*2000*55. .LOGOUT Or find out why the code that has always been there to do this doesn't work any more. Probably some tests in the main "scheduling" loop are in the wrong order. Perhaps it has the same bug as my four instructions: 5*2000*55. doesn't fit in 18 bits...  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 2 Feb 89 11:40:03 EST Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 20024224620) by MC.LCS.MIT.EDU 2 Feb 89 11:37:52 EST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 532375; Thu 2-Feb-89 11:36:42 EST Date: Thu, 2 Feb 89 11:37 EST From: David A. Moon Subject: proposal for new special request type To: Alan Bawden cc: SRA@XX.LCS.MIT.EDU, BUG-COMSAT@MC.LCS.MIT.EDU In-Reply-To: <19890202012802.6.ALAN@QUESTION-AUTHORITY.AI.MIT.EDU> Message-ID: <19890202163719.4.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Wed, 1 Feb 89 20:28 EST From: Alan Bawden Date: Tue, 31 Jan 1989 15:40 EST From: Rob Austein Just closing the STATS file wouldn't solve the same class of problems, ... You are right, it wouldn't solve the same class of problems. It would solve a much more serious problem. It would solve the problem when -somebody- (usually Penny or me) has to manually gun COMSAT on MC about once a day. We've been doing this for months now. Putting in a special request to make it more convenient for us to manually gun COMSAT once a day misses the point. Human beings should not be involved in the process at all. So yes. It would be nice to have a way to cleanly shut down COMSAT using a magic request. But before adding such a feature, how about relieving the pooor operators of a stupid manual task? I would not complain if you did something incredibly kludgy, like inserting the following four instructions in some -safe- place: .CALL [SETZ ? SIXBIT /FILLEN/ ? MOVEI ? SETZM A] .LOSE %LSSYS CAIL A,5*2000*55. .LOGOUT Or find out why the code that has always been there to do this doesn't work any more. Probably some tests in the main "scheduling" loop are in the wrong order.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 1 Feb 89 23:11:02 EST Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by MC.LCS.MIT.EDU 1 Feb 89 20:28:35 EST Received: from QUESTION-AUTHORITY.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 170210; Wed 1-Feb-89 20:27:52 EST Date: Wed, 1 Feb 89 20:28 EST From: Alan Bawden Subject: proposal for new special request type To: SRA@XX.LCS.MIT.EDU cc: BUG-COMSAT@MC.LCS.MIT.EDU In-Reply-To: Message-ID: <19890202012802.6.ALAN@QUESTION-AUTHORITY.AI.MIT.EDU> Date: Tue, 31 Jan 1989 15:40 EST From: Rob Austein Just closing the STATS file wouldn't solve the same class of problems, ... You are right, it wouldn't solve the same class of problems. It would solve a much more serious problem. It would solve the problem when -somebody- (usually Penny or me) has to manually gun COMSAT on MC about once a day. We've been doing this for months now. Putting in a special request to make it more convenient for us to manually gun COMSAT once a day misses the point. Human beings should not be involved in the process at all. So yes. It would be nice to have a way to cleanly shut down COMSAT using a magic request. But before adding such a feature, how about relieving the pooor operators of a stupid manual task? I would not complain if you did something incredibly kludgy, like inserting the following four instructions in some -safe- place: .CALL [SETZ ? SIXBIT /FILLEN/ ? MOVEI ? SETZM A] .LOSE %LSSYS CAIL A,5*2000*55. .LOGOUT  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 31 Jan 89 15:50:09 EST Received: from LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 31 Jan 89 15:39:18 EST Date: Tue, 31 Jan 1989 15:40 EST Message-ID: From: Rob Austein To: Alan Bawden Cc: BUG-COMSAT@MC.LCS.MIT.EDU Subject: proposal for new special request type In-reply-to: Msg of 31 Jan 1989 15:14-EST from Alan Bawden Date: Tuesday, 31 January 1989 15:14-EST From: Alan Bawden Why not just fix COMSAT to close the STATS file perodically? That should be easier than adding a new request. (In theory. No telling what you might discover when you actually go and look at the code, but you might as well start with the intention of doing the right thing.) Just closing the STATS file wouldn't solve the same class of problems, we'd also need to plug all the memory leaks, including the ones that are considered features by the code (@FILE handling falls in this catagory, if I remember correctly). Which we seem to have been talking about doing for as long as I've been on this mailing list. Just rebooting is trivial by comparison. Actually, it might be even more useful to have a SPECIAL-REQ that simply caused COMSAT to log out, so that we could install new versions, etc, without having to gun it down in the middle of doing something useful.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 31 Jan 89 15:29:11 EST Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by MC.LCS.MIT.EDU 31 Jan 89 15:14:57 EST Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 169825; Tue 31-Jan-89 15:14:26 EST Date: Tue, 31 Jan 89 15:14 EST From: Alan Bawden Subject: proposal for new special request type To: SRA@MC.LCS.MIT.EDU cc: BUG-COMSAT@MC.LCS.MIT.EDU In-Reply-To: <532522.890130.SRA@MC.LCS.MIT.EDU> Message-ID: <19890131201437.3.ALAN@PIGPEN.AI.MIT.EDU> Date: Mon, 30 Jan 89 13:25:37 EST From: Rob Austein ... How about we add a SPECIAL-REQ type that causes COMSAT to reboot itself?... Why not just fix COMSAT to close the STATS file perodically? That should be easier than adding a new request. (In theory. No telling what you might discover when you actually go and look at the code, but you might as well start with the intention of doing the right thing.)  Date: Mon, 30 Jan 89 20:30:59 EST From: David Chapman To: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <528800.890130.ZVONA@AI.AI.MIT.EDU> While we are in feature-requesting mode: I noticed that an awful lot of the stuff in MC's queue was (once again) this SIMTEL20 junk. It occurs to me that it might be very easy to get that stuff sent by BULK. I don't actually understand the modularity of all this or anything, but it seems like if the thingamie that accepts incoming netmail looked for a special header line like X-Bulk: YES or something it could just put it in the .bulk. queue instead of .mail. And it shouldn't be too hard for SIMTEL20 to put that line in. It also shouldn't be hard for SIMTEL20 list maintainers to verify that none of their addresses are MC-local. My guess is that doing this would eliminate most of the strain on COMSAT.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 30 Jan 89 13:27:30 EST Date: Mon, 30 Jan 89 13:25:37 EST From: Rob Austein Subject: proposal for new special request type To: BUG-COMSAT@MC.LCS.MIT.EDU cc: SRA@MC.LCS.MIT.EDU Message-ID: <532522.890130.SRA@MC.LCS.MIT.EDU> XX was down last night and most of this morning, so of course all of my mail is currently enqueued on MC waiting for a chance to do the retransmit phase. Which caused me to notice that the STATS file was getting kind of large again, which caused me to think about the following: How about we add a SPECIAL-REQ type that causes COMSAT to reboot itself? This would be a lot cleaner than having to GUN COMSAT from PEEK, since we could be sure it happened when COMSAT wasn't doing anything vital. I suppose it would also be nice if we could add one that said "Please stop looking at new mail and go through your flinking queue already", but that's probably harder. Comments?  Date: Thu, 26 Jan 89 06:25:36 EST From: "Pandora B. Berman" Subject: scrod again To: BUG-GMSGS@AI.AI.MIT.EDU cc: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <526677.890126.CENT@AI.AI.MIT.EDU> i had a large accumulation of mail. it disappeared just as i logged in; my init file runs GMSGS. alan says this comes from GMSGS and COMSAT both trying to write the mail file at the same time, and that it should get fixed some day real soon now, or something.  Date: Wed, 18 Jan 89 22:47:45 EST From: "Pandora B. Berman" Subject: nothing is wrong with mit bb To: JTW@XX.LCS.MIT.EDU cc: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <522422.890118.CENT@AI.AI.MIT.EDU> Date: Mon, 16 Jan 1989 12:08 EST From: JTW@XX.LCS.MIT.EDU To: "Pandora B. Berman" Subject: nothing is wrong with mit bb As the ITS broadcast addresses are presently structured, your MITBB feed can not be on only one of these lists, only both or neither. This seems wierd... Is it really true?? look at any available NAMES >. *RANDOMS is on both *MIT and *BBOARD. GAB consed up this pseudo-broadcast list for some DEC folks; it now also includes your friends at CRL, these folks at XAIT, and some list at UMASS. these last two must have been added more recently -- perhaps due to the change in condition of XX? -- and incompetently, because they were not added on ML. some non-thinker also added an EXPO address to only *LCS-UVAX@MC, but that's irrelevant. i have fixed these dissonances. we now face the question about what to do about the XAIT people's complaint; it's not only theirs, because back when i added the CRL list, they expressed a preference for *MIT material only. we can remove *RANDOMS from *BBOARD -- it does include an R-OPTION NOTDIST, but i have severe doubts that that helps anyone on a non-ITS. i want to treat all the non-MIT folks in the same fashion; otherwise our system-msg equipment will proliferate beyond all reasonable bounds (after all, we're doing them a favor by sending them our system msgs in the first place). anyone else have opinions?  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 18 Jan 89 17:48:25 EST Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by MC.LCS.MIT.EDU 18 Jan 89 17:11:55 EST Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 167065; Wed 18-Jan-89 17:11:39 EST Date: Wed, 18 Jan 89 17:11 EST From: Alan Bawden Subject: COMSAT forward-path/return-path parsing To: SRA@MC.LCS.MIT.EDU cc: BUG-MAIL@MC.LCS.MIT.EDU In-Reply-To: <527699.890117.SRA@MC.LCS.MIT.EDU> Message-ID: <19890118221151.1.ALAN@PIGPEN.AI.MIT.EDU> Date: Tue, 17 Jan 89 23:54:21 EST From: Rob Austein ... I also cleaned up the two zillion ancient COMSAT binaries that were on MC and AI. The version that was running as LAUNCH is now OBIN in each directory, and all of the ones that are running now are LAUNCH. I renamed the OBIN files to OLAUNCH because they were the old PDUMP files. (I presume you deleted the SBLKs.) I renamed the LAUNCH files to BIN, because they were SBLKs, and dumped out new PDUMPs. (When you start a comsat with PURIFY$G it conveniently offers to dump to name the dump LAUNCH...) So the two mailers on MC are sharing their pages again.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 18 Jan 89 00:02:30 EST Date: Tue, 17 Jan 89 23:54:21 EST From: Rob Austein Subject: COMSAT forward-path/return-path parsing To: BUG-MAIL@MC.LCS.MIT.EDU Message-ID: <527699.890117.SRA@MC.LCS.MIT.EDU> JTW and I did a minor edit to COMSAT that may fix the long-standing problem where most of the error messages COMSAT generated for mail originating on other machines were garbage. It turned out that COMSAT wasn't sufficiently paranoid when checking if a particular recipient was in fact an at-domain-list path ("@foo,@bar,@baz:a@b") and would append an extraneous hostname to the end of the path. We're not sure that this fixes the problem, but the preliminary results look good. We installed this as the running COMSAT on AI, MC (including BULK) and ML. MD doesn't seem to exist this month. I also cleaned up the two zillion ancient COMSAT binaries that were on MC and AI. The version that was running as LAUNCH is now OBIN in each directory, and all of the ones that are running now are LAUNCH.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 17 Jan 89 23:33:24 EST Received: from bigboote.LCS.MIT.EDU (TCP 2206400176) by MC.LCS.MIT.EDU 17 Jan 89 18:34:59 EST Received: by bigboote.LCS.MIT.EDU id AA07267; Tue, 17 Jan 89 18:35:15 EST Date: Tue, 17 Jan 89 18:35:15 EST Message-Id: <8901172335.AA07267@bigboote.LCS.MIT.EDU> From: Rob Austein Sender: sra@bigboote.LCS.MIT.EDU To: bug-mail@mc.lcs.mit.edu Subject: mc comsat managed to wedge itself in a gc It crashed while most of the way through a gc (probably out of memory, I didn't check, there are BURNUPs if anybody cares), left both a huge LISTS MSGS and a huge _SATEL OUTPUT, and spent the next several hours with DRAGON booting a new COMSAT which would immediately crash for lack of disk space to do a gc. I flushed all the dead comsats and temporary files and it gc'd ok and started processing mail again. Thanks to Henry Mensch for pointing out this lossage. It seems that COMSAT should probably flush things like _SATEL OUTPUT when it's booting.  Received: from harvard.harvard.edu (TCP 1200000011) by AI.AI.MIT.EDU 16 Jan 89 13:59:56 EST Received: by harvard.harvard.edu; Mon, 16 Jan 89 13:54:19 EST Received: by babbage.HARVARD.EDU; Mon, 16 Jan 89 13:48:07 EST Date: Mon, 16 Jan 89 13:48:07 EST From: Steven Augart Sender: swa@harvard.harvard.edu To: CENT@AI.AI.MIT.EDU Cc: BUG-MAIL@AI.AI.MIT.EDU In-Reply-To: "Pandora B. Berman"'s message of Mon, 16 Jan 89 07:45:31 EST <520657.890116.CENT@AI.AI.MIT.EDU> Subject: problem with :MAIL on AI? Thanks for the reply, SRA answered my question but didn't send his reply to BUG-MAIL. Seems that SWA EMACS (which I'd partly inherited from a friend) was messing up :MAIL's performance). Everything works again and my faith in the great ITS is restored!  Date: Mon, 16 Jan 89 07:45:31 EST From: "Pandora B. Berman" Subject: problem with :MAIL on AI? To: SWA@AI.AI.MIT.EDU cc: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <520657.890116.CENT@AI.AI.MIT.EDU> Date: Sat, 14 Jan 89 16:31:34 EST From: Steven Augart Subject: problem with :MAIL on AI? To: BUG-MAIL@AI.AI.MIT.EDU Symptom: I am using the MAIL program on AI (which I invoke from DDT with ":M". I type ESC E in order to edit my mail message. I found EMACS with an empty MAIN buffer, and no other buffers. When I return to MAIL, (with C-X C-C) I find that the message body I was trying to edit no longer exists. on seeing that empty buffer, did you try typing ^L? that always brings forth the msg text for me.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 15 Jan 89 18:48:37 EST Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 15 Jan 89 18:40:40 EST Date: Sun, 15 Jan 1989 18:38 EST Message-ID: From: JTW@XX.LCS.MIT.EDU To: "Frank J. Wancho" Cc: BUG-MAIL@MC.LCS.MIT.EDU, GHICKS@WSMR-SIMTEL20.ARMY.MIL Subject: CSNET domain In-reply-to: Msg of 15 Jan 1989 16:54-EST from Frank J. Wancho From: Frank J. Wancho Re: CSNET domain At the request of the CSNET folks back in November, who have registered all the hosts for which they relay as domain addresses, earlier this week Greg converted his INFO-IBMPC mailing list from "user%host%relay.cs.net"@mc.lcs.mit.edu to "user%host"@mc.lcs.mit.edu. All the addresses with the new form were rejected by MC as "unknown recipients." The rejections are appended. Was this, perhaps, a transient problem? Should we try again? --Frank -------------------- MC doesn't use the domain system. It uses host tables. Although this situation is completely unreasonable and intolerable, we don't have any immediate way to fix it. While I expect that it will be fixed eventually, even that is iffy, and it will not help you right now. If you wish to continue using MC, you will have to keep your addresses in the old user%host%RELAY.CS.NET form. This will probably give the CSNET people fits, but it will work, at least for a while. Sorry there is no better answer. -john  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 15 Jan 89 18:28:41 EST Received: from WSMR-SIMTEL20.ARMY.MIL (TCP 3200000112) by MC.LCS.MIT.EDU 15 Jan 89 18:20:26 EST Date: Sun, 15 Jan 1989 14:54 MST Message-ID: From: "Frank J. Wancho" To: BUG-MAIL@MC.LCS.MIT.EDU cc: WANCHO@WSMR-SIMTEL20.ARMY.MIL, GHICKS@WSMR-SIMTEL20.ARMY.MIL Subject: CSNET domain At the request of the CSNET folks back in November, who have registered all the hosts for which they relay as domain addresses, earlier this week Greg converted his INFO-IBMPC mailing list from "user%host%relay.cs.net"@mc.lcs.mit.edu to "user%host"@mc.lcs.mit.edu. All the addresses with the new form were rejected by MC as "unknown recipients." The rejections are appended. Was this, perhaps, a transient problem? Should we try again? --Frank -------------------- ============ A copy of your message is being returned, because: ============ "BB_INFO_PC%SMR.SDR.SLB.COM" is an unknown recipient. "BB_INFO_PC%M_DSAVX1%SDR.SLB.COM" is an unknown recipient. "BILLR%WWU.EDU" is an unknown recipient. "BURROWS%M_SIFVX1%SDR.SLB.COM" is an unknown recipient. "CASPI%IIL%SC.INTEL.COM" is an unknown recipient. "HUTIN%EPSVXC%SDR.SLB.COM" is an unknown recipient. "IBM-USERS%WFU.EDU" is an unknown recipient. "IBMLIST%COLOSTATE.EDU" is an unknown recipient. "IBMPC%SC.INTEL.COM" is an unknown recipient. "IBMPC%CIS.TEMPLE.EDU" is an unknown recipient. "IBMPCC%CS.UIOWA.EDU" is an unknown recipient. "IBMPCLIST%LSU.EDU" is an unknown recipient. "INFO-IBMPC%ADAM.CEO.DG.COM" is an unknown recipient. "INFO-IBMPC%SP.UNISYS.COM" is an unknown recipient. "INFO-IBMPC%SRC.ORG" is an unknown recipient. "INFO-IBMPC%UFL.EDU" is an unknown recipient. "INFO-IBMPC%WELLESLEY.EDU" is an unknown recipient. "INFO-IBMPC-READERS%CARLETON.EDU" is an unknown recipient. "JAMES%VAXE.COE.NORTHEASTERN.EDU" is an unknown recipient. "JBD%CGI.COM" is an unknown recipient. "MAISEL%UBT0.HRZ.UNI-BAYREUTH.DBP.DE" is an unknown recipient. "MPREWITT%NMSU.EDU" is an unknown recipient. "MRCC%SP.UNISYS.COM" is an unknown recipient. "NU-INFO-IBMPC%NORTHEASTERN.EDU" is an unknown recipient. "PCSUBSCRIBER%ATC.BENDIX.COM" is an unknown recipient. "PEK%UTRC%UTRCGW.UTC.COM" is an unknown recipient. "PICARD%GMR.COM" is an unknown recipient. "INFO-IBMPC%MERIDIAN.COMICS.UCI.EDU" is an unknown recipient. "RAND%MERRIMACK.EDU" is an unknown recipient. "ROSENBERG%CS.UMASS.EDU" is an unknown recipient. "ROSSY%WWU.EDU" is an unknown recipient. "SANDRA%VAXE.COE.NORTHEASTERN.EDU" is an unknown recipient. "SCHOLTES%ASC%SDR.SLB.COM" is an unknown recipient. "SETH%S49.PRIME.COM" is an unknown recipient. "WEIDENHAMMER%VAX.HMI.DBP.DE" is an unknown recipient. "WELCH%VAXE.COE.NORTHEASTERN.EDU" is an unknown recipient. "INFO-IBMPC%CS.UMASS.EDU" is an unknown recipient. "INFO-IBMPC-INCOMING%CSL.TI.COM" is an unknown recipient. "INFO-IBMPC%CL.UH.EDU" is an unknown recipient. "FAUNT%SPAR-20.SPAR.SLB.COM" is an unknown recipient. "MBASS%UONEURO.UOREGON.EDU" is an unknown recipient. "D0BHELP%VENUS.TAMU.EDU" is an unknown recipient. "GUTHERY%ASCVX5.ASC@SDR.SLB.COM" is an unknown recipient. ============ Failed message follows: ============ [deleted]  Date: Sat, 14 Jan 89 16:31:34 EST From: Steven Augart Subject: problem with :MAIL on AI? To: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <520101.890114.SWA@AI.AI.MIT.EDU> Symptom: I am using the MAIL program on AI (which I invoke from DDT with ":M". I type ESC E in order to edit my mail message. I found EMACS with an empty MAIN buffer, and no other buffers. When I return to MAIL, (with C-X C-C) I find that the message body I was trying to edit no longer exists. -- SWA@AI  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 12 Jan 89 22:43:20 EST Date: Thu 12 Jan 89 22:34:39-EST From: Rob Austein To: ZVONA@AI.AI.MIT.EDU cc: BUG-MAIL@AI.AI.MIT.EDU, SRA@XX.LCS.MIT.EDU In-Reply-To: <518977.890112.ZVONA@AI.AI.MIT.EDU> Reply-To: SRA@LCS.MIT.EDU Message-ID: <12462102692.21.SRA@XX.LCS.MIT.EDU> I forwarded it. The reason is that I've been having trouble getting through to those guys on certain subjects, and I was attempting to point out that their unilateral randomness has been creating serious bad feelings. I also wanted to make sure that Frank saw the message before anybody else at SIMTEL20, in the hopes that having the person who did this kicked by Frank would be more useful than by us. Sorry about that, didn't occur to me that a message on a public mailing list would be considered private. -------  Date: Thu, 12 Jan 89 22:35:14 EST From: David Chapman To: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <518977.890112.ZVONA@AI.AI.MIT.EDU> I wish that whoever had forwarded my message to FJW hadn't. I would have worded it differently. Maybe that's hypocritical of me, but still.  Date: Wed, 11 Jan 89 21:57:26 EST From: David Chapman Subject: damn it! To: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <518055.890111.ZVONA@AI.AI.MIT.EDU> AI's comsat spent the last two hours delivering a piece of info-ibmpc mail (see the file ai:.mail.;aargh mail). This is another of thse things that's sent out from SIMTEL20. We never resolved what to do about those on MC; the problem seems to have gone away, pro tem anyway. But it's definitely inexcusable for this to be going through AI. Does someone more official want to tell the SIMTEL20 people not to do this, or shall I call myself POSTMASTER@AI, or do we want to come up with some broader policy (e.g. inolving MC as well)?  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 5 Jan 89 12:12:34 EST Received: from ZERMATT.LCS.MIT.EDU (CHAOS 17316) by MC.LCS.MIT.EDU 5 Jan 89 12:07:53 EST Received: from MICKEY-MOUSE.LCS.MIT.EDU by ZERMATT.LCS.MIT.EDU via CHAOS with CHAOS-MAIL id 221479; Thu 5-Jan-89 12:05:40 EST Date: Thu, 5 Jan 89 12:05 EST From: Scheme Requestee Subject: Forwarding To: bug-mail@MC.LCS.MIT.EDU cc: schreq@MC.LCS.MIT.EDU Message-ID: <"19890105170510.7.SCHREQ@MC"@MICKEY-MOUSE.LCS.MIT.EDU> Mail from the scheme mailing list to the following hosts is now forwarded via XX. What should I do when XX goes away? ads.arpa mouse.cdc.com alpha.ces.cwru.edu oliver.cs.mcgill.ca alw.nih.gov sesame.stanford.edu relay.ubc.ca cs.williams.edu -Jonathan  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 11 Dec 88 16:41:31 EST Date: Sun 11 Dec 88 16:40:03-EST From: Rob Austein Subject: Re: I'm embarrassed to use COMSAT To: DEVON@AI.AI.MIT.EDU cc: BUG-COMSAT@AI.AI.MIT.EDU, CSTACY@AI.AI.MIT.EDU, SRA@XX.LCS.MIT.EDU In-Reply-To: <499306.881206.DEVON@AI.AI.MIT.EDU> Message-ID: <12453649532.56.SRA@XX.LCS.MIT.EDU> Date: Tue, 6 Dec 88 03:54:07 EST From: Devon Sean McCullough I'm not clear on whether this is a COMSAT problem or whether this is a stupidity in the BABYL command 3F which is how I sent the offending mail. It's BABYL's 3F command that's dogfood. COMSAT did the second-best it could with an illegally formatted message, ie, assumed that you meant all those addresses on the local host. The best thing that it could have done was throw the message back at you, but that's impractical due to historical accident. Here in the future all mail composition programs (UAs) should be required to specify hostnames even for the local host, but it's not likely to happen on ITS. -------  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 9 Dec 88 19:07:33 EST Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 154562; Fri 9-Dec-88 19:06:08 EST Date: Fri, 9 Dec 88 19:06 EST From: Alan Bawden Subject: I'm embarrassed to use COMSAT To: DEVON@AI.AI.MIT.EDU cc: CStacy@REAGAN.AI.MIT.EDU, BUG-COMSAT@AI.AI.MIT.EDU, GUMBY@AI.AI.MIT.EDU In-Reply-To: <501487.881209.DEVON@AI.AI.MIT.EDU> Message-ID: <19881210000608.1.ALAN@PIGPEN.AI.MIT.EDU> Date: Fri, 9 Dec 88 10:17:34 EST From: Devon Sean McCullough I tried the babyl 3F command on the following message, remailing To: elbows, devon ... And COMSAT saw ... AUTHOR: Christopher C. Stacy ... From the documentation of the AUTHOR: field in MAIL > files: AUTHOR This is a recipient-type specification. There should be one of these for each author of the message. There MUST be at least one AUTHOR or COMSAT will complain. These people will be put in the FROM field in the header. NOTE: at the moment, only one AUTHOR is allowed, and it must be a simple string, as for FROM-UNAME. In the future more than one will be allowed and full rcpt syntax will be parsed. {=> PARCSN A$CSN} The NOTE quite clearly tells you that what Babyl is trying to do does not work. There are other things that Babyl could do that -would- work. I'm *not* complaining! Bullshit. Like the saying goes, if you don't like the food, you can do the cooking yourself, and I'm not into hacking on a MIDAS stove, although like Gren I would be glad to cook up C code. Then go join the Unix weenie army, and leave us alone.  Date: Fri, 9 Dec 88 10:17:34 EST From: Devon Sean McCullough Subject: I'm embarrassed to use COMSAT To: CStacy@REAGAN.AI.MIT.EDU cc: BUG-COMSAT@AI.AI.MIT.EDU, GUMBY@AI.AI.MIT.EDU Message-ID: <501487.881209.DEVON@AI.AI.MIT.EDU> I tried the babyl 3F command on the following message, remailing To: elbows, devon Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 8 Dec 88 17:06:13 EST Received: from JONES.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 154206; Thu 8-Dec-88 16:46:00 EST Date: Thu, 8 Dec 88 16:45 EST From: Christopher C. Stacy Subject: I'm embarrassed to use COMSAT To: DEVON@AI.AI.MIT.EDU cc: GUMBY@AI.AI.MIT.EDU, BUG-COMSAT@AI.AI.MIT.EDU In-Reply-To: <500678.881208.GUMBY@AI.AI.MIT.EDU> Message-ID: <19881208214557.2.CSTACY@JONES.AI.MIT.EDU> I resent that. Actually, <498060.881204.DEVON@AI.AI.MIT.EDU> was resent from Devon, who got it by my resending it to him. AI's MTP (COMSAT) couldn't have munched the header in the manner indicated, unless it was handed a badly formed request. It could have been munched by BABYL, either directly or by requesting COMSAT to do something silly, or it could have happened on the other end by LION.WATERLOO.EDU or whatever. There isn't enough information here to say what happened because we don't know how DEVON tried to resend the message. And COMSAT saw FROM-PROGRAM:BABYL FROM-XUNAME:DEVON FROM-UNAME:DEVON HEADER-FORCE:RFC733 USER-HEADER:Orig-Date: Thu, 8 Dec 88 16:45 EST AUTHOR: Christopher C. Stacy USER-HEADER:To: DEVON at AI.AI.MIT.EDU USER-HEADER:cc: GUMBY at AI.AI.MIT.EDU, BUG-COMSAT at AI.AI.MIT.EDU SUBJECT: I'm embarrassed to use COMSAT USER-HEADER:ReSent-To: elbows, devon RCPT:(elbows@AI (R-OPTION BCC)) RCPT:(devon@AI (R-OPTION BCC)) TEXT;-1 I resent that. Actually, <498060.881204.DEVON@AI.AI.MIT.EDU> was resent from Devon, who got it by my resending it to him. AI's MTP (COMSAT) couldn't have munched the header in the manner indicated, unless it was handed a badly formed request. It could have been munched by BABYL, either directly or by requesting COMSAT to do something silly, or it could have happened on the other end by LION.WATERLOO.EDU or whatever. There isn't enough information here to say what happened because we don't know how DEVON tried to resend the message. Anyway, my mailbox got Date: Fri, 9 Dec 88 08:24:23 EST From: Christopher C. Stacy @AI.AI.MIT.EDU Sender: DEVON@AI.AI.MIT.EDU Subject: I'm embarrassed to use COMSAT To: ELBOWS@AI.AI.MIT.EDU, DEVON@AI.AI.MIT.EDU Orig-Date: Thu, 8 Dec 88 16:45 EST To: DEVON at AI.AI.MIT.EDU cc: GUMBY at AI.AI.MIT.EDU, BUG-COMSAT at AI.AI.MIT.EDU ReSent-To: elbows, devon Message-ID: <501438.881209.DEVON@AI.AI.MIT.EDU> I resent that. Actually, <498060.881204.DEVON@AI.AI.MIT.EDU> was resent from Devon, who got it by my resending it to him. AI's MTP (COMSAT) couldn't have munched the header in the manner indicated, unless it was handed a badly formed request. It could have been munched by BABYL, either directly or by requesting COMSAT to do something silly, or it could have happened on the other end by LION.WATERLOO.EDU or whatever. There isn't enough information here to say what happened because we don't know how DEVON tried to resend the message. ^_ So as you see this is a genuine COMSAT bug. I'm *not* complaining! Like the saying goes, if you don't like the food, you can do the cooking yourself, and I'm not into hacking on a MIDAS stove, although like Gren I would be glad to cook up C code.  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 8 Dec 88 17:33:31 EST Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 154226; Thu 8-Dec-88 17:30:10 EST Date: Thu, 8 Dec 88 17:30 EST From: Alan Bawden Subject: I'm embarrassed to use COMSAT To: DEVON@AI.AI.MIT.EDU cc: BUG-COMSAT@AI.AI.MIT.EDU, CSTACY@AI.AI.MIT.EDU In-Reply-To: <499306.881206.DEVON@AI.AI.MIT.EDU> Message-ID: <19881208223008.1.ALAN@PIGPEN.AI.MIT.EDU> Date: Tue, 6 Dec 88 03:54:07 EST From: Devon Sean McCullough Subject: I'm embarrassed to use COMSAT Then go use some other mailer. It does seem a shame to blame COMSAT, given that the problem is probably caused by Babyl putting the wrong thing in the MAIL > file, but that shouldn't stop you from taking your complaints elsewhere.  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 8 Dec 88 17:06:13 EST Received: from JONES.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 154206; Thu 8-Dec-88 16:46:00 EST Date: Thu, 8 Dec 88 16:45 EST From: Christopher C. Stacy Subject: I'm embarrassed to use COMSAT To: DEVON@AI.AI.MIT.EDU cc: GUMBY@AI.AI.MIT.EDU, BUG-COMSAT@AI.AI.MIT.EDU In-Reply-To: <500678.881208.GUMBY@AI.AI.MIT.EDU> Message-ID: <19881208214557.2.CSTACY@JONES.AI.MIT.EDU> I resent that. Actually, <498060.881204.DEVON@AI.AI.MIT.EDU> was resent from Devon, who got it by my resending it to him. AI's MTP (COMSAT) couldn't have munched the header in the manner indicated, unless it was handed a badly formed request. It could have been munched by BABYL, either directly or by requesting COMSAT to do something silly, or it could have happened on the other end by LION.WATERLOO.EDU or whatever. There isn't enough information here to say what happened because we don't know how DEVON tried to resend the message.  Date: Thu, 8 Dec 88 13:27:24 EST From: David Vinayak Wallace Subject: I'm embarrassed to use COMSAT To: DEVON@AI.AI.MIT.EDU cc: BUG-COMSAT@AI.AI.MIT.EDU, CSTACY@AI.AI.MIT.EDU In-reply-to: Msg of Tue 6 Dec 88 03:54:07 EST from Devon Sean McCullough Message-ID: <500678.881208.GUMBY@AI.AI.MIT.EDU> Date: Tue, 6 Dec 88 03:54:07 EST From: Devon Sean McCullough I'm not clear on whether this is a COMSAT problem or whether this is a stupidity in the BABYL command 3F which is how I sent the offending mail. This is more likely BB's problem since an error like this would likely show up more often. Anyway, you can't trust the headers which have come back from a sendmail host. Sendmail, like a TV preacher, cannot resist molesting headers which go by. Date: Mon, 5 Dec 88 10:43:23 PST From: sclafani at src.dec.com (Michael Sclafani) To: seven at vax.ftp.com cc: elbows at bloom-beacon.mit.edu Re: Returned mail: Deferred: Bad file number Sigh. Looks like DEVON (probably) or CStacy resent a risks message to elbows@AI.AI.MIT.EDU. AI's mail transport agent blindly tacked on "@AI.AI.MIT.EDU" to the "from" field, generating an illegal address. (Can you say "bogus"?) bloom-beacon then either choked on the illegal address, or tried to fix it, or whatever. I don't know enough to determine where the other failures are, but I think that AI isn't generating a correct return-path for failures, or beacon is ignoring the return path, and using the from field for rejections, or some other machine is doing same. Yours for Compliant mailers, /Scliff Note the FROM line in the ITS-perpetrated header below: Received: from AI.AI.MIT.EDU by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Sun, 4 Dec 88 09:43:35 EST Resent-Date: Sun, 4 Dec 88 09:43:30 EST Resent-Message-Id: <8812041443.AA14969@BLOOM-BEACON.MIT.EDU> Date: Sun, 4 Dec 88 09:43:30 EST From: Kevyn Collins-Thompson @AI.AI.MIT.EDU Sender: DEVON@AI.AI.MIT.EDU Subject: Mix-up Impedes Romance To: ELBOWS@AI.AI.MIT.EDU, ERRIS@AI.AI.MIT.EDU, K-E@AI.AI.MIT.EDU Orig-Date: Fri, 2 Dec 88 12:02:38 EST To: RISKS-LIST@KL.SRI.COM Resent-From: Christopher C. Stacy Resent-To: elbows, erris, k-e Message-Id: <498060.881204.DEVON@AI.AI.MIT.EDU>  Date: Tue, 6 Dec 88 03:54:07 EST From: Devon Sean McCullough Subject: I'm embarrassed to use COMSAT To: BUG-COMSAT@AI.AI.MIT.EDU, CSTACY@AI.AI.MIT.EDU, DEVON@AI.AI.MIT.EDU Message-ID: <499306.881206.DEVON@AI.AI.MIT.EDU> I'm not clear on whether this is a COMSAT problem or whether this is a stupidity in the BABYL command 3F which is how I sent the offending mail. Date: Mon, 5 Dec 88 10:43:23 PST From: sclafani at src.dec.com (Michael Sclafani) To: seven at vax.ftp.com cc: elbows at bloom-beacon.mit.edu Re: Returned mail: Deferred: Bad file number Sigh. Looks like DEVON (probably) or CStacy resent a risks message to elbows@AI.AI.MIT.EDU. AI's mail transport agent blindly tacked on "@AI.AI.MIT.EDU" to the "from" field, generating an illegal address. (Can you say "bogus"?) bloom-beacon then either choked on the illegal address, or tried to fix it, or whatever. I don't know enough to determine where the other failures are, but I think that AI isn't generating a correct return-path for failures, or beacon is ignoring the return path, and using the from field for rejections, or some other machine is doing same. Yours for Compliant mailers, /Scliff Note the FROM line in the ITS-perpetrated header below: Received: from AI.AI.MIT.EDU by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Sun, 4 Dec 88 09:43:35 EST Resent-Date: Sun, 4 Dec 88 09:43:30 EST Resent-Message-Id: <8812041443.AA14969@BLOOM-BEACON.MIT.EDU> Date: Sun, 4 Dec 88 09:43:30 EST From: Kevyn Collins-Thompson @AI.AI.MIT.EDU Sender: DEVON@AI.AI.MIT.EDU Subject: Mix-up Impedes Romance To: ELBOWS@AI.AI.MIT.EDU, ERRIS@AI.AI.MIT.EDU, K-E@AI.AI.MIT.EDU Orig-Date: Fri, 2 Dec 88 12:02:38 EST To: RISKS-LIST@KL.SRI.COM Resent-From: Christopher C. Stacy Resent-To: elbows, erris, k-e Message-Id: <498060.881204.DEVON@AI.AI.MIT.EDU>  Date: Fri, 2 Dec 88 20:19:02 EST From: David Vinayak Wallace Subject: Did I do something wrong? To: ZVONA@AI.AI.MIT.EDU cc: BUG-MAIL@AI.AI.MIT.EDU, MBECK@AI.AI.MIT.EDU In-reply-to: Msg of Fri 2 Dec 88 10:48:34 EST from David Chapman Message-ID: <497470.881202.GUMBY@AI.AI.MIT.EDU> Though if you look in the domain RFC it's legal. That is, every domain conceptually ends with which, for convenience's sake, can be omitted. I wonder how many domain name parsers actually implement this?  Date: Fri, 2 Dec 88 10:48:34 EST From: David Chapman Subject: Did I do something wrong? To: MBECK@AI.AI.MIT.EDU cc: BUG-MAIL@AI.AI.MIT.EDU In-reply-to: Msg of Fri 2 Dec 88 09:30:16 EST from Mark Becker Message-ID: <497070.881202.ZVONA@AI.AI.MIT.EDU> It didn't like the extra period after .edu. "GREN@AI.AI.MIT.EDU." at AI.AI.MIT.EDU is an unknown recipient. ^ |  Date: Fri, 2 Dec 88 09:30:16 EST From: Mark Becker Subject: Did I do something wrong? To: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <497011.881202.MBECK@AI.AI.MIT.EDU> COMSAT returned this. WHOIS says GREN exists. What did I do wrong? Note: The original "To:" field was GREN@AI.AI.MIT.EDU. Date: Fri, 2 Dec 88 09:24:42 EST From: Communications Satellite ============ A copy of your message is being returned, because: ============ "GREN@AI.AI.MIT.EDU." at AI.AI.MIT.EDU is an unknown recipient. ============ Failed message follows: ============ Date: Fri, 2 Dec 88 09:24:41 EST From: Mark Becker Subject: Lost mail To: "GREN@AI.AI.MIT.EDU."@AI.AI.MIT.EDU Message-ID: <497005.881202.MBECK@AI.AI.MIT.EDU> I don't know why the Dead Mail Reaper though that mail was dead.. I received it several days ago. Mark  Date: Thu, 10 Nov 88 17:53:01 EST From: "Pandora B. Berman" Subject: mail to LL still doesn't work To: BUG-MAIL@AI.AI.MIT.EDU cc: fritz@LL.ARPA Message-ID: <483645.881110.CENT@AI.AI.MIT.EDU> (let's see if quoting his address this way will fake out COMSAT.) in response to my explanation to W8SDZ that mailing his digests to LL.ARPA via ITS doesn't work: Received: from LL.ARPA (TCP 1200000012) by AI.AI.MIT.EDU 10 Nov 88 10:30:42 EST Date: Thu 10 Nov 1988 10:26:19 EST From: Subject: LL.ARPA connection To: CENT@ai.ai.mit.edu Message-ID: I received a copy of your complaint to WSMR-SIMTEL20.ARMY.MIL about sending mail to LL.ARPA. We also have noticed your efforts to send us mail. I would be willing to work with someone at your facility to repair the problem. It is somewhat local in that we have only noticed this problem with MIT.EDU. It is noticed with AI.AI.MIT.EDU and MC.LCS.MIT.EDU. We do have a non standard TCP and SMTP but they can be repaired. Glad to help. Fritz WIllmann (617) 981-2770  Date: Thu, 10 Nov 88 00:17:45 EST From: "Pandora B. Berman" Subject: LL.ARPA loses big To: FJW@AI.AI.MIT.EDU, w8sdz@WSMR-SIMTEL20.ARMY.MIL cc: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <483052.881110.CENT@AI.AI.MIT.EDU> i just flushed a couple of msgs from MC's queue due to excessive age; they were digests from SIMTEL20, so they bounced back to you under their various -REQUEST list names. sample header: ---------- Received: from SIMTEL20.ARMY.MIL (TCP 3200000112) by MC.LCS.MIT.EDU 20 Sep 88 07:25:44 EDT Date: Tue, 20 Sep 88 01:30:48 MDT From: INFO-HAMS-REQUEST@SIMTEL20.ARMY.MIL Reply-To: INFO-HAMS@SIMTEL20.ARMY.MIL Subject: INFO-HAMS Digest V88 #367 To: INFO-HAMS@SIMTEL20.ARMY.MIL INFO-HAMS Digest Tue, 20 Sep 88 Volume 88 : Issue 367 ---------- the reason they were still hanging around trying to be sent is that they were trying to be sent to LL.ARPA. the ITSs have a problem of long standing in trying to communicate with LL.ARPA -- basically, we can't, and haven't been able to for at least a couple years. i assume this is due to some arcane disagreement concerning our ideas of how to do TCP and theirs, or something of similar immovability. most of the time, the ITSs can't open a connection to LL at all. when one manages to, the following situation invariably occurs (from AI STATS file): 084118 Unqueueing to host LL.ARPA 084119 ICP->LL.ARPA (TCP-SMTP) 084147 QID=<473091.881027@AI.AI.MIT.EDU> 084147 TO->SAGE ...NTMSND IOC error i do mean invariably. possibly someone more technically adept than i can explain why this never works. however, in the mean time, all mail you send to LL.ARPA via any ITS will just clog up our mail queues; if you want it to actually get through, you need to find another route for it.  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 6 Nov 88 18:01:46 EST Received: from GAYE.AI.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 6 Nov 88 17:57-EST Date: Sun, 6 Nov 88 17:56 EST From: David Vinayak Wallace Subject: getting to bitnet To: Pandora B. Berman cc: dead-flames-request@MC.LCS.MIT.EDU, BUG-MAIL@AI.AI.MIT.EDU In-Reply-To: <473043.881027.CENT@AI.AI.MIT.EDU> Message-ID: <881106175622.5.GUMBY@GAYE.AI.MIT.EDU> Date: Thu, 27 Oct 88 01:53:21 EDT From: "Pandora B. Berman" a whole pissload of dead-flames goes to bitnet via CUNYVM. i bet things would be speeded up if this stuff went via MITVMA instead, since that's so near a hop from MC. I would, but mitvm doesn't guarentee to forward everything any more; cuny is the official gateway.  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 6 Nov 88 17:59:46 EST Received: from GAYE.AI.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 6 Nov 88 17:55-EST Date: Sun, 6 Nov 88 17:54 EST From: David Vinayak Wallace Subject: [COMSAT: forwarded] To: David Chapman cc: BUG-COMSAT@AI.AI.MIT.EDU In-Reply-To: <476042.881031.ZVONA@AI.AI.MIT.EDU> Message-ID: <881106175416.3.GUMBY@GAYE.AI.MIT.EDU> Date: Mon, 31 Oct 88 19:40:41 EST From: David Chapman I don't see why this should go to mail-maintainers (and so clutter up FAILED STUFF). Date: Mon, 31 Oct 88 19:31:15 EST From: Communications Satellite To: ZVONA at MC.LCS.MIT.EDU cc: MAIL-MAINTAINERS at MC.LCS.MIT.EDU Error in input request file. Parsing error: Bad SITE spec - "@APOLLO.COM" Line stopped at is: RCPT:(shuster_m @APOLLO.COM) Message not sent and not queued;text of bad file follows: -------- There are two reasons. Both depend on the fact that most mail users are naive and won't know what to do when this happens: 1> I have peeked in there and discovered host table changes I didn't know had happened, and hence have cleaned up some lists. 2> It's nice to be able to be able to redirect naive users. Now, both of these depend on having knowledgeable people around to look into this. I used to do this before I got the dead-flames digested. However since the Institute still requires theses I'm sure that from time to time there will be people who feel compelled to clean up this file!  Date: Thu, 3 Nov 88 17:56:12 EST From: Jonathan A Rees Subject: digests on MC To: CENT@AI.AI.MIT.EDU cc: BUG-MAIL@AI.AI.MIT.EDU In-reply-to: Msg of Wed 19 Oct 88 02:45:30 EDT from "Pandora B. Berman" Message-ID: <478440.881103.JAR@AI.AI.MIT.EDU> SCHEME is now a digest, as of last night. I hope this helps make life a little easier for MC's COMSAT.  Date: Mon, 31 Oct 88 19:40:41 EST From: David Chapman Subject: [COMSAT: forwarded] To: BUG-COMSAT@AI.AI.MIT.EDU Message-ID: <476042.881031.ZVONA@AI.AI.MIT.EDU> I don't see why this should go to mail-maintainers (and so clutter up FAILED STUFF). Date: Mon, 31 Oct 88 19:31:15 EST From: Communications Satellite To: ZVONA at MC.LCS.MIT.EDU cc: MAIL-MAINTAINERS at MC.LCS.MIT.EDU Error in input request file. Parsing error: Bad SITE spec - "@APOLLO.COM" Line stopped at is: RCPT:(shuster_m @APOLLO.COM) Message not sent and not queued;text of bad file follows: -------- ...  Date: Sun, 30 Oct 88 03:42:27 EST From: "Pandora B. Berman" Subject: comsat is broken (so what else is new) To: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <474938.881030.CENT@AI.AI.MIT.EDU> COMSAT has this problem with dequeuing mail. sometimes, when it successfully sends out a queued msg, it then sends a CMSG to the msg's (apparent) author. whenever it does this, it next proceeds to lose by timing out when it tried to dequeue the next msg to that host. for example: 081637 Unqueueing to host MC.LCS.MIT.EDU 081637 ICP->MC.LCS.MIT.EDU (CHAOS-SMTP) 081639 QID=<473707.881027.CENT@AI.AI.MIT.EDU> 081639 TO->HEADER-PEOPLE-REQUEST 081642 CMSG ID=<473924.881028@AI.AI.MIT.EDU> EXP->CENT@1200400006 081643 Local->AI.AI.MIT.EDU 081643 TO->CENT 081644 QID=<473710.881027.CENT@AI.AI.MIT.EDU>...Timeout this happens regardless of recipient host (ITS, twenex, unix, etc.). alan suggests that the problem has to do with COMSAT's state saving mechanism -- i.e. when COMSAT is going to send such a CMSG, it stashes away some idea of what state to return to after the CMSG, but in doing so, fucks up somehow (at least for dequeuing mail). i have found only one host that AI COMSAT could dequeue to, send a resultant CMSG, and then continue to successfully dequeue to -- ML. damned if i understand why, since AI does have this problem with MC and MD. this was for one long spate of dequeuing all its mail for ML; alan suggests that perhaps AI simply lucked out and had the right thing in the right accumulator in this instance.  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 30 Oct 88 02:49:51 EST Date: Sun, 30 Oct 1988 02:45 EST Message-ID: From: JTW@XX.LCS.MIT.EDU To: CENT@AI.AI.MIT.EDU, cph@WHEATIES.AI.MIT.EDU cc: BUG-MAIL@AI.AI.MIT.EDU Subject: mail lossage In-reply-to: Msg of 30 Oct 1988 02:04-EDT from Pandora B. Berman There's a standard bug where if you run sendmail right out of the box it uses as the EOL character, instead of like the spec says. This is berkeley braindamage, which perhaps HP didn't fix. There's a configuration option which tells sendmail to follow the spec, but I can't recall exactly what it is. -john  Date: Sun, 30 Oct 88 01:04:27 EST From: "Pandora B. Berman" Subject: mail lossage To: cph@WHEATIES.AI.MIT.EDU cc: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <474883.881030.CENT@AI.AI.MIT.EDU> we gotta problem with KLEPH and MURREN and CHAMARTIN, and possibly a couple other machines i have forgotten. alan says these are the 4th floor HP sort. i am deliberately sending this msg to you via WH because i have reason to believe that sending directly would excite the exact bug we're seeing. if there is someone downstairs more responsible for mail on the bobcats than you, please pass this word along. when AI opens a TCP-SMTP connection to any of these machines, this is what happens every time: 073559 Unqueueing to host CHAMARTIN.AI.MIT.EDU 073559 ICP->CHAMARTIN.AI.MIT.EDU (TCP-SMTP) 073601 QID=<467542.881019@AI.AI.MIT.EDU>...Timeout 074102 Unqueueing to host MC.LCS.MIT.EDU in other words, AI gets the connection, and then after five minutes it times out, presumably without getting anything through. alan says there is presumably some lack of good communication between COMSAT and the HP mail servers on these machines, and he suspects end-of-line chars -- i.e. COMSAT is sending some combination the bobcats can't deal with, or vice versa. please look into this. as the date in the sample msg number shows, this has been going on for over a week, and we have a lot of mail backed up here trying to get through. thanks.  Date: Thu, 27 Oct 88 01:53:21 EDT From: "Pandora B. Berman" Subject: getting to bitnet To: dead-flames-request@MC.LCS.MIT.EDU cc: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <473043.881027.CENT@AI.AI.MIT.EDU> a whole pissload of dead-flames goes to bitnet via CUNYVM. i bet things would be speeded up if this stuff went via MITVMA instead, since that's so near a hop from MC.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 26 Oct 88 21:15:39 EDT Date: Wed, 26 Oct 88 21:12:54 EDT From: Alan Bawden To: BUG-MAIL@MC.LCS.MIT.EDU Message-ID: <496989.881026.ALAN@MC.LCS.MIT.EDU> Once again, I have turned incoming mail off for MC. I did this because there was barely enough room to GC LISTS MSGS. Let's leave it this way until sometime tomorrow to see if we can get LISTS MSGS back down below 2000 blocks...  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 26 Oct 88 17:28:26 EDT Received: from OTIS.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 145474; Wed 26-Oct-88 17:25:14 EDT Date: Wed, 26 Oct 88 17:25 EDT From: Alan Bawden Subject: bulk digests To: ZVONA@AI.AI.MIT.EDU cc: BUG-MAIL@AI.AI.MIT.EDU In-Reply-To: <471612.881025.ZVONA@AI.AI.MIT.EDU> Message-ID: <19881026212512.6.ALAN@OTIS.AI.MIT.EDU> Date: Tue, 25 Oct 88 14:59:15 EDT From: David Chapman So as long as there are no local recipients on a BULK list, it's OK? That's easy, then: indirect local recpients, if any, through AI or someplace. Should we start systematically moving big lists to BULK? Hold on. It's not as easy as you think to control local delivery. Recall that people can change their INQUIR entries to say that mail should be sent to them @MC, which the BULK mailer will see, and then they can edit .MAIL.;NAMES > to say where it should really go, which the BULK mailer will -not- see, and it will thus start delivering locally. Also, when the host table changes, and an address suddenly becomes unparsable, the mailer will revert to local delivery. It would be better if we were to first introduce a lock to control local delivery, and then arrange for the BULK mailer to share the NAMES file somehow.  Date: Wed, 26 Oct 88 06:06:55 EDT From: "Pandora B. Berman" Subject: truly moby digest To: dead-flames-request@MC.LCS.MIT.EDU cc: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <472293.881026.CENT@AI.AI.MIT.EDU> dead-flames digest was 24 blocks long this morning. alan and i watched COMSAT with awe as for several hours it diligently pushed this through to all the recipients. well, almost all. after (or perhaps while) delivering the msg text to EDDIE, COMSAT ran out of address space and fell over. i renamed the digest in question from MAILIN > to BADREQ > and started comsat up again. you are welcome to either figure out who didn't get it and send it directly to them, or just delete it.  Date: Tue, 25 Oct 88 14:59:15 EDT From: David Chapman Subject: bulk digests To: ALAN@AI.AI.MIT.EDU cc: BUG-MAIL@AI.AI.MIT.EDU In-reply-to: Msg of Mon 24 Oct 88 22:11 EDT from Alan Bawden Message-ID: <471612.881025.ZVONA@AI.AI.MIT.EDU> So as long as there are no local recipients on a BULK list, it's OK? That's easy, then: indirect local recpients, if any, through AI or someplace. Should we start systematically moving big lists to BULK?  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 24 Oct 88 22:14:05 EDT Received: from OTIS.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 145055; Mon 24-Oct-88 22:11:17 EDT Date: Mon, 24 Oct 88 22:11 EDT From: Alan Bawden Subject: bulk digests To: ZVONA@AI.AI.MIT.EDU cc: BUG-MAIL@AI.AI.MIT.EDU In-Reply-To: <467600.881019.ZVONA0@AI.AI.MIT.EDU> Message-ID: <19881025021120.3.ALAN@OTIS.AI.MIT.EDU> Date: Wed, 19 Oct 88 16:01:16 EDT From: David Chapman I thought that the BULK mailer was still believed not to be reliable. (Am I wrong about this?) The problems about local delivery that existed at the time I originally started the BULK mailer have not yet been dealt with. I believe KLH suggested the best method for doing the necessary locking (he pointed out that a single filesystem-wide lock would be sufficient), but nobody has done that yet. Other than this, I don't know of any reliability problems.  Date: Mon, 24 Oct 88 17:14:17 EDT From: David Chapman Subject: ADA-SW overload To: WANCHO@SIMTEL20.ARMY.MIL cc: BUG-MAIL@AI.AI.MIT.EDU, W8SDZ@SIMTEL20.ARMY.MIL, SRA@XX.LCS.MIT.EDU In-reply-to: Msg of Sat 22 Oct 1988 12:46 MDT from Frank J. Wancho Message-ID: <470861.881024.ZVONA@AI.AI.MIT.EDU> I'm sorry to have been a bit rude about ADA-SW; I didn't intend for you to see that message as written, and we're in crisis mode here. BULK COMSAT is an experimental mailer feature for delivering large lists. I think that it's still considered unreliable, though I don't know. (I was hoping somone else would answer this message.) David  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 22 Oct 88 15:16:42 EDT Date: Sat, 22 Oct 88 15:14:23 EDT From: David Chapman Sender: ZVONA0@MC.LCS.MIT.EDU To: BUG-COMSAT@MC.LCS.MIT.EDU Message-ID: <494742.881022.ZVONA0@MC.LCS.MIT.EDU> If it were a one-line patch, it might help in the current circumstances if COMSAT didn't bother trying to contact arpanet hosts when the net was down..  Received: from SIMTEL20.ARMY.MIL (TCP 3200000112) by AI.AI.MIT.EDU 22 Oct 88 14:48:37 EDT Date: Sat, 22 Oct 1988 12:46 MDT Message-ID: From: "Frank J. Wancho" Subject: ADA-SW overload To: Rob Austein Cc: bug-mail@AI.AI.MIT.EDU, W8SDZ@SIMTEL20.ARMY.MIL, Wancho@SIMTEL20.ARMY.MIL, Zvona@AI.AI.MIT.EDU In-reply-to: Msg of 22 Oct 1988 10:58-MDT from Rob Austein Rob and Dave, The ADA-SW list had been a low traffic list until earlier this week when its maintainer sent out a whole slew of messages (it is a one-way list). As a result, he now sends messages into the auto-digest queue when he knows he's about to send several individual announcements, and to the single queue for just one in a 24-hour period. I know this doesn't help the load caused by the messages already in the queue, but I think we can safely say this problem won't occur again with that list. What determines which list is set up for the single message queue or the auto-digest queue is based on the average volume. Lists with more than, say three messages a day, on the average, get routed to the auto-digest queue. ADA-SW was an oddball in that it would be inactive for long periods of time and then have a burst of messages. Now there is some control on that. Now, tell me about BULK COMSAT... --Frank  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 22 Oct 88 13:01:44 EDT Date: Sat 22 Oct 88 12:58:14-EDT From: Rob Austein To: Zvona@AI.AI.MIT.EDU, Wancho@SIMTEL20.ARMY.MIL, W8SDZ@SIMTEL20.ARMY.MIL cc: bug-mail@AI.AI.MIT.EDU In-Reply-To: <19881022000050.3.ZVONA@MARLEY.AI.MIT.EDU> Message-ID: <12440491028.15.SRA@XX.LCS.MIT.EDU> Date: Fri, 21 Oct 88 20:00 EDT From: David Chapman I've been watching the mail queue on MC, trying to figure where the computrons are going. SCHEME is taking up a lot, HEADER-PEOPLE is taking up a lot. ADA-SW is taking up a lot. ADA-SW? Well, there is no ADA-SW on MC; some hoser at SIMTEL20 is just routing a lot of his mailing list's mail through it. (See file below.) Is there any reason not to tell him to stop? [*Long* example quoted by Zvona removed here] I think the theory behind this (as I heard it second hand from Mark Crispin) is that SIMTEL20 should handle anything on the MILNET side of the line and MC should handle anything on the ARPANET side of the line. Which on the face of it sort of makes sense. But David's right, the volume involved here has gotten entirely out of hand. If this (or the other lists that appear to have been split between SIMTEL20 and MC) were based on MC, we would eventually either mark the list as something that must go through the BULK COMSAT or must be run through the auto-DIGESTifier or something. As it is, we have no control over how much of MC's time is taken up by stuff offloaded from SIMTEL20. I appreciate the good job you guys are doing at SIMTEL20 trying to keep all these public service lists going; I think we all do. I even sort of agree in principle with the idea of the ARPANET/MILNET split, given how wedged the mailbridge links always are. But I think the time has come for us to all talk about policy and that sort of thing, because it seems that much of the problem you guys were complaining about earlier this week is of your own making. Not to mention MC's functions as a local mail router (eg, the *BBOARD and *MIT lists) are being seriously damaged by this kind of overload, causing our own users to bitch and moan. Thanks.... --Rob (for Postmaster@MC.LCS.MIT.EDU) -------  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 21 Oct 88 20:14:14 EDT Received: from MARLEY.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 144520; Fri 21-Oct-88 20:12:03 EDT Date: Fri, 21 Oct 88 20:12 EDT From: David Chapman To: bug-mail@AI.AI.MIT.EDU Message-ID: <19881022001204.5.ZVONA@MARLEY.AI.MIT.EDU> Ditto INFO-HAMS, so there's probably an open-ended list of these we'll have to track down if we take action on them.  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 21 Oct 88 20:10:51 EDT Received: from MARLEY.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 144518; Fri 21-Oct-88 20:08:40 EDT Date: Fri, 21 Oct 88 20:08 EDT From: David Chapman Subject: indirecting mail through MC To: bug-mail@AI.AI.MIT.EDU Message-ID: <19881022000841.4.ZVONA@MARLEY.AI.MIT.EDU> VIDEOTECH is doing the same thing (though at least they had the decency to put an entry for it into the NAMES file).  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 21 Oct 88 20:03:15 EDT Received: from MARLEY.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 144515; Fri 21-Oct-88 20:00:50 EDT Date: Fri, 21 Oct 88 20:00 EDT From: David Chapman To: bug-mail@AI.AI.MIT.EDU Message-ID: <19881022000050.3.ZVONA@MARLEY.AI.MIT.EDU> I've been watching the mail queue on MC, trying to figure where the computrons are going. SCHEME is taking up a lot, HEADER-PEOPLE is taking up a lot. ADA-SW is taking up a lot. ADA-SW? Well, there is no ADA-SW on MC; some hoser at SIMTEL20 is just routing a lot of his mailing list's mail through it. (See file below.) Is there any reason not to tell him to stop? NET-MAIL-FROM-HOST:3200000112 RETURN-PATH:@SIMTEL20.ARMY.MIL:ADA-SW-REQUEST@SIMTEL20.ARMY.MIL TO:"11TSTARK%GALLUA.BITNET%CUNYVM.CUNY.EDU@MC.LCS.MIT.EDU TO:"203013%DHHMPI5D.BITNET%CUNYVM.CUNY.EDU@MC.LCS.MIT.EDU TO:"26631853%WSUVM1.BITNET%CUNYVM.CUNY.EDU@MC.LCS.MIT.EDU TO:"381752%UOTTAWA.BITNET%CUNYVM.CUNY.EDU@MC.LCS.MIT.EDU TO:"5005P%NAVPGS.BITNET%CUNYVM.CUNY.EDU@MC.LCS.MIT.EDU TO:"ab%BU-CS.BU.EDU@MC.LCS.MIT.EDU TO:"ada%JOVE.CAM.UNISYS.COM@MC.LCS.MIT.EDU TO:"ADASW%muvms1.bitnet%CUNYVM.CUNY.EDU@MC.LCS.MIT.EDU TO:"ADASW%UMASS-CS%RELAY.CS.NET@MC.LCS.MIT.EDU TO:"ada-sw%EECS.NWU.EDU@MC.LCS.MIT.EDU TO:"ada-sw%SCCGATE.SCC.COM@MC.LCS.MIT.EDU TO:"ada-sw%SEI.CMU.EDU@MC.LCS.MIT.EDU TO:"ada-sw%alcoa.com%RELAY.CS.NET@MC.LCS.MIT.EDU TO:"ada-sw%sperry-csd%RELAY.CS.NET@MC.LCS.MIT.EDU TO:"ada-sw-incoming%csc.ti.com%TI.COM@MC.LCS.MIT.EDU TO:"adaskl%SKL-CRC.ARPA@MC.LCS.MIT.EDU TO:"AJZ%NIHCU.BITNET%CUNYVM.CUNY.EDU@MC.LCS.MIT.EDU TO:"akopp%AJPO.SEI.CMU.EDU@MC.LCS.MIT.EDU TO:"ALESTER%UGA.BITNET%CUNYVM.CUNY.EDU@MC.LCS.MIT.EDU TO:"ALEXANDR%IBM.COM@MC.LCS.MIT.EDU TO:"AOVS754%UTA3081.BITNET%CUNYVM.CUNY.EDU@MC.LCS.MIT.EDU TO:"arpalists#ada-sw%ANDREW.CMU.EDU@MC.LCS.MIT.EDU TO:"asp%SEI.CMU.EDU@MC.LCS.MIT.EDU TO:"august%VLSI.JPL.NASA.GOV@MC.LCS.MIT.EDU TO:"B36960%ANLEES.BITNET%CUNYVM.CUNY.EDU@MC.LCS.MIT.EDU TO:"bam%burdvax.prc.unisys.com@MC.LCS.MIT.EDU TO:"BAUM%TAMVXOCN.BITNET%CUNYVM.CUNY.EDU@MC.LCS.MIT.EDU TO:"BB_ADA_SW%smr.sdr.slb.com%RELAY.CS.NET@MC.LCS.MIT.EDU TO:"BBARDIN%AJPO.SEI.CMU.EDU@MC.LCS.MIT.EDU TO:"bbb%SEI.CMU.EDU@MC.LCS.MIT.EDU TO:"BGABLE%AJPO.SEI.CMU.EDU@MC.LCS.MIT.EDU TO:"bowman%AJPO.SEI.CMU.EDU@MC.LCS.MIT.EDU TO:"Brender%TLE.DEC%DECWRL.DEC.COM@MC.LCS.MIT.EDU TO:"brett%tle.DEC%DECWRL.DEC.COM@MC.LCS.MIT.EDU TO:"bryan%SIERRA.STANFORD.EDU@MC.LCS.MIT.EDU TO:"BYRNE%ARECIBO.AERO.ORG@MC.LCS.MIT.EDU TO:"C2390N%UMVMA.BITNET%CUNYVM.CUNY.EDU@MC.LCS.MIT.EDU TO:"CDONALDSON%AJPO.SEI.CMU.EDU@MC.LCS.MIT.EDU TO:"cja%EECS.UMICH.EDU@MC.LCS.MIT.EDU TO:"cmh%SUNSPOT.LARC.NASA.GOV@MC.LCS.MIT.EDU TO:"colket%SEI.CMU.EDU@MC.LCS.MIT.EDU TO:"COMUSER%JPNTSCVM.BITNET%CUNYVM.CUNY.EDU@MC.LCS.MIT.EDU TO:"CROBY%AJPO.SEI.CMU.EDU@MC.LCS.MIT.EDU TO:"ctabka%TSCA.ISTC.SRI.COM@MC.LCS.MIT.EDU TO:"CWILLIAMS%BLUTO.SCC.COM@MC.LCS.MIT.EDU TO:"DASMITH%AJPO.SEI.CMU.EDU@MC.LCS.MIT.EDU TO:"DDG7959%TAMVENUS.BITNET%CUNYVM.CUNY.EDU@MC.LCS.MIT.EDU TO:"decwrl!nsc!nsc.NSC.COM!baer1%UCBVAX.BERKELEY.EDU@MC.LCS.MIT.EDU TO:"denny%dione.cray.com%UC.MSC.UMN.EDU@MC.LCS.MIT.EDU TO:"DSADABB%M_DSAVX1%SLB-DOLL.CSNET%RELAY.CS.NET@MC.LCS.MIT.EDU TO:"DSMITH%AJPO.SEI.CMU.EDU@MC.LCS.MIT.EDU TO:"dsr%hector%ATT.ARPA@MC.LCS.MIT.EDU TO:"E02Z9001%TWNMOE10.BITNET%CUNYVM.CUNY.EDU@MC.LCS.MIT.EDU TO:"EBERARD%AJPO.SEI.CMU.EDU@MC.LCS.MIT.EDU TO:"edob0133%dhiurz1.BITNET%CUNYVM.CUNY.EDU@MC.LCS.MIT.EDU TO:"EHEATER%AJPO.SEI.CMU.EDU@MC.LCS.MIT.EDU TO:"enea!vaxs.ericsson.se!yzykkg%SEISMO.CSS.GOV@MC.LCS.MIT.EDU TO:"engvax!ada-sw%CSVAX.CALTECH.EDU@MC.LCS.MIT.EDU TO:"erland%cs.chalmers.se%RELAY.CS.NET@MC.LCS.MIT.EDU TO:"farber%HUEY.UDEL.EDU@MC.LCS.MIT.EDU TO:"FCDU3%VTVM2.BITNET%CUNYVM.CUNY.EDU@MC.LCS.MIT.EDU TO:"floyd!clyde!wayback!amb%UCBVAX.BERKELEY.EDU@MC.LCS.MIT.EDU TO:"floyd!clyde!wayback!arny%UCBVAX.BERKELEY.EDU@MC.LCS.MIT.EDU TO:"floyd!clyde!bonnie!wayback!nco%UCBVAX.BERKELEY.EDU@MC.LCS.MIT.EDU TO:"fortin%zap.uucp%larry.mcrcim.mcgill.edu@MC.LCS.MIT.EDU TO:"FREDYU%AJPO.SEI.CMU.EDU@MC.LCS.MIT.EDU TO:"frigo%cernvax.BITNET%CUNYVM.CUNY.EDU@MC.LCS.MIT.EDU TO:"gargaro%AJPO.SEI.CMU.EDU@MC.LCS.MIT.EDU TO:"GAUSTIN%AJPO.SEI.CMU.EDU@MC.LCS.MIT.EDU TO:"GBOOCH%AJPO.SEI.CMU.EDU@MC.LCS.MIT.EDU TO:"GDAU100%BGUVM.BITNET%CUNYVM.CUNY.EDU@MC.LCS.MIT.EDU TO:"GGRCS%UNO.BITNET%CUNYVM.CUNY.EDU@MC.LCS.MIT.EDU TO:"GILBERT%YALEVMX.BITNET%CUNYVM.CUNY.EDU@MC.LCS.MIT.EDU TO:"GMCKEE%AJPO.SEI.CMU.EDU@MC.LCS.MIT.EDU TO:"goheen%KL.SRI.COM@MC.LCS.MIT.EDU TO:"going%myrtle%SUN.COM@MC.LCS.MIT.EDU TO:"Goodenough%SEI.CMU.EDU@MC.LCS.MIT.EDU TO:"GOOSSENS%CERNVM.BITNET%CUNYVM.CUNY.EDU@MC.LCS.MIT.EDU TO:"GR2173%SIUCVMB.BITNET%CUNYVM.CUNY.EDU@MC.LCS.MIT.EDU TO:"GXP2F%UOTADM02.BITNET%CUNYVM.CUNY.EDU@MC.LCS.MIT.EDU TO:"HANLEY%ASD.SPAN%STAR.STANFORD.EDU@MC.LCS.MIT.EDU TO:"HAUG%VAX.RUNIT.UNIT.UNINETT%TOR.NTA.NO@MC.LCS.MIT.EDU TO:"hermix!info-ada%RAND-UNIX.ARPA@MC.LCS.MIT.EDU TO:"HHUMMEL%AJPO.SEI.CMU.EDU@MC.LCS.MIT.EDU TO:"hight%TSCA.ISTC.SRI.COM@MC.LCS.MIT.EDU TO:"HROMANOWSKY%AJPO.SEI.CMU.EDU@MC.LCS.MIT.EDU TO:"HUEBSCH%UTKVX3.BITNET%CUNYVM.CUNY.EDU@MC.LCS.MIT.EDU TO:"HWCHOY%ZPOV01.DEC%DECWRL.DEC.COM@MC.LCS.MIT.EDU TO:"incoming-ada-sw%BURDVAX.PRC.UNISYS.COM@MC.LCS.MIT.EDU TO:"INTEREST_GROUP_SERVER%IBM.COM@MC.LCS.MIT.EDU TO:"IO60217%MAINE.BITNET%CUNYVM.CUNY.EDU@MC.LCS.MIT.EDU TO:"IR1779%SER.BITNET%CUNYVM.CUNY.EDU@MC.LCS.MIT.EDU TO:"JACKSON%UOTTAWA.BITNET%CUNYVM.CUNY.EDU@MC.LCS.MIT.EDU TO:"jbrookshire%AJPO.SEI.CMU.EDU@MC.LCS.MIT.EDU TO:"JDW4794%TNTECH.BITNET%CUNYVM.CUNY.EDU@MC.LCS.MIT.EDU TO:"JFTJF%ALASKA.BITNET%CUNYVM.CUNY.EDU@MC.LCS.MIT.EDU TO:"JIMR%CLARGRAD.BITNET%CUNYVM.CUNY.EDU@MC.LCS.MIT.EDU TO:"JKUNDIG%AJPO.SEI.CMU.EDU@MC.LCS.MIT.EDU TO:"JREDDAN%AJPO.SEI.CMU.EDU@MC.LCS.MIT.EDU TO:"jtf%SEI.CMU.EDU@MC.LCS.MIT.EDU TO:"JUGED%AJPO.SEI.CMU.EDU@MC.LCS.MIT.EDU TO:"JWOLFE%AJPO.SEI.CMU.EDU@MC.LCS.MIT.EDU TO:"JWS%PSUARLC.BITNET%CUNYVM.CUNY.EDU@MC.LCS.MIT.EDU TO:"kailand!smcf%UXC.CSO.UIUC.EDU@MC.LCS.MIT.EDU TO:"KAUFMAN%VLSI.JPL.NASA.GOV@MC.LCS.MIT.EDU TO:"king%rd1632.ncr.com%RELAY.CS.NET@MC.LCS.MIT.EDU TO:"KSCHOONOVER%AJPO.SEI.CMU.EDU@MC.LCS.MIT.EDU TO:"KUBIADAS%HTIKUB5.BITNET%CUNYVM.CUNY.EDU@MC.LCS.MIT.EDU TO:"kurt%BOULDER.COLORADO.EDU@MC.LCS.MIT.EDU TO:"lal%RTI.RTI.ORG@MC.LCS.MIT.EDU TO:"larry%VLSI.JPL.NASA.GOV@MC.LCS.MIT.EDU TO:"Lehman%ASD.SPAN%VLSI.JPL.NASA.GOV@MC.LCS.MIT.EDU TO:"LINDA%JOVE.CAM.UNISYS.COM@MC.LCS.MIT.EDU TO:"lli.es%XEROX.COM@MC.LCS.MIT.EDU TO:"lloyd%skylrk.DEC%DECWRL.DEC.COM@MC.LCS.MIT.EDU TO:"LOONEY%UXV.LARC.NASA.GOV@MC.LCS.MIT.EDU TO:"LPRICE%VMSA.CF.UCI.EDU@MC.LCS.MIT.EDU TO:"MACKEYW%SERVAX.BITNET%CUNYVM.CUNY.EDU@MC.LCS.MIT.EDU TO:"MARMSTRONG%AJPO.SEI.CMU.EDU@MC.LCS.MIT.EDU TO:"marshall%software.org%RELAY.CS.NET@MC.LCS.MIT.EDU TO:"mcvax!enea!tut!pjl%SEISMO.CSS.GOV@MC.LCS.MIT.EDU TO:"mcvax!tut!tut.fi!vmk%SEISMO.CSS.GOV@MC.LCS.MIT.EDU TO:"mdean%BBN.COM@MC.LCS.MIT.EDU TO:"ME660021%UTHVM1.BITNET%CUNYVM.CUNY.EDU@MC.LCS.MIT.EDU TO:"MEMERSON%AJPO.SEI.CMU.EDU@MC.LCS.MIT.EDU TO:"MENDAL%SIERRA.STANFORD.EDU@MC.LCS.MIT.EDU TO:"MFELDMAN%GWUVM.BITNET%CUNYVM.CUNY.EDU@MC.LCS.MIT.EDU TO:"mholden%AJPO.SEI.CMU.EDU@MC.LCS.MIT.EDU TO:"mitchell%tle.DEC%DECWRL.DEC.COM@MC.LCS.MIT.EDU TO:"MORRISET%URVAX.BITNET%CUNYVM.CUNY.EDU@MC.LCS.MIT.EDU TO:"MURAD%ARDEC-LCSS.ARPA@MC.LCS.MIT.EDU TO:"MWOLFF%ESTEC.BITNET%CUNYVM.CUNY.EDU@MC.LCS.MIT.EDU TO:"ncmagel%NDSUVAX.BITNET%CUNYVM.CUNY.EDU@MC.LCS.MIT.EDU TO:"NOMDENET%VENERA.ISI.EDU@MC.LCS.MIT.EDU TO:"nyberg%ajpo.sei.cmu.edu@MC.LCS.MIT.EDU TO:"ONEILL%AJPO.SEI.CMU.EDU@MC.LCS.MIT.EDU TO:"orgass%IBM.COM@MC.LCS.MIT.EDU TO:"ozan%emc2.dec%DECWRL.DEC.COM@MC.LCS.MIT.EDU TO:"pb%PIPE.CS.WISC.EDU@MC.LCS.MIT.EDU TO:"petsd!joe%RUTGERS.EDU@MC.LCS.MIT.EDU TO:"pfister_rob%Dneast.DEC%DECWRL.DEC.COM@MC.LCS.MIT.EDU TO:"PGTM203%CALSTATE.BITNET%CUNYVM.CUNY.EDU@MC.LCS.MIT.EDU TO:"PMAHER%AJPO.SEI.CMU.EDU@MC.LCS.MIT.EDU TO:"PMYERS%AJPO.SEI.CMU.EDU@MC.LCS.MIT.EDU TO:"prlb2!kulcs!ada-sw%UUNET.UU.NET@MC.LCS.MIT.EDU TO:"RAYSSD!SUD.RAY.COM!GRANITO%A.CS.UIUC.EDU@MC.LCS.MIT.EDU TO:"REXB%VM.CC.PURDUE.EDU@MC.LCS.MIT.EDU TO:"rlvs%SEI.CMU.EDU@MC.LCS.MIT.EDU TO:"RT2BOPER%MIAMIU.BITNET%CUNYVM.CUNY.EDU@MC.LCS.MIT.EDU TO:"scherrer%EUROPE.DEC%DECWRL.DEC.COM@MC.LCS.MIT.EDU TO:"SCOTT%UCF1VM.BITNET%CUNYVM.CUNY.EDU@MC.LCS.MIT.EDU TO:"sfl%SEI.CMU.EDU@MC.LCS.MIT.EDU TO:"sigada%wright.csnet%RELAY.CS.NET@MC.LCS.MIT.EDU TO:"simmons%nucst4.neep.wisc.edu%pipe.cs.wisc.edu@MC.LCS.MIT.EDU TO:"SIMTEL20%CCINT1.RSRE.MOD.UK@MC.LCS.MIT.EDU TO:"SJONES%FORD-WDL1.ARPA@MC.LCS.MIT.EDU TO:"ssc-vax!hauser%BEAVER.CS.WASHINGTON.EDU@MC.LCS.MIT.EDU TO:"ssc-vax!ssc-bee!sdy%BEAVER.CS.WASHINGTON.EDU@MC.LCS.MIT.EDU TO:"STEVEG%MAINE.BITNET%MITVMA.MIT.EDU@MC.LCS.MIT.EDU TO:"SXA00006%BAGAMCOK.BITNET%CUNYVM.CUNY.EDU@MC.LCS.MIT.EDU TO:"SYSDAN%SEMAX51.BITNET%CUNYVM.CUNY.EDU@MC.LCS.MIT.EDU TO:"TARR%CS.UMASS.EDU%RELAY.CS.NET@MC.LCS.MIT.EDU TO:"tcb%FORD-WDL1.ARPA@MC.LCS.MIT.EDU TO:"TDG%UMN-REI-SC.ARPA@MC.LCS.MIT.EDU TO:"TDOWNEY%BFLY-VAX.BBN.COM@MC.LCS.MIT.EDU TO:"TENE%TECHMAX.BITNET%CUNYVM.CUNY.EDU@MC.LCS.MIT.EDU TO:"TERWILL%ARECIBO.AERO.ORG@MC.LCS.MIT.EDU TO:"tornier%emc2.dec%DECWRL.DEC.COM@MC.LCS.MIT.EDU TO:"TRACZ%SIERRA.STANFORD.EDU@MC.LCS.MIT.EDU TO:"trwarcadia!ada-sw%oberon.usc.edu@MC.LCS.MIT.EDU TO:"trwrb!smpvax1!sdl%UCBVAX.BERKELEY.EDU@MC.LCS.MIT.EDU TO:"trwrc!ada-sw.aml%UCBVAX.BERKELEY.EDU@MC.LCS.MIT.EDU TO:"TVOVERBE%ESTEC.BITNET%CUNYVM.CUNY.EDU@MC.LCS.MIT.EDU TO:"U012%CBEBDA3T.BITNET%CUNYVM.CUNY.EDU@MC.LCS.MIT.EDU TO:"U5226%CZHETH5A.BITNET%CUNYVM.CUNY.EDU@MC.LCS.MIT.EDU TO:"uci-ada-sw%ICS.UCI.EDU@MC.LCS.MIT.EDU TO:"vanavermaet%brsadg.dec%DECWRL.DEC.COM@MC.LCS.MIT.EDU TO:"VM0291%WVNVM.BITNET%CUNYVM.CUNY.EDU@MC.LCS.MIT.EDU TO:"wester%FORD-COS1.ARPA@MC.LCS.MIT.EDU TO:"WIENER%VLSI.JPL.NASA.GOV@MC.LCS.MIT.EDU TO:"wmiller%AJPO.SEI.CMU.EDU@MC.LCS.MIT.EDU TO:"wpl%BURDVAX.PRC.UNISYS.COM@MC.LCS.MIT.EDU TO:"WVNET02%WVNVMS.BITNET%CUNYVM.CUNY.EDU@MC.LCS.MIT.EDU TO:"YANKE%ARECIBO.AERO.ORG@MC.LCS.MIT.EDU TO:"ZEIL%XANTH.CS.ODU.EDU@MC.LCS.MIT.EDU TO:"ZWARTS%HGRRUG51.BITNET%CUNYVM.CUNY.EDU@MC.LCS.MIT.EDU TEXT;-1 Received: from SIMTEL20.ARMY.MIL (TCP 3200000112) by MC.LCS.MIT.EDU 21 Oct 88 19:03:11 EDT Date: Mon, 17 Oct 88 10:39:20 MDT From: Rick Conn Subject: Hash Functions compoennt To: ADA-SW: ; Message-ID: <12439176867.15.RCONN@SIMTEL20> Ada Software Repository Release Notice Release of: Hash Functions component ------------------------------ 1. Taxonomy: COMPONENTS ABSTRACTIONS STRING HASHING ------------------------------ 2. Author: Bill Toscano, Michael Gordon Intermetrics, Inc, 733 Concord Ave Cambridge, MA 02138 Contact: Lt. Colonel Falgiano ESD/SCW Hanscom AFB, MA 01731 ------------------------------ 3. Abstract: This generic package contains one generic function, HASH_STRING, which generates a hashing number for a string, where the hashing number is in the range from 0 to PRIME-1, where PRIME is a POSITIVE number passed as a generic parameter. ABSTRACTIONS is used by NOSC/WIS tools 5.1.1, 5.1.2, 6.1.2, and 6.2. See also NEW_ABSTRACTIONS. ------------------------------ 4. Directory Listing: Directory PD2: File Name Bytes Lines --------------- -------- ------ HASHFCNS.BDY 1844 62 HASHFCNS.SPC 307 11 =============== ======== ====== 2 Files 2151 73 -------  Date: Thu, 20 Oct 88 21:07:31 EDT From: David Chapman To: BUG-COMSAT@AI.AI.MIT.EDU Message-ID: <468842.881020.ZVONA@AI.AI.MIT.EDU> The ideal COMSAT of the future will produce CLI messages that tell me that I have mail from sappho%b@ucscc.ucsc.edu, rather than that I have mail from 192.35.28.3.  Date: Thu, 20 Oct 88 18:20:55 EDT From: "Pandora B. Berman" Subject: i don't know my own name To: postmaster@SUMEX-2060.STANFORD.EDU cc: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <468719.881020.CENT@AI.AI.MIT.EDU> Received: from SUMEX-AIM.Stanford.EDU (TCP 1200000070) by AI.AI.MIT.EDU 20 Oct 88 06:33:32 EDT Date: Thu, 20 Oct 88 03:23:30 PDT From: The Mailer Daemon To: CENT@AI.AI.MIT.EDU Subject: PS:[--QUEUED-MAIL--].RETRANSMIT.31313 No such host as "SUMEX-2060.STANFORD.EDU", bad queue file follows: ------- =DELIVERY-OPTIONS:MAIL =NET-MAIL-FROM-HOST:[10.2.0.6].#Internet =RETURN-PATH:CENT@AI.AI.MIT.EDU =NOTIFY: 21-Oct-88 03:04 =DEQUEUE: 23-Oct-88 03:04 _AI.AI.MIT.EDU CENT SUMEX-2060.STANFORD.EDU MRC%PANDA Received: from AI.AI.MIT.EDU ([10.2.0.6]) by SUMEX-AIM.STANFORD.EDU with TCP; Thu, 20 Oct 88 03:04:31 PDT Date: Wed, 19 Oct 88 23:27:01 EDT From: "Pandora B. Berman" Subject: work on ML To: ricchio@XX.LCS.MIT.EDU cc: BUG-KS@AI.AI.MIT.EDU Message-ID: <467947.881019.CENT@AI.AI.MIT.EDU> [msg text omitted] this bounced due to the address MRC%PANDA@@SUMEX-AIM.STANFORD.EDU in the list BUG-KS@AI. i note that SUMEX has changed its primary name to SUMEX-2060 in the host tables (which is what we still operate off of), while retaining the aliases SUMEX-AIM and SUMEX. it seems a little unreasonable that SUMEX-AIM refuses to recognize itself as SUMEX-2060 when processing mail.  Date: Wed, 19 Oct 88 23:21:05 EDT From: "Pandora B. Berman" Subject: failed mail To: JAR@AI.AI.MIT.EDU cc: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <467942.881019.CENT@AI.AI.MIT.EDU> the 5 badreqs currently on AI were originally mail to RRRS-AUTHORS or to SCHEME. they lost when alan had things set up for several hours monday to shunt MC's outgoing mail through AI (while MC's imp connection was fukt again). we think they lost because they are addressed to some file at SAIL, and the odd sail file syntax somehow confused COMSAT after the one extra hop to AI. could you take a gander at them and decide whether to send them along or just flush them? thanks.  Date: Wed, 19 Oct 88 16:57:05 EDT From: "Pandora B. Berman" Subject: mc up To: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <467672.881019.CENT@AI.AI.MIT.EDU> ok, MC's LISTS MSGS had reduced itself to 1300+ blocks, and had not sent out anything more after a few complete iterations of the queue. so i bit the bullet and turned mail acceptance back on.  Date: Wed, 19 Oct 88 16:01:16 EDT From: David Chapman Sender: ZVONA0@AI.AI.MIT.EDU Subject: bulk digests To: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <467600.881019.ZVONA0@AI.AI.MIT.EDU> I thought that the BULK mailer was still believed not to be reliable. (Am I wrong about this?) BTW, why doesn't someone just flush the bug-@ misfeature? It regularly screws people and I can't believe that the bug-@ list is vital anymore. (That it points at bug-atsign@oz is suggestive.) Or is this another example of COMSAT's modularity being so bad that fixing it would be near-impossible?  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 19 Oct 88 11:54:25 EDT Date: Wed 19 Oct 88 12:03:18-EDT From: Rob Austein Subject: Re: digests on MC To: CENT@AI.AI.MIT.EDU cc: BUG-MAIL@AI.AI.MIT.EDU, MT@AI.AI.MIT.EDU, SRA@XX.LCS.MIT.EDU In-Reply-To: <467174.881019.CENT@AI.AI.MIT.EDU> Message-ID: <12439694596.11.SRA@XX.LCS.MIT.EDU> Date: Wed, 19 Oct 88 02:45:30 EDT From: "Pandora B. Berman" at some point, we may run into the problem that too many lists get sufficient traffic to be digestified -- i.e., if we digested all of them, they would be -all- that MC COMSAT would do.. Not a big problem. We just change DIGEST to use the BULK COMSAT. -------  Date: Wed, 19 Oct 88 02:45:30 EDT From: "Pandora B. Berman" Subject: digests on MC To: BUG-MAIL@AI.AI.MIT.EDU cc: MT@AI.AI.MIT.EDU Message-ID: <467174.881019.CENT@AI.AI.MIT.EDU> in response to overwhelming urging, MT considerately turned SUBGENIUS into a automagic digest. this should cut down on the 4 hours a day it's been hogging MC COMSAT. on the other hand, by carefully following the directions and reassembling the DIGEST file, he superseded alan's previous action of turning off digesting. so the digests ran tonight, and i have flushed MC:DRAGON;DIGEST XBIN since it is now obsolete. there are now 5 automagic digests; AVIATION, the last of them tonight, is still being delivered at 02:40, probably in part because its msg is 19 blocks long! at some point, we may run into the problem that too many lists get sufficient traffic to be digestified -- i.e., if we digested all of them, they would be -all- that MC COMSAT would do.  Date: Tue, 18 Oct 88 17:45:31 EDT From: Alan Bawden Subject: Today's news To: BUG-MAIL@AI.AI.MIT.EDU cc: ZVONA@AI.AI.MIT.EDU, MAP@AI.AI.MIT.EDU Message-ID: <466909.881018.ALAN@AI.AI.MIT.EDU> When I came in today I went upstairs to look at MC before calling the NOC about our IMP connection, and low and behold, it was working again without our intervention. (I -did- have to use the NET command in LOCK to get things working again, and I wish ITS TCP didn't have that problem.) Thus I rearranged things again: 1. MC is back delivering mail directly over both networks. AI now has an 1100 block LISTS MSGS full of mail offloaded from MC last night. (The next time we need to do this, we should patch TCPGAT to point to XX.) 2. MC is currently refusing new incoming mail. I did this by patching SMTPSW is SYSBIN;FTPS BIN, and by renaming DEVICE;CHAOS MAIL to be DEVICE;.CHAOS MAIL. 3. I turned off all the digestifiers by renaming DRAGON;DIGEST BIN to be DRAGON;DIGEST XBIN. 4. I set all mailer timeouts back to their original larger values. This way MC's COMSAT gets a better chance to empty its queue. 5. I moved all files that are not essential from .MAIL. to .MAIL2 so that there would be more directory room for GC'ing huge LISTS MSGS files. (It hit 2500 blocks early this morning!) Things shouldn't remain this way for too long because other hosts will start bouncing mail they have queued for MC. So somebody -must- undo this sometime in the next day or so. In fact, since MC's LISTS MSGS just dropped down below 1800 blocks while I was typing in this message, this can probably be done relatively soon. REMEMBER: MC will almost certainly crash again, and wedge its IMP connection, so you need to keep an eye on things. I'll be in Philadelphia if you need me.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 18 Oct 88 04:48:43 EDT Date: Tue, 18 Oct 88 04:48:10 EDT From: Alan Bawden Subject: Fighting fires To: BUG-MAIL@MC.LCS.MIT.EDU Message-ID: <493581.881018.ALAN@MC.LCS.MIT.EDU> Since MC just lost its IMP connection yet again, I have patched TCPGAT to rout all non-Chaos mail through AI. LISTS MSGS on MC is currently at 2436 blocks, a new record I think, but since it has been passing mail to AI for hours it should get a heck of a lot smaller should COMSAT ever decide to GC it. (Why the hell isn't there a way to force COMSAT to do that?) I have moved all non-essential files from .MAIL. to .MAIL2 to try to be certain the GC goes without incident. I have also patched the SMTPSW in the SMTP server to accept no new mail. (I didn't do anything about the Chaos MAIL server. As far as I can tell, only EDDIE uses it...) Tomorrow I'll see if the NOC can help us debug the problem with out IMP connection. I guess I'm going to give up waiting for this sucker to GC and get some sleep....  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 17 Oct 88 23:29:41 EDT Received: from OTIS.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 143539; Mon 17-Oct-88 23:28:33 EDT Date: Mon, 17 Oct 88 23:28 EDT From: Alan Bawden Subject: Vacation. To: Bug-MAIL@AI.AI.MIT.EDU, Bug-ITS@AI.AI.MIT.EDU Message-ID: <19881018032823.2.ALAN@OTIS.AI.MIT.EDU> Due to the lossage with MC, there are a few things that I have done that you might all need to know about. Especially since I'll be out of town this from this Wednesday through next Monday. 1. I have swapped AI and MC's LH/DH-11s to see if this has any effect on the problem with the MC's IMP port. 2. I have left COMSAT on MC running in hyper-active mode. That is, I have patched all of its timeouts to very small values. This makes COMSAT eat new mail faster, so that people who haven't been able to talk to MC for days have a better chance of delivering new mail before timing out. Of course the flip side of this is that MC is growing a rather large queue of mail it hasn't been able to deliver. The COMSAT PDUMP file (COMSAT LAUNCH) has the fast timeouts, but the SBLK file (COMSAT IV) does not. So if it becomes necessary to undo what I have done, you should: [a] notice that the files on .MAIL. are all links to the corresponding files on .BULK., [b] load .BULK.;COMSAT IV into a job (J$J $L .BULK.;COMSAT IV), [c] start it at PURIFY (PURIFY$G), and [d] put the resulting PDUMP file into .BULK.;COMSAT LAUNCH (which is -not- the default you will be offered! Use delete, or type $ to change the offered default.). 3. I have changed the algorithm employed by the SMTP and Chaos MAIL servers to decide whether or not to accept new MAIL > files. The previous code tried to limit the number of MAIL files to 30. The new code looks at the .MAIL. directory and computes how full it is and refuses new MAIL > files if it is more than 75% full. If this has any bad effects, you can retract it by renaming DEVICE;CHAOS OMAIL to be DEVICE;CHAOS MAIL and renaming SYSBIN;FTPS OBIN to be SYSBIN;FTPS BIN.  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 11 Oct 88 16:06:06 EDT Date: Tue 11 Oct 88 16:03:44-EDT From: Rob Austein Subject: Re: How did I get on this mailing list? (Stop the list, I want to get off!) To: CGay@ALDERAAN.SCRC.Symbolics.COM cc: Bug-COMSAT@AI.AI.MIT.EDU, Bug-Random-Program@AI.AI.MIT.EDU, Postmaster@MCC.COM, postmaster@ELEPHANT-BUTTE.SCRC.Symbolics.COM In-Reply-To: <19881011194242.2.CGAY@DUNE.SCRC.Symbolics.COM> Message-ID: <12437641212.11.SRA@XX.LCS.MIT.EDU> Date: Tue, 11 Oct 88 15:42 EDT From: Carl L. Gay I don't suppose it's possible to use MIT-AI instead? See below for explaination. Well, the AI.MIT.EDU hosts were not effected by the particular change in question, so it might work, but no promises; the nickname is subject to removal by pretty much anybody at Tech Square who feels like it. Theoreticly AI is not supposed to be a mail workhorse except for AI lab use. You'd have to get a statement from somebody who actually uses the machine one way or the other about political feasibility. It might be better if you could figure out some way to get your mailer to forward through MC but use MC's real name. --Rob -------  Received: from ALDERAAN.SCRC.Symbolics.COM (TCP 20024224555) by AI.AI.MIT.EDU 11 Oct 88 15:44:12 EDT Received: from DUNE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 228401; Tue 11-Oct-88 15:42:55 EDT Date: Tue, 11 Oct 88 15:42 EDT From: Carl L. Gay Subject: Re: How did I get on this mailing list? (Stop the list, I want to get off!) To: SRA@XX.LCS.MIT.EDU cc: Bug-COMSAT@AI.AI.MIT.EDU, Bug-Random-Program@AI.AI.MIT.EDU, Postmaster@MCC.COM, postmaster@ELEPHANT-BUTTE.SCRC.Symbolics.COM In-Reply-To: <12437629104.11.SRA@XX.LCS.MIT.EDU> Message-ID: <19881011194242.2.CGAY@DUNE.SCRC.Symbolics.COM> Date: Tue 11 Oct 88 14:57:13-EDT From: Rob Austein Date: Tue, 11 Oct 88 13:12 EDT From: Carl L. Gay To: macivory-beta-customers-request@elephant-butte.scrc.symbolics.com From: SRA@XX.LCS.MIT.EDU Subject: How did I get on this mailing list? In the last day or so I've started receiving messages posted to a mailing list called "MacIvory-Beta-Customers".... The only thing I can think of is that we route some of the recipients on the mailing list through MC. Here's the entry: Bug-MacIvory%mcc.com@mit-mc ;Local distribution at MCC Could that possibly be the source of the problem? Everything else on the list looks inocuous. Yep, it's the BUG-COBOL@WASHINGTON syndrome again: 232501 InReq: 1 > 1; SPECS:{NET-MAIL-FROM: ELEPHANT-BUTTE.SCRC.SYMBOLICS.COM}{RTP:@ELEPHANT-BUTTE.SCRC.Symbolics.COM:TYSON%AI.SRI.COM@RITTER.AI.SRI.COM}{TL=2552.} ID=<491461.881010@MC.LCS.MIT.EDU> EXP->SPMCDONALD%BBN.COM@MIT-MC.ARPA@1200600054::={IGNORED},TMITCHELL%BBN.COM@MIT-MC.ARPA@1200600054::={IGNORED},(BUG MACIVORY%MCC.COM@MIT-MC.ARPA)@1200600054::=((BUG RANDOM-PROGRAM)@1200600054::=(ALAN@1200600054::=(ALAN@40700003130),CENT@1200600054::=(CENT@40700003130),CSTACY@1200600054::=(CSTACY@40700003130),DCP@1200600054::=(DCP@40700003130),ED@1200600054::=(ED@20024224620),GSB-NOCLI@1200600054::=(GSB@1200600054::=(GSB@40700003130)),KLOTZ-HOLD@1200600054::=((FILE [NUL:])@1200600054),MMCM@1200600054::=(MMCM@20024224620),GUMBY@1200600054::=(GUMBY@40700003130),Moon-Junk@20024224620,PGS@1200600054::=(PGS@40700003130),SRA@1200600054::=(SRA@40700002420))) Clear as Cobol (to my eyes). Please be informed that MC.LCS.MIT.EDU no longer recognizes "MIT-MC" or "MIT-MC.ARPA" as a name for itself (we ran out of address space to store all the old nicknames, so they are now gone from the MIT host tables). I was afraid you were going to say this. Someone just mentioned it to me yesterday. This, combined with a long standing COMSAT bug that (for historical reasons) is refered to as the "BUG-@" feature, causes MC to get confused by addresses of the form "BUG-whatever@MIT-MC" or "BUG-whatever%wherever@MIT-MC". Please change any and all occurances of the names MIT-MC and MIT-MC.ARPA to MC.LCS.MIT.EDU. Okay. I'll take care of this asap. I don't suppose it's possible to use MIT-AI instead? See below for explaination. Also, why is it necessary for you guys to send mail through MC to get to MCC.COM and BBN.COM in the first place? Have pity on a poor little KS-10.... The Symbolics mailer has a bug (which I don't fully understand) such that it blows up when booting if it can't resolve any particular host name, and for some reason it can't just ask the domain system about the host. Instead the host has to exist in the local namespace. So putting (e.g.) bug-macivory@mcc.com in a mailing list will blow up. Apparently fixing this would involve a major rewrite of the mailer and we don't have the resources for that right now... Sorry if this has caused a lot of inconvenience.  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 11 Oct 88 15:08:15 EDT Date: Tue 11 Oct 88 14:57:13-EDT From: Rob Austein Subject: Re: How did I get on this mailing list? (Stop the list, I want to get off!) To: CGay@ALDERAAN.SCRC.Symbolics.COM, Bug-COMSAT@AI.AI.MIT.EDU, Bug-Random-Program@AI.AI.MIT.EDU, Postmaster@MCC.COM cc: postmaster@ELEPHANT-BUTTE.SCRC.Symbolics.COM In-Reply-To: <19881011171257.9.CGAY@DUNE.SCRC.Symbolics.COM> Message-ID: <12437629104.11.SRA@XX.LCS.MIT.EDU> Date: Tue, 11 Oct 88 13:12 EDT From: Carl L. Gay To: macivory-beta-customers-request@elephant-butte.scrc.symbolics.com From: SRA@XX.LCS.MIT.EDU Subject: How did I get on this mailing list? In the last day or so I've started receiving messages posted to a mailing list called "MacIvory-Beta-Customers".... The only thing I can think of is that we route some of the recipients on the mailing list through MC. Here's the entry: Bug-MacIvory%mcc.com@mit-mc ;Local distribution at MCC Could that possibly be the source of the problem? Everything else on the list looks inocuous. Yep, it's the BUG-COBOL@WASHINGTON syndrome again: 232501 InReq: 1 > 1; SPECS:{NET-MAIL-FROM: ELEPHANT-BUTTE.SCRC.SYMBOLICS.COM}{RTP:@ELEPHANT-BUTTE.SCRC.Symbolics.COM:TYSON%AI.SRI.COM@RITTER.AI.SRI.COM}{TL=2552.} ID=<491461.881010@MC.LCS.MIT.EDU> EXP->SPMCDONALD%BBN.COM@MIT-MC.ARPA@1200600054::={IGNORED},TMITCHELL%BBN.COM@MIT-MC.ARPA@1200600054::={IGNORED},(BUG MACIVORY%MCC.COM@MIT-MC.ARPA)@1200600054::=((BUG RANDOM-PROGRAM)@1200600054::=(ALAN@1200600054::=(ALAN@40700003130),CENT@1200600054::=(CENT@40700003130),CSTACY@1200600054::=(CSTACY@40700003130),DCP@1200600054::=(DCP@40700003130),ED@1200600054::=(ED@20024224620),GSB-NOCLI@1200600054::=(GSB@1200600054::=(GSB@40700003130)),KLOTZ-HOLD@1200600054::=((FILE [NUL:])@1200600054),MMCM@1200600054::=(MMCM@20024224620),GUMBY@1200600054::=(GUMBY@40700003130),Moon-Junk@20024224620,PGS@1200600054::=(PGS@40700003130),SRA@1200600054::=(SRA@40700002420))) Please be informed that MC.LCS.MIT.EDU no longer recognizes "MIT-MC" or "MIT-MC.ARPA" as a name for itself (we ran out of address space to store all the old nicknames, so they are now gone from the MIT host tables). This, combined with a long standing COMSAT bug that (for historical reasons) is refered to as the "BUG-@" feature, causes MC to get confused by addresses of the form "BUG-whatever@MIT-MC" or "BUG-whatever%wherever@MIT-MC". Please change any and all occurances of the names MIT-MC and MIT-MC.ARPA to MC.LCS.MIT.EDU. Also, why is it necessary for you guys to send mail through MC to get to MCC.COM and BBN.COM in the first place? Have pity on a poor little KS-10.... --Rob  Date: Sun, 2 Oct 88 23:26:57 EDT From: "Pandora B. Berman" Subject: retransmit To: header-people@MC.LCS.MIT.EDU cc: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <455322.881002.CENT@AI.AI.MIT.EDU> These two msgs from the usenet Header-People community apparently got bounced by some combination of MC's down time last week (it's been having these strange parity errors...) and the experimentally patched mailer MC has been running more recently. This situation is being watched. Header-People-Request ---------- Date: Sat 1 Oct 88 17:14:20-EDT From: The Mailer Daemon To: header-people-request@mc.lcs.mit.edu Subject: Message of 27-Sep-88 22:19:31 Message undeliverable and dequeued after 4 days: header-people@mc.lcs.mit.edu: Cannot connect to host ------------ Received: from BLOOM-BEACON.MIT.EDU by XX.LCS.MIT.EDU with TCP/SMTP; Tue 27 Sep 88 22:19:31-EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Tue, 27 Sep 88 21:58:06 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 27 Sep 88 14:17:57 GMT From: clyde!watmath!egisin@bellcore.bellcore.com (Eric Gisin) Organization: U of Waterloo, Ontario Subject: Re: "Return-Receipt-To:" and Mail/mailx Message-Id: <21154@watmath.waterloo.edu> References: <511@mipseast.mips.COM>, <3975@psuvax1.cs.psu.edu>, <22535@tut.cis.ohio-state.edu> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu The .mailcf hack was apparently removed from 4.3 bsd sendmail. If your system has exec'able shell scripts, you can create your own sendmail. This is my etc/sendmail -- #! /bin/sh (cat <<.; cat) | /usr/lib/sendmail "$@" From: (Eric Gisin) egisin @ math.Waterloo.EDU (U of Waterloo) , Then assign SENDMAIL=$HOME/etc/sendmail and export it from your .profile. -------------------- -------------------- Date: Sun 2 Oct 88 01:54:29-EDT From: The Mailer Daemon To: header-people-request@mc.lcs.mit.edu Subject: Message of 28-Sep-88 16:19:37 Message undeliverable and dequeued after 3 days: header-people@mc.lcs.mit.edu: Cannot connect to host ------------ Received: from BLOOM-BEACON.MIT.EDU by XX.LCS.MIT.EDU with TCP/SMTP; Wed 28 Sep 88 16:19:38-EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Wed, 28 Sep 88 15:54:54 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 28 Sep 88 17:29:28 GMT From: dartvax!andyb%coat.uucp@bu-cs.bu.edu (Andy Behrens) Organization: Burlington Coat Factory Warehouse Subject: Re: "Return-Receipt-To:" and Mail/mailx Message-Id: <10213@dartvax.Dartmouth.EDU> References: <3975@psuvax1.cs.psu.edu>, <22535@tut.cis.ohio-state.edu>, <21154@watmath.waterloo.edu> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu Egisin@watmath.waterloo.edu (Eric Gisin) writes: > You can create your own sendmail. This is my etc/sendmail -- > > #! /bin/sh > (cat <<.; cat) | /usr/lib/sendmail "$@" > From: (Eric Gisin) egisin @ math.Waterloo.EDU (U of Waterloo) > . > > Then assign SENDMAIL=$HOME/etc/sendmail and export it from your .profile. In many versions of mail, the environment variable is $sendmail (lower case) rather than $SENDMAIL. Also, the existing mail delivery program may not be /usr/lib/sendmail; on my system it is "/bin/mail". It may be more convenient to put a set sendmail=$HOME/mysendmail command in your .mailrc file. If you want everyone on the system to use the local version of sendmail, put the set command in the global mail rc file. (Berkeley /usr/lib/Mail.rc, SysV /usr/lib/mailx/mailx.rc). -- "Christ died for our sins. Dare we make his martyrdom meaningless by not committing them?" Andy Behrens andyb@coat.uucp (formerly: andyb@burcoat.uucp) internet: andyb%coat@dartmouth.edu uucp: {harvard,decvax}!dartvax!coat!andyb bitnet: andyb%coat@dartcms1 RFD 1, Box 116, East Thetford, Vt. 05043 (802) 649-1258 -------  Date: Sat, 1 Oct 88 22:26:10 EDT From: David Chapman To: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <454675.881001.ZVONA@AI.AI.MIT.EDU> AI is currently unable to send mail to MC. If you examine the stats file for now you'll see several instances of mail sent from AI to MC timing out and being queued. However, MC is running fine otherwise, and is accepting mail from at least some other hosts. Very weird.  Received: from life.ai.mit.edu (TCP 20015020120) by AI.AI.MIT.EDU 30 Sep 88 03:50:27 EDT Received: from GARP.MIT.EDU by life.ai.mit.edu; Thu, 29 Sep 88 19:38:13 EDT Received: by GARP.MIT.EDU with sendmail-5.54/4.7 id ; Thu, 29 Sep 88 19:35:32 EDT Date: Thu, 29 Sep 88 19:35:32 EDT From: henry@garp.mit.edu (Henry Mensch) Message-Id: <8809292335.AA07596@GARP.MIT.EDU> To: CENT@ai.ai.mit.edu Cc: HEADER-PEOPLE-REQUEST@ai.ai.mit.edu, BUG-MAIL@ai.ai.mit.edu In-Reply-To: "Pandora B. Berman"'s message of Thu, 29 Sep 88 18:01:25 EDT <453071.880929.CENT@AI.AI.MIT.EDU> Subject: Header-People header weirdness Reply-To: henry@garp.mit.edu actually, i had the message flow backwards (obviously, it is coming off usenet ...) the remainder of my text is correct. # Henry Mensch / / E40-379 MIT, Cambridge, MA # {decvax,harvard,mit-eddie}!garp!henry /  Date: Fri, 30 Sep 88 01:30:27 EDT From: "Pandora B. Berman" Subject: Header-People header weirdness To: SRA@XX.LCS.MIT.EDU cc: HEADER-PEOPLE-REQUEST@AI.AI.MIT.EDU, BUG-MAIL@AI.AI.MIT.EDU, henry@GARP.MIT.EDU Message-ID: <453183.880930.CENT@AI.AI.MIT.EDU> Date: Thu 29 Sep 88 18:19:33-EDT From: Rob Austein Subject: Re: Header-People header weirdness To: CENT@AI.AI.MIT.EDU cc: henry@GARP.MIT.EDU, HEADER-PEOPLE-REQUEST@AI.AI.MIT.EDU, BUG-MAIL@AI.AI.MIT.EDU Whoa. Penny, there's a big difference between "Sender:" and "Reply-To:".... so i didn't recall off the top of my head which header someone else had pasted onto mail i am mildly responsible for. so shoot me. ...Whether any host should presume to mangle the headers of the messages it passes is a separate issue.... that was what i thought i was complaining about. Date: Thu, 29 Sep 88 18:44:25 EDT From: henry@GARP.MIT.EDU (Henry Mensch) To: CENT@AI.AI.MIT.EDU Cc: HEADER-PEOPLE-REQUEST@AI.AI.MIT.EDU, BUG-MAIL@AI.AI.MIT.EDU Subject: Header-People header weirdness ...that's right; sendmail (on any unix system) will add the "Sender:" field if the sender is not one of the trusted users that it knows (via its configuration file). All the "Sender:" header does is indicate that the "From:" field may not represent the true origin of the message. (useful if you're trying to figure out if a message is forged by an amateur or not.) no software that I know of uses "Sender:" for anything, and this has NOTHING to do with where replies get sent. sorry, i confused you by mentioning Reply-to: when i meant (as the example showed) Sender:. i hack mail on a simple system that doesn't have 17 different weird headers that cause warnings to be sent to 17 different consed-up addresses according to path the mail took, configuration of system reached, and phase of moon -- nor does it fuck with the headers on mail it sees. the problem is of course not replies from anyone the mail reached, but errors the mail incurred which are sent to an address some Eunuchs decided on whim to add to the msg -- the errors don't arrive here by ESP, so they -must- be using the Sender: header to decide where to go. i disagree with any system that professes the right to aribitrarily add significant headers to mail which comes from an ITS. the only lenience i would grant whoever is responsible for this particular fiasco is that the consed-up address actually makes some sense. you have an address on your list which Erik Fair asked you to add some time ago. this address causes the header-people list to be gatewayed into a usenet newsgroup. it seems that, somewhere down the pike, someone's news system is forwarding header-people articles BY MAIL (not via usenet) to the luser for whom you keep receiving bounce messages. obviously, they don't realize that header-people is originally a mailing list and that if people want it in their mailboxes they should send e-mail to header-people-request@... ah. that makes some sense, after i read it twice; i am unfamiliar with usenet "news" beyond the understanding that it exists. a slim hope for tracking down the asshsole, but better than none. the bounce messages return via bloom-beacon because that's how the original got where it did. fine. i have no disagreements with that principle.  Received: from GARP.MIT.EDU (TCP 2222000315) by AI.AI.MIT.EDU 29 Sep 88 18:53:48 EDT Received: by GARP.MIT.EDU with sendmail-5.54/4.7 id ; Thu, 29 Sep 88 18:44:25 EDT Date: Thu, 29 Sep 88 18:44:25 EDT From: henry@GARP.MIT.EDU (Henry Mensch) Message-Id: <8809292244.AA07260@GARP.MIT.EDU> To: CENT@AI.AI.MIT.EDU Cc: HEADER-PEOPLE-REQUEST@AI.AI.MIT.EDU, BUG-MAIL@AI.AI.MIT.EDU In-Reply-To: "Pandora B. Berman"'s message of Thu, 29 Sep 88 18:01:25 EDT <453071.880929.CENT@AI.AI.MIT.EDU> Subject: Header-People header weirdness Reply-To: henry@GARP.MIT.EDU Date: Thu, 29 Sep 88 18:01:25 EDT From: "Pandora B. Berman" I did not add that SENDER: header; i only maintain the list. that's right; sendmail (on any unix system) will add the "Sender:" field if the sender is not one of the trusted users that it knows (via its configuration file). All the "Sender:" header does is indicate that the "From:" field may not represent the true origin of the message. (useful if you're trying to figure out if a message is forged by an amateur or not.) no software that I know of uses "Sender:" for anything, and this has NOTHING to do with where replies get sent. find that unlikely. and whenever the mail bounces (as with this bad address msg), it has always come through BLOOM-BEACON. if it isn't you, it must be "USENET", whoever or whatever that is. in fact, in reply to your original comment, presumably the fellow whose address you twiddled sent mail to USENET@B-B because right there in the Rec'd line it says to contact that very address "if you have questions".. you have an address on your list which Erik Fair asked you to add some time ago. this address causes the header-people list to be gatewayed into a usenet newsgroup. it seems that, somewhere down the pike, someone's news system is forwarding header-people articles BY MAIL (not via usenet) to the luser for whom you keep receiving bounce messages. obviously, they don't realize that header-people is originally a mailing list and that if people want it in their mailboxes they should send e-mail to header-people-request@... the bounce messages return via bloom-beacon because that's how the original got where it did. nothing bloom-beacon does is at fault here (whew!). your near-impossible task is to figure out whose news site is forwarding mail to this bozo (i imagine it's at stanford) and to hang it from the gallows until it be dead. # Henry Mensch / / E40-379 MIT, Cambridge, MA # {decvax,harvard,mit-eddie}!garp!henry /  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 29 Sep 88 18:39:19 EDT Date: Thu 29 Sep 88 18:19:33-EDT From: Rob Austein Subject: Re: Header-People header weirdness To: CENT@AI.AI.MIT.EDU cc: henry@GARP.MIT.EDU, HEADER-PEOPLE-REQUEST@AI.AI.MIT.EDU, BUG-MAIL@AI.AI.MIT.EDU In-Reply-To: <453071.880929.CENT@AI.AI.MIT.EDU> Message-ID: <12434520211.38.SRA@XX.LCS.MIT.EDU> Whoa. Penny, there's a big difference between "Sender:" and "Reply-To:"; "Sender:" (and the SMTP-return-path that doesn't show up except in the COMSAT log) specify where error messages generated by mailer daemons regarding delivery problems with this message should go. "Reply-To:" specifies what a user's mail agent (eg, RMAIL) should use when the user invokes the REPLY function ("R", whatever). On the face of it the message you quote is completely reasonable as far as it goes (I haven't checked through the COMSAT logs for the SMTP return path but assume it was set to the same as the Sender field or you wouldn't have gotten the bounce message). Whether any host should presume to mangle the headers of the messages it passes is a separate issue. Keep in mind, though, that at present COMSAT is too braindead to set the return-path itself, so maybe we shouldn't complain too much about Bloom-Beacon doing it for us. The fact that some luser (apparently, from the conversation) used the name "usenet" in the mailing lists file is just an example of Shawn Routhier's Law of Conservation of Twits. --Rob -------  Date: Thu, 29 Sep 88 18:01:25 EDT From: "Pandora B. Berman" Subject: Header-People header weirdness To: henry@GARP.MIT.EDU cc: HEADER-PEOPLE-REQUEST@AI.AI.MIT.EDU, BUG-MAIL@AI.AI.MIT.EDU Message-ID: <453071.880929.CENT@AI.AI.MIT.EDU> [prequel for BUG-MAIL readers: henry had fixed an address in the Header-People list, and i had replied that he did so tastefully.] Date: Mon, 26 Sep 88 23:54:40 EDT From: henry@GARP.MIT.EDU (Henry Mensch) To: CENT@AI.AI.MIT.EDU Subject: Header-People, ANBB Date: Mon, 26 Sep 88 22:24:50 EDT From: "Pandora B. Berman" Date: Mon, 26 Sep 88 21:28:16 EDT From: henry@GARP.MIT.EDU (Henry Mensch) To: CENT@AI.AI.MIT.EDU Subject: HEADER-PEOPLE 'tis good to know this ... i don't know why he wrote to usenet@bloom-beacon. this address was probably added to a header somewhere along the way (perhaps before he replied, and he just didn't remove it). bloom-beacon has apparently decided it has the right to add things like reply-to:header-people-request to any H-P mail that runs through it, so i would not be at all surprised if this was their fault. um, bloom-beacon doesn't do anything of the sort (I know ... I'm {root,postmaster,usenet}@bloom-beacon...) i cite the following type of evidence, which has been appearing in my mbx (as HEADER-PEOPLE-REQUEST) for several months now: Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 27 Sep 88 01:20:13 EDT Received: from argus.Stanford.EDU (TCP 4416000227) by MC.LCS.MIT.EDU 26 Sep 88 23:57:41 EDT Received: from MC.LCS.MIT.EDU by argus.Stanford.EDU with TCP; Mon, 26 Sep 88 20:54:03 PDT Date: Mon, 26 Sep 88 20:54:03 PDT From: Mail Delivery Subsystem Subject: Returned mail: Host unknown To: <@mc.lcs.mit.edu:header-people-request@mc.lcs.mit.edu> ----- Transcript of session follows ----- 550 ... Host unknown ----- Unsent message follows ----- Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 26 Sep 88 23:18:21 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Mon, 26 Sep 88 22:52:45 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 27 Sep 88 00:49:00 GMT From: blitz!ehrlich@psuvax1.psu.edu (Dan Ehrlich) Organization: Department of Computer Science, Penn State University Subject: Re: "Return-Receipt-To:" and Mail/mailx Message-Id: <3977@psuvax1.cs.psu.edu> References: <511@mipseast.mips.COM>, <3975@psuvax1.cs.psu.edu> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu [msg text removed] I did not add that SENDER: header; i only maintain the list. COMSAT certainly didn't. conceivably there are many deranged users out there who have hacked their mail programs to add this header to their H-P mail, but i find that unlikely. and whenever the mail bounces (as with this bad address msg), it has always come through BLOOM-BEACON. if it isn't you, it must be "USENET", whoever or whatever that is. in fact, in reply to your original comment, presumably the fellow whose address you twiddled sent mail to USENET@B-B because right there in the Rec'd line it says to contact that very address "if you have questions".  Date: Wed, 28 Sep 88 12:47:30 EDT From: "Patrick G. Sobalvarro" To: BUG-COMSAT@AI.AI.MIT.EDU Message-ID: <452313.880928.PGS@AI.AI.MIT.EDU> Is there some simple way in which we could get COMSAT to forward messages on which it received an "unknown host" error to WHEATIES? So long as COMSAT doesn't do domain resolution, we may as well try to have someone else do it.  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 22 Sep 88 12:46:10 EDT Date: Thu 22 Sep 88 11:34:37-EDT From: Rob Austein Subject: End of the road, anybody got any bright ideas? To: Info-Hosts@AI.AI.MIT.EDU, Bug-COMSAT@AI.AI.MIT.EDU Message-ID: <12432611487.23.SRA@XX.LCS.MIT.EDU> The HOSTS3 compiler ran out of address space again, and I've run out of clever ideas for how to automaticly discard useless information to make everything important fit again. So unless somebody comes up with some bright idea, this means the end of the comprehensive HOSTS3 table and its derivatives. There is no problem with continuing to produce the chaosnet host tables, although at the moment that process is also stopped due to the breakage of the comprehensive table. Once again I ask that anybody left using the comprehensive table make themselves known. We already know about the ITS machines. Anyone else? If I don't hear loud screams (and suggestions) I'll assume that from this point on the HOSTS3 table stuff is an ITS internal maintainance issue of no interest to anyone else. --Rob -------  Date: Mon, 19 Sep 88 20:53:54 EDT From: Alan Bawden Sender: ALAN5@AI.AI.MIT.EDU Subject: COMSAT all fucked up. To: BUG-COMSAT@AI.AI.MIT.EDU Message-ID: <446614.880919.ALAN5@AI.AI.MIT.EDU> 185643 Foo: NTRBUF Overflow: {554 cannot prescan from (<@AI.AI.MIT.EDU,@Riverside.SCRC.Symbolics.COM,@SAMSON.CADR.DIALNET.SYMBOLICS.COM,@Riverside.SCRC.Symbolics.COM,@Riverside.SCRC.Symbolics.COM,@AI.AI.MIT.EDU,@Riverside.SCRC.Symbolics.COM,@SAMSON.CADR.DIALNET.SYMBOLICS.COM,@Riv}erside.SCRC.Symbolics.COM,@Riverside.SCRC.Symbolics.COM,@AI.AI.MIT.EDU:ganymede!tmb@WHEATIES.AI.MIT.EDU>)}...IOC error Why doesn't COMSAT look at the first three characters and realize that this is a permanent error? Who cares if the rest of the message overflows the goddamn buffer? If it would look and see that it is a permanent error, it wouldn't keep trying to deliver the damn message over and over again. By the way, I was looking at the code the other day and it turns out that "IOC error" has little to do with IOC errors. The error handling is all screwed up such that "IOC error" is what it puts in the log for any number of random things that can go wrong during delivery (including real IOC errors and various failures while parsing replies). I'll bet that the failure count ever gets incremented in the "IOC error" case either. I haven't verified this by looking at the code; this is just what I observed happening in the case above.  Date: Thu, 15 Sep 88 23:51:04 EDT From: "Pandora B. Berman" Subject: free space To: BUG-MAIL@AI.AI.MIT.EDU, HENRY@AI.AI.MIT.EDU Message-ID: <444448.880915.CENT@AI.AI.MIT.EDU> a good way to free up an easy K or so on DSK: is to run dired on HENRY;. he reads mail from a lispm, which creates incrementally numbered versions of his rmail file, and he rarely remembers to clean them up.  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 12 Sep 88 23:03:55 EDT Date: Mon, 12 Sep 1988 23:00 EDT Message-ID: From: JTW@XX.LCS.MIT.EDU To: "Pandora B. Berman" Cc: ALAN@AI.AI.MIT.EDU, BUG-MAIL@AI.AI.MIT.EDU, Moon@SCRC-STONY-BROOK.ARPA Subject: 31 temporary errors In-reply-to: Msg of 12 Sep 1988 22:51-EDT from Pandora B. Berman From: Pandora B. Berman cc: ALAN at AI.AI.MIT.EDU, BUG-MAIL at AI.AI.MIT.EDU Re: 31 temporary errors Date: Mon, 12 Sep 88 21:40 EDT From: David A. Moon Subject: Msg of Tuesday, 30 August 1988 00:13-EDT To: Alan Bawden cc: Bug-MAIL@AI.AI.MIT.EDU Date: Tue, 30 Aug 88 16:58 EDT From: Alan Bawden As the following two messages demonstrate, COMSAT gives up absurdly quickly in the face of temporary errors. These two mesages, sent automatically on ML and MD last midnight, timed out in about 7.5 hours. (.MAIL. on AI was full.) (I guess COMSAT must retry a temporary error every 15 minutes, and then it gives up when the 31st try fails, that would work out to 7.5 hours.) The number 31 used to be 700, who changed it? oh come now. who do you think? Ah. But while we're here, it does seem that every 15 minutes is a little excessive, here in the future. Heck, it can take that long to send five words across the country. The not-quite-published-yet Host Requirements RFC wants you to use (yow!) an exponential backoff in your retry times, or, failing that, to try a few times fairly fast (they suggest 1/2 hour), and then mellow out a little. I guess we can add this to the list of all the things we've all been going to do to COMSAT for the past five years.  Date: Mon, 12 Sep 88 22:51:27 EDT From: "Pandora B. Berman" Subject: 31 temporary errors To: Moon@SCRC-STONY-BROOK.ARPA cc: ALAN@AI.AI.MIT.EDU, BUG-MAIL@AI.AI.MIT.EDU Message-ID: <441990.880912.CENT@AI.AI.MIT.EDU> Date: Mon, 12 Sep 88 21:40 EDT From: David A. Moon Subject: Msg of Tuesday, 30 August 1988 00:13-EDT To: Alan Bawden cc: Bug-MAIL@AI.AI.MIT.EDU Date: Tue, 30 Aug 88 16:58 EDT From: Alan Bawden As the following two messages demonstrate, COMSAT gives up absurdly quickly in the face of temporary errors. These two mesages, sent automatically on ML and MD last midnight, timed out in about 7.5 hours. (.MAIL. on AI was full.) (I guess COMSAT must retry a temporary error every 15 minutes, and then it gives up when the 31st try fails, that would work out to 7.5 hours.) The number 31 used to be 700, who changed it? oh come now. who do you think?  Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 20024224620) by AI.AI.MIT.EDU 12 Sep 88 21:46:30 EDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 458032; Mon 12-Sep-88 21:41:34 EDT Date: Mon, 12 Sep 88 21:40 EDT From: David A. Moon Subject: Msg of Tuesday, 30 August 1988 00:13-EDT To: Alan Bawden cc: Bug-MAIL@AI.AI.MIT.EDU In-Reply-To: <19880830205846.2.ALAN@PIGPEN.AI.MIT.EDU> Message-ID: <19880913014044.2.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Tue, 30 Aug 88 16:58 EDT From: Alan Bawden As the following two messages demonstrate, COMSAT gives up absurdly quickly in the face of temporary errors. These two mesages, sent automatically on ML and MD last midnight, timed out in about 7.5 hours. (.MAIL. on AI was full.) (I guess COMSAT must retry a temporary error every 15 minutes, and then it gives up when the 31st try fails, that would work out to 7.5 hours.) The number 31 used to be 700, who changed it? Date: Tue, 30 Aug 88 07:46:46 EDT From: Communications Satellite FAILED: ALAN at AI.AI.MIT.EDU; I gave up on sending this after 31 "temporary" errors. Failed message follows: ------- Date: Tue, 30 Aug 88 00:13:10 EDT From: Alan Bawden Subject: Feep! To: ALAN%MD.LCS.MIT.EDU@MC.LCS.MIT.EDU Message-ID: <3710.880830.ALAN@MD.LCS.MIT.EDU> Job DAILY ran. Date: Tue, 30 Aug 88 07:44 EDT From: Communications Satellite Subject: Msg of Tuesday, 30 August 1988 00:11-EDT To: ALAN%ML.AI.MIT.EDU@MC.LCS.MIT.EDU FAILED: ALAN at AI.AI.MIT.EDU; I gave up on sending this after 31 "temporary" errors. Failed message follows: ------- Date: Tue, 30 Aug 88 00:11:12 EDT From: Alan Bawden Subject: Feep! To: ALAN%ML.AI.MIT.EDU@MC.LCS.MIT.EDU Message-ID: <7782.880830.ALAN@ML.AI.MIT.EDU> Job DAILY ran.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 9 Sep 88 17:59:19 EDT Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by MC.LCS.MIT.EDU 9 Sep 88 17:35:33 EDT Received: from QUESTION-AUTHORITY.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 133688; Fri 9-Sep-88 17:35:20 EDT Date: Fri, 9 Sep 88 17:35 EDT From: Alan Bawden Subject: good news and bad news To: SRA@MC.LCS.MIT.EDU cc: BUG-MAIL@MC.LCS.MIT.EDU In-Reply-To: <477731.880908.SRA@MC.LCS.MIT.EDU> Message-ID: <19880909213518.4.ALAN@QUESTION-AUTHORITY.AI.MIT.EDU> Date: Thu, 8 Sep 88 11:58:39 EDT From: Rob Austein The good news is that Mr. Bawden seems to have correctly located the mysterious bug that caused COMSAT to get horribly confused when the IMP is unavailable. The bad news is that, now that COMSAT is no longer confused, it generates a 50 block STATS file in 3 hours when the IMP is unavailable. Actually, it always did this. At least now that I fixed the bug it generates 50 blocks of the correct error message! Also, I happend to do an $$3^F on AI:SYSNET; and noticed that the write dates of NETRTS * are out of order with respect to the version numbers. Is this known to the people who did it? Huh? AI SYSNET FREE BLOCKS #0=3270 #2=2784 2 NETRTS 345 13 +582 12/15/86 10:02:49 (5/15/88) GUMBY 2 NETRTS 348 13 +600 1/22/87 13:29:50 (9/02/88) SRA 0 NETRTS 350 13 +688 5/15/88 02:40:55 (6/16/88) ALAN 0 NETRTS 351 13 +728 6/16/88 13:40:11 (9/08/88) SRA 0 NETRTS 352 13 +728 ! 9/08/88 00:16:08 (9/08/88) ALAN  Date: Fri, 9 Sep 88 01:51:22 EDT From: Alan Bawden To: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <439975.880909.ALAN@AI.AI.MIT.EDU> There are about a zillion BADREQ files on AI for redistributing mail to the SLUG mailing list. I don't see the problem myself, so perhaps somebody could figure it out and drop a note to SLUG-Admin explaining how they can fix it. (Assuming it isn't our problem.) Here is a sample one: NET-MAIL-FROM-HOST:1201200002 RETURN-PATH:@IU.AI.SRI.COM:slug-admin@Warbucks.AI.SRI.COM TO:"Slug-local%zermatt.lcs.mit.edu@ai.ai.mit.edu TO:"CSTACY@ai.ai.mit.edu TO:"Gavan@ai.ai.mit.edu TO:"deg@ai.ai.mit.edu TO:"Henry-News@ai.ai.mit.edu TO:"psi@ai.ai.mit.edu TO:"jrd%media-lab.media.mit.edu@ai.ai.mit.edu TO:"mt%media-lab.media.mit.edu@ai.ai.mit.edu TO:"slug%xn.ll.mit.edu@ai.ai.mit.edu TO:""apollo!weissman"%eddie.mit.edu@ai.ai.mit.edu TEXT;-1 Received: from IU.AI.SRI.COM (TCP 1201200002) by AI.AI.MIT.EDU 8 Sep 88 15:00:11 EDT Received: from Warbucks.AI.SRI.COM by IU.AI.SRI.COM via SMTP with TCP; Thu, 8 Sep 88 11:22:47-PDT Received: from mitre-bedford.ARPA by Warbucks.AI.SRI.COM with INTERNET ; Thu, 8 Sep 88 11:19:34 PDT Full-Name: Smith Message-Id: <8809081818.AA11141@mitre-bedford.ARPA> Posted-From: The MITRE Corp., Bedford, MA To: slug@Warbucks.AI.SRI.COM Subject: remote process communication Date: Thu, 08 Sep 88 14:18:52 EDT From: bds@mitre-bedford.ARPA We need to make 2 or more Symbolics 36xx pass messages back and forth between processes. More explicitly, we want to run a database on one machine and 1 or more interfaces on other machines. Getting processes to talk to each other on the same machine is no problem. Can anyone please tell me how to get them to talk to each other when they're on different machines? Thanks. Barry Smith bds@mitre-bedford.arpa  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 8 Sep 88 12:02:51 EDT Date: Thu, 8 Sep 88 11:58:39 EDT From: Rob Austein Subject: good news and bad news To: BUG-MAIL@MC.LCS.MIT.EDU Message-ID: <477731.880908.SRA@MC.LCS.MIT.EDU> The good news is that Mr. Bawden seems to have correctly located the mysterious bug that caused COMSAT to get horribly confused when the IMP is unavailable. The bad news is that, now that COMSAT is no longer confused, it generates a 50 block STATS file in 3 hours when the IMP is unavailable. Also, I happend to do an $$3^F on AI:SYSNET; and noticed that the write dates of NETRTS * are out of order with respect to the version numbers. Is this known to the people who did it?  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 8 Sep 88 11:53:52 EDT Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 8 Sep 88 11:49:29 EDT Date: Thu 8 Sep 88 11:49:23-EDT From: Rob Austein Subject: Re: Mail problem To: pdb@SEI.CMU.EDU cc: postmaster@MC.LCS.MIT.EDU, BUG-MAIL@MC.LCS.MIT.EDU, postmaster@MEDIA-LAB.MEDIA.MIT.EDU In-Reply-To: <8809081520.AA00565@ci.sei.cmu.edu> Message-ID: <12428944159.25.SRA@XX.LCS.MIT.EDU> Date: Thu, 08 Sep 88 11:20:13 EDT From: Pat Barron I'm not sure if this problem is on my end or your end - I think what's going on is that MC is handing me mail from "@MC.LCS.MIT.EDU:compass!worley", which my mailer is choking on since that's not a valid RFC822 return path. --Pat. ------- Forwarded Message Received: by ci.sei.cmu.edu (5.54/2.2) id AA09027; Wed, 7 Sep 88 12:38:32 EDT Received: by sei.cmu.edu (5.54/2.2) id AA00157; Wed, 7 Sep 88 12:27:11 EDT Date: Wed, 7 Sep 88 12:34:10 EDT From: Communications Satellite Subject: Msg of Wednesday, 7 September 1988 12:34-EDT To: "MAILER-DAEMON@sei.cmu.edu"@sei.cmu.edu Message-Id: <477281.880907@MC.LCS.MIT.EDU> ============ A copy of your message is being returned, because: ========== "COMPASS!WORLEY" at MC.LCS.MIT.EDU is an unknown recipient. ============ Failed message follows: ============ Received: from sei.cmu.edu (TCP 20073201001) by MC.LCS.MIT.EDU 7 Sep 88 12:30:37 EDT Received: by sei.cmu.edu (5.54/2.2) id AA00106; Wed, 7 Sep 88 12:22:08 EDT Date: Wed, 7 Sep 88 12:22:08 EDT From: Mail Delivery Subsystem Subject: Returned mail: Remote protocol error Message-Id: <8809071622.AA00106@sei.cmu.edu> To: <@MC.LCS.MIT.EDU:compass!worley> ----- Transcript of session follows ----- >>> MAIL From:<@MC.LCS.MIT.EDU:compass!worley> <<< 550 malformed path '<@MC.LCS.MIT.EDU' - Missing @ in address 554 skh@cs.cmu.edu,toad@cs.cmu.edu,milnes@cs.cmu.edu... Remote protocol error: Bad file number >>> MAIL From:<@MC.LCS.MIT.EDU:compass!worley> <<< 550 malformed path '<@MC.LCS.MIT.EDU' - Missing @ in address 554 Peter.Shell@ML.RI.CMU.EDU... Remote protocol error: Bad file number >>> MAIL From:<@MC.LCS.MIT.EDU:compass!worley> <<< 550 malformed path '<@MC.LCS.MIT.EDU' - Missing @ in address 554 David.Douglas@ME.RI.CMU.EDU... Remote protocol error: Bad file number ----- Unsent message follows ----- Received: by sei.cmu.edu (5.54/2.2) id AA29963; Wed, 7 Sep 88 12:17:20 EDT Received: from media-lab.media.mit.edu (TCP 2225200002) by MC.LCS.MIT.EDU 7 Sep 88 12:12:26 EDT Received: from THINK.COM by media-lab.media.mit.edu (5.59/4.8) id AA22052; Wed, 7 Sep 88 12:10:33 EDT Return-Path: Received: from news.think.com by Think.COM; Wed, 7 Sep 88 12:12:49 EDT Received: by news.think.com; Wed, 7 Sep 88 12:20:12 EDT Received: from galaxy.compass.com by compass.com (3.2/SMI-3.2) id AA03100; Wed, 7 Sep 88 11:43:01 EDT Received: by galaxy.compass.com (3.2/SMI-3.2) id AA15308; Wed, 7 Sep 88 11:43:35 EDT Date: Wed, 7 Sep 88 11:43:35 EDT From: compass!worley@sei.cmu.edu (Dale Worley) Message-Id: <8809071543.AA15308@galaxy.compass.com> To: subgenius@media-lab.media.mit.edu Subject: Scientologists [ Deleted text of message --Pat.] ------- End of Forwarded Message There are two distinct problems here. Problem 1 is that media-lab.media.mit.edu handed MC a message with an SMTP return path of "compass!worley" (even though the RFC822 headers say "worley@compass.UUCP" -- I checked COMSAT's log to see what was in the envelope). This is of course blatently illegal. Problem 2 is that MC's FTPS (the ITS SMTP listener) isn't smart enough to reject such a message as mallformed. I suppose COMSAT itself could also be blamed here for assuming that the return path it got from FTPS was legal. --Rob -------  Date: Tue, 30 Aug 88 17:40:08 EDT From: "Pandora B. Berman" Subject: missing OSTATS To: RAY@AI.AI.MIT.EDU cc: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <434693.880830.CENT@AI.AI.MIT.EDU> Date: Tue, 30 Aug 88 15:47:29 EDT From: Ray Hirschfeld Subject: missing OSTATS To: BUG-MAIL@AI.AI.MIT.EDU I moved OSTATS 1029, OSTATS 1030, OSTATS 1031, and OSTATS 1032 to my directory (ray) because .mail. was full. Also, I moved them to pk2 because pk0 was full. If anybody wants them, take them. Otherwise I'll delete them in a day or two. thanks, but you (in fact) took more pains than were strictly necessary. normally, the standard way to deal with OSTATS files is: 1. move them to SECOND: as soon as you notice them. 2. on the busy ITSs, delete any over a week old. MC has a daemon which does this automagically; on AI, we do it by hand. ML and MD are currently too idle to make this worth while -- it takes them a month or so to build a single OSTATS file. 3. when space runs low, delete any that are backed up. 4. in true space crunch, delete all but the most recent 2, regardless of backed-up state. the general rule is that OSTATS files are useful, but not vital; we like to keep some around if we can, but if we can't, don't hesitate to flush them.  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 30 Aug 88 17:22:57 EDT Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 131984; Tue 30-Aug-88 16:58:40 EDT Date: Tue, 30 Aug 88 16:58 EDT From: Alan Bawden Subject: Msg of Tuesday, 30 August 1988 00:13-EDT To: Bug-MAIL@AI.AI.MIT.EDU In-Reply-To: <3711.880830@MD.LCS.MIT.EDU>, The message of 30 Aug 88 07:46 EDT from COMSAT%MD.LCS.MIT.EDU@MC.LCS.MIT.EDU, The message of 30 Aug 88 07:46 EDT from Communications Satellite, <7783.880830@ML.AI.MIT.EDU>, The message of 30 Aug 88 07:44 EDT from COMSAT%ML.AI.MIT.EDU@MC.LCS.MIT.EDU, The message of 30 Aug 88 07:44 EDT from Communications Satellite Message-ID: <19880830205846.2.ALAN@PIGPEN.AI.MIT.EDU> As the following two messages demonstrate, COMSAT gives up absurdly quickly in the face of temporary errors. These two mesages, sent automatically on ML and MD last midnight, timed out in about 7.5 hours. (.MAIL. on AI was full.) (I guess COMSAT must retry a temporary error every 15 minutes, and then it gives up when the 31st try fails, that would work out to 7.5 hours.) Date: Tue, 30 Aug 88 07:46:46 EDT From: Communications Satellite FAILED: ALAN at AI.AI.MIT.EDU; I gave up on sending this after 31 "temporary" errors. Failed message follows: ------- Date: Tue, 30 Aug 88 00:13:10 EDT From: Alan Bawden Subject: Feep! To: ALAN%MD.LCS.MIT.EDU@MC.LCS.MIT.EDU Message-ID: <3710.880830.ALAN@MD.LCS.MIT.EDU> Job DAILY ran. Date: Tue, 30 Aug 88 07:44 EDT From: Communications Satellite Subject: Msg of Tuesday, 30 August 1988 00:11-EDT To: ALAN%ML.AI.MIT.EDU@MC.LCS.MIT.EDU FAILED: ALAN at AI.AI.MIT.EDU; I gave up on sending this after 31 "temporary" errors. Failed message follows: ------- Date: Tue, 30 Aug 88 00:11:12 EDT From: Alan Bawden Subject: Feep! To: ALAN%ML.AI.MIT.EDU@MC.LCS.MIT.EDU Message-ID: <7782.880830.ALAN@ML.AI.MIT.EDU> Job DAILY ran.  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 30 Aug 88 17:21:58 EDT Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 131974; Tue 30-Aug-88 16:48:44 EDT Date: Tue, 30 Aug 88 16:48 EDT From: Alan Bawden Subject: missing OSTATS cc: RAY@AI.AI.MIT.EDU, BUG-MAIL@AI.AI.MIT.EDU In-Reply-To: <434520.880830.RAY@AI.AI.MIT.EDU> Message-ID: <19880830204841.1.ALAN@PIGPEN.AI.MIT.EDU> Date: Tue, 30 Aug 88 15:47:29 EDT From: Ray Hirschfeld I moved OSTATS 1029, OSTATS 1030, OSTATS 1031, and OSTATS 1032 to my directory (ray) because .mail. was full.... I dealt with these.  Date: Tue, 30 Aug 88 15:47:29 EDT From: Ray Hirschfeld Subject: missing OSTATS To: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <434520.880830.RAY@AI.AI.MIT.EDU> I moved OSTATS 1029, OSTATS 1030, OSTATS 1031, and OSTATS 1032 to my directory (ray) because .mail. was full. Also, I moved them to pk2 because pk0 was full. If anybody wants them, take them. Otherwise I'll delete them in a day or two. Ray  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 27 Aug 88 12:18:24 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 20024224620) by MC.LCS.MIT.EDU 27 Aug 88 12:16:49 EDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 451354; Sat 27-Aug-88 12:15:44 EDT Date: Sat, 27 Aug 88 12:15 EDT From: David A. Moon Subject: [COMSAT@MC.LCS.MIT.EDU: Msg of Thursday, 25 August 1988 18:45-EDT] To: JTW@XX.LCS.MIT.EDU cc: bug-mail@MC.LCS.MIT.EDU, Chapman.pa@XEROX.COM In-Reply-To: Message-ID: <19880827161552.2.MOON@EUPHRATES.SCRC.Symbolics.COM> Line-fold: No Date: Thu, 25 Aug 1988 23:03 EDT From: JTW@XX.LCS.MIT.EDU From: David A. Moon Re: [COMSAT@MC.LCS.MIT.EDU: Msg of Thursday, 25 August 1988 18:45-EDT] Date: Thu, 25 Aug 88 15:52 PDT From: Chapman.pa@Xerox.COM I sent this to sappho%b@ucscc.ucsc.edu. Here's a vote for removing this broken ``optimization'' from COMSAT. I don't think Comsat has ever had such an "optimization". It might have a bug, but judging by the header, whatever program you used to send the mail did it. What program was it? (And complain to the maintainer of that program.) You sure? I thought it was part of the folklore that COMSAT would short-circuit routing paths like this - a number of people have bitched about it over the past couple of years. It seems like it would have been a reasonable thing to do, too, back in 1812 when host tables still worked, but it sure is a screw now. I'm pretty sure that XMAILR used to do this, but Comsat never did. I remember this from when I experimented with @ and % trying to get a message to take the longest possible path before it got back to me. Chapman's complaint is caused by a bug in Babyl, sending the address to Comsat with an extra space in it, which then causes this problem due to Comsat's left-to-right parsing. Comsat really should have rejected the address as an error, because the host was specified twice, but for some reason it doesn't check. I don't think domains will make any difference to this, the problem is that Comsat accepts too many different formats of address and has too little error checking in its parser.  Date: Fri, 26 Aug 88 19:29:19 EDT From: "Philip E. Agre" Subject: errant missives To: BUG-COMSAT@AI.AI.MIT.EDU, bug-mail@WHEATIES.AI.MIT.EDU Message-ID: <433433.880826.AGRE@AI.AI.MIT.EDU> I got this notification on AI the other day but I never got the mail it referred to. Also I have failed to get at least one other message in the last few days. Have there been mail problems somewhere between AI and Wheaties? Where might the message be hiding? I'm afraid all test messages I've tried have worked correctly. Phil AI ITS.1616. DDT.1544. TTY 17 3. Lusers, Fair Share = 72% agre$u AGRE0$U--Init-- THURSDAY, AUGUST 25, 1988 00:23:33 AM r 00:23 78% 3. 49. .FOO. ^A (Getting SENDS for AGRE) You have net mail from NSS.CS.UCL.AC.UK: Received: from NSS.Cs.Ucl.AC.UK (TCP 20012204403) by AI.AI.MIT.EDU 24 Aug 88 21:19:16 EDT Received: from computer-science.nottingham.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP id aa00645; 25 Aug 88 1:48 BST Received: from rpsyc by Robin.Cs.Nott.AC.UK id aa17870; 24 Aug 88 18:16 BST (21 more lines) ^_ r 00:23 78% 3. 49. .FOO. $$u AI ITS 1616 Console 17 Free. 00:23:40  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 26 Aug 88 15:26:35 EDT Received: from Xerox.COM (TCP 1500006350) by MC.LCS.MIT.EDU 26 Aug 88 15:22:34 EDT Received: from Semillon.ms by ArpaGateway.ms ; 26 AUG 88 12:20:32 PDT Date: Fri, 26 Aug 88 12:19 PDT From: Chapman.pa@Xerox.COM Subject: [COMSAT@MC.LCS.MIT.EDU: Msg of Thursday, 25 August 1988 18:45-EDT] To: JTW@XX.LCS.MIT.EDU cc: Moon@STONY-BROOK.SCRC.SYMBOLICS.COM, bug-mail@MC.LCS.MIT.EDU In-Reply-To: Message-ID: <19880826191904.2.ZVONA@SPIFF.parc.xerox.com> Line-fold: no I don't think Comsat has ever had such an "optimization". You sure? I thought it was part of the folklore that COMSAT would short-circuit routing paths like this - Actually I have a vague memory of babyl doing something like this. But I could be wrong.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 25 Aug 88 23:06:15 EDT Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 25 Aug 88 23:04:13 EDT Date: Thu, 25 Aug 1988 23:03 EDT Message-ID: From: JTW@XX.LCS.MIT.EDU To: "David A. Moon" Cc: bug-mail@MC.LCS.MIT.EDU, Chapman.pa@XEROX.COM Subject: [COMSAT@MC.LCS.MIT.EDU: Msg of Thursday, 25 August 1988 18:45-EDT] In-reply-to: Msg of 25 Aug 1988 21:25-EDT from David A. Moon From: David A. Moon Re: [COMSAT@MC.LCS.MIT.EDU: Msg of Thursday, 25 August 1988 18:45-EDT] Date: Thu, 25 Aug 88 15:52 PDT From: Chapman.pa@Xerox.COM I sent this to sappho%b@ucscc.ucsc.edu. Here's a vote for removing this broken ``optimization'' from COMSAT. I don't think Comsat has ever had such an "optimization". It might have a bug, but judging by the header, whatever program you used to send the mail did it. What program was it? (And complain to the maintainer of that program.) You sure? I thought it was part of the folklore that COMSAT would short-circuit routing paths like this - a number of people have bitched about it over the past couple of years. It seems like it would have been a reasonable thing to do, too, back in 1812 when host tables still worked, but it sure is a screw now. (Amusingly, rutgers, one of the big uucp forwarding nodes, just started doing this in their uucp router, on the theory that for some reason they were likely to have a more up to date uucp map than their clients. So far they have gotten about 1e06 flaming missles pointing out that most people who own small workstations in Italy don't -put- their machines in the uucp maps, and dammit, if we asked you to send the mail through host xyzzy, we meant it. But they still haven't got the point, and consequently appear to be sending a more or less infinite amount of mail off into hyperspace...) Oh well, we seem to actually be getting to the point when we'll be ready (euphemism) to delve into COMSAT to hook it up to the domain system. Perhaps we can straighten all this out then. (Any of you who are actually interested in -doing- this work, please identify yourselves to an usher. Thank you.)  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 25 Aug 88 21:28:02 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 20024224620) by MC.LCS.MIT.EDU 25 Aug 88 21:26:32 EDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 450893; Thu 25-Aug-88 21:25:36 EDT Date: Thu, 25 Aug 88 21:25 EDT From: David A. Moon Subject: [COMSAT@MC.LCS.MIT.EDU: Msg of Thursday, 25 August 1988 18:45-EDT] To: Chapman.pa@Xerox.COM cc: bug-mail@MC.LCS.MIT.EDU In-Reply-To: <19880825225234.2.ZVONA@SPIFF.parc.xerox.com>, <472185.880825@MC.LCS.MIT.EDU>, The message of 25 Aug 88 18:45 EDT from COMSAT@MC.LCS.MIT.EDU, The message of 25 Aug 88 18:45 EDT from Communications Satellite Message-ID: <19880826012544.4.MOON@EUPHRATES.SCRC.Symbolics.COM> Line-fold: No Date: Thu, 25 Aug 88 15:52 PDT From: Chapman.pa@Xerox.COM I sent this to sappho%b@ucscc.ucsc.edu. Here's a vote for removing this broken ``optimization'' from COMSAT. I don't think Comsat has ever had such an "optimization". It might have a bug, but judging by the header, whatever program you used to send the mail did it. What program was it? (And complain to the maintainer of that program.) Date: Thu, 25 Aug 88 15:45 PDT From: Communications Satellite Subject: Msg of Thursday, 25 August 1988 18:45-EDT To: ZVONA@MC.LCS.MIT.EDU FAILED: sappho at REAGAN.AI.MIT.EDU; Recipient name apparently rejected. Last reply was: {550 Recipient sappho@REAGAN.AI.MIT.EDU is not defined on this host.} Failed message follows: ------- Date: Thu, 25 Aug 88 18:45:21 EDT From: David Chapman To: sappho@REAGAN.AI.MIT.EDU Message-ID: <472184.880825.ZVONA@MC.LCS.MIT.EDU> I've removed you from the pagnaism list pro tem. Let me know when you wan tback on.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 25 Aug 88 19:06:17 EDT Received: from Xerox.COM (TCP 1500006350) by MC.LCS.MIT.EDU 25 Aug 88 19:05:00 EDT Received: from Semillon.ms by ArpaGateway.ms ; 25 AUG 88 15:54:26 PDT Date: Thu, 25 Aug 88 15:52 PDT From: Chapman.pa@Xerox.COM Subject: [COMSAT@MC.LCS.MIT.EDU: Msg of Thursday, 25 August 1988 18:45-EDT] To: bug-mail@mc.lcs.mit.edu Included-msgs: <472185.880825@MC.LCS.MIT.EDU>, The message of 25 Aug 88 15:45 PDT from COMSAT@MC.LCS.MIT.EDU, The message of 25 Aug 88 15:45 PDT from Communications Satellite Message-ID: <19880825225234.2.ZVONA@SPIFF.parc.xerox.com> Line-fold: no I sent this to sappho%b@ucscc.ucsc.edu. Here's a vote for removing this broken ``optimization'' from COMSAT. Date: Thu, 25 Aug 88 15:45 PDT From: Communications Satellite Subject: Msg of Thursday, 25 August 1988 18:45-EDT To: ZVONA@MC.LCS.MIT.EDU FAILED: sappho at REAGAN.AI.MIT.EDU; Recipient name apparently rejected. Last reply was: {550 Recipient sappho@REAGAN.AI.MIT.EDU is not defined on this host.} Failed message follows: ------- Date: Thu, 25 Aug 88 18:45:21 EDT From: David Chapman To: sappho@REAGAN.AI.MIT.EDU Message-ID: <472184.880825.ZVONA@MC.LCS.MIT.EDU> I've removed you from the pagnaism list pro tem. Let me know when you wan tback on.  Date: Tue, 23 Aug 88 12:36:49 EDT From: Devon Sean McCullough To: BUG-COMSAT@AI.AI.MIT.EDU Message-ID: <431729.880823.DEVON@AI.AI.MIT.EDU> I send mail to bboard with an expires field which was ignored.  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 8 Aug 88 14:30:23 EDT Date: Mon 8 Aug 88 14:25:40-EDT From: Rob Austein Subject: Re: mit-ai.arpa To: DCP@QUABBIN.SCRC.Symbolics.COM cc: bug-comsat@AI.AI.MIT.EDU, Bug-Mailer@QUABBIN.SCRC.Symbolics.COM In-Reply-To: <19880808164239.5.DCP@SWAN.SCRC.Symbolics.COM> Message-ID: <12420846144.44.SRA@XX.LCS.MIT.EDU> Date: Mon, 8 Aug 88 12:42 EDT From: David C. Plummer It would be (selfishly) nice if AI accepted MIT-AI.ARPA as an (obsolete) name for itself when receiving mail. As far as I can tell, AI rejects such mail at the SMTP HELO phase or somesuch, and unfortunately the Symbolics mailers send all knowledge about all of this into a black hole (i.e., no notice is sent back to the sender). It's not happening in the SMTP listener (FTPS isn't that smart). Presumably it's happening in COMSAT, which is rejecting it for the simple reason that "MIT-AI.ARPA" isn't in the host tables. If you edit the namespace object AI|AI and add that nickname, it should work (eventually, it takes a day or so for everything to propegate). You might want to ask somebody at the AI lab first though, they may have some policy reason for wanting to keep nicknames like that out of the host tables. This request is to get around another (known) bug in the Symbolics mail system that disallows domain names in the mailboxes files, and I figured it would be easier to kludge ITS than the Symbolics mailer. Don't spend too much time on it, though. Thanks. Don't worry, we won't. -------  Received: from JASPER.SCRC.Symbolics.COM (TCP 20024224472) by AI.AI.MIT.EDU 8 Aug 88 12:46:51 EDT Received: from SWAN.SCRC.Symbolics.COM by JASPER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 208918; Mon 8-Aug-88 12:43:45 EDT Date: Mon, 8 Aug 88 12:42 EDT From: David C. Plummer Subject: mit-ai.arpa To: bug-comsat@AI.AI.MIT.EDU cc: Bug-Mailer@QUABBIN.SCRC.Symbolics.COM Message-ID: <19880808164239.5.DCP@SWAN.SCRC.Symbolics.COM> It would be (selfishly) nice if AI accepted MIT-AI.ARPA as an (obsolete) name for itself when receiving mail. As far as I can tell, AI rejects such mail at the SMTP HELO phase or somesuch, and unfortunately the Symbolics mailers send all knowledge about all of this into a black hole (i.e., no notice is sent back to the sender). This request is to get around another (known) bug in the Symbolics mail system that disallows domain names in the mailboxes files, and I figured it would be easier to kludge ITS than the Symbolics mailer. Don't spend too much time on it, though. Thanks.  Date: Mon, 8 Aug 88 06:50:03 EDT From: "Pandora B. Berman" Subject: bug-who? To: BUG-MAIL@AI.AI.MIT.EDU cc: DEVON@AI.AI.MIT.EDU, GREN@AI.AI.MIT.EDU Message-ID: <424248.880808.CENT@AI.AI.MIT.EDU> once upon a time, when the world was new and all, there was a KA10 called AI. and as time passed, it grew surpassingly many mailing lists, for it was friendly and popular. and it grew many bug lists, for all the hackers hacked there at least sometimes, and any bug- address sent to on another ITS which didn't know it always went to AI, because that was the canonical place for bug lists, and it was sure to find someone to help, even if it was only BUG-RANDOM-PROGRAM. one among many of these bug lists was BUG-SENDER. there's been a lot of water under the bridge since then, and the world is no longer quite so new and all. AI has passed the job of being the canonical place for bug lists to MC. AI is not a KA any more, nor is MC a KL. when the mailing lists were copied from oldMC to newMC, someone dutifully copied the entry explicitly sending mail for BUG-SENDER to that address on AI. but on the new AI, that address doesn't exist; however, since it's a bug- address, AI tries to be helpful by sending any mail for it to the canonical bug- host, which is MC.... this problem was exercised this morning. by the time i found it, it was over 4 blocks long -- see MC:BADREQ 1 for giggles. by perusing the archive version of the AIKA NAMES file, i discovered that BUG-SENDER used to forward to BUG-GREN@OZ.... OZ is pretty much no more, and i'm no longer conversant with Gren's state, but one can probably get mail to him if one doesn't try too hard. Ian, below is the original msg shorn of the extraneous headers, empty footers, and green special-delivery stripes down the side. i have fixed BUG-SENDER to go directly to you rather than shilly-shallying around like this again. ---------- Date: Sun, 7 Aug 88 22:38:25 EDT From: Devon Sean McCullough Subject: try to talk to a unix, see what you get... To: BUG-SENDER@AI.AI.MIT.EDU Message-ID: <424035.880807.DEVON@AI.AI.MIT.EDU> Date: Sun, 7 Aug 88 21:55:52 EDT From: Communications Satellite To: DEVON at AI.AI.MIT.EDU cc: MAIL-MAINTAINERS at AI.AI.MIT.EDU Error in input request file. Parsing error: Line 0: EOF and no ")" Line stopped at is: RCPT:(^_ Message not sent and not queued;text of bad file follows: -------- FROM-PROGRAM:SENDER FROM-XUNAME:DEVON FROM-UNAME:DEVON RCPT:(^_ TTY@EDDIE.MIT.EDU) TEXT;-1  Date: Mon, 8 Aug 88 04:54:32 EDT From: "Pandora B. Berman" Subject: Undeliverable Mail To: postmaster@MITVMA.MIT.EDU, smtp@MITVMA.MIT.EDU cc: HEADER-PEOPLE-REQUEST@AI.AI.MIT.EDU, BUG-MAIL@AI.AI.MIT.EDU Message-ID: <424202.880808.CENT@AI.AI.MIT.EDU> Date: Sat, 6 Aug 88 05:19:06 EDT From: "Pandora B. Berman" Subject: Undeliverable Mail To: postmaster@MITVMA.MIT.EDU, smtp@MITVMA.MIT.EDU cc: HEADER-PEOPLE-REQUEST@AI.AI.MIT.EDU, BUG-MAIL@AI.AI.MIT.EDU Date: Sat, 06 Aug 88 03:42:23 EDT From: SMTP@MITVMA.MIT.EDU To: header-people-request@mc.lcs.mit.edu Subject: Undeliverable Mail Error in Batch SMTP Command Sequence. Unable to deliver mail to some/all recipients. Reply codes with first digit = '4' or '5' are error replies: 220 MITVMA.MIT.EDU running IBM VM SMTP R1.1 on Sat, 06 Aug 88 03:42:22 EDT 050 HELO MITVMA.MIT.EDU 250 MITVMA.MIT.EDU 050 TICK 5816 250 OK 050 MAIL FROM: 250 OK 050 RCPT TO: 550 Host 'BITNET' Unknown 050 DATA 503 No Recipients specified ** Text of Mail follows ** [removed] QUIT the original address the msg was sent to was the Header-People@MC list, which includes the address "MJL%DGAIPP1S.BITNET@MITVMA.MIT.EDU". this particular address is new on the list, but this is the form that has always worked; MITVMA must have garbled the ".BITNET" to "@BITNET". the Header-People list includes many bitnet addresses which explicitly forward through MITVMA, but this is the only one complained about. what goes on here? i take it back. i apologize. what i had in the list was really "MJL%DGAIPP1S%BITNET@MITVMA.MIT.EDU", which would understandably cause exactly the kind of error that ensued. it's fixed now. sorry for the fuss & commotion.  Date: Sat, 6 Aug 88 05:19:06 EDT From: "Pandora B. Berman" Subject: Undeliverable Mail To: postmaster@MITVMA.MIT.EDU, smtp@MITVMA.MIT.EDU cc: HEADER-PEOPLE-REQUEST@AI.AI.MIT.EDU, BUG-MAIL@AI.AI.MIT.EDU Message-ID: <423571.880806.CENT@AI.AI.MIT.EDU> Date: Sat, 06 Aug 88 03:42:23 EDT From: SMTP@MITVMA.MIT.EDU To: header-people-request@mc.lcs.mit.edu Subject: Undeliverable Mail Error in Batch SMTP Command Sequence. Unable to deliver mail to some/all recipients. Reply codes with first digit = '4' or '5' are error replies: 220 MITVMA.MIT.EDU running IBM VM SMTP R1.1 on Sat, 06 Aug 88 03:42:22 EDT 050 HELO MITVMA.MIT.EDU 250 MITVMA.MIT.EDU 050 TICK 5816 250 OK 050 MAIL FROM: 250 OK 050 RCPT TO: 550 Host 'BITNET' Unknown 050 DATA 503 No Recipients specified ** Text of Mail follows ** HELO MITVMA.MIT.EDU TICK 5816 MAIL FROM: RCPT TO: DATA Received: from MITVMA by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 5816; Sat, 06 Aug 88 03:42:14 EDT Received: from MC.LCS.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with TCP; Sat, 06 Aug 88 03:42:10 EDT Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 6 Aug 88 03:26:26 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Sat, 6 Aug 88 03:21:42 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 6 Aug 88 06:13:40 GMT From: palo-alto!vixie@decwrl.dec.com (Paul Vixie) Organization: DEC Western Research Lab Subject: Real data to support my claim that '-d sun' is the way to go. Message-Id: <3703@palo-alto.DEC.COM> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu [text of msg mostly removed] Paul Vixie Digital Equipment Corporation Work: vixie@dec.com Play: paul@vixie.UUCP Western Research Laboratory uunet!decwrl!vixie uunet!vixie!paul Palo Alto, California, USA +1 415 853 6600 +1 415 864 7013 , QUIT note that the "," just before the QUIT was probably a "." when COMSAT received it (i suppose MITVMA sent it?); i believe COMSAT always changes periods alone on lines to commas to forestall multics braindamage. the original address the msg was sent to was the Header-People@MC list, which includes the address "MJL%DGAIPP1S.BITNET@MITVMA.MIT.EDU". this particular address is new on the list, but this is the form that has always worked; MITVMA must have garbled the ".BITNET" to "@BITNET". the Header-People list includes many bitnet addresses which explicitly forward through MITVMA, but this is the only one complained about. what goes on here?  Date: Wed, 3 Aug 88 23:26:19 EDT From: David Chapman Subject: what's this bullshit? To: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <422321.880803.ZVONA@AI.AI.MIT.EDU> :mail zvona@mc foo^C MAIL error - No such site known: "mc" MAIL error - No recipients!  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 28 Jul 88 17:23:37 EDT Received: from WRONSKI.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 127101; Thu 28-Jul-88 17:21:43 EDT Date: Thu, 28 Jul 88 17:21 EDT From: Alan Bawden Subject: *msg software buggy To: CENT@AI.AI.MIT.EDU cc: BUG-MAIL@AI.AI.MIT.EDU In-Reply-To: <418049.880725.CENT@AI.AI.MIT.EDU> Message-ID: <19880728212146.2.ALAN@WRONSKI.AI.MIT.EDU> Date: Mon, 25 Jul 88 17:11:42 EDT From: "Pandora B. Berman" on both AI and MC (and therefore i expect in general) i have found *MSGs that have hung on much too long in .MSGS.;. on inspection, they proved to be all sent on the 25th of odd-numbered months which have 31 days, and to have acquired expiration dates of X/00/88, where X was the same month in which they were sent (3 or 5). i have deleted most of these, but have left around a representative of each class on AI:.MSGS.; for examination. i assume the expiration-date generator is addled. I fixed the bug in the DATIME library that caused such dates to be generated when I caught some other program doing this. The bug only happens in 31-day months after February during a leap year. "Somebody" probably put this time bomb there a few years ago. I presume that the reason you haven't seen any of these turds generated this July, is that COMSAT was recently reassembled and picked up the DATIME fix.  Date: Mon, 25 Jul 88 17:11:42 EDT From: "Pandora B. Berman" Subject: *msg software buggy To: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <418049.880725.CENT@AI.AI.MIT.EDU> on both AI and MC (and therefore i expect in general) i have found *MSGs that have hung on much too long in .MSGS.;. on inspection, they proved to be all sent on the 25th of odd-numbered months which have 31 days, and to have acquired expiration dates of X/00/88, where X was the same month in which they were sent (3 or 5). i have deleted most of these, but have left around a representative of each class on AI:.MSGS.; for examination. i assume the expiration-date generator is addled.  Date: Fri, 22 Jul 88 21:15:21 EDT From: "Pandora B. Berman" Subject: too much mail To: HENRY@AI.AI.MIT.EDU cc: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <417207.880722.CENT@AI.AI.MIT.EDU> i was looking for space online and found over 30 copies of your BABYL > and over 15 copies of your NEWS > files; they were taking up about 2500 blocks. as you may recall, ITS does not have automatic version deletion. please keep your directory from eating all of free space by cleaning up after yourself. i think this is a symptom of ZMAIL (i recall seeing it on OZ also); it might help if your mail files were named HENRY BABYL and HENRY NEWS, so that they would overwrite rather than create more copies.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 21 Jul 88 16:12:36 EDT Received: from void (TCP 2206400236) by MC.LCS.MIT.EDU 21 Jul 88 16:06:44 EDT Received: by VOID.AI.MIT.EDU; Thu, 21 Jul 88 16:07:24 edt Date: Thu, 21 Jul 88 16:07:24 edt From: jar@VOID.AI.MIT.EDU (Jonathan Rees) Message-Id: <8807212007.AA13876@void> To: bug-comsat@mc Subject: [COMSAT@AI.AI.MIT.EDU: Msg of Monday, 20 June 1988 17:16-EDT] Reply-To: jar@zurich.ai.mit.edu Why did it take 31 days for this :SEND (or was :QSEND?) to bounce back to me? And here I've been assuming all this time that I was snubbed... - Jonathan Date: Thu, 21 Jul 88 12:29:52 EDT From: Communications Satellite Subject: Msg of Monday, 20 June 1988 17:16-EDT To: JAR@AI.AI.MIT.EDU FAILED: mohr at KAZOO.LCS.MIT.EDU; Recipient name apparently rejected. Last reply was: {550 No user is logged in.} Failed message follows: ------- JAR@AI.AI.MIT.EDU 06/20/88 17:16:53 To: mohr at KAZOO.LCS.MIT.EDU You have dinner plans? (Not immediately, later)  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 18 Jul 88 22:04:21 EDT Date: Mon 18 Jul 88 21:58:31-EDT From: Rob Austein Subject: Re: mailer on ITS To: dms@wheaties.ai.mit.edu cc: bug-mailer@AI.AI.MIT.EDU In-Reply-To: <8807190059.AA05276@cheerios.ai.mit.edu> Message-ID: <12415423559.19.SRA@XX.LCS.MIT.EDU> Date: Mon, 18 Jul 88 20:59:26 EDT From: dms@wheaties.ai.mit.edu (David M Siegel) Looking at this header, it seems that COMSAT wants to return the message to the fellow at DEC, but uses the "received from" lines to cleverly figure that it should first forward the message to prep, since that was who sent it to ai in the first place: Date: Wed, 13 Jul 88 15:06:20 EDT From: Communications Satellite Subject: Msg of Sunday, 10 July 1988 19:22-EDT To: "decvax!gsg!gsgpyr!lew@decwrl.dec.com"@prep.ai.mit.edu Message-Id: <411579.880713@AI.AI.MIT.EDU> It is not parsing the RECEIVED lines, I assure you. Since you have cleverly edited out the lines of the error message that show what the original message looked like, it is hard to tell what did happen. Why is this even necessary, since AI can easily send the message to decwrl.dec.com in the first place? Go read the mail specs (RFCs 821/822) to see why you return things along the same path you got them. The basic theory is that since something is known to be broken (or we wouldn't be sending an error message) it is best to be conservative to maximize the chance that the error message will in fact make it home. There is no need for AI to even tack the quotes marks and @prep.ai.mit.edu stuff onto the address. It could just as easily forward the unmodified address to prep, and let prep deal with it. Prep would then correctly forward the message to DEC. One more thing... it is a good idea to allow quotes to be put around local usernames, since there is not reason why a username can't contain some special character that also means something to mailers. The only reason I keep bringing this up is that I get sometimes 20 of these style bounced messages a day. Ok, I understand why this bothers you. What you should understand is that nobody really has time to go making changes to COMSAT when it's not broken. If you have time and are willing to take responsibility for what you break, great, I'll show you the sources, have fun. -------  Received: from cheerios.ai.mit.edu (TCP 20015021413) by AI.AI.MIT.EDU 18 Jul 88 21:00:48 EDT Received: by cheerios.ai.mit.edu; Mon, 18 Jul 88 20:59:26 EDT Date: Mon, 18 Jul 88 20:59:26 EDT From: dms@wheaties.ai.mit.edu (David M Siegel) Message-Id: <8807190059.AA05276@cheerios.ai.mit.edu> To: bug-mailer@ai.ai.mit.edu Subject: mailer on ITS Looking at this header, it seems that COMSAT wants to return the message to the fellow at DEC, but uses the "received from" lines to cleverly figure that it should first forward the message to prep, since that was who sent it to ai in the first place: Date: Wed, 13 Jul 88 15:06:20 EDT From: Communications Satellite Subject: Msg of Sunday, 10 July 1988 19:22-EDT To: "decvax!gsg!gsgpyr!lew@decwrl.dec.com"@prep.ai.mit.edu Message-Id: <411579.880713@AI.AI.MIT.EDU> Why is this even necessary, since AI can easily send the message to decwrl.dec.com in the first place? There is no need for AI to even tack the quotes marks and @prep.ai.mit.edu stuff onto the address. It could just as easily forward the unmodified address to prep, and let prep deal with it. Prep would then correctly forward the message to DEC. One more thing... it is a good idea to allow quotes to be put around local usernames, since there is not reason why a username can't contain some special character that also means something to mailers. The only reason I keep bringing this up is that I get sometimes 20 of these style bounced messages a day. -Dave  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 13 Jul 88 18:21:50 EDT Date: Wed 13 Jul 88 18:17:04-EDT From: Rob Austein Subject: Re: [MAILER-DAEMON@prep.ai.mit.edu: Returned mail: Host unknown] To: dms@wheaties.ai.mit.edu cc: bug-mail@AI.AI.MIT.EDU In-Reply-To: <8807132146.AA00213@cheerios.ai.mit.edu> Message-ID: <12414072525.12.SRA@XX.LCS.MIT.EDU> Date: Wed, 13 Jul 88 17:46:00 EDT From: dms@wheaties.ai.mit.edu (David M Siegel) It looks like it is the AI mailer that is adding quotes to the return address in these messages. Is that really the correct thing to be doing? No, it is A correct thing to be doing. There are other correct things it could do instead. Life is rough in a heterogeneous world. Return-Path: Date: Wed, 13 Jul 88 13:46:19 EST From: MAILER-DAEMON@prep.ai.mit.edu (Mail Delivery Subsystem) Subject: Returned mail: Host unknown To: ----- Transcript of session follows ----- 550 ... Host unknown: Connection refused by prep.ai.mit.edu ----- Unsent message follows ----- Received: from ai.ai.mit.edu by prep.ai.mit.edu; Wed, 13 Jul 88 13:46:19 EST Date: Wed, 13 Jul 88 15:06:20 EDT From: Communications Satellite Subject: Msg of Sunday, 10 July 1988 19:22-EDT To: "decvax!gsg!gsgpyr!lew@decwrl.dec.com"@prep.ai.mit.edu Message-Id: <411579.880713@AI.AI.MIT.EDU> FAILED: hack at GNU.AI.MIT.EDU; Host appears to be permanently down or not accepting mail. Failed message follows: ------- Received: from prep.ai.mit.edu (TCP 20015020016) by AI.AI.MIT.EDU 10 Jul 88 19:22:54 EDT Received: from decwrl.dec.com by prep.ai.mit.edu; Sun, 10 Jul 88 18:02:35 EST Received: from decvax by decwrl.dec.com (5.54.4/4.7.34) id AA21290; Sun, 10 Jul 88 16:18:18 PDT Received: by gsg.UUCP (5.51/5.17) id AA04054; Sun, 10 Jul 88 19:03:46 EDT Received: by gsgpyr.UUCP (5.51/4.7) id AA18060; Sun, 10 Jul 88 18:52:30 EDT Date: Sun, 10 Jul 88 18:52:30 EDT From: decvax!gsg!gsgpyr!lew@decwrl.dec.com (Paul Lew) Message-Id: <8807102252.AA18060@gsgpyr.UUCP> To: gsg!decvax!decwrl!bug-gdb@prep.ai.mit.edu Subject: recommendation on gdb needed -------  Received: from cheerios.ai.mit.edu (TCP 20015021413) by AI.AI.MIT.EDU 13 Jul 88 17:46:45 EDT Received: by cheerios.ai.mit.edu; Wed, 13 Jul 88 17:46:00 EDT Date: Wed, 13 Jul 88 17:46:00 EDT From: dms@wheaties.ai.mit.edu (David M Siegel) Message-Id: <8807132146.AA00213@cheerios.ai.mit.edu> To: bug-mailer@ai.ai.mit.edu Subject: [MAILER-DAEMON@prep.ai.mit.edu: Returned mail: Host unknown] It looks like it is the AI mailer that is adding quotes to the return address in these messages. Is that really the correct thing to be doing? Return-Path: Date: Wed, 13 Jul 88 13:46:19 EST From: MAILER-DAEMON@prep.ai.mit.edu (Mail Delivery Subsystem) Subject: Returned mail: Host unknown To: ----- Transcript of session follows ----- 550 ... Host unknown: Connection refused by prep.ai.mit.edu ----- Unsent message follows ----- Received: from ai.ai.mit.edu by prep.ai.mit.edu; Wed, 13 Jul 88 13:46:19 EST Date: Wed, 13 Jul 88 15:06:20 EDT From: Communications Satellite Subject: Msg of Sunday, 10 July 1988 19:22-EDT To: "decvax!gsg!gsgpyr!lew@decwrl.dec.com"@prep.ai.mit.edu Message-Id: <411579.880713@AI.AI.MIT.EDU> FAILED: hack at GNU.AI.MIT.EDU; Host appears to be permanently down or not accepting mail. Failed message follows: ------- Received: from prep.ai.mit.edu (TCP 20015020016) by AI.AI.MIT.EDU 10 Jul 88 19:22:54 EDT Received: from decwrl.dec.com by prep.ai.mit.edu; Sun, 10 Jul 88 18:02:35 EST Received: from decvax by decwrl.dec.com (5.54.4/4.7.34) id AA21290; Sun, 10 Jul 88 16:18:18 PDT Received: by gsg.UUCP (5.51/5.17) id AA04054; Sun, 10 Jul 88 19:03:46 EDT Received: by gsgpyr.UUCP (5.51/4.7) id AA18060; Sun, 10 Jul 88 18:52:30 EDT Date: Sun, 10 Jul 88 18:52:30 EDT From: decvax!gsg!gsgpyr!lew@decwrl.dec.com (Paul Lew) Message-Id: <8807102252.AA18060@gsgpyr.UUCP> To: gsg!decvax!decwrl!bug-gdb@prep.ai.mit.edu Subject: recommendation on gdb needed I am wondering if there is a port of gdb to system V environment. (I have the source of gdb version 2.5). My target machine is based on ATT system V release 2.4 and the cpu is 68010. There are some modication to support bsd TCP but the compiler is from system V.2.4. I noticed there is a m68k-opcode.h which should be usable, but there is no m-.h file for system V. Do I need to make a m-.h file or can I use one of the existing m-*.h file? Sdb on our target machine failed on large program and it is very hard to debug with adb on programs use dynamic memory allocation. Will gdb be able to debug large program like GNU Emacs or X window programs? Any help or pointer will be appreciated. Thanks for you time... -- Paul 07/10/88 06:50 PM --  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 11 Jul 88 20:43:55 EDT Date: Mon 11 Jul 88 20:39:29-EDT From: Rob Austein Subject: Re: [MAILER-DAEMON@wheaties.ai.mit.edu: Returned mail: Host unknown] To: dms@wheaties.ai.mit.edu cc: bug-mail@AI.AI.MIT.EDU In-Reply-To: <8807120032.AA06874@cheerios.ai.mit.edu> Message-ID: <12413574164.25.SRA@XX.LCS.MIT.EDU> Date: Mon, 11 Jul 88 20:32:50 EDT From: dms@wheaties.ai.mit.edu (David M Siegel) How should the quotes be handled? That is, what does: "dms@wheaties.ai.mit.edu"@wheaties.ai.mit.edu mean? Should this go to user "dms" at "wheaties.ai.mit.edu", or user "dms@wheaties.ai.mit.edu", at wheaties, where dms@wheaties.ai.mit.edu should be a username on wheaties. That's up to the mailer on wheaties. Quotes mean that everybody involved in getting the mail to wheaties should treat that as an atom. I would assume that you would treat it as a username "dms" but suit yourself. COMSAT will do the other, but that's because once upon a time there was a religous faction that believed it should be possible to send to a BUG- mailing list for the @ program (BUG-@@AI). -------  Received: from cheerios.ai.mit.edu (TCP 20015021413) by AI.AI.MIT.EDU 11 Jul 88 20:33:56 EDT Received: by cheerios.ai.mit.edu; Mon, 11 Jul 88 20:32:50 EDT Date: Mon, 11 Jul 88 20:32:50 EDT From: dms@wheaties.ai.mit.edu (David M Siegel) Message-Id: <8807120032.AA06874@cheerios.ai.mit.edu> To: bug-mail@ai.ai.mit.edu Cc: bug-mailer@ai.ai.mit.edu In-Reply-To: Rob Austein's message of Mon 11 Jul 88 19:36:53-EDT <12413562768.25.SRA@XX.LCS.MIT.EDU> Subject: [MAILER-DAEMON@wheaties.ai.mit.edu: Returned mail: Host unknown] How should the quotes be handled? That is, what does: "dms@wheaties.ai.mit.edu"@wheaties.ai.mit.edu mean? Should this go to user "dms" at "wheaties.ai.mit.edu", or user "dms@wheaties.ai.mit.edu", at wheaties, where dms@wheaties.ai.mit.edu should be a username on wheaties. -Dave  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 11 Jul 88 19:41:15 EDT Date: Mon 11 Jul 88 19:36:53-EDT From: Rob Austein Subject: Re: [MAILER-DAEMON@wheaties.ai.mit.edu: Returned mail: Host unknown] To: dms@wheaties.ai.mit.edu cc: bug-mailer@AI.AI.MIT.EDU Reply-To: bug-mail@ai.ai.mit.edu In-Reply-To: <8807112156.AA06746@cheerios.ai.mit.edu> Message-ID: <12413562768.25.SRA@XX.LCS.MIT.EDU> Date: Mon, 11 Jul 88 17:56:04 EDT From: dms@wheaties.ai.mit.edu (David M Siegel) Any idea who is putting quotes around the username? Or if the quotes are valid? No, yes. Return-Path: Date: Mon, 11 Jul 88 17:17:51 EDT From: MAILER-DAEMON@wheaties.ai.mit.edu (Mail Delivery Subsystem) Subject: Returned mail: Host unknown To: postmaster ----- Transcript of session follows ----- 421 Host wheaties.ai.mit.edu@ not found for mailer tcp. 550 ... Host unknown ----- Message header follows ----- Return-Path: <@@wheaties.ai.mit.edu> Received: from MC.LCS.MIT.EDU by wheat-chex.ai.mit.edu; Mon, 11 Jul 88 17:02:36 EDT Date: Mon, 11 Jul 88 17:00:06 EDT From: Communications Satellite Subject: Msg of Monday, 11 July 1988 16:56-EDT To: "djb@wheaties.ai.mit.edu"@wheat-chex.ai.mit.edu Message-Id: <449871.880711@MC.LCS.MIT.EDU> -------  Received: from cheerios.ai.mit.edu (TCP 20015021413) by AI.AI.MIT.EDU 11 Jul 88 17:56:24 EDT Received: by cheerios.ai.mit.edu; Mon, 11 Jul 88 17:56:04 EDT Date: Mon, 11 Jul 88 17:56:04 EDT From: dms@wheaties.ai.mit.edu (David M Siegel) Message-Id: <8807112156.AA06746@cheerios.ai.mit.edu> To: bug-mailer@ai.ai.mit.edu Subject: [MAILER-DAEMON@wheaties.ai.mit.edu: Returned mail: Host unknown] Any idea who is putting quotes around the username? Or if the quotes are valid? Return-Path: Date: Mon, 11 Jul 88 17:17:51 EDT From: MAILER-DAEMON@wheaties.ai.mit.edu (Mail Delivery Subsystem) Subject: Returned mail: Host unknown To: postmaster ----- Transcript of session follows ----- 421 Host wheaties.ai.mit.edu@ not found for mailer tcp. 550 ... Host unknown ----- Message header follows ----- Return-Path: <@@wheaties.ai.mit.edu> Received: from MC.LCS.MIT.EDU by wheat-chex.ai.mit.edu; Mon, 11 Jul 88 17:02:36 EDT Date: Mon, 11 Jul 88 17:00:06 EDT From: Communications Satellite Subject: Msg of Monday, 11 July 1988 16:56-EDT To: "djb@wheaties.ai.mit.edu"@wheat-chex.ai.mit.edu Message-Id: <449871.880711@MC.LCS.MIT.EDU>  Date: Tue, 5 Jul 88 23:27:26 EDT From: "Pandora B. Berman" Subject: *msg To: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <407769.880705.CENT@AI.AI.MIT.EDU> i have just regularized the *msg address on the 3 ITSi which hack mail. when MD comes up again i should fix the ones there also. i found varying treatment of some hosts, which clearly had been either added or removed on only the more popular machines. i think i have guessed correctly as to which way the remote folks wanted to go; if there are any complaints about outslaughts or droughts of bboard trash, have it directed to me. we should remember to install such changes on all local ITSi. actually -we- probably do; it's the other folks around, who know some things about *msgs, who would appear to be the culprits.  Date: Sun, 3 Jul 88 07:03:05 EDT From: "Philip E. Agre" To: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <406823.880703.AGRE@AI.AI.MIT.EDU> I said :mail suchman.pa@xerox and got an error message MAIL error - Ambiguous site spec. "xerox"=>{XEROX.ARPA,XEROX.COM} Now, :HOST shows that those two names refer to the same machine. This reminds me a little of that famous episode on OZ where the programs DATE and DAYTIME ran the same code but DA wouldn't complete.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 22 Jun 88 15:05:04 EDT Received: from MCC.COM (TCP 1200600076) by MC.LCS.MIT.EDU 22 Jun 88 15:01:46 EDT Received: from BRAHMA.ACA.MCC.COM (BRAHMA.ACA.MCC.COM.#Chaos) by MCC.#Chaos with Chaos/SMTP; Wed 22 Jun 88 13:51:50-CDT Date: Wed, 22 Jun 88 13:51 CDT From: David Vinayak Wallace To: Chapman.pa@Xerox.COM cc: bug-mail@mc.lcs.mit.edu In-Reply-To: <19880621220324.2.ZVONA@SPIFF.parc.xerox.com> Message-ID: <880622135146.7.GUMBY@BRAHMA.ACA.MCC.COM> Date: Tue, 21 Jun 88 15:03 PDT From: Chapman.pa@Xerox.COM IWBNI the error message about the too-big message explained that it was written to BADREQ n, so the loser could recover it. In an older message to bug-mail I told you where to change the comsat sources. The piece of mail in question got sent yesterday or so. Does this mean that someone manually renamed BADREQ 1 to MAIL >? Yes, I did.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 21 Jun 88 19:28:05 EDT Received: from SRI-NIC.ARPA (TCP 1200000063) by MC.LCS.MIT.EDU 21 Jun 88 19:27:29 EDT Date: Tue, 21 Jun 88 16:26:20 PDT From: Ken Harrenstien Subject: Re: I put OLD-OZ and MX in MC's COMSATs' HFLUSH lists To: Alan@AI.AI.MIT.EDU, Moon@STONY-BROOK.SCRC.SYMBOLICS.COM cc: JTW@XX.LCS.MIT.EDU, SRA@mc.lcs.mit.edu, ZVONA@AI.AI.MIT.EDU, BUG-COMSAT@mc.lcs.mit.edu, bug-mail@mc.lcs.mit.edu, bug-digest@mc.lcs.mit.edu, KLH@SRI-NIC.ARPA In-Reply-To: <19880621200355.0.ALAN@PIGPEN.AI.MIT.EDU> Message-ID: <12408317967.36.KLH@SRI-NIC.ARPA> Hi. I just dipped into my local KLH-ITS mail file which has been accumulating stuff forwarded from AI/MC (I gave up trying to telnet-read mail at MIT long ago), and have a couple comments about the bulk mailing stuff. (1) Good idea. Even better idea if COMSAT could split its load up automatically and farm it out to subsidiary unqueuers. Hmmm, maybe a good thesis project... (2) Local mail delivery can be handled by locking. That is, when COMSAT attempts to write to a mail file, it should seize the lock and if it doesn't get it just waits until it's free -- normally this doesn't take much time, so it's probably fine just to wait rather than trying to do something else (which would be too hairy). I don't think locking is too hard to enforce. Local mail file writing is concentrated in just one or two places. Even if you can't figure out a simple way to do file locking (e.g. opening for append, but without actually writing anything), you can always just use a single global lock, perhaps in the LOCK file (you'll need to make a few changes to the way this file is referenced and used if you want all of the COMSATs to share it). Good luck. -------  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 21 Jun 88 18:05:41 EDT Received: from Xerox.COM (TCP 1500006350) by MC.LCS.MIT.EDU 21 Jun 88 18:05:24 EDT Received: from Semillon.ms by ArpaGateway.ms ; 21 JUN 88 15:04:33 PDT Date: Tue, 21 Jun 88 15:03 PDT From: Chapman.pa@Xerox.COM To: bug-mail@mc.lcs.mit.edu Message-ID: <19880621220324.2.ZVONA@SPIFF.parc.xerox.com> Line-fold: no 003218 InReq: 4 > 1; 003218 Note: Inreq file too big! Length=3+67 SPECS:{J:PAGAN}{PFTHMG}{CLAIMS-TO-BE:Paganism-REQUEST}{TL=4992.} 003218 Note: Error during parse of input request. 003218 Input-request error, msg sent: ID=<438320.880618@MC.LCS.MIT.EDU> EXP->MAIL-MAINTAINERS@1200600054::=((FILE [.MAIL.; FAILED STUFF])@1200600054),PAGANISM-REQUEST@1200600054::=((FILE [ZVONA;PAGAN REQUES])@1200600054) 003224 Local->MC.LCS.MIT.EDU 003224 TO->[ZVONA;PAGAN REQUES] 003225 TO->[.MAIL.; FAILED STUFF] 003226 Note: Renaming bad input file to BADREQ 1 IWBNI the error message about the too-big message explained that it was written to BADREQ n, so the loser could recover it. The piece of mail in question got sent yesterday or so. Does this mean that someone manually renamed BADREQ 1 to MAIL >? -------  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 21 Jun 88 16:13:42 EDT Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by MC.LCS.MIT.EDU 21 Jun 88 16:07:02 EDT Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 120878; Tue 21-Jun-88 16:04:00 EDT Date: Tue, 21 Jun 88 16:03 EDT From: Alan Bawden Subject: I put OLD-OZ and MX in MC's COMSATs' HFLUSH lists To: Moon@STONY-BROOK.SCRC.SYMBOLICS.COM cc: JTW@XX.LCS.MIT.EDU, SRA@MC.LCS.MIT.EDU, ZVONA@AI.AI.MIT.EDU, BUG-COMSAT@MC.LCS.MIT.EDU, bug-mail@MC.LCS.MIT.EDU, bug-digest@MC.LCS.MIT.EDU In-Reply-To: <19880621174539.2.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-ID: <19880621200355.0.ALAN@PIGPEN.AI.MIT.EDU> Date: Tue, 21 Jun 88 13:45 EDT From: David A. Moon I don't see why you don't just make the bulk mailer never, ever write a local file, and instead ... I didn't do it because I would have had to understand a fair amount more about COMSAT first. Everyone should please recall that I once swore that if I was ever forced to start learning about how COMSAT worked, I would simply terminate mail service on ITS instead. I've already bent that rule by doing what I have done, and I did spend several hours trying to produce a COMSAT that would not do local delivery, and I couldn't find a way to do it.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 21 Jun 88 13:48:50 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 20024224620) by MC.LCS.MIT.EDU 21 Jun 88 13:47:21 EDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 422745; Tue 21-Jun-88 13:45:51 EDT Date: Tue, 21 Jun 88 13:45 EDT From: David A. Moon Subject: I put OLD-OZ and MX in MC's COMSATs' HFLUSH lists To: Alan Bawden cc: JTW@XX.LCS.MIT.EDU, SRA@MC.LCS.MIT.EDU, ZVONA@AI.AI.MIT.EDU, BUG-COMSAT@MC.LCS.MIT.EDU, bug-mail@MC.LCS.MIT.EDU, bug-digest@MC.LCS.MIT.EDU In-Reply-To: <19880621021223.9.ALAN@PIGPEN.AI.MIT.EDU> Message-ID: <19880621174539.2.MOON@EUPHRATES.SCRC.Symbolics.COM> I don't see why you don't just make the bulk mailer never, ever write a local file, and instead send all such requests over to the other Comsat (through the network) and have it write the file. This would even include the AILIST archive file. Then there would have to be such fear of screwing things up when making a mailing list be distributed by the bulk mailer. I've only thought of two problems with this. One is the purely clerical problem of finding all the places in Comsat that know about delivery to the local host and turning them off for the bulk mailer, so the network will still be used. The other is to make sure that when mail is sent to the other Comsat for delivery to a local user's mailbox, the address transmitted is the user's name rather than the file name of the user's mailbox, to avoid the problem you mentioned that is caused by the two Comsats having different NAMES files. I think a good way to cope with this would be for the bulk mailer never to do any user-name-to-mailbox expansion through INQUIR, the tourist user directory database, etc. -- any address reaching that point would just be transmitted to the other Comsat. The only address expansion done by the bulk mailer would be done via its NAMES file, and the only kind of delivery done would be network delivery.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 20 Jun 88 22:16:00 EDT Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by MC.LCS.MIT.EDU 20 Jun 88 22:14:11 EDT Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 120714; Mon 20-Jun-88 22:12:28 EDT Date: Mon, 20 Jun 88 22:12 EDT From: Alan Bawden Subject: I put OLD-OZ and MX in MC's COMSATs' HFLUSH lists To: JTW@XX.LCS.MIT.EDU, SRA@MC.LCS.MIT.EDU cc: ZVONA@AI.AI.MIT.EDU, BUG-COMSAT@MC.LCS.MIT.EDU, bug-mail@MC.LCS.MIT.EDU, bug-digest@MC.LCS.MIT.EDU In-Reply-To: , The message of 19 Jun 88 17:33 EDT from JTW@XX.LCS.MIT.EDU, <438861.880619.ZVONA@MC.LCS.MIT.EDU>, The message of 19 Jun 88 22:25 EDT from ZVONA@MC.LCS.MIT.EDU, The message of 19 Jun 88 22:25 EDT from David Chapman, <433170.880608.SRA@MC.LCS.MIT.EDU>, <12404850562.46.SRA@XX.LCS.MIT.EDU> Message-ID: <19880621021223.9.ALAN@PIGPEN.AI.MIT.EDU> Date: Sun, 19 Jun 88 22:25 EDT From: David Chapman I see that COMSAT BULK is actually running. Would it in fact help with the too-big-mail problem? Should I be using it? Is it reliable? Well, just how big was the file that blew out? Clearly it can only help if your digest is still within -some- limit... I think the digestifier really should be keeping a limit on the size of the digest it is willing to create. If the day's inbox doesn't fit in a single digest, it should write the remainder of the inbox into a separate file (with second filename "BACKLOG"?) to appear at the beginning of the next day's digest. Any mailing list that consistently loses ground with this scheme does not deserve our support. Date: Wed, 8 Jun 88 13:45:15 EDT From: Rob Austein ... Alan, IWBNI ... (2) you sent BUG-COMSAT a short note explaining in English just what you ended up doing with all this .BULK. stuff and what the current proceedure is for launching COMSAT, etc. All I did was create a .BULK. directory that contains all the same files as .MAIL.. COMSAT decides a start-up time which directory to use based on its JNAME. If its JNAME is "VDNBRG", then it uses .BULK. (and sets it's JNAME to be "BULK"). If its JNAME is anything else, it uses .MAIL. (and sets its JNAME to be "IV"). There is a CHANNA;RAKASH VDNBRG to be certain that a bulk mailer gets started at ITS boot time. There is a DRAGON;HOURLY VDNBRG to be certain that the bulk mailer doesn't stay dead for more than an hour. Date: Wed 8 Jun 88 13:59:18-EDT From: Rob Austein So, how does anything ever get queued for the BULK mailer? As far as I can tell the only thing currently going there is AILIST. You just have to know to write a request into .BULK.;MAIL >. Currently the only program that knows how to do this is the AIList digestifier, which I believe is a special purpose program that runs on Lisp Machines. I did -not- do anything to prevent the bulk mailer from delivering mail into local mailboxes. If both COMSAT IV and COMSAT BULK try to deliver mail into the same local inbox, mail will be lost. Fortunately, this is not much of an issue, since there are no -users- who keep their inboxes on MC. (AIList makes -one- local delivery, into an archive file that the other COMSAT never touches.) Unfortunately, it is not quite as easy ask you might at first think to determine that mail delivered by the bulk mailer will not go to any local users. For example, suppose user FRED has an INQUIR entry that says to deliver his mail to MC. Then in MC:.MAIL.;NAMES > he says to forward his mail to framistat%octal!dingbat!bang!mit-eddie.arpa@uk.nrl.dialnet.symbolics.com (which is too long to fit in his INQUIR entry). Well, if FRED is on a mailing list expanded by COMSAT BULK, his INQUIR entry will cause the bulk mailer do decide that FRED is a local user, but since COMSAT BULK looks in .BULK.;NAMES > and not .MAIL.;NAMES >, it will not see his forwarding entry, and so will deliver mail to GUEST1;FRED MAIL! Currently, the safest way to move a mailing list to BULK delivery is to start by examining the expansion of the mailing list as performed by the regular COMSAT to be certain that you know -all- of the entries in the NAMES file that effect the mailing list. I'll bet the digest program has ".MAIL." wired into it somewhere, but that should be easy to fix so that mailing lists could choose the mailer that they want to use.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 19 Jun 88 17:36:22 EDT Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 19 Jun 88 17:33:57 EDT Date: Sun, 19 Jun 1988 17:33 EDT Message-ID: From: JTW@XX.LCS.MIT.EDU To: David Chapman cc: bug-mail@MC.LCS.MIT.EDU, bug-digest@MC.LCS.MIT.EDU In-reply-to: Msg of 19 Jun 1988 16:40-EDT from David Chapman The size that comsat can handle is limited dynamically by AvailMem - AllTheRestOfTheJunkInCore. There is a bug in the GC such that this number tends to shrink over time. If you find that you're losing and what you're trying to do isn't absurd, rebooting comsat will often help. Unfortunately I don't have a good feel for what absurd is these days, but I would hope that 100K would be possible. If things start getting this big, other people are going to have problems too, and you might consider sending out smaller digests more often.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 19 Jun 88 16:41:37 EDT Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 19 Jun 88 16:41:19 EDT Date: Sun, 19 Jun 88 16:40:44 EDT From: David Chapman To: BUG-mail@MC.LCS.MIT.EDU, BUG-digest@MC.LCS.MIT.EDU cc: DANA@AI.AI.MIT.EDU Message-ID: <400030.880619.ZVONA@AI.AI.MIT.EDU> Right, OK, so there was indeed enough volume on the (digested) paganism list that it went over COMSAT's threshold. This makes the automatic digestifier pretty useless. (Gumby, Dana, has this never happened for you?) Is there anything that can be done about this? The size message COMSAT can deal with is limited mostly by the size of the names database, right? That means that if this second-COMSAT hack were hacked, it would have a tiny NAMES database and so could send much bigger messages, right?  Date: Thu, 16 Jun 88 14:24:02 EDT From: Rob Austein Subject: Ancient message from Moon entitled "Two Comsat bugs" To: BUG-COMSAT@AI.AI.MIT.EDU Message-ID: <398708.880616.SRA@AI.AI.MIT.EDU> On Thursday, 11 September 1986, Dave Moon sent a message to Bug-COMSAT describing two bugs that were combining to cause COMSAT to repeatedly call up Lispms trying to deliver an SMTP send (actually, it was probably a SOML, which confuses the hell out of the Lispm) even after the Lispm had properly informed COMSAT that it didn't want the message. I just found a hardcopy of Moon's message and decided to look into this. I fixed the easier of the two bugs (SMTP delivery mode getting trashed in NSMINI). I also added a line to NETICP to clear the reply buffer when starting a new connection to kill the phantom reply code bug (now when TCP loses we'll barf in some new and interesting way). These changes are only in the source at the moment, I didn't build a new COMSAT. I didn't fix the harder of the two bugs, which is deep in the guts of SYSNET;NETSND. Moon's description: The second bug is that if [NSMINI] still gets an error the second time, NTMINI returns MR$PER in A to NTSN20, which jumps to NTSN80, which jumps to NTSN99, which restores A, losing the error code. Thus all errors [in a PR$MIN handler, ie, SMTP MAIL/SAML/SOML/SEND FROM: commands] get treated as temporary errors even if in fact they were really permenant errors. I will leave out the customary barfing noises about how gross the code in NETSND is by modern standards, and will assume that if we fix this at all it will be in the traditional COMSAT way of using a kludge instead of fixing the problem. I think we might be able to use the same technique at NTSN20 that the %QULOS feature does at NTSN12. The probem is that NETSND is not written with the idea that a single transaction might yield a hard error for all recipients of a message (ie, SMTP "xxxx FROM:" commands are retrofitted into NETSND). Perhaps it would work to add a couple of lines of code at NTSN20 that used a flag word (zeroed at the begining of NETSND) to record the first time that NTMINI fails so that we can loop through marking all recipients as bad in the same way as %QULOS does. We might even be able to give a halfway decent error message, since the rejection message (actually the second one where we tried a null return path) should still be in NTRBUF. Also note that NTSN20 is not the only place where NTMINI gets called, the incredibly hairy (and probably 99% unnecessary now) XCRP code calls it in half a dozen places. Presumably all of these should be fixed so that their error return jumps to the error handler for NTSN20. Comments? A second opinion would be nice....  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 8 Jun 88 13:45:07 EDT Date: Wed, 8 Jun 88 13:45:15 EDT From: Rob Austein Subject: I put OLD-OZ and MX in MC's COMSATs' HFLUSH lists To: BUG-COMSAT@MC.LCS.MIT.EDU Message-ID: <433170.880608.SRA@MC.LCS.MIT.EDU> I put the addresses for MX and for OLD-OZ (which no longer accepts incoming mail) into the HFLUSH list in MC: .BULK.; COMSAT LAUNCH and relaunched both MC COMSATs. Somebody might want to do this for AI. I probably should have included Multics.MIT.EDU's address too. I'd make these hosts permenant entries in the HFLUSH list (in the source code) except that I suppose somebody might reuse the addresses some day. Alan, IWBNI (1) you cleaned up all the old COMSAT binaries and (2) you sent BUG-COMSAT a short note explaining in English just what you ended up doing with all this .BULK. stuff and what the current proceedure is for launching COMSAT, etc.  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 31 May 88 13:46:07 EDT Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 115609; Tue 31-May-88 13:45:17 EDT Date: Tue, 31 May 88 13:45 EDT From: Alan Bawden Subject: MX support for COMSAT To: budd@bu-it.BU.EDU cc: bug-mail@AI.AI.MIT.EDU, tower@bu-it.bu.edu In-Reply-To: Message-ID: <19880531174527.2.ALAN@PIGPEN.AI.MIT.EDU> Date: Wed, 25 May 1988 2:27:32 EDT From: Phil Budne After years of turism on ITS I'd like to make a contribution. I'm an experienced MIDAS programmer, but only on "BOTS" and "Twenex" My first idea was adding HELP, VRFY and EXPN commands to the SMTP server (FTPS), perhaps via a MBX (mailbox) device that COMSAT could use as well. Then Len Tower suggested MX support for COMSAT. I've been looking at COMSAT/DQDEV/RESOLV/NETRTS from AI:SYSNET; HELP, VRFY and EXPN would be nice, but I expect that a MBX: device is the wrong way to go. Something like what 20X does, where you run a subfork ("inferior job" in ITS parlance) that does the work for you is probably more like the right thing. MX support will happen when there is a working resolver, and there is already a bunch of us working on various aspects of that. I don't immediately see any pieces of that that we could break off for you, although I certainly would like to spread the load out a bit. I always do like to get new people involved in this, there are too few of us as it is. Certainly hacking a JOBDEV is one of the more intersting part of programming for ITS, but I can imagine it could be a pain to debug. And COMSAT is a bad program to break. All these statements are true. Please tell me what you think, or the reasons this is all unimaginably difficult, and hasn't been done before! Well, there are many issues surrounding MX support that aren't immediately obvious. The hardest issue is managing mail addressed to hosts whose names you have not found MX records for -yet-. COMSAT currently assumes that any hostname can either be immediately converted into a number, or it must be illegal. That assumption is falsified by the domain system. This introduces a whole new phase into the mail delivery process, and changes the data structures involved. A mailing list expander that ran as an inferior job is a much more straightforward task, I expect, although I haven't given it a great deal of thought. If you are really serious about doing -something-, you should probably "warm up" by writing some more trivial utility program that runs under ITS, just to familiarize yourself with the system calls, interrupt system, etc. I'll be happy to critique your code.  Received: from bu-it.BU.EDU (TCP 20061201050) by AI.AI.MIT.EDU 25 May 88 02:31:17 EDT Received: from BUIT2.BU.EDU by bu-it.BU.EDU (5.58/4.7) id AA18977; Wed, 25 May 88 02:28:06 EDT Return-Path: Received: by buit2 (5.58/4.7) id AA22810; Wed, 25 May 88 02:27:43 EDT Date: Wed, 25 May 1988 2:27:32 EDT From: Phil Budne Cc: budd@bu-it.bu.edu, tower@bu-it.bu.edu Subject: MX support for COMSAT To: bug-mail@ai.ai.mit.edu Message-Id: After years of turism on ITS I'd like to make a contribution. I'm an experienced MIDAS programmer, but only on "BOTS" and "Twenex" My first idea was adding HELP, VRFY and EXPN commands to the SMTP server (FTPS), perhaps via a MBX (mailbox) device that COMSAT could use as well. Then Len Tower suggested MX support for COMSAT. I've been looking at COMSAT/DQDEV/RESOLV/NETRTS from AI:SYSNET; Certainly hacking a JOBDEV is one of the more intersting part of programming for ITS, but I can imagine it could be a pain to debug. And COMSAT is a bad program to break. Please tell me what you think, or the reasons this is all unimaginably difficult, and hasn't been done before! -Phil  Date: Tue, 17 May 88 03:20:04 EDT From: "Pandora B. Berman" Subject: sca list To: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <379351.880517.CENT@AI.AI.MIT.EDU> Date: Mon, 16 May 88 23:21:23 PDT From: groff%epee.DEC@decwrl.dec.com (What is that light at the end of the tunnel?) To: cent@ai.ai.mit.edu, GROFF@decwrl.dec.com Subject: mc and sca Well Dave ask me to hold off moving to MC... and to a digest form (I was planning on polling people first)... --PLEASE forward my apologies to the users experiencing problems due to SCA usage of AI.. I will try to move it as soon as possible... just to let folks know, this is being worked on; zvona (and to some degree i) are giving dana a hand with figuring out the best way to cut down SCA's load on COMSAT.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 17 May 88 02:26:48 EDT Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 17 May 88 00:18:35 EDT Date: Tue 17 May 88 00:12:55-EDT From: Rob Austein Subject: Re: serious bug: COMSAT is sending error reports to the wrong address To: fair@ucbarpa.Berkeley.EDU, Postmaster@OZ.AI.MIT.EDU cc: bug-comsat@MC.LCS.MIT.EDU In-Reply-To: <8805170117.AA24815@ucbarpa.Berkeley.EDU> Message-ID: <12398932954.55.SRA@XX.LCS.MIT.EDU> From: fair@ucbarpa.Berkeley.EDU (Erik E. Fair) Subject: serious bug: COMSAT is sending error reports to the wrong address To: bug-comsat@mc.lcs.mit.edu Date: Mon, 16 May 88 18:17:52 PDT Path: ucbvax!MC.LCS.MIT.EDU!COMSAT From: COMSAT@MC.LCS.MIT.EDU (Communications Satellite) Newsgroups: junk Subject: Msg of Saturday, 14 May 1988 03:35-EDT Message-ID: <420438.880514@MC.LCS.MIT.EDU> Date: 14 May 88 07:36:20 GMT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The Internet Lines: 443 FAILED: TETHER at MITLNS.MIT.EDU; Funny reply from foreign host after sending message. Last reply was: {554 Unable to deliver mail to given recipient(s)} Failed message follows: ------- Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 14 MAY 88 03:34:04 EDT Received: from XX.LCS.MIT.EDU by OZ.AI.MIT.EDU with Chaos/SMTP; Sat 14 May 88 03:31:58-EDT Received: from Score.Stanford.EDU by XX.LCS.MIT.EDU with TCP/SMTP; Sat 14 May 88 03:30:21-EDT Date: Fri 13 May 88 22:37:33 PDT Subject: Info-Atari16 Digest V88 #249 From: Info-Atari16 Digest Sender: Info-Atari16-request@Score.Stanford.EDU Errors-to: Info-Atari16-request@Score.Stanford.EDU Maint-Path: Info-Atari16-request@Score.Stanford.EDU To: Info-Atari16 Distribution List: ; Reply-to: Info-Atari16@Score.Stanford.edu Info-Atari16 Digest Friday, May 13, 1988 Volume 88 : Issue 249 [body deleted in the name of brevity -eef] I got this message from info-atari16@score.stanford.edu. I should never have seen it. The reason I saw it is that COMSAT sent this to the address plucked from either the "From" or "Reply-To" fields of the above header. This is wrong. RFC821 and RFC822 both say that errors should go to the Return-Path (which is passed in the SMTP MAIL FROM: command during an SMTP transaction), and failing that, to the address in the "Sender:" field. You should resort to the "From:" field only when the previous two possibilities have been exhausted. Please fix this bug. Erik E. Fair ucbvax!fair fair@ucbarpa.berkeley.edu Right analysis, wrong culprit. This is OZ lossage. COMSAT preserves SMTP return paths just fine, but when a message goes through OZ the return-path gets lost because OZ uses the obsolete Chaos/MAIL protocol for all outgoing mail. The likelyhood of this getting fixed is, um, pretty low. -------  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 16 MAY 88 21:22:46 EDT Received: from ucbarpa.Berkeley.EDU (TCP 1200000116) by MC.LCS.MIT.EDU 16 May 88 21:20:05 EDT Received: by ucbarpa.Berkeley.EDU (5.59/1.28) id AA24815; Mon, 16 May 88 18:17:55 PDT From: fair@ucbarpa.Berkeley.EDU (Erik E. Fair) Message-Id: <8805170117.AA24815@ucbarpa.Berkeley.EDU> Subject: serious bug: COMSAT is sending error reports to the wrong address To: bug-comsat@mc.lcs.mit.edu Date: Mon, 16 May 88 18:17:52 PDT Path: ucbvax!MC.LCS.MIT.EDU!COMSAT From: COMSAT@MC.LCS.MIT.EDU (Communications Satellite) Newsgroups: junk Subject: Msg of Saturday, 14 May 1988 03:35-EDT Message-ID: <420438.880514@MC.LCS.MIT.EDU> Date: 14 May 88 07:36:20 GMT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The Internet Lines: 443 FAILED: TETHER at MITLNS.MIT.EDU; Funny reply from foreign host after sending message. Last reply was: {554 Unable to deliver mail to given recipient(s)} Failed message follows: ------- Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 14 MAY 88 03:34:04 EDT Received: from XX.LCS.MIT.EDU by OZ.AI.MIT.EDU with Chaos/SMTP; Sat 14 May 88 03:31:58-EDT Received: from Score.Stanford.EDU by XX.LCS.MIT.EDU with TCP/SMTP; Sat 14 May 88 03:30:21-EDT Date: Fri 13 May 88 22:37:33 PDT Subject: Info-Atari16 Digest V88 #249 From: Info-Atari16 Digest Sender: Info-Atari16-request@Score.Stanford.EDU Errors-to: Info-Atari16-request@Score.Stanford.EDU Maint-Path: Info-Atari16-request@Score.Stanford.EDU To: Info-Atari16 Distribution List: ; Reply-to: Info-Atari16@Score.Stanford.edu Info-Atari16 Digest Friday, May 13, 1988 Volume 88 : Issue 249 [body deleted in the name of brevity -eef] I got this message from info-atari16@score.stanford.edu. I should never have seen it. The reason I saw it is that COMSAT sent this to the address plucked from either the "From" or "Reply-To" fields of the above header. This is wrong. RFC821 and RFC822 both say that errors should go to the Return-Path (which is passed in the SMTP MAIL FROM: command during an SMTP transaction), and failing that, to the address in the "Sender:" field. You should resort to the "From:" field only when the previous two possibilities have been exhausted. Please fix this bug. Erik E. Fair ucbvax!fair fair@ucbarpa.berkeley.edu  Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 20024224620) by AI.AI.MIT.EDU 16 May 88 11:52:16 EDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 405069; Mon 16-May-88 11:48:28 EDT Date: Mon, 16 May 88 11:48 EDT From: David A. Moon Subject: that period-appending bug To: David Chapman cc: BUG-MAIL@AI.AI.MIT.EDU In-Reply-To: <378258.880515.ZVONA@AI.AI.MIT.EDU> Message-ID: <19880516154814.5.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Sun, 15 May 88 14:31:43 EDT From: David Chapman I sent a message to paganism@mc, zvona (from AI). The copy I got locally had one period at the end. The copy that went into the paganism inbox had two periods. I'm mystified, but this makes it quite clear that it's a real phenomenon.. Period-doubling is a well-known form of chaotic behavior.  Date: Sun, 15 May 88 19:01:31 EDT From: Alan Bawden Subject: Bad state,4?!?!? To: BUG-COMSAT@AI.AI.MIT.EDU Message-ID: <378373.880515.ALAN@AI.AI.MIT.EDU> Ever wonder what (TCP-SMTP=Bad state,4) means when it appears in the STATS file? Well, I got tired of not knowing and I looked at the source. It means precisely the same thing as (TCP-SMTP=Timeout) There was no "bad state" at all. Details in the source which I edited to keep this from happening in the future. (But I didn't assemble the fix because the problem is harmless, it just make the STATS file look silly.) I suppose I must be about to figure out what this IOC error crap is all about...  Date: Sun, 15 May 88 14:31:43 EDT From: David Chapman Subject: that period-appending bug To: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <378258.880515.ZVONA@AI.AI.MIT.EDU> I sent a message to paganism@mc, zvona (from AI). The copy I got locally had one period at the end. The copy that went into the paganism inbox had two periods. I'm mystified, but this makes it quite clear that it's a real phenomenon.  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 13 May 88 04:07:20 EDT Received: from EMACK-AND-BOLIOS.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 13 May 88 04:01-EDT Date: Fri, 13 May 88 04:03 EDT From: David Vinayak Wallace Subject: Comsat not wedged at all To: Leonard N. Foner cc: Bug-Mail@AI.AI.MIT.EDU In-Reply-To: Message-ID: <880513040311.2.GUMBY@EMACK-AND-BOLIOS.LCS.MIT.EDU> Date: 13 May 1988 02:54 EDT (Fri) From: "Leonard N. Foner" I found MC's COMSAT wedged. A new NAMES file had been written yesterday, but COMSAT had not written a NAMED file. The STATS file was 200 blocks long. A test message on MC to FONER@MC did not arrive at OZ, and there were about 30 queued messages. Comsat wasn't wedged. Your test messages didn't get through because they were waiting for comsat to get through all the other mail. On SRA's advice, I gunned it and relaunched it, but I don't think I launched it correctly. I did: :LOAD .MAIL.;COMSAT LAUNCH :START and it halted immediately with a message about DEATHV. Gunning it is fine if the stats file gets huge, though personally I don't see what's so incredibly terrible about that happening. Use :mail to restart it. However, two COMSAT jobs appeared (the IV job and the JOB.07 job) and gobbled 70% of the machine between them for a few minutes. It wrote out a new NAMED file, opened a new STATS file, and is now using about 3% of the machine. None of the queued mail has disappeared. It can't deliver all the mail immediately, you know. It appears to have been busy delivering a large digest to about 200 people. COMSAT (or any program) ISN'T going to use a lot of resources doing all those .HANGs. The queue (at least the MAIL files) should disappear by morning. Compounding the problem is that several hosts send a message per recipient, which makes .mail. fill more quickly and requires that comsat parse more request files. If you look at the old stats files, comsat becomes extremely busy between midnight and about 7AM. C'est la vie.  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 13 May 88 04:01:59 EDT Date: Fri 13 May 88 03:57:48-EDT From: Rob Austein Subject: Re: More on MC's COMSAT To: FONER%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU cc: Bug-Mail@AI.AI.MIT.EDU In-Reply-To: Message-ID: <12397925316.52.SRA@XX.LCS.MIT.EDU> Gumby and I both concluded that you not in fact do anything wrong, you were probably confused by how long it takes COMSAT to deliver mail to a lot of the lists it serves these days. You might want to investigate the C command in the job-oriented displays in PEEK if you're going to be volunteering yourself as a COMSAT cleaner-upper. -------  Received: from OZ.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 13 MAY 88 03:17:41 EDT Date: 13 May 1988 03:15 EDT (Fri) Message-ID: From: "Leonard N. Foner" To: Bug-Mail@AI.AI.MIT.EDU Subject: More on MC's COMSAT cc: Foner%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU Well, I gunned it again and started it with :MAIL. MAIL claimed that COMSAT was back in orbit, but it still doesn't seem to be flushing its queue. I don't recall how to read its (locked) STATS file. PEEK shows sporadic TCP connections coming up & down, but I can't tell if COMSAT is initiating them or if they're responses to pokes from elsewhere. Since I don't have a clue, I'm going to sleep. If I've screwed up, I assume somebody will set me right. If somebody figures out what's going on with COMSAT these days, I'm interested.  Received: from OZ.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 13 MAY 88 02:59:54 EDT Date: 13 May 1988 02:54 EDT (Fri) Message-ID: From: "Leonard N. Foner" To: Bug-Mail@AI.AI.MIT.EDU Subject: MC COMSAT wedged; restart doubtful cc: Foner%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU I found MC's COMSAT wedged. A new NAMES file had been written yesterday, but COMSAT had not written a NAMED file. The STATS file was 200 blocks long. A test message on MC to FONER@MC did not arrive at OZ, and there were about 30 queued messages. On SRA's advice, I gunned it and relaunched it, but I don't think I launched it correctly. I did: :LOAD .MAIL.;COMSAT LAUNCH :START and it halted immediately with a message about DEATHV. However, two COMSAT jobs appeared (the IV job and the JOB.07 job) and gobbled 70% of the machine between them for a few minutes. It wrote out a new NAMED file, opened a new STATS file, and is now using about 3% of the machine. None of the queued mail has disappeared. What did I do wrong?  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 12 May 88 07:48:15 EDT Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 12 May 88 07:32:21 EDT Posted-From: The MITRE Corp., Bedford, MA Received: from darwin.sun.uucp by linus.MENET (3.2/4.7) id AA27322; Thu, 12 May 88 07:29:07 EDT From: John D. Ramsdell Posted-Date: Thu, 12 May 88 07:26:33 EDT Received: by darwin.sun.uucp (3.2/SMI-3.0DEV3) id AA13300; Thu, 12 May 88 07:26:33 EDT Date: Thu, 12 May 88 07:26:33 EDT Message-Id: <8805121126.AA13300@darwin.sun.uucp> To: SCHREQ@MC.LCS.MIT.EDU Cc: BUG-MAIL@MC.LCS.MIT.EDU, guru@mitre-bedford.ARPA In-Reply-To: Scheme Requestee's message of Wed, 11 May 88 16:20:53 EDT <418737.880511.SCHREQ@MC.LCS.MIT.EDU> Subject: To: ramsdell%linus@mitre-bedford.ARPA The address you wrote: ramsdell%linus@mitre-bedford.ARPA is correct. There is an ARPAnet site at U Maryland which is called LINUS, but our mailer at mitre-bedford.arpa is supposed to send linus mail to this machine. I have had no other indications that mitre-bedford does anything different, so COMSAT problem is likely. If you prefer using another address, use ramsdell%mdf@mitre-bedford.ARPA MDF is MITRE's attempt at making mail names correspond to people's names, not their account names. It is extra indirection, so the linus address is preferable. --------------------------------- Posted-Date: Wed, 11 May 88 16:20:53 EDT Date: Wed, 11 May 88 16:20:53 EDT From: Scheme Requestee Subject: To: ramsdell%linus@mitre-bedford.ARPA To: BUG-MAIL@MC.LCS.MIT.EDU Cc: ramsdell@mbunix Am I missing something obvious, or doing something wrong, or is there a bug somewhere? I'm trying to send a message to ramsdell%linus@mitre-bedford.ARPA but COMSAT is instead trying to send it to ramsdell@LINUS.UMD.EDU Is this somehow related to the problem we were having last year with SUSHI.STANFORD.EDU? Should I use double quotes or what? If so why? Please advise. - Jonathan  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 12 May 88 05:29:23 EDT Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 12 May 88 05:28:04 EDT Date: Thu 12 May 88 05:25:02-EDT From: Rob Austein Subject: Re: To: ramsdell%linus@mitre-bedford.ARPA To: SCHREQ@MC.LCS.MIT.EDU cc: BUG-MAIL@MC.LCS.MIT.EDU, ramsdell%linus@MITRE-BEDFORD.ARPA In-Reply-To: <418737.880511.SCHREQ@MC.LCS.MIT.EDU> Message-ID: <12397679053.64.SRA@XX.LCS.MIT.EDU> Date: Wed, 11 May 88 16:20:53 EDT From: Scheme Requestee Subject: To: ramsdell%linus@mitre-bedford.ARPA To: BUG-MAIL@MC.LCS.MIT.EDU cc: linus!ramsdell@MITRE-BEDFORD.ARPA Message-ID: <418737.880511.SCHREQ@MC.LCS.MIT.EDU> Am I missing something obvious, or doing something wrong, or is there a bug somewhere? I'm trying to send a message to ramsdell%linus@mitre-bedford.ARPA but COMSAT is instead trying to send it to ramsdell@LINUS.UMD.EDU Back in the days when people were apes and there were 50 hosts on the ARPANET, this was a feature. Here in the future it's a bug. This is of course the "feature" where COMSAT realizes that you've "needlessly" specified a path that goes to a machine it knows about via another machine it knows about, so it helpfully saves you the extra hop. This is the first time I've seen this particular varient (I guess "LINUS" must be completely unambiguous in the NIC host table) but it was bound to happen eventually. Is this somehow related to the problem we were having last year with SUSHI.STANFORD.EDU? Should I use double quotes or what? If so why? The only bug I remember with SUSHI was not related to this (that was the domain resolver problem on the Stanford end, right?). Double quotes might be of some help, basicly you need to find a form where COMSAT absolutely, positively, does not recognize LINUS as a hostname. IWBNI somebody had the ambition to remove this misfeature once and for all. -------  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 12 May 88 04:05:23 EDT Date: Wed, 11 May 88 16:23:09 EDT From: Alan Bawden Subject: And you thought PDUMP finally worked. To: BUG-COMSAT@MC.LCS.MIT.EDU, BUG-ITS@MC.LCS.MIT.EDU cc: ZVONA@MC.LCS.MIT.EDU Message-ID: <418741.880511.ALAN@MC.LCS.MIT.EDU> Note the -times- in the following consecutive entries from the mailer STATS file on MC. 084735 Note: GC'ing MSGS, 5646555-1620312=4026243 145143 ===> BUG: FATAL ERROR <=== Date: 05/11/88 14:51:42 Autopsy from 22770 Preserved from 22061 Last UUO = 017100,,062447 at 52657 MC was low on disk space at the time, which is probably what caused the original error, but what do you suppose was happening during the 6 hour pause? I'll guess that there is a bug in the PDUMP system call (probably also having to do with low disk space) that kept COMSAT hung until Zvona logged in and noticed the problem. Probably something he did to try and diagnose the problem PCLSR'd the call, and then it finished.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 12 May 88 04:05:13 EDT Date: Wed, 11 May 88 16:20:53 EDT From: Scheme Requestee Subject: To: ramsdell%linus@mitre-bedford.ARPA To: BUG-MAIL@MC.LCS.MIT.EDU cc: linus!ramsdell@MITRE-BEDFORD.ARPA Message-ID: <418737.880511.SCHREQ@MC.LCS.MIT.EDU> Am I missing something obvious, or doing something wrong, or is there a bug somewhere? I'm trying to send a message to ramsdell%linus@mitre-bedford.ARPA but COMSAT is instead trying to send it to ramsdell@LINUS.UMD.EDU Is this somehow related to the problem we were having last year with SUSHI.STANFORD.EDU? Should I use double quotes or what? If so why? Please advise. - Jonathan Date: Fri, 6 May 88 16:09:45 EDT From: Communications Satellite To: SCHREQ@MC.LCS.MIT.EDU Re: Msg of Friday, 6 May 1988 16:09-EDT FAILED: ramsdell at LINUS.UMD.EDU; Recipient name apparently rejected. Last reply was: {550 ... User unknown} Failed message follows: ------- Date: Fri, 6 May 88 16:09:33 EDT From: Scheme Requestee Subject: [COMSAT: Msg of Thursday, 5 May 1988 21:52-EDT] To: ramsdell@LINUS.UMD.EDU cc: SCHREQ@MC.LCS.MIT.EDU Message-ID: <416204.880506.SCHREQ@MC.LCS.MIT.EDU> Let me try this once again before mailing to BUG-MAIL. The "To:" line of this message is: To: John D. Ramsdell ---------- Date: Thu, 5 May 88 21:52:59 EDT From: Communications Satellite Subject: Msg of Thursday, 5 May 1988 21:52-EDT To: SCHREQ@MC.LCS.MIT.EDU Message-ID: <415723.880505@MC.LCS.MIT.EDU> FAILED: ramsdell at LINUS.UMD.EDU; Recipient name apparently rejected. Last reply was: {550 ... User unknown} Failed message follows: ------- Date: Thu, 5 May 88 21:52:49 EDT From: Scheme Requestee Subject: [COMSAT: Msg of Tuesday, 26 April 1988 17:34-EDT] To: ramsdell@LINUS.UMD.EDU Message-ID: <415722.880505.SCHREQ@MC.LCS.MIT.EDU> I can't imagine how this happened; I'll ignore it for now and wait until I see it again to worry about it. - Jonathan Date: Tue, 26 Apr 88 18:12:10 EDT From: Communications Satellite To: SCHREQ@MC.LCS.MIT.EDU Re: Msg of Tuesday, 26 April 1988 17:34-EDT FAILED: ramsdell at LINUS.UMD.EDU; Recipient name apparently rejected. Last reply was: {550 ... User unknown} Failed message follows: ------- Date: Tue, 26 Apr 88 17:34:50 EDT From: Scheme Requestee Subject: Cross mailing between UseNet and the ArpaNet To: ramsdell@LINUS.UMD.EDU cc: SCHEME@MC.LCS.MIT.EDU In-reply-to: Msg of Mon 18 Apr 88 07:12:28 EDT from John D. Ramsdell Message-ID: <411485.880426.SCHREQ@MC.LCS.MIT.EDU> Date: Mon, 18 Apr 88 07:12:28 EDT From: John D. Ramsdell Did you get the UseNet to ArpaNet connection working? If so, please tell the rest of us so we know if we no longer need to send our contributions to MIT. It is my understanding that mail is forwarded in both directions, without danger of divergence. Submissions to comp.lang.scheme will go to scheme@mc, and vice versa. I believe we have Eric Fair at Berkeley to thank for this somewhat miraculous achievement.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 7 May 88 17:46:27 EDT Date: Sat, 7 May 88 17:45:51 EDT From: Rob Austein Subject: MC COMSAT hung for most of the day To: BUG-COMSAT@MC.LCS.MIT.EDU Message-ID: <416628.880507.SRA@MC.LCS.MIT.EDU> I found MC's COMSAT crashed and burned, apparently ran out of space in .MAIL. while GC'ing. DRAGON hadn't been able to start a new one either. I flushed two zillion unnecessary old NAMES and NAMED files, the _SATEL OUTPUT file COMSAT had been writing, and rebooted COMSAT. It immediately GC'd from ~1400 blocks in LISTS MSGS down to ~700 blocks. I wouldn't have noticed this except that I was doing some Postmaster things and got a "directory full" error when trying to send a message via BABYL. Perhaps the magic PUFF routine that complains about TCP lossage should also check for .MAIL.; full somehow? Also, perhaps I should teach DRAGON;HOURLY GCMAIL to flush old NAMES and NAMED files like it does OSTATS?  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 29 Apr 88 16:23:47 EDT Date: Fri 29 Apr 88 16:14:40-EDT From: Rob Austein Subject: Re: size limits To: BUG-MAIL@AI.AI.MIT.EDU In-Reply-To: <367917.880429.GUMBY@AI.AI.MIT.EDU> Message-ID: <12394389444.68.SRA@XX.LCS.MIT.EDU> No, because we really do also want it to go idle every now and then regardless of how big the messages it handles are. Too much cruft that never happens right because it never goes idle. -------  Date: Fri, 29 Apr 88 15:03:53 EDT From: David Vinayak Wallace Subject: size limits To: Moon@SCRC-STONY-BROOK.ARPA cc: BUG-MAIL@AI.AI.MIT.EDU In-reply-to: Msg of Fri 29 Apr 88 13:01 EDT from David A. Moon Message-ID: <367917.880429.GUMBY@AI.AI.MIT.EDU> Do it on demand. If a message is too big to read, but is smaller than some "reasonable" limit, it could force itself to "go idle." The problem with this is that it could cause an infinite loop if it really DID run out of room.  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 29 Apr 88 13:51:27 EDT Date: Fri 29 Apr 88 13:41:17-EDT From: Rob Austein Subject: Re: size limits To: Moon@STONY-BROOK.SCRC.Symbolics.COM cc: Bug-Mail@AI.AI.MIT.EDU In-Reply-To: <19880429170141.1.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-ID: <12394361520.55.SRA@XX.LCS.MIT.EDU> Would it make sense to put in a kludge that forces it to go idle once every two hours even if it has not caught up to the mail backlog? It'd make a lot of sense if anybody can figure out how to do it. It'd also fix the problem where the STATS file gets to be hundreds of blocks long because COMSAT never gets to the part of the code that renames it and starts a new one. -------  Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 20024224620) by AI.AI.MIT.EDU 29 Apr 88 13:10:44 EDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 394878; Fri 29-Apr-88 13:02:08 EDT Date: Fri, 29 Apr 88 13:01 EDT From: David A. Moon Subject: Re: size limits To: Bug-Mail@AI.AI.MIT.EDU In-Reply-To: <12394253210.14.SRA@XX.LCS.MIT.EDU> Message-ID: <19880429170141.1.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Fri 29 Apr 88 03:46:19-EDT From: Rob Austein It'd help a lot if it just flushed all the dead @FILE stuff it's not using anymore when it starts running low on space. My understanding, which may be deficient, is that Comsat does flush that stuff whenever it goes idle, because it purges EQVAR out of its memory. It used to go idle every few minutes. The problem is now that Comsat is so overloaded on AI and MC, it can go for days and days without ever going idle. Would it make sense to put in a kludge that forces it to go idle once every two hours even if it has not caught up to the mail backlog?  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 29 Apr 88 04:03:59 EDT Date: Fri 29 Apr 88 03:46:19-EDT From: Rob Austein Subject: Re: size limits To: JAR@AI.AI.MIT.EDU cc: bug-mail@AI.AI.MIT.EDU Reply-To: Bug-Mail@AI.AI.MIT.EDU In-Reply-To: <367092.880428.JAR@AI.AI.MIT.EDU> Message-ID: <12394253210.14.SRA@XX.LCS.MIT.EDU> Date: Thu, 28 Apr 88 12:09:15 EDT From: Jonathan A Rees From: Rob Austein To: JAR at MC.LCS.MIT.EDU I moved a huge BADREQ file off of MC:.MAIL.; into AI:JAR;. Your friend is confused about what's reasonable to send via mail. Thanks. How do I find out the size limit, so he can break it up? We have no other alternative for file transfer besides US-mailing tapes, which is a pain. You should have sent this to BUG-MAIL and you know it. Fooey. You're not going to like this.... You're really not going to like this.... Ok, so the size limit is determined on the fly by how much address space COMSAT has left over after it's done mapping LSR1 and LIST EQV and however many @FILEs it may have seen since it was last rebooted. The big change between COMSAT III and COMSAT IV was that COMSAT III also kept the entire of HOSTS3 in its address space. Even without that it's pretty clear that we're pushing COMSAT far beyond what it was originally intended to cope with. If a COMSAT has been running for a while, the limit may well be down to a few blocks (1 block == 5Kbyte). I told you you weren't going to like it. Feel free to fix COMSAT. It'd help a lot if it just flushed all the dead @FILE stuff it's not using anymore when it starts running low on space. --Rob -------  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 14 Apr 88 23:58:58 EDT Date: Thu 14 Apr 88 23:46:13-EDT From: Rob Austein Subject: Re: Mail transport problem To: jspear@[26.20.0.47], JSPEAR@AI.AI.MIT.EDU cc: BUG-MAIL@AI.AI.MIT.EDU, Hostmaster@SRI-NIC.ARPA In-Reply-To: <359982.880414.JSPEAR@AI.AI.MIT.EDU> Message-ID: <12390539484.31.SRA@XX.LCS.MIT.EDU> Date: Thu, 14 Apr 88 23:31:29 EDT From: "Jon L. Spear" Subject: Mail transport problem To: BUG-MAIL@AI.AI.MIT.EDU Symptom: I am unable to send mail from AI to myself on the machine I spend most time on (jspear@afit-ab.arpa). After a few days I get a comsat message back Host appears to be permanently down or not accepting mail. Additional info: On telneting to AI from AFIT.AB-ARPA, :f shows that I am coming from Net site 26.20.0.47. If I lookup AFIT-AB.ARPA at the NIC, it says our real name is AFITNET.ARPA and that AFIT-AB is a nicname. It shows our address as: 26.14.0.47 (MILNET, host 14, IMP 47) [3203,,400057] 129.92.1.2 (AFIT) [20127,,402] but that the machine is not a VAX 11/785 but a CISCO-AGS running UNIX. My guess is that the CISCO must be the DDN gateway machine they said they were going to install. If, from AFIT-AB.ARPA I try to telnet to itself, it waits for a while and reports that: connect to address 26.14.0.47: Connection timed out Trying 129.92.1.2... Connected to AFITNET.ARPA. and I get the usual login prompt. Sounds like the NIC table info is out of date. Talk to HOSTMASTER@SRI-NIC.ARPA about this. You'll need your local host administrator to back you up, and there may be some red tape involved since the bad address on the MILNET proper rather than your local wire; changing addresses on the ARPANET proper requires DCA approval, I don't know how it works on the other side of the Great Divide. Observation: While the NIC info appears suspect, I can still get mail from some other non-MILNET sites, so it seems possible that there is also a problem with MIT's mailer (at MC?) in that it doesn't try a secondary address if one exists. Or maybe I am even more confused than I know. You're not the first person to say it, although you're politer than some. (a) It's harder than it looks to try the alternate addresess, and (b) it is something of a religious question as to whether or not it's a good idea to try alternate addresses unless you can do it exactly the right way, which may not be possible in some mailers. For most mailers (including COMSAT) it would take a major rewrite that, at least in COMSAT's case, is unlikely to happen. --Rob (for Postmaster & Bug-MAIL @AI.AI.MIT.EDU) -------  Date: Thu, 14 Apr 88 23:31:29 EDT From: "Jon L. Spear" Subject: Mail transport problem To: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <359982.880414.JSPEAR@AI.AI.MIT.EDU> I be cornfused, but maybe someone could help me (and likely my host administrator) clear up a simple problem. Symtom: I am unable to send mail from AI to myself on the machine I spend most time on (jspear@afit-ab.arpa). After a few days I get a comsat message back Host appears to be permanently down or not acxcepting mail. Additional info: On telneting to AI from AFIT.AB-ARPA, :f shows that I am coming from Net site 26.20.0.47. If I lookup AFIT-AB.ARPA at the NIC, it says our real name is AFITNET.ARPA and that AFIT-AB is a nicname. It shows our address as: 26.14.0.47 (MILNET, host 14, IMP 47) [3203,,400057] 129.92.1.2 (AFIT) [20127,,402] but that the machine is not a VAX 11/785 but a CISCO-AGS running UNIX. My guess is that the CISCO must be the DDN gateway machine they said they were going to install. If, from AFIT-AB.ARPA I try to telnet to itself, it waits for a while and reports that: connect to address 26.14.0.47: Connection timed out Trying 129.92.1.2... Connected to AFITNET.ARPA. and I get the usual login prompt. Observation: While the NIC info appears suspect, I can still get mail from some other non-MILNET sites, so it seems possible that there is also a problem with MIT's mailer (at MC?) in that it doesn't try a secondary address if one exists. Or maybe I am even more confused than I know. Any suggestions would be welcome. Thanks, Jon P.S. Sorry about the typos. EMACS over telnet is very painfully slow so I didn't have an editor.  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 29 Mar 88 00:21:21 EST Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 101769; Tue 29-Mar-88 00:18:01 EST Date: Tue, 29 Mar 88 00:18 EST From: Alan Bawden Subject: Help me Mr. Mailer To: SRA@XX.LCS.MIT.EDU cc: Bug-COMSAT@AI.AI.MIT.EDU In-Reply-To: Message-ID: <880329001821.8.ALAN@PIGPEN.AI.MIT.EDU> Date: Mon, 28 Mar 1988 18:39 EST From: Rob Austein Dear Distraught, If you patch LL.ARPA's address into the HFLUSH table... -- Mr. Mailer Thank you, Mr. Mailer, I knew I could count on your advice. It worked like a charm.  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 28 Mar 88 18:43:35 EST Date: Mon, 28 Mar 1988 18:39 EST Message-ID: From: Rob Austein To: Alan Bawden Cc: Bug-COMSAT@AI.AI.MIT.EDU Subject: Help me Mr. Mailer In-reply-to: Msg of 28 Mar 1988 17:01-EST from Alan Bawden Date: Monday, 28 March 1988 17:01-EST From: Alan Bawden To: Bug-COMSAT@AI.AI.MIT.EDU Re: Help me Mr. Mailer On AI there are 384 messages queued for LL.ARPA, some of them have been in the queue since January. A SHOW-Q says that the failure count for that host is "1". LISTS MSGS is over 1000 blocks long. Can someone -please- figure out a way to make COMSAT decide that LL.ARPA is -down- and flush all that crap? Please? You don't even have to fix the bug that makes this happen (although that would be nice...). I'm tired of having to babysit COMSAT every time it wants to garbage collect. I could submit 384 kill requests, I suppose. Dear Distraught, If you patch LL.ARPA's address into the HFLUSH table (find the first slot that holds -1, since MX's addresses may already be in that table), COMSAT will start discarding mail to LL.ARPA as fast as it can spin AI's little disks. Probably. This assumes that those messages are still on the queue somewhere as opposed to just being loose garbage that COMSAT is somehow perpetuating across GCs. If the latter is the case, there are still Things We Can Do, but let's start out down in the kiloton range, shall we? -- Mr. Mailer  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 28 Mar 88 17:04:34 EST Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 101646; Mon 28-Mar-88 17:01:19 EST Date: Mon, 28 Mar 88 17:01 EST From: Alan Bawden Subject: Help me Mr. Mailer To: Bug-COMSAT@AI.AI.MIT.EDU Message-ID: <880328170137.3.ALAN@PIGPEN.AI.MIT.EDU> On AI there are 384 messages queued for LL.ARPA, some of them have been in the queue since January. A SHOW-Q says that the failure count for that host is "1". LISTS MSGS is over 1000 blocks long. Can someone -please- figure out a way to make COMSAT decide that LL.ARPA is -down- and flush all that crap? Please? You don't even have to fix the bug that makes this happen (although that would be nice...). I'm tired of having to babysit COMSAT every time it wants to garbage collect. I could submit 384 kill requests, I suppose.  Date: Thu, 24 Mar 88 20:19:13 EST From: David Chapman Subject: A curse on our mailer? To: ALAN@AI.AI.MIT.EDU cc: BUG-COMSAT@AI.AI.MIT.EDU, JTW@AI.AI.MIT.EDU In-reply-to: Msg of Thu 24 Mar 88 18:51:00 EST from Alan Bawden Message-ID: <347074.880324.ZVONA@AI.AI.MIT.EDU> Geez. Better try Ye Obscure Magick Weirdnesse Spell (conveniently posted on the KS CPU). Were any other other PAGANISM recipients suffering similarly? Maintaining this list is a moby pain -- it goes to the damnedest places, and tickles mailer bugs at every hop.  Date: Thu, 24 Mar 88 18:51:00 EST From: Alan Bawden Subject: A curse on our mailer? To: PAGANISM-REQUEST@AI.AI.MIT.EDU cc: BUG-COMSAT@AI.AI.MIT.EDU, JTW@AI.AI.MIT.EDU Message-ID: <347020.880324.ALAN@AI.AI.MIT.EDU> I flushed sorceror@LL.ARPA from PAGANISM and MIT-PSG, because about 90% of the queued mail on AI (383 messages, maybe 1000 blocks!) were messages for him, and LL.ARPA hasn't answered the phone since early in January. [ It is apparently a COMSAT bug that COMSAT hasn't started bouncing these messages rather than just letting them accumulate. ]  Date: Thu, 17 Mar 88 00:03:48 EST From: Puff the Magic Dragon Subject: Happy Birthday! To: KSC@AI.AI.MIT.EDU Message-ID: <342995.880317.DRAGON@AI.AI.MIT.EDU> Happy birthday to you, Happy birthday to you, Happy birthday dear Kennedy, Happy birthday to you.  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 10 Mar 88 15:52:08 EST Date: Thu 10 Mar 88 15:49:12-EST From: Rob Austein Subject: Re: Need to correct for bad @FILE To: MAP@AI.AI.MIT.EDU cc: BUG-COMSAT@AI.AI.MIT.EDU, HEATH-PEOPLE-REQUEST@AI.AI.MIT.EDU In-Reply-To: <339086.880310.MAP@AI.AI.MIT.EDU> Message-ID: <12381288531.56.SRA@XX.LCS.MIT.EDU> Date: Thu, 10 Mar 88 06:58:39 EST From: "Michael A. Patton" There was an error in the file [MC:COMAIL;HEATH PEOPLE] which caused expansions to generate errors (and a bunch of spurious mail files). I corrected the problem at least a week ago, but COMSAT apparently hasn't been launched since then and it still has the bad info loaded. My question is: Is there some way I could cause it to flush the old data and re-read that file? GUN and reboot COMSAT. There isn't any way to get it to flush its cache on the fly. -------  Date: Thu, 10 Mar 88 06:58:39 EST From: "Michael A. Patton" Subject: Need to correct for bad @FILE To: BUG-COMSAT@AI.AI.MIT.EDU cc: HEATH-PEOPLE-REQUEST@AI.AI.MIT.EDU In-reply-to: Msg of Mon 29 Feb 88 14:58:10 EST from Communications Satellite Message-ID: <339086.880310.MAP@AI.AI.MIT.EDU> There was an error in the file [MC:COMAIL;HEATH PEOPLE] which caused expansions to generate errors (and a bunch of spurious mail files). I corrected the problem at least a week ago, but COMSAT apparently hasn't been launched since then and it still has the bad info loaded. My question is: Is there some way I could cause it to flush the old data and re-read that file? -Mike  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 7 Mar 88 05:10:39 EST Date: Mon, 7 Mar 88 05:07:34 EST From: "Pandora B. Berman" Subject: comsat overflow strikes again To: BUG-MAIL@MC.LCS.MIT.EDU Message-ID: <384520.880307.CENT@MC.LCS.MIT.EDU> i logged in this morning and was aghast to find MC LISTS MSGS at 2137 blocks. yes, that's 2137, with a 2 in the thousands place. i pulled the time-honored manuever of moving it to .mail1; and leaving a link, so comsat would have enough space on .mail.; to gc into. comsat prompty gc'd down to 1291. yesterday aft. alan reinstalled the old its, or comsat, or tcp, or whatever it was that didn't use to cause LISTS MSGS to balloon as badly as it's been doing recently, and comsat has apparently been disgorging its queued mail ever since, when not distracted by new mail..  Date: Sat, 5 Mar 88 14:58:43 EST From: David Chapman To: ALAN@AI.AI.MIT.EDU cc: BUG-MAIL@AI.AI.MIT.EDU In-reply-to: Msg of Fri 4 Mar 88 21:15:18 EST from Alan Bawden Message-ID: <336623.880305.ZVONA@AI.AI.MIT.EDU> Date: Fri, 4 Mar 88 21:15:18 EST From: Alan Bawden To: ZVONA%ML.AI.MIT.EDU at MC.LCS.MIT.EDU There is a SPLIT Emacs library.. Ah HAH! I thought it was just me... I'm pretty sure there is a bug in MAIL such that it sometimes randomly doubles the period at the end of a message. I can't reproduce this, but here is evidence that it's not just me.  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 4 Mar 88 22:28:51 EST Date: Fri 4 Mar 88 22:17:37-EST From: Rob Austein To: ZVONA@AI.AI.MIT.EDU cc: BUG-MAIL@AI.AI.MIT.EDU In-Reply-To: <336255.880304.ZVONA@AI.AI.MIT.EDU> Message-ID: <12379786375.53.SRA@XX.LCS.MIT.EDU> Date: Fri, 4 Mar 88 18:41:32 EST From: David Chapman ai:.mail.; was full. I deleted a bunch of ostats. I thought there was supposed to be a daemon that did that? There is one (MC: DRAGON; HOURLY GCMAIL) but it isn't installed on AI because certain parties found it distasteful. I just work here. -------  Date: Fri, 4 Mar 88 18:41:32 EST From: David Chapman To: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <336255.880304.ZVONA@AI.AI.MIT.EDU> ai:.mail.; was full. I deleted a bunch of ostats. I thought there was supposed to be a daemon that did that?  Date: Tue, 1 Mar 88 22:53:49 EST From: David Chapman Subject: [quintus!watson: Reply to: Msg of Monday, 29 February 1988 23:33-EST] To: BUG-COMSAT@AI.AI.MIT.EDU cc: quintus!watson@SUN.COM Message-ID: <334727.880301.ZVONA@AI.AI.MIT.EDU> How do I find out what message this was and why it got dequeued? Date: Tue 1 Mar 1988 17:23:18 PST From: Kennita Watson To: paganism at ai.ai.mit.edu Re: Reply to: Msg of Monday, 29 February 1988 23:33-EST > FAILED: sorceror at LL.ARPA, anton%postgres.Berkeley.EDU at UCBVAX.BERKELEY.EDU, oster%dewey.soe.berkeley.edu at UCBVAX.BERKELEY.EDU, lah%dewey.soe.berkeley.edu at UCBVAX.BERKELEY.EDU > This message was manually killed by Comsat maintainers. Say what?! Kennita  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 24 Feb 88 12:52:19 EST Received: from galileo.s1.gov (TCP 20003600061) by MC.LCS.MIT.EDU 24 Feb 88 12:16:58 EST Received: by galileo.s1.gov id AA14005; Wed, 24 Feb 88 07:24:43 PST id AA14005; Wed, 24 Feb 88 07:24:43 PST Date: Wed, 24 Feb 88 07:24:43 PST From: ota%galileo.s1.gov@mordor.s1.gov Message-Id: <8802241524.AA14005@galileo.s1.gov> To: maeda@ai.ai.mit.edu Cc: space-request@mc.lcs.mit.edu, bug-mailer@mc.lcs.mit.edu In-Reply-To: Christopher Maeda's message of Wed, 24 Feb 88 08:39 EST <880224083948.2.MAEDA@MACH.AI.MIT.EDU> Subject: I want to gateway aviation to usenet. The gateway works by getting the cooperation of someone with a Unix system that has usenet access. In my case I send all incoming message from the Internet side to 'post-space@ucbvax.berkeley.edu' in addition to appending it to a digest queue file here. This stuff gets inserted into the usenet sci.space news group. Messages that are received there in sci.space but which were not originated from post-space@ucbvax are mailed to space-incoming@angband.s1.gov. This stuff only gets appended to the digest queue file but is not forwarded to post-space@ucbvax. The only tricky part is pulling stuff out of the usenet news group and avoiding loops in the process. I don't know if there is a special program for this or what. My usenet contact for all this is: fair@ucbarpa.berkeley.edu (Erik E. Fair) So you might drop him a line for his suggestions as well. Let me know if you have more questions, Ted Anderson  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 24 Feb 88 10:45:42 EST Received: from MCC.COM (TCP 1200600076) by MC.LCS.MIT.EDU 24 Feb 88 10:40:32 EST Received: from THOTH.ACA.MCC.COM by MCC.COM with TCP; Wed 24 Feb 88 09:39:24-CST Date: Wed, 24 Feb 88 09:36 CST From: David Vinayak Wallace Subject: I want to gateway aviation to usenet. To: Christopher Maeda cc: space-request@MC.LCS.MIT.EDU, bug-mailer@MC.LCS.MIT.EDU In-Reply-To: <880224083948.2.MAEDA@MACH.AI.MIT.EDU> Message-ID: <880224093652.4.GUMBY@THOTH.ACA.MCC.COM> Date: Wed, 24 Feb 88 08:39 EST From: Christopher Maeda I've been getting tons of requests for aviation from usenet lusers that heard we weren't connected. How do I gateway to usenet? Is it some comsat hack? Ask postmaster@eddie.mit.edu, see if they'll help. Basically you want to copy what I did for dead-flames.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 24 Feb 88 10:30:42 EST Received: from galileo.s1.gov (TCP 20003600061) by MC.LCS.MIT.EDU 24 Feb 88 10:26:08 EST Received: by galileo.s1.gov id AA14005; Wed, 24 Feb 88 07:24:43 PST id AA14005; Wed, 24 Feb 88 07:24:43 PST Date: Wed, 24 Feb 88 07:24:43 PST From: ota%galileo.s1.gov@mordor.s1.gov Message-Id: <8802241524.AA14005@galileo.s1.gov> To: maeda@ai.ai.mit.edu Cc: space-request@mc.lcs.mit.edu, bug-mailer@mc.lcs.mit.edu In-Reply-To: Christopher Maeda's message of Wed, 24 Feb 88 08:39 EST <880224083948.2.MAEDA@MACH.AI.MIT.EDU> Subject: I want to gateway aviation to usenet. The gateway works by getting the cooperation of someone with a Unix system that has usenet access. In my case I send all incoming message from the Internet side to 'post-space@ucbvax.berkeley.edu' in addition to appending it to a digest queue file here. This stuff gets inserted into the usenet sci.space news group. Messages that are received there in sci.space but which were not originated from post-space@ucbvax are mailed to space-incoming@angband.s1.gov. This stuff only gets appended to the digest queue file but is not forwarded to post-space@ucbvax. The only tricky part is pulling stuff out of the usenet news group and avoiding loops in the process. I don't know if there is a special program for this or what. My usenet contact for all this is: fair@ucbarpa.berkeley.edu (Erik E. Fair) So you might drop him a line for his suggestions as well. Let me know if you have more questions, Ted Anderson  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 24 Feb 88 08:43:02 EST Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by MC.LCS.MIT.EDU 24 Feb 88 08:40:03 EST Received: from MACH.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 93912; Wed 24-Feb-88 08:39:47 EST Date: Wed, 24 Feb 88 08:39 EST From: Christopher Maeda Subject: I want to gateway aviation to usenet. To: space-request@MC.LCS.MIT.EDU, bug-mailer@MC.LCS.MIT.EDU Message-ID: <880224083948.2.MAEDA@MACH.AI.MIT.EDU> I've been getting tons of requests for aviation from usenet lusers that heard we weren't connected. How do I gateway to usenet? Is it some comsat hack? Chris  Date: Tue, 23 Feb 88 17:40:07 EST From: David Chapman Subject: failing sends To: Gumby@MCC.COM cc: BUG-COMSAT@AI.AI.MIT.EDU, BUG-SENDER@AI.AI.MIT.EDU In-reply-to: Msg of Tue 23 Feb 88 00:23 CST from David Vinayak Wallace Message-ID: <330884.880223.ZVONA@AI.AI.MIT.EDU> Well, the right thing to do probably is to try to figure out a mailing address for the addressee and offer to mail to that. It could look in the INQUIR database or ask Bonzo or something. This is obviously not one of those real high priority items.  Received: from MCC.COM (TCP 1200600076) by AI.AI.MIT.EDU 23 Feb 88 01:28:35 EST Received: from THOTH.ACA.MCC.COM by MCC.COM with TCP; Tue 23 Feb 88 00:25:40-CST Date: Tue, 23 Feb 88 00:23 CST From: David Vinayak Wallace Subject: failing sends To: David Chapman cc: BUG-COMSAT@AI.AI.MIT.EDU, bug-sender@ai.ai.mit.edu In-Reply-To: <330281.880222.ZVONA@AI.AI.MIT.EDU> Message-ID: <880223002306.1.GUMBY@THOTH.ACA.MCC.COM> Date: Mon, 22 Feb 88 18:50:54 EST From: David Chapman In the perfect world of the future, COMSAT would realize that most people you might want to qsend to are on workstations which won't accept mail if sending fails. I assume you really mean the SEND program and not COMSAT. What do you want it to do? Not offer to mail it? Or ask you for a mailing address? Date: Mon, 22 Feb 88 17:22:12 EST From: Communications Satellite To: ZVONA at AI.AI.MIT.EDU Re: Msg of Monday, 22 February 1988 17:21-EST FAILED: agre at MARLEY.AI.MIT.EDU; Recipient name apparently rejected. Last reply was: {550- Local error: FEP file FEP:>lmfs.file.newest, required for the file system as a partition, is not accessible: 550- FEP File not found. 550- For FEP0:>lmfs.file 550 For MARLEY:>AGRE>mail.text} Failed message follows: ------- ZVONA@AI.AI.MIT.EDU 02/22/88 17:21:47 To: agre at MARLEY.AI.MIT.EDU Have you hacked the Searle thing, or shall I try to fight with nfrod?  Date: Mon, 22 Feb 88 18:50:54 EST From: David Chapman Subject: [COMSAT: Msg of Monday, 22 February 1988 17:21-EST] To: BUG-COMSAT@AI.AI.MIT.EDU Message-ID: <330281.880222.ZVONA@AI.AI.MIT.EDU> In the perfect world of the future, COMSAT would realize that most people you might want to qsend to are on workstations which won't accept mail if sending fails. Date: Mon, 22 Feb 88 17:22:12 EST From: Communications Satellite To: ZVONA at AI.AI.MIT.EDU Re: Msg of Monday, 22 February 1988 17:21-EST FAILED: agre at MARLEY.AI.MIT.EDU; Recipient name apparently rejected. Last reply was: {550- Local error: FEP file FEP:>lmfs.file.newest, required for the file system as a partition, is not accessible: 550- FEP File not found. 550- For FEP0:>lmfs.file 550 For MARLEY:>AGRE>mail.text} Failed message follows: ------- ZVONA@AI.AI.MIT.EDU 02/22/88 17:21:47 To: agre at MARLEY.AI.MIT.EDU Have you hacked the Searle thing, or shall I try to fight with nfrod?  Received: from SPEECH.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 10 FEB 88 14:56:37 EST Date: Wed 10 Feb 88 14:56:28-EST From: "John Wroclawski" Subject: Re: unknown hosts... To: SRA@XX.LCS.MIT.EDU, JAR@AI.AI.MIT.EDU cc: BUG-COMSAT@AI.AI.MIT.EDU In-Reply-To: <12373670200.56.SRA@XX.LCS.MIT.EDU> Message-ID: <12373676753.28.JTW@MIT-SPEECH> Now wait. There's a big difference between what OZ does, which is dump stuff onto XX whenever it can't immediately open a network connection throuth a rather questionable gateway, and what JAR proposed for the ITSes to do, which was to dump mail to XX whenever COMSAT didn't know the name of something. Given the number of failing TCP opens we're seeing, the OZ plan seems like a disaster. But I don't think what JAR actually suggested is a bad idea at all. If you really want to find out, just have COMSAT keep stats on what percentage of queued messages are rejected because it doesn't know the name. BTW, Jonathan, both of your original examples were because the machine in question had recently changed it's name. Both machines are correctly in the host tables under their new names, and can be reached by comsat. I don't want to take anything away from fixing COMSAT right, but there's a -lot- of stuff that has to happen before that's done. -john -------  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 10 Feb 88 14:24:29 EST Date: Wed 10 Feb 88 14:20:28-EST From: Rob Austein Subject: Re: unknown hosts... To: JAR@AI.AI.MIT.EDU cc: BUG-COMSAT@AI.AI.MIT.EDU In-Reply-To: <324586.880210.JAR@AI.AI.MIT.EDU> Message-ID: <12373670200.56.SRA@XX.LCS.MIT.EDU> Reagan and Zermatt are also overloaded. Suns run sendmail. The right thing to do is fix COMSAT. -------  Date: Wed, 10 Feb 88 13:22:21 EST From: Jonathan A Rees Subject: unknown hosts... To: SRA@XX.LCS.MIT.EDU cc: BUG-COMSAT@AI.AI.MIT.EDU In-reply-to: Msg of Wed 10 Feb 88 12:25:07-EST from Rob Austein Message-ID: <324586.880210.JAR@AI.AI.MIT.EDU> I'm sorry, I didn't mean to single out XX; I really meant any machine that knows how to talk domains. This could be Reagan or Zermatt or even one of the Suns (?).  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 10 Feb 88 12:29:12 EST Date: Wed 10 Feb 88 12:25:07-EST From: Rob Austein Subject: Re: unknown hosts... To: JAR@AI.AI.MIT.EDU cc: BUG-COMSAT@AI.AI.MIT.EDU In-Reply-To: <324533.880210.JAR@AI.AI.MIT.EDU> Message-ID: <12373649203.34.SRA@XX.LCS.MIT.EDU> Date: Wed, 10 Feb 88 11:55:10 EST From: Jonathan A Rees Subject: unknown hosts... To: BUG-COMSAT@AI.AI.MIT.EDU Because of hosts disappearing from the tables (like NSS.CS.UCL.AC.UK and, more recently, ADS.ARPA) or being unknown in the first place, I am having to route an increasingly large number of messages through XX these days -- this means manually editing message headers (which I often forget to do) and changing mailing lists. As a temporary kludge until domain name resolution works on ITS, it seems plausible to me that COMSAT might do automatically what I'm now doing manually, namely turn FOO@BAR to FOO%BAR@XX when BAR is not in the host table. Doesn't OZ do something vaguely like this already? Am I being completely off the wall? What would be the problem with this? You're not completely off the wall, but you're pretty close to it. What OZ does is only very vaugely related to what you propose. I don't think OZ's mailer will accept mail to any host that isn't in the host tables. What it does to is drop any mail it can't deliver "directly" (via the chaos server named "TCP" on MC, AI, or XX) on the first attempt onto some other machine, supposedly one of MC, AI, or XX, in decreasing order of preference. This has the odd effect of making sure that the bulk of the OZ mail that is being relayed via XX or the ITSen is mail to losing hosts. The business of signing all usernames as "foo%oz@xx" isn't related to the underlying mechanism, it's just that the last time anybody touched OZ's mailer, we were still running COMSAT III and XX was the only reliable path into OZ. The problem with routing all the trash via XX is that XX, like the KL before it, is under attack from the accountants. MMAILR CPU time is not something we can usefully bill to people. The SYS accounting group on XX (me, the operating system, and the system daemons) already account for about half of the machine; the bulk of that is mail related (MMAILR, SMTJFN, the domain resolver, and the TCP/IP code itself). For political reasons we are having a hard time getting anybody to accept the idea of paying for XX the way the AI lab pays for OZ, as a flat rate; it's the old story of people getting something for nothing for so long that they either believe they're entitled to it for free or don't believe it's worth anything. Even from a technical standpoint, I'm not really fond of the idea of automaticly dumping all of MC's garbage on XX, it sort of defeats the purpose of having a Mail Computer, yes? Excess computrons you might have sitting idle should be used to get the KCC compiler ported to ITS, not to implement still more kludges. So, in my capacity as a BUG-COMSAT person I am reluctant to do a lot of work rewiring things inside the guts of COMSAT to implement a change that will make life worse for me in my capacity as BUG-XX. --Rob -------  Date: Wed, 10 Feb 88 11:55:10 EST From: Jonathan A Rees Subject: unknown hosts... To: BUG-COMSAT@AI.AI.MIT.EDU Message-ID: <324533.880210.JAR@AI.AI.MIT.EDU> Because of hosts disappearing from the tables (like NSS.CS.UCL.AC.UK and, more recently, ADS.ARPA) or being unknown in the first place, I am having to route an increasingly large number of messages through XX these days -- this means manually editing message headers (which I often forget to do) and changing mailing lists. As a temporary kludge until domain name resolution works on ITS, it seems plausible to me that COMSAT might do automatically what I'm now doing manually, namely turn FOO@BAR to FOO%BAR@XX when BAR is not in the host table. Doesn't OZ do something vaguely like this already? Am I being completely off the wall? What would be the problem with this? - Jonathan Date: Wed, 10 Feb 88 11:41:30 EST From: Communications Satellite To: JAR at AI.AI.MIT.EDU Re: Msg of Wednesday, 10 February 1988 11:41-EST ============ A copy of your message is being returned, because: ============ "CLOWNEY@ELO.RUTGERS.EDU" at AI.AI.MIT.EDU is an unknown recipient. ============ Failed message follows: ============ Date: Wed, 10 Feb 88 11:41:21 EST From: Jonathan A Rees Subject: buffering To: "CLOWNEY@ELO.RUTGERS.EDU"@AI.AI.MIT.EDU Message-ID: <324524.880210.JAR@AI.AI.MIT.EDU> As a workaround, you might try calling FORCE-OUTPUT on the output port in question before oding the READ. E.g. ((access force-output t-standard-env) (current-output-port))  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 5 Feb 88 10:10:45 EST Date: Fri 5 Feb 88 10:05:05-EST From: Rob Austein Subject: Re: Please remove this "fix" and stop breaking our NAMES files To: Gumby@AI.AI.MIT.EDU cc: BUG-COMSAT@AI.AI.MIT.EDU, BUG-FTP@AI.AI.MIT.EDU In-Reply-To: <880205024139.4.GUMBY@THOTH.ACA.MCC.COM> Message-ID: <12372312989.59.SRA@XX.LCS.MIT.EDU> Right, it's the SYS*** stuff I object to, the .MA*** stuff is probably the right thing. So long as your changes will allow the normal sequence of write and RENMWO on SYS***, I'll be satisfied. You please remove the extra patches, I don't want to remove old stuff by accident. -------  Received: from MCC.COM (TCP 1200600076) by AI.AI.MIT.EDU 5 Feb 88 03:46:28 EST Received: from THOTH.ACA.MCC.COM by MCC.COM with TCP; Fri 5 Feb 88 02:44:34-CST Date: Fri, 5 Feb 88 02:41 CST From: David Vinayak Wallace Subject: Please remove this "fix" and stop breaking our NAMES files To: Rob Austein cc: BUG-COMSAT@AI.AI.MIT.EDU, BUG-FTP@AI.AI.MIT.EDU In-Reply-To: Message-ID: <880205024139.4.GUMBY@THOTH.ACA.MCC.COM> Date: Thu, 4 Feb 1988 01:29 EST From: Rob Austein Date: Wednesday, 3 February 1988 19:49-EST From: Bruce Nemnich Did I miss something? Did someone at Think.COM trash NAMES lately? I haven't seen any problems. Gumby (who has been paying more attention to ITS mail than I have) seems to have gotten annoyed enough (whether incrementally or catastrophicaly I don't know) at some anonymous person on your end of the world that he went and made some changes to the ITS FTP server to defend against your people. Unfortunately these changes also defend against legitimate MIT people doing legitimate MIT things (updating host tables), which got me upset. We need input from Gumby on this. He has just recently vanished into the twilight zone for an extended period of time, so said input may be hard to get. I may just go and undo his changes without his permission, but I'd like to avoid it if possible, it seems tasteless. [Note that the Think people are not cc'd in order not to muddy the waters.] I don't want to remove the restriction on writing the .MA*** directories via FTP. Unfortunately there will always be pinheads in the world, sometimes we all pay a price to defend from them. I find it hard to believe that anyone who knows what s/he's doing has no other recourse but TCP-FTP (people like BARMAR are exceptions who can be fixed by giving them accounts). Or we could allow writes if you login with some special name. But then they'll just mail that name to arpanet-bboards, and lots of people who've never before thought of changing that file will decide to, or perhaps to MAIL copies of it to [.MAIL.;NAMES >], who knows? The case of the SYS*** directories is different; more a case of over-exuberance. There was already code to prevent deletion on the SYS*** directories; I added the same code to rename and write. I guess it should probably come out; I'll take it out, or you can. Let me know. In summary, I think the protection on .MA*** should stay, and in support of this I enclose without further coment the following message from to-day's mail (from a completely different mailing list): Date: Thu, 4 Feb 88 14:37:44 EST From: nesheim@Think.COM Message-Id: <8802041937.AA00477@yggdrasil.think.com> To: DCP@quabbin.scrc.symbolics.com, namedroppers@sri-nic.arpa Subject: Re: Thinking Machine's domain administration Date: Wed, 3 Feb 88 14:38 EST From: David C. Plummer Remember that message I sent to PostMaster@Think.COM because that what it says in the SOA record? Here's what I got back: SMTP error from THINK.COM: 550 ... User unknown SMTP error from THINK.COM: 550 ... Addressee unknown The second one is OK. The first one bothers me. This is a request for the administrator of COM to forward my message to the administrator of THINK.COM. That structure is in place; let's see if it works. I did get two copies of the message you sent, and PostMaster@THINK.COM works fine at the moment. We have a globally writable aliases database which folks are in the unfortunate habit of trashing with regularity here.  Received: from Think.COM (TCP 1201000006) by AI.AI.MIT.EDU 4 Feb 88 14:20:57 EST Return-Path: Received: from pozzo.think.com by Think.COM; Thu, 4 Feb 88 14:18:57 EST Received: by pozzo.think.com; Thu, 4 Feb 88 14:18:52 est Date: Thu, 4 Feb 88 14:18:52 est From: Bruce Nemnich Message-Id: <8802041918.AA23600@pozzo.think.com> To: SRA@xx.lcs.mit.edu Cc: BUG-COMSAT@ai.ai.mit.edu, BUG-FTP@ai.ai.mit.edu, GUMBY@ai.ai.mit.edu, Postmaster@Think.COM, sra@xx.lcs.mit.edu In-Reply-To: Rob Austein's message of Thu, 4 Feb 1988 01:29 EST Subject: Please remove this "fix" and stop breaking our NAMES files We've hired enough new people around here since the previous flame session that I'll send out a message to everyone telling them to avoid editing NAMES with FTP, and if they do ever write it, to check for errors, etc. I hadn't been aware of recent lossage. --bruce  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 4 Feb 88 01:34:31 EST Date: Thu, 4 Feb 1988 01:29 EST Message-ID: From: Rob Austein To: Bruce Nemnich Cc: BUG-COMSAT@AI.AI.MIT.EDU, BUG-FTP@AI.AI.MIT.EDU, GUMBY@AI.AI.MIT.EDU, Postmaster@THINK.COM, sra@XX.LCS.MIT.EDU Subject: Please remove this "fix" and stop breaking our NAMES files In-reply-to: Msg of 3 Feb 1988 19:49-EST from Bruce Nemnich Date: Wednesday, 3 February 1988 19:49-EST From: Bruce Nemnich To: SRA@xx.lcs.mit.edu cc: GUMBY@ai.ai.mit.edu, Postmaster@Think.COM, BUG-COMSAT@ai.ai.mit.edu, BUG-FTP@ai.ai.mit.edu Re: Please remove this "fix" and stop breaking our NAMES files Date: Tue, 2 Feb 1988 16:37 EST From: Rob Austein ... If people at Thinking Machines Incorporated are still screwing up our NAMES files, we should enable the ASSHOL feature on them for a few weeks, as promised the last time this happened. That might succeed in getting their attention. We might want to slightly modify the ASSHOL feature so that it rejects anthing on THINK.COM's network with a response of 550-Refused because twits at your site keep editing our mailing list 550-files via FTP and breaking them. We'll start accepting mail from 550 you again when you find these people and shoot them. Did I miss something? Did someone at Think.COM trash NAMES lately? I haven't seen any problems. Gumby (who has been paying more attention to ITS mail than I have) seems to have gotten annoyed enough (whether incrementally or catastrophicaly I don't know) at some anonymous person on your end of the world that he went and made some changes to the ITS FTP server to defend against your people. Unfortunately these changes also defend against legitimate MIT people doing legitimate MIT things (updating host tables), which got me upset. We need input from Gumby on this. He has just recently vanished into the twilight zone for an extended period of time, so said input may be hard to get. I may just go and undo his changes without his permission, but I'd like to avoid it if possible, it seems tasteless. --Rob  Received: from Think.COM (TCP 1201000006) by AI.AI.MIT.EDU 3 Feb 88 19:51:13 EST Return-Path: Received: from pozzo.think.com by Think.COM; Wed, 3 Feb 88 19:49:25 EST Received: by pozzo.think.com; Wed, 3 Feb 88 19:49:21 est Date: Wed, 3 Feb 88 19:49:21 est From: Bruce Nemnich Message-Id: <8802040049.AA13313@pozzo.think.com> To: SRA@xx.lcs.mit.edu Cc: GUMBY@ai.ai.mit.edu, Postmaster@Think.COM, BUG-COMSAT@ai.ai.mit.edu, BUG-FTP@ai.ai.mit.edu In-Reply-To: Rob Austein's message of Tue, 2 Feb 1988 16:37 EST Subject: Please remove this "fix" and stop breaking our NAMES files Date: Tue, 2 Feb 1988 16:37 EST From: Rob Austein ... If people at Thinking Machines Incorporated are still screwing up our NAMES files, we should enable the ASSHOL feature on them for a few weeks, as promised the last time this happened. That might succeed in getting their attention. We might want to slightly modify the ASSHOL feature so that it rejects anthing on THINK.COM's network with a response of 550-Refused because twits at your site keep editing our mailing list 550-files via FTP and breaking them. We'll start accepting mail from 550 you again when you find these people and shoot them. --Rob Did I miss something? Did someone at Think.COM trash NAMES lately? --bruce  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 2 Feb 88 19:14:31 EST Date: Tue, 2 Feb 88 19:14:02 EST From: Rob Austein To: BUG-COMSAT@MC.LCS.MIT.EDU Message-ID: <367043.880202.SRA@MC.LCS.MIT.EDU> Could it be that the mysterious COMSAT IOC errors are the net connection going to state %NTWRT (Output buffer full)? COMSAT's code for handling interrupts on net connections appears to date to NCP/FTP mail, if the error messages are any indication. COMSAT doesn't do a WHYINT on the net connection, it just aborts with the cryptic "NTMSND IOC" message.  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 2 Feb 88 16:44:35 EST Date: Tue, 2 Feb 1988 16:37 EST Message-ID: From: Rob Austein To: David Vinayak Wallace , Postmaster@THINK.COM, Bruce@THINK.COM Cc: BUG-COMSAT@AI.AI.MIT.EDU, BUG-FTP@AI.AI.MIT.EDU Subject: Please remove this "fix" and stop breaking our NAMES files In-reply-to: Msg of 25 Jan 1988 03:35-EST from David Vinayak Wallace Date: Monday, 25 January 1988 03:35-EST From: David Vinayak Wallace To: BUG-COMSAT@AI.AI.MIT.EDU In case someone complains, I fixed ftp a couple of weeks ago so that you now cannot delete nor rename files on SYS*** nor .MA***, nor can you write .MAIL.;NAMES > via ftp. I got sick of the losers at think writing NAMES > with ftp and losing, despite our repeated requests that they cease and desist. david PS: the error message is "Permission denied" a la our favorite operating system. [PHOTO: Recording initiated Tue 2-Feb-88 4:23PM] MIT TOPS-20 Command Processor 5(312161)-2 XX>ftp ai < AI.AI.MIT.EDU ITS 1615, FTP server 330 on 2 FEB 1988 1628 EST < Bugs/gripes to BUG-FTP @ MIT-MC Setting default transfer type to binary, byte size 36. Default login as sra < OK, your user name is SRA FTP>send login.cmd "syshst;ignore this" < DSK:SYSHST;IGNORE THIS: permission denied FTP>exit XX>pop [PHOTO: Recording terminated Tue 2-Feb-88 4:24PM] How are people on TCP-only machines supposed to update the host tables now? The whole point of putting the tables on AI was to have them publicly accessible. I've already gotten one complaint on this. If people at Thinking Machines Incorporated are still screwing up our NAMES files, we should enable the ASSHOL feature on them for a few weeks, as promised the last time this happened. That might succeed in getting their attention. We might want to slightly modify the ASSHOL feature so that it rejects anthing on THINK.COM's network with a response of 550-Refused because twits at your site keep editing our mailing list 550-files via FTP and breaking them. We'll start accepting mail from 550 you again when you find these people and shoot them. --Rob  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 30 Jan 88 15:24:08 EST Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 30 Jan 88 14:19:28 EST Date: Sat 30 Jan 88 14:14:46-EST From: Rob Austein Subject: Re: mc mail failures To: HOBBIT@aim.rutgers.edu cc: Bug-COMSAT@MC.LCS.MIT.EDU Reply-To: Bug-COMSAT@MC.LCS.MIT.EDU In-Reply-To: Message from "_*Hobbit* " of Sat 30 Jan 88 04:59:41-EST Message-ID: <12370785579.21.SRA@XX.LCS.MIT.EDU> Date: Sat, 30 Jan 88 04:52 EST From: _*Hobbit* I looked at this in more depth tonight; it seems that MC is occasionally replying to a RCPT TO: line with a *blank* line instead of a "250 OK". This mailer [PMDF] seems to interpret this as an invalid addressee or something, but in all likelihood would up requeueing the message for some reason even though it had already been sent anyway. Can you look into the blank line problem, and I'll look into the requeueing business? Is there a spec on how blank lines as answers should be interpreted? I haven't discounted the possibility that our network implementation is erroneously handing me the blank lines either, but I've had no problem with other hosts. When PMDF says "SMTP server rejected address" that's a *locally*-generated message, it turns out; it tries to stick the error message from the foriegn host in that line, but if there wasn't one [as in these cases] it supplies its own. Off the top of my head I'd guess that this is a to \n conversion problem. Given the amount of mail traffic MC handles, you'd think we'd have noticed before now if the SMTP server were out of spec. I'll look into it, but it would help if I knew exactly what the SMTP dialog looked like so that I can see if the dialog itself triggers any weird behavior. I don't recall offhand if there's any mention of how to handle blank lines, they're probably illegal, but should probably be ignored unless there's some reason to think that the client has gone into a DATA command on you. I have five or six recipients of this list at MC; would setting up an exploder be appropriate? Doesn't matter either way in terms of load, COMSAT does about the same amount of work either way. If we set up an exploder somebody would have to maintain it, so unless it would make your life noticably easier, let's not. --Rob -------  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 25 Jan 88 08:24:48 EST Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 25 JAN 88 08:27:07 EST Date: Mon, 25 Jan 1988 08:27 EST Message-ID: From: Richard Pavelle To: bug-mail@MC.LCS.MIT.EDU cc: Richard Pavelle Subject: mail to UK Can someone help me? My mail to the UK does not get through when addressed as below. Thanks. Date: Wednesday, 20 January 1988 07:40-EST From: Richard Pavelle To: liaison%uk.ac.ucl.cs.nss.arpa at MC.LCS.MIT.EDU Re: mail to UK Can you help me? I wish to send mail to colleagues in the UK. My mail is returned to me with the message below: < Not authorized to send mail to address: < @cs.qmc.ac.uk:mm@maths.qmc.ac.uk You have just relayed a message < through UK.AC.UCL.CS < If you intended your message to go through the Arpanet Gateway, then < please note that the Gateway is now known as uk.ac.ucl.cs.nss. < Contact liaison@uk.ac.ucl.cs.nss for help, or send a text-less message < to authorisation@uk.ac.ucl.cs.nss for an automatic message < specifically about UK<->US relaying.  Date: Mon, 25 Jan 88 03:35:43 EST From: David Vinayak Wallace Subject: old news To: BUG-COMSAT@AI.AI.MIT.EDU Message-ID: <315765.880125.GUMBY@AI.AI.MIT.EDU> In case someone complains, I fixed ftp a couple of weeks ago so that you now cannot delete nor rename files on SYS*** nor .MA***, nor can you write .MAIL.;NAMES > via ftp. I got sick of the losers at think writing NAMES > with ftp and losing, despite our repeated requests that they cease and desist. david PS: the error message is "Permission denied" a la our favorite operating system.  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 14 Dec 87 14:47:05 EST Date: Mon, 14 Dec 1987 14:45 EST Message-ID: From: Rob Austein To: David Vinayak Wallace Cc: Mailer-Error-of-the-Day@MC.LCS.MIT.EDU, Bug-COMSAT@AI.AI.MIT.EDU Reply-To: Bug-COMSAT@AI.AI.MIT.EDU Subject: amusing comsat lossage In-reply-to: Msg of 14 Dec 1987 06:51-EST from David Vinayak Wallace Date: Monday, 14 December 1987 06:51-EST From: David Vinayak Wallace To: mailer-error-of-the-day@MC.LCS.MIT.EDU Re: amusing comsat lossage (this doesn't go to bug-comsat since it's not a bug). Check out mc:.mail.;badreq 1. JTW sent mail to bug-cftp. MC is the bug host, but has an entry pointing to bug-cftp@ai (shows how long it's been since someone reported a bug in ITS cftp). So his 8-line message looped until enough Received: lines and terminating newlines had been added to cause COMSAT to say "Your messge is too long to send." The return-path's pretty funky too. Except that COMSAT appended a blank line to the end for each pass, which seems less than optimal.  Date: Mon, 14 Dec 87 13:58:28 EST From: Ray Hirschfeld Subject: comsat case sensitivity To: MAIL-MAINTAINERS@AI.AI.MIT.EDU, BUG-MAIL@AI.AI.MIT.EDU Message-ID: <299379.871214.RAY@AI.AI.MIT.EDU> I tried to show a message in the AI queue that happened to have letters in the message number. The request failed when I used lowercase but worked when I tried again with uppercase. This seems like a unix-style misfeature. Ray  Date: Tue, 8 Dec 87 15:14:35 EST From: Richard Mlynarik Subject: shit for brains To: BUG-COMSAT@AI.AI.MIT.EDU Message-ID: <296501.871208.MLY@AI.AI.MIT.EDU> I accidentally set up an address which forwarded to itself. (mly-lispm@ai forwarded to itself, instead of to mly-lispm@mc) Comsat (rightly, I suppose) silently killed messages sent to this address. IWBNI the NAMED ERR file had said something.  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 18 Nov 87 11:07:44 EST Date: Wed, 18 Nov 1987 11:04 EST Message-ID: From: Rob Austein To: Devon Sean McCullough Cc: BUG-COMSAT@AI.AI.MIT.EDU Reply-To: BUG-COMSAT@AI.AI.MIT.EDU Subject: oh well In-reply-to: Msg of 18 Nov 1987 10:31-EST from Devon Sean McCullough Date: Wednesday, 18 November 1987 10:31-EST From: Devon Sean McCullough To: BUG-COMSAT@AI.AI.MIT.EDU Re: oh well I typed :mail davis@nails ... and it accepted the message. Typing :HOST NAILS produces NAILS.GSFC.NASA.GOV "SERVER" System: UNIX CPU: SUN-3 GSFC = 128.183.10.60 20055,,605074 (no services listed) :KILL * but look at this: Date: Wed, 18 Nov 87 09:31:11 EST From: Communications Satellite To: DEVON at AI.AI.MIT.EDU Re: Msg of Wednesday, 18 November 1987 09:30-EST FAILED: davis at NAILS.GSFC.NASA.GOV; Recipient name apparently rejected. Last reply was: {554 ... Unknown domain GOV} Failed message follows: ------- Date: Wed, 18 Nov 87 09:30:36 EST From: Devon Sean McCullough To: davis@NAILS.GSFC.NASA.GOV Message-ID: <287649.871118.DEVON@AI.AI.MIT.EDU> Testing address "Davis@nails" from mit-ai. So NAILS.GSFC.NASA.GOV doesn't know its own name. Presumably either (1) nobody there cares about mail or (2) they'll eventually notice that they don't receive any mail. Why are you reporting this to BUG-COMSAT?  Date: Wed, 18 Nov 87 10:31:24 EST From: Devon Sean McCullough Subject: oh well To: BUG-COMSAT@AI.AI.MIT.EDU Message-ID: <287678.871118.DEVON@AI.AI.MIT.EDU> I typed :mail davis@nails ... and it accepted the message. Typing :HOST NAILS produces NAILS.GSFC.NASA.GOV "SERVER" System: UNIX CPU: SUN-3 GSFC = 128.183.10.60 20055,,605074 (no services listed) :KILL * but look at this: Date: Wed, 18 Nov 87 09:31:11 EST From: Communications Satellite To: DEVON at AI.AI.MIT.EDU Re: Msg of Wednesday, 18 November 1987 09:30-EST FAILED: davis at NAILS.GSFC.NASA.GOV; Recipient name apparently rejected. Last reply was: {554 ... Unknown domain GOV} Failed message follows: ------- Date: Wed, 18 Nov 87 09:30:36 EST From: Devon Sean McCullough To: davis@NAILS.GSFC.NASA.GOV Message-ID: <287649.871118.DEVON@AI.AI.MIT.EDU> Testing address "Davis@nails" from mit-ai.  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 15 Nov 87 02:09:57 EST Date: Sun, 15 Nov 1987 02:07 EST Message-ID: From: Rob Austein To: Tom Greene Cc: mbr@XX.LCS.MIT.EDU, ray@XX.LCS.MIT.EDU, ty@XX.LCS.MIT.EDU, bug-comsat@AI.AI.MIT.EDU Subject: [Mark Reinhold : Theory backup CANCELLED] In-reply-to: Msg of 14 Nov 1987 10:32-EST from Tom Greene Date: Saturday, 14 November 1987 10:32-EST From: Tom Greene Can you update me on the status of 'MC has not been accepting incoming mail?' Date: Fri, 13 Nov 87 18:48:10 -0500 From: Mark Reinhold To: dmh@eddie.mit.edu, dmh@THEORY.LCS.MIT.EDU Cc: ray@ai.ai.mit.edu, bard@THEORY.LCS.MIT.EDU, tjg@xx.LCS.MIT.EDU, ty@xx.LCS.MIT.EDU Subject: Theory backup CANCELLED The message you sent this afternoon did not make it to any members of the TOC group because MC, the host on which the TOC list is maintained, has not been accepting incoming mail. Therefore, please DO NOT backup Theory this weekend. I just spoke with Tom Greene about this, and he agrees that taking the machine down for the morning with essentially no notice is unacceptable. You should coordinate with Ty re. finding another time for the backup; Tom was suggesting next Tuesday evening. According to the COMSAT log, MC and IMP 44 stopped talking to each other sometime Friday morning. COMSAT doesn't detect this properly, so the message in the log file is obscure. Since the IMP connection appears to have come back without anybody rebooting MC, I assume that this was one of those random IMP spazzes where it does unmentionable things on the 1822 interface while telling the outside world that the host is dead. I'd say you should flame at BBN, except that they don't admit the problem exists and even if it does it'll be fixed in the next release of the IMP (=PSN) software. Right.  Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 20024224620) by AI.AI.MIT.EDU 12 Nov 87 17:33:27 EST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 278386; Thu 12-Nov-87 17:31:37 EST Date: Thu, 12 Nov 87 17:31 EST From: David A. Moon Subject: how can I find a path to GROUCHO.UCAR.EDU, pray tell? To: Devon Sean McCullough cc: BUG-COMSAT@AI.AI.MIT.EDU In-Reply-To: <283452.871110.DEVON@AI.AI.MIT.EDU> Message-ID: <19871112223124.2.MOON@EUPHRATES.SCRC.Symbolics.COM> You could try mailing to Davis%GROUCHO.UCAR.EDU@reagan.ai.mit.edu. I'm not positive but I think that tends to work.  Date: Wed, 11 Nov 87 12:14:56 EST From: Alan Bawden Subject: Rube Goldberg To: BUG-COMSAT@AI.AI.MIT.EDU cc: MAP@AI.AI.MIT.EDU, CUBE-LOVERS-REQUEST@AI.AI.MIT.EDU, Mailer-Error-of-the-Day@MC.LCS.MIT.EDU Message-ID: <283833.871111.ALAN@AI.AI.MIT.EDU> Date: Tue, 10 Nov 87 15:02:18 EST From: Michael A. Patton To: BUG-COMSAT at AI.AI.MIT.EDU cc: MAP at AI.AI.MIT.EDU, CUBE-LOVERS-REQUEST at AI.AI.MIT.EDU While looking at the .MAIL. directory just now I noticed two files which indicated some gross lossage (a mail-rejection loop it appears). I renamed the two files to LOSS 1 and LOSS 2. They are very similar. I have seen these before, but the queue was never backed up enough for me to rename them before they took off around the loop again. It is worth some laughs to look through these files to see all the mailer errors that happened -before- the thing finally settled down into the loop where MAP caught it! The final loop is COMSAT complaining that Orphanage@AI is unknown, but since the return path given by BRL-SMOKE.ARPA was -also- Orphanage@AI.AI.MIT.EDU, this generates mail to Orphanage%AI.AI.MIT.EDU@BRL-SMOKE.ARPA, which loops. To prevent this happening again, I created Orphanage@AI and made it forward to Orphanage@MC wich already existed. P.S. The seem to start with an erroneous address on the CUBE-Lovers list. There was nothing wrong with Cube-Lovers. Mail sent by @ardec-lcss.arpa:beck@clstr1.decnet to Cube-Lovers was delayed at BRL because they couldn't reach Rutgers. The delay message was routed back through AI by BRL, but when COMSAT told ARDEC-LCSS.ARPA that it had mail for "beck@clstr1.decnet" an error occured. Cube-Lovers is certainly not responsible for the validity of the return addresses generated by its subscribers!  Date: Wed, 11 Nov 87 12:10:46 EST From: Alan Bawden Subject: Rube Goldberg To: BUG-COMSAT@AI.AI.MIT.EDU cc: MAP@AI.AI.MIT.EDU, "MAILER-ERROR-OF-THE-DAY@MC CUBE-LOVERS-REQUEST"@AI.AI.MIT.EDU In-reply-to: Msg of Tue 10 Nov 87 15:02:18 EST from Michael A. Patton Message-ID: <283830.871111.ALAN@AI.AI.MIT.EDU> Date: Tue, 10 Nov 87 15:02:18 EST From: Michael A. Patton To: BUG-COMSAT at AI.AI.MIT.EDU cc: MAP at AI.AI.MIT.EDU, CUBE-LOVERS-REQUEST at AI.AI.MIT.EDU While looking at the .MAIL. directory just now I noticed two files which indicated some gross lossage (a mail-rejection loop it appears). I renamed the two files to LOSS 1 and LOSS 2. They are very similar. I have seen these before, but the queue was never backed up enough for me to rename them before they took off around the loop again. It is worth some laughs to look through these files to see all the mailer errors that happened -before- the thing finally settled down into the loop where MAP caught it! The final loop is COMSAT complaining that Orphanage@AI is unknown, but since the return path given by BRL-SMOKE.ARPA was -also- Orphanage@AI.AI.MIT.EDU, this generates mail to Orphanage%AI.AI.MIT.EDU@BRL-SMOKE.ARPA, which loops. To prevent this happening again, I created Orphanage@AI and made it forward to Orphanage@MC wich already existed. P.S. The seem to start with an erroneous address on the CUBE-Lovers list. There was nothing wrong with Cube-Lovers. Mail sent by @ardec-lcss.arpa:beck@clstr1.decnet to Cube-Lovers was delayed at BRL because they couldn't reach Rutgers. The delay message was routed back through AI by BRL, but when COMSAT told ARDEC-LCSS.ARPA that it had mail for "beck@clstr1.decnet" an error occured. Cube-Lovers is certainly not responsible for the validity of the return addresses generated by its subscribers!  Date: Tue, 10 Nov 87 21:31:43 EST From: Devon Sean McCullough Subject: how can I find a path to GROUCHO.UCAR.EDU, pray tell? To: BUG-COMSAT@AI.AI.MIT.EDU Message-ID: <283452.871110.DEVON@AI.AI.MIT.EDU> Date: Tue, 10 Nov 87 21:28:35 EST From: Communications Satellite To: DEVON at AI.AI.MIT.EDU Re: Msg of Tuesday, 10 November 1987 21:28-EST ============ A copy of your message is being returned, because: ============ "DAVIS@GROUCHO.UCAR.EDU" at AI.AI.MIT.EDU is an unknown recipient. ============ Failed message follows: ============ Date: Tue, 10 Nov 87 21:28:33 EST From: Devon Sean McCullough Subject: test message To: "DAVIS@GROUCHO.UCAR.EDU"@AI.AI.MIT.EDU cc: DEVON@AI.AI.MIT.EDU In-reply-to: Msg of Tue 10 Nov 87 10:33:17 MST from Glenn P. Davis Message-ID: <283450.871110.DEVON@AI.AI.MIT.EDU> The ITS mailer is fucked because the guy who was supposed to hack it to work with domains never did the job. Maybe I should fix it myself. So I can't mail to you at your real address. I will ask the mail maintainers here to fix the problem. Meanwhile let me know if you don't receive this message. --Devon  Date: Tue, 10 Nov 87 15:02:18 EST From: "Michael A. Patton" To: BUG-COMSAT@AI.AI.MIT.EDU cc: MAP@AI.AI.MIT.EDU, CUBE-LOVERS-REQUEST@AI.AI.MIT.EDU Message-ID: <283176.871110.MAP@AI.AI.MIT.EDU> While looking at the .MAIL. directory just now I noticed two files which indicated some gross lossage (a mail-rejection loop it appears). I renamed the two files to LOSS 1 and LOSS 2. They are very similar. I have seen these before, but the queue was never backed up enough for me to rename them before they took off around the loop again. P.S. The seem to start with an erroneous address on the CUBE-Lovers list.  Date: Fri, 6 Nov 87 15:42:03 EST From: Alan Bawden Subject: BBoards not working properly. To: BUG-COMSAT@AI.AI.MIT.EDU Message-ID: <280689.871106.ALAN@AI.AI.MIT.EDU> Notice the DISTRIB field on the following message. I am unable to explain it by anything that appears in the NAMES file on MC. I don't believe it could possibly be what anyone wants either. MSG: *MSG 3591 Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 5 Nov 87 12:17:42 EST DISTRIB: *PFC, *BBOARD EXPIRES: 11/12/87 11:23:50 linsay@ATHENA.MIT.EDU 11/05/87 11:23:50 Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 5 Nov 87 11:19:13 EST Received: from ATHENA by XX.LCS.MIT.EDU with TCP/SMTP; Thu 5 Nov 87 11:10:52-EST Received: by ATHENA.MIT.EDU (5.45/4.7) id AA01126; Thu, 5 Nov 87 11:14:19 EST From: Received: by M66-080-11 (5.45/4.7) id AA05004; Thu, 5 Nov 87 11:14:02 EST Message-Id: <8711051614.AA05004@M66-080-11> To: bboard@xx.lcs.mit.edu Subject: MAC II programmer wanted Date: Thu, 05 Nov 87 11:13:55 EST I need a student to help program a MAC II for my experiments on chaos and non-linear dynamics. The MAC II is fully loaded: 8 Mb memory, 90 Mb disk, 19" high resolution eight plane color graphics monitor, and a laser printer. Work will include color graphics programs (plots, rotations, animation?) and interface programs between the MAC II and a PDP11/73 running UNIX. Knowledge of UNIX, C, and Pascal desirable. Possible compensation: UROP credit, senior thesis, money. To be discussed. Call Paul S. Linsay, 3-8072  Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 20024224620) by AI.AI.MIT.EDU 6 Nov 87 15:06:40 EST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 273926; Fri 6-Nov-87 15:06:07 EST Date: Fri, 6 Nov 87 15:06 EST From: David A. Moon Subject: What I did just now to a wedged mailer (at SRA's direction) To: BUG-COMSAT@AI.AI.MIT.EDU cc: Michael A. Patton In-Reply-To: <280417.871106.MAP@AI.AI.MIT.EDU> Message-ID: <19871106200618.5.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Fri, 6 Nov 87 02:14:02 EST From: "Michael A. Patton" There was (and still is) a COMSAT IV job with PCLSR REALTM PARERR and it's associated COMSAT JOB.06 with "BADPI 4". It was writing log to STATS 1.... There was (but is no more) a COMSAT IV0 job in RENMWO with REALTM set, and associated JOB.07 in _HANG with no PIs. It was writing to STATS 2... I thought we had fixed this damnable lossage where a top-level interrupt unlocks the job's locks, allowing a second Comsat to get started, and then screwing up the world if someone restarts the original Comsat. Mike, PARERR means either a parity error in main memory or an irrecoverable disk error while swapping in a page. Either way there's be something, somewhere, on the system console printout about it. I hope the AI machine didn't suffer too badly from preventative maintenance a couple days ago.  Date: Fri, 6 Nov 87 02:14:02 EST From: "Michael A. Patton" Subject: What I did just now to a wedged mailer (at SRA's direction) To: BUG-COMSAT@AI.AI.MIT.EDU cc: MAP@AI.AI.MIT.EDU Message-ID: <280417.871106.MAP@AI.AI.MIT.EDU> Just now I discovered the mailer on AI wedged (details below). I punted what I figured to be the minimum and restarted with a :mail map ... ^C This seems to have recovered it (I've already received some mail). The Details: I first noticed it because when mail I CCed to myself didn't show up, I tried looking at .MAIL.; and found a lot of MAIL files (actually 45 by later count). I didn't notice a MAILIN file and the oldest MAIL file was from about 9PM (and at that time it was just 1:30, that's four and a half hours. This seemed excessive. I then did a PEEK and noticed all sorts of stuff: [In the following discussion I have abbreviated slightly some host names and message text, please take account and feel free to ask if a particular point is important.] There was (and still is) a COMSAT IV job with PCLSR REALTM PARERR and it's associated COMSAT JOB.06 with "BADPI 4". It was writing log to STATS 1 and it ended by having some gibberish from GRAPE-NUTS (which it punted) and then "unqueuing to 18.80.0.28" and stopped at the opening [i.e. it says "ICP -> 18.80.0.28 (TCP-SMTP" and stops]. The TCP connection showed in the PEEK as closed (by foreign end). All of this is still there as I type this. There was (but is no more) a COMSAT IV0 job in RENMWO with REALTM set, and associated JOB.07 in _HANG with no PIs. It was writing to STATS 2 which was a new file started at 210033 whose first real item (after standard launch procedures) was "Unqueuing to WARBUCKS" which had an open connection and had gotten to "TO->wilkins" and stopped there. The last line had the timestamp 210109. The connection to WARBUCKS was still open. I looked at various things (disk space, was WARBUCKS up, others) but couldn't see anything actually strange, except that it had been sending this one piece of mail for four and a half hours. At this point there wasn't much left to do without a COMSAT wizard, so I did in the COMSAT IV0 and sent mail (with :MAIL) which succeeded in launching a new COMSAT which started delivering from the queue. It's been up over 1/2 hour (but hasn't quite caught up yet) without any obvious problems. I'll wait around until it gets to looking at the queue in any case (shouldn't be more than a few minutes unless one of those messages is to Dead-Heads in which case I'll go to sleep). Bye, and good luck. Mike  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 27 Oct 87 17:30:15 EST Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 27 Oct 87 16:27:47 EST Date: Tue, 27 Oct 87 16:28:16 EST From: Ray Hirschfeld Subject: happy birthday To: ALAN@AI.AI.MIT.EDU cc: BUG-mail@MC.LCS.MIT.EDU, BUG-random-program@MC.LCS.MIT.EDU In-reply-to: Msg of Mon 26 Oct 87 12:36:06 EST from Alan Bawden Message-ID: <275890.871027.RAY@AI.AI.MIT.EDU> Date: Mon, 26 Oct 87 12:36:06 EST From: Alan Bawden ... If you are talking about some -other- birthday demon (you mentioned XX in your bug report), why complain to Bug-MAIL and Bug-Random-Program at MC? Oops, sorry everybody. It was a slip of the brain. I meant to type XX, not MC. It looks like the message got to the right place, though. Ray  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 26 Oct 87 16:11:11 EST Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 26 Oct 87 16:07:50 EST Received: from WHORFIN.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 26 Oct 87 14:55-EST Date: Mon, 26 Oct 87 14:59 EST From: Rob Austein Reply-To: Bug-HAPPY-BIRTHDAY@XX.LCS.MIT.EDU Subject: happy birthday To: Ray Hirschfeld cc: BUG-mail@MC.LCS.MIT.EDU, BUG-random-program@MC.LCS.MIT.EDU, BUG-HAPPY-BIRTHDAY@XX.LCS.MIT.EDU In-Reply-To: <275114.871026.RAY@AI.AI.MIT.EDU> Message-ID: <871026145902.5.SRA@WHORFIN.LCS.MIT.EDU> Date: Mon, 26 Oct 87 12:13:29 EST From: Ray Hirschfeld I don't know quite where to send this, since I don't know where the birthday code lives, but I (and the others on the XX happy-birthday list) received 325 copies of the birthday notification yesterday. I wouldn't be surprised if the fellow who's birthday it was got 325 cards as well. It's very suggestive that this happened around the time of the time change. The OZ birthday wizard didn't do the same thing, but I think it runs a couple of hours later. Presumably you mean that you got a bunch of messages from Birthday-Wizard@XX. I don't know exactly what happened, because the program is such a nothing that I never thought to keep logs of its behavior before. There is a known bug in the way the Twenex EXEC handles the /AFTER: switch (used by batch jobs that resubmit themselves for tomorow). It is just barely possible that if for some reason the happy birthday job was running just when the wall clock was set back, it would hit this bug and set the after time wrong. It seems a little odd though, since the time change is supposed to happen at 3AM or something like that, not at midnight. I haven't looked at the code involved recently, and, since there's a one hour window that occurs once a year, you can understand why this problem doesn't get much attention. I modified XX:<221B-BAKER-STREET>HAPPY-BIRTHDAY.SUB so that it will run at 4AM instead of midnight and so that it will keep logs so that we will have something to read next year if the EXEC bug doesn't get fixed in the meantime.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 26 Oct 87 12:39:50 EST Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 26 Oct 87 12:36:06 EST Date: Mon, 26 Oct 87 12:36:06 EST From: Alan Bawden Subject: happy birthday To: RAY@AI.AI.MIT.EDU cc: BUG-mail@MC.LCS.MIT.EDU, BUG-random-program@MC.LCS.MIT.EDU In-reply-to: Msg of Mon 26 Oct 87 12:13:29 EST from Ray Hirschfeld Message-ID: <275145.871026.ALAN@AI.AI.MIT.EDU> I'm confused. Are you talking about the birthday mail sent by Puff the Magic Dradon on AI? I'm in the birthday list that Puff mails to, and I only got -one- copy of last night's mail. If you are talking about some -other- birthday demon (you mentioned XX in your bug report), why complain to Bug-MAIL and Bug-Random-Program at MC?  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 26 Oct 87 12:15:08 EST Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 26 Oct 87 12:13:00 EST Date: Mon, 26 Oct 87 12:13:29 EST From: Ray Hirschfeld Subject: happy birthday To: BUG-mail@MC.LCS.MIT.EDU, BUG-random-program@MC.LCS.MIT.EDU Message-ID: <275114.871026.RAY@AI.AI.MIT.EDU> I don't know quite where to send this, since I don't know where the birthday code lives, but I (and the others on the XX happy-birthday list) received 325 copies of the birthday notification yesterday. I wouldn't be surprised if the fellow who's birthday it was got 325 cards as well. It's very suggestive that this happened around the time of the time change. The OZ birthday wizard didn't do the same thing, but I think it runs a couple of hours later. Ray  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 24 Oct 87 17:21:18 EDT Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 24 Oct 87 17:19:59 EDT Date: Sat, 24 Oct 87 17:20:16 EDT From: Alan Bawden Subject: eeeehhhh!!!! To: SRA@XX.LCS.MIT.EDU cc: BUG-COMSAT@MC.LCS.MIT.EDU, POSTMASTER@MC.LCS.MIT.EDU In-reply-to: Msg of Fri 23 Oct 1987 16:20 EDT from Rob Austein Message-ID: <274189.871024.ALAN@AI.AI.MIT.EDU> Date: Fri, 23 Oct 1987 16:20 EDT From: Rob Austein Date: Friday, 23 October 1987 16:06-EDT From: Alan Bawden The following is going to happen more and more until we get COMSAT to not insist on parsing hostnames at the time the NAMES file is compiled (and also at the time MAIL files are processed). Um, how will this help? When J. Random User wants to change a mailing list, he won't be effected by changes to the hostname-to-IPaddr since the last time someone changed the file. This seems like a fairly simple point to me. Why are you puzzled? Am I overlooking something? I'm just saying that the current situation where a failure to turn a hostname into a number is treated as an instantly fatal error is becoming an increasing screw (even -without- a domain resolver). Given COMSAT's current behavior with temporary errors, we might well find the messages still in the queue three years from now and COMSAT still waiting for somebody to put the names back into the host tables.... Do we really believe that COMSAT is currently broken with respect to -all- temporaty errors? I thought we had only seen this in the "IOC error" case. (Why doesn't it tell us -what- IOC error I wonder?) I don't see any reason to suppose that the temporary error of not being able to parse a hostname shouldn't cause a timeout after some reasonable period. It's better than that. It didn't change to anything, it just dropped all its service fields except IP/GW (see XX: HOSTS; HOSTS NIC). We long ago got to the point where the HAKHST.TECO code has to remove anything that doesn't claim to support TCP/SMTP or TCP/TELNET in order to keep the table size down (and at that it's not enough, there are more pruning criteria, and it's still just this side of explosion). Well, if I can get this thesis proposal finished I might get back to the KCC project and then we can get around to eliminating this problem on ITS once and for all. Of course the changes to COMSAT I was just talking about have to be done as well, and probably should be done -first-.  Date: Fri, 23 Oct 87 17:15:34 EDT From: David Vinayak Wallace Subject: eeeehhhh!!!! (host table frotzed?) To: BUG-MAIL@AI.AI.MIT.EDU cc: ALAN@MC.LCS.MIT.EDU In-reply-to: Msg of Fri 23 Oct 87 16:06:26 EDT from Alan Bawden Message-ID: <273745.871023.GUMBY@AI.AI.MIT.EDU> (This is a host-table bug too, but I don't think it's appropriate for info-hosts, no matter what ai:syshst;-read- -this- says. This should get all the guilty parties anyway!) Date: Fri, 23 Oct 87 16:06:26 EDT From: Alan Bawden [...] In addition, I can't figure out what the heck CS.ROCHESTER.EDU changed its hosttable name -to-, so I can put this forwarding entry back. MC:.MAIL.;NAMED ERR678 contains: --L1957 EVAL error: Error while processing attribute "EQV-LIST" Bad SITE spec - "@CS.ROCHESTER.EDU" In list: (RAILROAD (EQV-LIST (RAILROAD @CS.ROCHESTER.EDU))) --L1958 EVAL error: Error while processing attribute "EQV-LIST" Bad SITE spec - "@CS.ROCHESTER.EDU" In list: (RAILROAD-REQUEST (EQV-LIST (Railroad-Request @CS.ROCHESTER.EDU))) I went to see if I could figure out what happened by comparing an old NIC host table with a new one. Note this: From: 14-Oct-87 Version number 681: HOST : 10.0.0.15, 192.5.53.209, 192.5.37.209 : CS.ROCHESTER.EDU,ROCHESTER.ARPA : VAX-11/750 : UNIX : TCP/TELNET,TCP/FTP,TCP/SMTP,UDP,UDP/DOMAIN : From: 21-Oct-87 Version number 682: HOST : 10.0.0.15, 192.5.53.209 : CS.ROCHESTER.EDU,ROCHESTER.ARPA : VAX-11/750 : UNIX : IP/GW : 22-Oct-87 Version number 683 is the same as 682. This seems fairly straightforward, so why doesn't AI know about this host under either name any more? I did a SRCCOM of the host tables and looked for other changes; everything appears (except milnet hosts -- are they stripped from the host table). What's going on?  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 23 Oct 87 16:24:43 EDT Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 23 Oct 87 16:21:18 EDT Date: Fri, 23 Oct 1987 16:20 EDT Message-ID: From: Rob Austein To: Alan Bawden Cc: BUG-COMSAT@MC.LCS.MIT.EDU, POSTMASTER@MC.LCS.MIT.EDU Subject: eeeehhhh!!!! In-reply-to: Msg of 23 Oct 1987 16:06-EDT from Alan Bawden Date: Friday, 23 October 1987 16:06-EDT From: Alan Bawden The following is going to happen more and more until we get COMSAT to not insist on parsing hostnames at the time the NAMES file is compiled (and also at the time MAIL files are processed). Um, how will this help? Given COMSAT's current behavior with temporary errors, we might well find the messages still in the queue three years from now and COMSAT still waiting for somebody to put the names back into the host tables.... I don't know who did the commenting out here, but I sympathize with his or her frustration, since all they did was change -something- -else- in the NAMES file, and they had to suffer from the fact that the host table had just changed. In addition, I can't figure out what the heck CS.ROCHESTER.EDU changed its hosttable name -to-, so I can put this forwarding entry back. It's better than that. It didn't change to anything, it just dropped all its service fields except IP/GW (see XX: HOSTS; HOSTS NIC). We long ago got to the point where the HAKHST.TECO code has to remove anything that doesn't claim to support TCP/SMTP or TCP/TELNET in order to keep the table size down (and at that it's not enough, there are more pruning criteria, and it's still just this side of explosion). Could I interest you in two tin cans and some string?  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 23 Oct 87 16:07:12 EDT Date: Fri, 23 Oct 87 16:06:26 EDT From: Alan Bawden Subject: eeeehhhh!!!! To: BUG-COMSAT@MC.LCS.MIT.EDU, POSTMASTER@MC.LCS.MIT.EDU Message-ID: <315091.871023.ALAN@MC.LCS.MIT.EDU> The following is going to happen more and more until we get COMSAT to not insist on parsing hostnames at the time the NAMES file is compiled (and also at the time MAIL files are processed). I don't know who did the commenting out here, but I sympathize with his or her frustration, since all they did was change -something- -else- in the NAMES file, and they had to suffer from the fact that the host table had just changed. In addition, I can't figure out what the heck CS.ROCHESTER.EDU changed its hosttable name -to-, so I can put this forwarding entry back. ;COMPARISON OF DSK:.MAIL.;NAMES 678 AND DSK:.MAIL.;NAMES 679 ;OPTIONS ARE /3 **** FILE DSK:.MAIL.;NAMES 678, 4-398 (22172) (BUG-PDP11 (EQV-LIST CSTACY RMS)) **** FILE DSK:.MAIL.;NAMES 679, 4-398 (22172) *************** **** FILE DSK:.MAIL.;NAMES 678, 4-1827 (78169) (RAILROAD (EQV-LIST (RAILROAD @CS.ROCHESTER.EDU))) (RAILROAD-REQUEST (EQV-LIST (Railroad-Request @CS.ROCHESTER.EDU))) **** FILE DSK:.MAIL.;NAMES 679, 4-1826 (78134) ;;; @cs.rochester.edu lost 23 Oct 1987 -- see .mail.;named err678 ;(RAILROAD (EQV-LIST (RAILROAD @CS.ROCHESTER.EDU))) ;(RAILROAD-REQUEST (EQV-LIST (Railroad-Request @CS.ROCHESTER.EDU))) *************** MC:.MAIL.;NAMED ERR678 contains: --L1957 EVAL error: Error while processing attribute "EQV-LIST" Bad SITE spec - "@CS.ROCHESTER.EDU" In list: (RAILROAD (EQV-LIST (RAILROAD @CS.ROCHESTER.EDU))) --L1958 EVAL error: Error while processing attribute "EQV-LIST" Bad SITE spec - "@CS.ROCHESTER.EDU" In list: (RAILROAD-REQUEST (EQV-LIST (Railroad-Request @CS.ROCHESTER.EDU))) 2 Errors detected, file NAMES 678 Rejected.  Date: Mon, 19 Oct 87 15:32:02 EDT From: Alan Bawden Subject: [Gumby: WRING@CRVAX.SRI.COM] To: BUG-COMSAT@AI.AI.MIT.EDU cc: GUMBY@AI.AI.MIT.EDU, CUBE-LOVERS-REQUEST@AI.AI.MIT.EDU Message-ID: <271382.871019.ALAN@AI.AI.MIT.EDU> I have complained about the following COMSAT behavior in the past, but nobody has ever replied with an explanation of just what it means when COMSAT writes "IOC error" into its log file. Certainly if it can cause COMSAT to hold on to a message since July, then there is a bug -somewhere- to be fixed. I am reluctant to remove someone from my mailing list because of something that might be a COMSAT bug. Date: Sun, 18 Oct 87 22:40 EDT From: David Vinayak Wallace To: CUBE-LOVERS-REQUEST at AI.AI.MIT.EDU Re: WRING@CRVAX.SRI.COM I just killed (another) message for CRVAX.SRI.COM which comsat had been trying to send since JULY! I say another because there's a comment in the file which indicates that this happend once before. Perhaps you might want to take this person off? It seems that COMSAT keeps getting some sort of IOC error while sending the message. However, despite what the code attempts to do, this doesn't get flagged as a temporary error. I have been unable to to connect to the machine at all, so I assume this IOC is a timeout. 042817 Unqueueing to host CRVAX.SRI.COM 042817 ICP->CRVAX.SRI.COM (TCP-SMTP) 042823 QID=<235310.870730@AI.AI.MIT.EDU> 042823 TO->WRING ...NTMSND IOC error --- CRVAX.SRI.COM: failure cnt 0 <235310.870730@AI.AI.MIT.EDU> 30 JUL 1987 1551 EDT hoey @NRL-AIC.ARPA 12214 S: Planar positions of -> WRING at CRVAX.SRI.COM --- Received: from nrl-aic.ARPA (TCP 3200200010) by AI.AI.MIT.EDU 30 Jul 87 15:51:13 EDT Return-Path: Received: Thu, 30 Jul 87 15:47:50 edt by nrl-aic.ARPA id AA22816 Date: 30 Jul 1987 15:46:10 EDT (Thu) From: Dan Hoey Subject: Planar positions of Rubik's Magic To: Cube-Lovers@AI.AI.MIT.EDU Message-Id: <554672771/hoey@nrl-aic> ...  Date: Mon, 5 Oct 87 14:28:12 EDT From: "Pandora B. Berman" Subject: communication with a janet address To: dzf@BOURBAKI.MIT.EDU cc: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <264800.871005.CENT@AI.AI.MIT.EDU> dzf@BOURBAKI.MIT.EDU 09/29/87 17:03:25 Re: communication with a janet address To: bboard@mc Does anyone know how to reach a janet address in Britain, namel uk.ac.cam.phx which is a computer at Cambridge Univ.? Please reply if you can help. dan freedman in the UK, for reasons i don't understand but which are probably political rather than technical, they reverse their domain-style internet addresses. thus, what they call UK.AC.CAM.PHX, on this side of the atlantic we would refer to as PHX.CAM.AC.UK. the internet host table here does not recognize this host name. however, you should not give up hope. the host NSS.CS.UCL.AC.UK -is- known, so you should be able to send your mail indirectly through there: username%PHX.CAM.CA.UK@NSS.CS.UCL.AC.UK or username%UK.AC.CAM.PHX@NSS.CS.UCL.AC.UK -- i'm not sure which will work, as it depends on how NSS parses and reformats the header. good luck.  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 24 Sep 87 15:53:28 EDT Date: Thu, 24 Sep 1987 15:46 EDT Message-ID: From: Rob Austein To: Hostmaster@SRI-NIC.ARPA Cc: BUG-MAIL@AI.AI.MIT.EDU, Jonathan A Rees Subject: [jeff%aiva.edinburgh.ac.uk: address change] In-reply-to: Msg of 24 Sep 1987 14:37-EDT from David A. Moon Hi. What happened to the host entry for NSS.CS.UCL.AC.UK? I know that it changed its name (it used to be CS.UCL.AC.UK with nickname NSS.CS.UCL.AC.UK), but now it seems to have vanished completely. Is this intentional? If so, OK, but I need to know what to tell users. I'm also having trouble connecting to the UK domain nameservers, but that's probably just the usual daytime arpanet lossage. Thanks. --Rob  Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 20024224620) by AI.AI.MIT.EDU 24 Sep 87 14:45:37 EDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 240691; Thu 24-Sep-87 14:38:11 EDT Date: Thu, 24 Sep 87 14:37 EDT From: David A. Moon Subject: [jeff%aiva.edinburgh.ac.uk: address change] To: Jonathan A Rees cc: BUG-MAIL@AI.AI.MIT.EDU In-Reply-To: <259664.870924.JAR@AI.AI.MIT.EDU> Message-ID: <870924143753.0.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Thu, 24 Sep 87 14:35:43 EDT From: Jonathan A Rees Anyone know how I can get mail to the UK? :host nss.cs.ucl.ac.uk and :host cs.ucl.ac.uk both fail. The latter, at least, used to work. Use % to send your mail through a machine that has real domain support, such as Reagan or XX. ITS only has fake domain support at present.  Date: Thu, 24 Sep 87 14:35:43 EDT From: Jonathan A Rees Subject: [jeff%aiva.edinburgh.ac.uk: address change] To: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <259664.870924.JAR@AI.AI.MIT.EDU> Anyone know how I can get mail to the UK? :host nss.cs.ucl.ac.uk and :host cs.ucl.ac.uk both fail. The latter, at least, used to work. - Jonathan Date: Thu, 10 Sep 87 16:13:53 -0100 From: Jeff Dalton To: info-clscheme-request at mc.lcs.mit.edu Re: address change The cs.ucl part of my address should now be nss.cs.ucl. The old form is scheduled to stop working Sept 16th. The full address is: J.Dalton%uk.ac.ed@nss.cs.ucl.ac.uk Jeff Dalton, JANET: J.Dalton@uk.ac.ed AI Applications Institute, ARPA: J.Dalton%uk.ac.ed@nss.cs.ucl.ac.uk Edinburgh University. UUCP: ...!ukc!ed.ac.uk!J.Dalton  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 17 Sep 87 02:35:21 EDT Received: from JONES.AI.MIT.EDU by XX.LCS.MIT.EDU with Chaos/SMTP; Thu 17 Sep 87 02:24:24-EDT Date: Thu, 17 Sep 87 02:29 EDT From: David Vinayak Wallace Subject: unfeatureful handling of disk full To: bug-mail@AI.AI.MIT.EDU Message-ID: <870917022902.9.GUMBY@JONES.AI.MIT.EDU> AI's disk was full and comsat barphed, which resulted in three of these in the dead-letter office. This should be handled more gracefully. ----- Forwarded message follows ----- Date: Wed, 16 Sep 87 09:53:04 EDT From: Communications Satellite Subject: Msg of Monday, 14 September 1987 23:09-EDT To: NET-ORIGIN@AI.AI.MIT.EDU Message-ID: <255580.870916@AI.AI.MIT.EDU> FAILED: PLUKEL at AI.AI.MIT.EDU; I gave up on sending this after 201 "temporary" errors. Failed message follows:  Date: Tue, 1 Sep 87 07:27:11 EDT From: Alan Bawden Subject: Todays news To: POOR-MX@AI.AI.MIT.EDU cc: BUG-COMSAT@AI.AI.MIT.EDU Message-ID: <248911.870901.ALAN@AI.AI.MIT.EDU> Yesterday MX ate part of the DRAGON directory and -all- of the .MAIL. directory. Presumably this is caused by more of the blocks-of-zeros lossage. I didn't bother to bring ITS back up, since I didn't see any reason to destroy more of the filesystem without fixing the hardware problem. (.MAIL. really is totally gone. It looks like the part of the directory containing all of the file blocks got zeroed, and then ITS ran for a wrile while mail servers created new MAIL > files. There is also a STATS 1 file, although I can't imagine how COMSAT could have continued to run for long with an empty directory.)  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 31 Aug 87 18:04:34 EDT Date: Mon, 31 Aug 1987 17:56 EDT Message-ID: From: Rob Austein To: David Chapman Cc: BUG-MAIL@AI.AI.MIT.EDU In-reply-to: Msg of 30 Aug 1987 17:11-EDT from David Chapman Date: Sunday, 30 August 1987 17:11-EDT From: David Chapman To: BUG-MAIL@AI.AI.MIT.EDU iwbi there were an equivalent of 20X's top-level mmailbox so you could see where comsat thinks mail would go. Presumably it wouldn't be hard to write this.. You might presume this. You'd also be wrong.  Date: Sun, 30 Aug 87 17:11:29 EDT From: David Chapman To: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <248375.870830.ZVONA@AI.AI.MIT.EDU> iwbi there were an equivalent of 20X's top-level mmailbox so you could see where comsat thinks mail would go. Presumably it wouldn't be hard to write this.  Received: from hub.ucsb.edu.ucsb (TCP 20033614050) by AI.AI.MIT.EDU 26 Aug 87 15:23:05 EDT Received: from by hub.ucsb.edu.ucsb (5.51) id AA23161; Wed, 26 Aug 87 12:15:24 PDT Posted-Date: Wed, 26 Aug 87 12:15:22 PDT From: postmaster@hub.ucsb.edu Organization: Center for Computational Sciences and Engineering To: Bug-COMSAT@AI.AI.MIT.EDU Cc: postmaster, Postmaster@AI.AI.MIT.EDU Subject: Re: A little problem. In-Reply-To: Your message of Wed, 26 Aug 87 14:01:00 EDT. Lyric: From safety... To where? Date: Wed, 26 Aug 87 12:15:22 PDT Sender: toad@hub.ucsb.edu > Ahem. I'll let this slide because the long-time Postmaster@AI handed > in her keys a few weeks ago, leaving me holding the bag. I think. Well, well, well, isn't nice to have extra work heaped on? > For some reason COMSAT didn't dequeue the message upon receiving the > 554 error code. [Maybe this is that loss-of-state bug that Moon found > and keeps citing in the hopes somebody will fix?] > Anyway, I manually dequeued the message and enclose it below. > --Rob Austein (for Postmaster@AI.AI.MIT.EDU) Yeah, that could indeed be the cause of it. Odd though; it sure must be an erratic bug. At least we've never seen it rear its ugly head 'round these parts before. Anyways, thanks for clearing it out. I'll keep an eye out for it again. So long, Tom  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 26 Aug 87 14:03:54 EDT Date: Wed, 26 Aug 1987 14:01 EDT Message-ID: From: Rob Austein To: Postmaster@HUB.UCSB.EDU Cc: Postmaster@AI.AI.MIT.EDU, Bug-COMSAT@AI.AI.MIT.EDU Reply-To: Bug-COMSAT@AI.AI.MIT.EDU Subject: A little problem. Date: Wednesday, 26 August 1987 11:08-EDT From: postmaster@hub.ucsb.edu Howdy Brother Postmaster, Ahem. I'll let this slide because the long-time Postmaster@AI handed in her keys a few weeks ago, leaving me holding the bag. I think. I seem to have a little problem at our site. Over the past weekend I received over 500 of the below messages -- each one apparently originating at AI.AI.MIT.EDU (at least that's what it looks like -- I can't seem to find a record of them originating here). Do you have any clue as to what might be causing this plague? Here's a sample of what COMSAT had in its log: 173307 Unqueueing to host HUB.UCSB.EDU 173308 ICP->HUB.UCSB.EDU (TCP-SMTP) 173313 QID=<244640.870820@AI.AI.MIT.EDU>...error for <>="554 buildaddr: error: no user", trying <>....init lost, R="554 buildaddr: error: no user" For some reason COMSAT didn't dequeue the message upon receiving the 554 error code. [Maybe this is that loss-of-state bug that Moon found a year ago and keeps citing in the hopes somebody will fix?] Anyway, I manually dequeued the message and enclose it below. --Rob Austein (for Postmaster@AI.AI.MIT.EDU) Date: Wednesday, 26 August 1987 13:45-EDT From: SRA@AI.AI.MIT.EDU Sender: SRA'@AI.AI.MIT.EDU Re: Request results Message deleted: Date: Thu, 20 Aug 87 20:19:13 EDT From: Communications Satellite Subject: Msg of Thursday, 20 August 1987 20:19-EDT To: "MAILER-DAEMON@hub.ucsb.edu"@HUB.UCSB.EDU Message-ID: <244640.870820@AI.AI.MIT.EDU> ============ A copy of your message is being returned, because: ============ "XX" at AI.AI.MIT.EDU is an unknown recipient. Will try sending to the file "USERS3;XX MAIL". ============ Failed message follows: ============ Received: from hub.ucsb.edu.ucsb (TCP 20033614050) by AI.AI.MIT.EDU 20 Aug 87 20:19:07 EDT Subject: Returned mail: User unknown Received: from by hub.ucsb.edu.ucsb (5.51) id AA20189; Thu, 20 Aug 87 17:18:59 PDT Date: Thu, 20 Aug 87 17:18:59 PDT From: Mail Delivery Subsystem Posted-Date: Thu, 20 Aug 87 17:18:59 PDT To: ----- Transcript of session follows ----- 550 qfAA20174: line 6: #... User unknown ----- Unsent message follows ----- Received: from AI.AI.MIT.EDU by hub.ucsb.edu.ucsb (5.51) id AA20174; Thu, 20 Aug 87 17:10:37 PDT Posted-Date: Thu, 20 Aug 87 19:54:13 EDT Date: Thu, 20 Aug 87 19:54:13 EDT From: xx@AI.AI.MIT.EDU Sender: ___035@AI.AI.MIT.EDU To: gihan@HUB.ucsb Message-Id: <244624.870820.___035@AI.AI.MIT.EDU> test 1652 end  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 21 Aug 87 19:21:18 EDT Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 21 Aug 87 18:47:13 EDT Date: Fri, 21 Aug 1987 18:43 EDT Message-ID: From: Rob Austein To: Info-Chives@XX.LCS.MIT.EDU Reply-To: Info-Chives-Request@XX.LCS.MIT.EDU cc: Info-KCC-Request@SRI-NIC.ARPA, Bug-COMSAT@MC.LCS.MIT.EDU Subject: Welcome to the INFO-CHIVES list (TOPS-20 domain resolver) [Bug-COMSAT and INFO-KCC-REQUEST are receiving this because there's some overlap of interests here. The ITS version isn't done yet, but we're working on it....] If you're receiving this message, it's because at one point you expressed an interest in the domain resolver code I've been developing. It's finally ready for people other than me to look at. CHIVES.EXE (the UDP resolver process) and the GTDOM% JSYS (the normal user interface) are finished, or at least functional enough to release. ZT (the zone transfer client) was written a long time ago and a lot of things have happened to the code since then, so it probably won't compile. I'll be fixing this Real Soon Now (I doubt it's a major job). For those who have had experience with the ISI GTDOM%, you can relax, the MIT GTDOM% is much lower profile, you don't have to hack PAGEM or anything hairy like that. The only non-trivial changes to existing monitor code is the addition of a few short accessor routines to IPCF.MAC and, if you're running under 5.4, retrofitting support for paged IPCF from monitor context (DEC supports this as of rel 6). All the stuff lives in XX: and child directories thereof, accessible via ANONYMOUS FTP. Documentation is a little scanty at the moment, there are -READ-.-THIS- and .DOC files scattered around hither and yon. GTDOM% has been tested somewhat under an MIT 5.4 monitor. It hasn't been used as the system resolver yet. It should be possible to bring GTDOM% up under 6.1 without too much trouble, but it hasn't been done yet because XX still runs 5.4 (this week). Please send mail to CHIVES-REQUEST@XX.LCS.MIT.EDU if you want to be on the alpha test mailing list (CHIVES-ALPHA@XX...). Also send mail if you no longer care about resolvers or 20s and want to be taken off all the lists, etcetera. I'm not sure if there will ever be a formal beta test version, not that many people seem to care. We'll see how it goes. Two things you should note before trying to obtain the code: (1) You need a current distribution of KCC (from SRI-NIC.ARPA). Contact INFO-KCC-REQUEST@SRI-NIC.ARPA for information about KCC. (2) Please note that the code IS copyrighted and has absolutely NO WARRANTY. This is to avoid having somebody try to sell the code back to me in a year or so and to avoid lawsuits. The copyright policy is spelled out in the file XX:COPYRIGHT.NOTICE; if you have problems with this, please get in touch with me about it and we'll see if we can work something out. Welcome to the future, TOPS-20 isn't quite dead yet....  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 8 Aug 87 20:12:57 EDT Received: from garp.mit.edu (TCP 2222000315) by MC.LCS.MIT.EDU 8 Aug 87 20:10:37 EDT Received: by garp.mit.edu; id AA06381; Sat, 8 Aug 87 20:06:08 EDT Date: Sat, 8 Aug 87 20:06:08 EDT From: henry@GARP.MIT.EDU (Henry Mensch) Posted-Date: Sat, 8 Aug 87 20:06:08 EDT Message-Id: <8708090006.AA06381@garp.mit.edu> To: postmaster@MC.LCS.MIT.EDU, bug-mail@MC.LCS.MIT.EDU Cc: postmaster@AI.AI.MIT.EDU Subject: mail lossage the .mail.;names > file has failed processing twice on MC ... it's barfing on lists I haven't even touched (mostly bad site specifications for SRI-KL.ARPA and SRI-STRIPE.ARPA). SRI-KL seems to have dropped it's ".ARPA" name, and SRI-STRIPE seems to be historical: 63 garp /users/henry --> whois sri-kl SRI International (SRI-KL) Information Systems Operations 333 Ravenswood Avenue Menlo Park, CA 94025 Hostname: KL.SRI.COM Nicknames: SRI.COM,STRIPE.SRI.COM Address: 10.1.0.2, 128.18.10.6 System: DEC-1090T running TOPS20 Host Administrator: Edwards, David L. (DLE6) DLE@KL.SRI.COM (415) 859-6136 TOPS-20 domain server To see the registered users of this host, repeat the command with a star ('*') in front. 64 garp /users/henry --> whois sri-stripe No match for "sri-stripe". I didn't attempt to fix anything; everything is left "as is." -- Henry Mensch /  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 4 Aug 87 16:33:12 EDT Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 4 Aug 87 16:17:34 EDT Date: Tue, 4 Aug 1987 16:12 EDT Message-ID: From: Rob Austein To: Richard Pavelle Cc: bug-mail@MC.LCS.MIT.EDU, Postmaster@UCBVAX.BERKELEY.EDU Reply-To: Postmaster@MC.LCS.MIT.EDU Subject: unable to respond In-reply-to: Msg of 4 Aug 1987 15:29-EDT from Richard Pavelle Date: Tuesday, 4 August 1987 15:29-EDT From: Richard Pavelle Date: Tuesday, 4 August 1987 06:26-EDT From: MAILER-DAEMON at ucbvax.Berkeley.EDU (Mail Delivery Subsystem) To: Re: Returned mail: Host unknown ----- Transcript of session follows ----- 550 ... Host unknown ----- Unsent message follows ----- Received: from AI.AI.MIT.EDU by ucbvax.Berkeley.EDU (5.58/1.27) id AA20981; Tue, 4 Aug 87 03:26:09 PDT Date: Tue, 4 Aug 87 06:25:47 EDT To: husc6!husc4!hadeishi@ucbvax.Berkeley.EDU Can someone tell me why the address to husc6!husc4!hadeishi@ucbvax.Berkeley.EDU does not work and what it should be changed to. Since the error message came from Berkeley's mailer, not MIT's, you should be asking Berkeley, hence the CC. Don't be surprised if the Berkeley people tell you that they don't know either, it's not really their problem. Perhaps you should try calling your correspondant on the telephone or some other low-tech method.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 4 Aug 87 16:05:07 EDT Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 4 AUG 87 15:40:57 EDT Date: Tue, 4 Aug 1987 15:29 EDT Message-ID: From: Richard Pavelle To: bug-mail@MC.LCS.MIT.EDU cc: rp%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU subject:unable to respond Date: Tuesday, 4 August 1987 06:26-EDT From: MAILER-DAEMON at ucbvax.Berkeley.EDU (Mail Delivery Subsystem) To: Re: Returned mail: Host unknown ----- Transcript of session follows ----- 550 ... Host unknown ----- Unsent message follows ----- Received: from AI.AI.MIT.EDU by ucbvax.Berkeley.EDU (5.58/1.27) id AA20981; Tue, 4 Aug 87 03:26:09 PDT Date: Tue, 4 Aug 87 06:25:47 EDT To: husc6!husc4!hadeishi@ucbvax.Berkeley.EDU Can someone tell me why the address to husc6!husc4!hadeishi@ucbvax.Berkeley.EDU does not work and what it should be changed to. Thanks.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 3 Aug 87 16:04:41 EDT Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 3 Aug 87 14:39:58 EDT Date: Mon, 3 Aug 1987 14:37 EDT Message-ID: From: Rob Austein To: henry@GARP.MIT.EDU (Henry Mensch) Cc: Bug-MAIL@MC.LCS.MIT.EDU Reply-To: Bug-MAIL@MC.LCS.MIT.EDU Subject: [COMSAT@MC.LCS.MIT.EDU: Msg of Monday, 3 August 1987 11:39-EDT] In-reply-to: Msg of 3 Aug 1987 12:43-EDT from henry@GARP.MIT.EDU (Henry Mensch) Date: Monday, 3 August 1987 12:43-EDT From: henry@GARP.MIT.EDU (Henry Mensch) Um, binde@rutgers.rutgers.edu *is* a known recipient; there's an accountn for binde on rutgers.rutgers.edu which forwards to red.rutgers.edu. What's the problem? "BINDE@RUTGERS.RUTGERS.EDU" at MC.LCS.MIT.EDU is an unknown recipient. The message is correct: MC.LCS.MIT.EDU doesn't know how to relay mail to "BINDE@RUTGERS.RUTGERS.EDU". RUTGERS.RUTGERS.EDU isn't in the NIC host table, and ITS doesn't have a domain resolver (yet (don't ask)). COMSAT's strange way of saying "unknown host" is a historical relic; see the BUG-MAIL archives if you really care why. BTW RED.RUTGERS.EDU -is- in the NIC table.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 3 Aug 87 12:54:04 EDT Received: from garp.mit.edu (TCP 2222000315) by MC.LCS.MIT.EDU 3 Aug 87 12:46:54 EDT Received: by garp.mit.edu; id AA01316; Mon, 3 Aug 87 12:43:22 EDT Date: Mon, 3 Aug 87 12:43:22 EDT From: henry@GARP.MIT.EDU (Henry Mensch) Posted-Date: Mon, 3 Aug 87 12:43:22 EDT Message-Id: <8708031643.AA01316@garp.mit.edu> To: bug-mail@MC.LCS.MIT.EDU Subject: [COMSAT@MC.LCS.MIT.EDU: Msg of Monday, 3 August 1987 11:39-EDT] Um, binde@rutgers.rutgers.edu *is* a known recipient; there's an accountn for binde on rutgers.rutgers.edu which forwards to red.rutgers.edu. What's the problem? Posted-Date: Mon, 3 Aug 87 11:39:33 EDT Received-Date: Mon, 3 Aug 87 11:36:23 EDT Date: Mon, 3 Aug 87 11:39:33 EDT From: Communications Satellite Subject: Msg of Monday, 3 August 1987 11:39-EDT To: "mail-men-request@GARP.MIT.EDU"@GARP.MIT.EDU ============ A copy of your message is being returned, because: ============ "BINDE@RUTGERS.RUTGERS.EDU" at MC.LCS.MIT.EDU is an unknown recipient. This name came from the expansion of MAIL-MEN-DIST ============ Failed message follows: ============ Received: from garp.mit.edu (TCP 2222000315) by MC.LCS.MIT.EDU 3 Aug 87 11:37:35 EDT Received: by garp.mit.edu; id AA00999; Mon, 3 Aug 87 11:30:43 EDT Comment: Header modified at GARP.MIT.EDU Precedence: bulk From: The Moderator Posted-Date: Mon, 3 Aug 87 11:33:04 edt Received-Date: Mon, 3 Aug 87 11:29:54 EDT Received: by andromeda.rutgers.edu; Mon, 3 Aug 87 11:33:04 edt Date: Mon, 3 Aug 87 11:33:04 edt Original-From: jwilliam@andromeda.rutgers.edu (John Williams) Message-Id: <8708031533.AA02687@andromeda.rutgers.edu> To: mail-men@GARP.MIT.EDU To all readers of mail-men: I'd like to introduce myself. I'm a relatively new reader and my name is John Williams. Although I will most likely be a ROM member for a while, I am interested in hearing how different men are adapting themselves and their lives to the new possibilities that are beginning to exist for men--redefinitions of traditional roles, reconsiderations of sexuality and sexual expression, nontraditional maleness as political identity. I'm also interested in the levels of conflict that continue to exist with regard to received notions of male identity as well as how these conflicts are successfully resolved. Another issue that is of interest to me is the nontraditional male in the traditional workplace--to what extent is such a coexistence possible? Are there inherent pressures in the workplace that will continue to reinforce traditional (destructive) male behaviors and attitudes? Some of these issues have been and are being discussed even as I write, and I look forward to reading more discussions of these issues. John Williams  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 22 Jul 87 19:48:27 EDT Date: Wed, 22 Jul 1987 19:21 EDT Message-ID: From: Rob Austein To: David Chapman Cc: BUG-MAIL@AI.AI.MIT.EDU In-reply-to: Msg of 22 Jul 1987 16:15-EDT from David Chapman Date: Wednesday, 22 July 1987 16:15-EDT From: David Chapman To: BUG-MAIL@AI.AI.MIT.EDU IWBNI the stats file showed the internet address of incoming mail. I sometimes get mail from hosts not in our table and can't reply to them; this would be a way to do so.. The STATS file has nothing to do with incoming mail, so this would be useless. The SMTP listener does log the host number (in octal) as part of the RECEIVED header it adds (and your BABYL automaticly filters out).  Date: Wed, 22 Jul 87 19:40:21 EDT From: David Vinayak Wallace Subject: mail host addresses To: ZVONA@AI.AI.MIT.EDU cc: BUG-MAIL@AI.AI.MIT.EDU In-reply-to: Msg of Wed 22 Jul 87 16:15:33 EDT from David Chapman Message-ID: <231094.870722.GUMBY@AI.AI.MIT.EDU> Date: Wed, 22 Jul 87 16:15:33 EDT From: David Chapman To: BUG-MAIL at AI.AI.MIT.EDU IWBNI the stats file showed the internet address of incoming mail. I sometimes get mail from hosts not in our table and can't reply to them; this would be a way to do so. Thanks to SRA the Received: line now contains this info (has for a while in case you have old messages you want to reply to).  Date: Wed, 22 Jul 87 16:15:33 EDT From: David Chapman To: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <230979.870722.ZVONA@AI.AI.MIT.EDU> IWBNI the stats file showed the internet address of incoming mail. I sometimes get mail from hosts not in our table and can't reply to them; this would be a way to do so.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 20 Jul 87 17:01:20 EDT Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 20 Jul 87 16:53:33 EDT Date: Mon, 20 Jul 1987 16:39 EDT Message-ID: From: Rob Austein To: Bug-COMSAT@MC.LCS.MIT.EDU, Bug-MM@XX.LCS.MIT.EDU Subject: A random idea I just had Perhaps COMSAT and MMAILR should have special code to reroute mail for FOO-REQUEST to POSTMASTER (or RANDOM-LIST-REQUEST) if FOO-REQUEST doesn't exist. Ie, treat -REQUEST addresses the same way BUG- addresses are treated, so that we can always tell the users to send complaints to FOO-REQUEST and they can trust the message to get someplace useful. This dovetails nicely with some of the recent discussion on HEADER-PEOPLE, and shouldn't be terribly hard to implement. Comments? --Rob  Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 20024224620) by AI.AI.MIT.EDU 20 Jul 87 13:00:25 EDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 195515; Mon 20-Jul-87 12:55:37 EDT Date: Mon, 20 Jul 87 12:55 EDT From: David A. Moon Subject: mail-men and MC To: Pandora B. Berman cc: henry@GARP.MIT.EDU, ZVONA@AI.AI.MIT.EDU, BUG-MAIL@AI.AI.MIT.EDU In-Reply-To: <228552.870717.CENT@AI.AI.MIT.EDU> Message-ID: <870720125532.4.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Fri, 17 Jul 87 01:07:50 EDT From: "Pandora B. Berman" Date: Wed, 15 Jul 87 09:58:00 EDT From: henry@GARP.MIT.EDU (Henry Mensch) To: zvona@AI.AI.MIT.EDU, cent@AI.AI.MIT.EDU Subject: mail-men and MC Well, I've set up a distribution point, and all seems OK so far (I haven't sent out a test message yet, but the mailer parsed the NAMES > file with no gripes so I figure things can't be too bad). Only problem I'm having now is that there seems to be mail on MC destined for GARP, only the SMTP process never seems to get past HELO MC.LCS.MIT.EDU (and this keeps happening, ad infinitum...) Can you look into this and kill off the job on the MC end, before this poor machine melts (there were about forty of these happening when I logged in this AM, which made for a load > 15.00 on garp). i killed the msg this evening. here it is: ---------- Date: Mon, 13 Jul 87 09:40:31 EDT From: The Moderator Sender: HCM@MC.LCS.MIT.EDU Subject: mail-men To: lee@CS.ROCHESTER.EDU cc: henry@GARP.MIT.EDU Message-ID: <258434.870713.HCM@MC.LCS.MIT.EDU> I'm so embarrassed -- I didn't have you on any of my lists, so you didn't get any of the messages for the past two months. They're available by anonymous FTP from GARP.MIT.EDU. I've put your address on the list; if you don't want the messages let me know. -- henry / ---------- this is a sample attempt to deliver it, from MC's COMSAT log: 155118 Unqueueing to host GARP.MIT.EDU 155119 ICP->GARP.MIT.EDU (TCP-SMTP) 155127 QID=<258434.870713.HCM@MC.LCS.MIT.EDU>...Timeout also, this is what happened when COMSAT killed the msg. as normal, it tried to deliver a copy back to the author, but it lost; i'm not sure why: 195632 InReq: 37 > 1; SPECS:{J:E}{CENT'}{CLAIMS-TO-BE:CENT}{TL=0.} 195632 Note: Special req:"KILL-MSG" 195633 CMSG ID=<260855.870716@MC.LCS.MIT.EDU> EXP->THE MODERATOR @1200600054::={IGNORED} The author was parsed as "THE MODERATOR " @ MIT-MC, and there is no one by that long name with a mailbox at MC. That's why it failed. I'm not sure why the From field was parsed that way; I gather the message was really sent from MIT-MC and the From field was forced to be that particular string; I suspect there is some bug in Comsat's handling of the particular way that that was done. Maybe Comsat should be sending it back to the Sent-by field in this case? 195634 CMSG EXP->DEAD-MAIL-RECEIPTS@1200600054::=((FILE [NUL:])@1200600054) 195635 Local->MC.LCS.MIT.EDU 195636 TO->[NUL:] 195636 All queued msgs gone for GARP.MIT.EDU ID=<260856.870716.CENT'@MC.LCS.MIT.EDU> EXP->CENT@1200600054::=(CENT@40700003130) 195638 ICP->AI.AI.MIT.EDU (CHAOS-SMTP) 195641 TO->CENT  Date: Fri, 17 Jul 87 01:07:50 EDT From: "Pandora B. Berman" Subject: mail-men and MC To: henry@GARP.MIT.EDU cc: ZVONA@AI.AI.MIT.EDU, BUG-MAIL@AI.AI.MIT.EDU Message-ID: <228552.870717.CENT@AI.AI.MIT.EDU> Date: Wed, 15 Jul 87 09:58:00 EDT From: henry@GARP.MIT.EDU (Henry Mensch) To: zvona@AI.AI.MIT.EDU, cent@AI.AI.MIT.EDU Subject: mail-men and MC Well, I've set up a distribution point, and all seems OK so far (I haven't sent out a test message yet, but the mailer parsed the NAMES > file with no gripes so I figure things can't be too bad). Only problem I'm having now is that there seems to be mail on MC destined for GARP, only the SMTP process never seems to get past HELO MC.LCS.MIT.EDU (and this keeps happening, ad infinitum...) Can you look into this and kill off the job on the MC end, before this poor machine melts (there were about forty of these happening when I logged in this AM, which made for a load > 15.00 on garp). i killed the msg this evening. here it is: ---------- Date: Mon, 13 Jul 87 09:40:31 EDT From: The Moderator Sender: HCM@MC.LCS.MIT.EDU Subject: mail-men To: lee@CS.ROCHESTER.EDU cc: henry@GARP.MIT.EDU Message-ID: <258434.870713.HCM@MC.LCS.MIT.EDU> I'm so embarrassed -- I didn't have you on any of my lists, so you didn't get any of the messages for the past two months. They're available by anonymous FTP from GARP.MIT.EDU. I've put your address on the list; if you don't want the messages let me know. -- henry / ---------- this is a sample attempt to deliver it, from MC's COMSAT log: 155118 Unqueueing to host GARP.MIT.EDU 155119 ICP->GARP.MIT.EDU (TCP-SMTP) 155127 QID=<258434.870713.HCM@MC.LCS.MIT.EDU>...Timeout also, this is what happened when COMSAT killed the msg. as normal, it tried to deliver a copy back to the author, but it lost; i'm not sure why: 195632 InReq: 37 > 1; SPECS:{J:E}{CENT'}{CLAIMS-TO-BE:CENT}{TL=0.} 195632 Note: Special req:"KILL-MSG" 195633 CMSG ID=<260855.870716@MC.LCS.MIT.EDU> EXP->THE MODERATOR @1200600054::={IGNORED} 195634 CMSG EXP->DEAD-MAIL-RECEIPTS@1200600054::=((FILE [NUL:])@1200600054) 195635 Local->MC.LCS.MIT.EDU 195636 TO->[NUL:] 195636 All queued msgs gone for GARP.MIT.EDU ID=<260856.870716.CENT'@MC.LCS.MIT.EDU> EXP->CENT@1200600054::=(CENT@40700003130) 195638 ICP->AI.AI.MIT.EDU (CHAOS-SMTP) 195641 TO->CENT  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 16 Jul 87 06:02:01 EDT Date: Thu 16 Jul 87 06:00:38-EDT From: Rob Austein Subject: Re: Comsat timed-out too quickly To: MLY@AI.AI.MIT.EDU cc: BUG-COMSAT@AI.AI.MIT.EDU In-Reply-To: <228035.870716.MLY@AI.AI.MIT.EDU> Message-ID: <12318780190.67.SRA@XX.LCS.MIT.EDU> Yeah, COMSAT started doing speed a year or so back after too many all nighters on the old MC. We think it's the result of some mods CStacy did to the scheduler code but have been unable to find anybody foolhardy\y\d\r\a\h\l\o\o\f brave enough to investigate in detail. -------  Date: Thu, 16 Jul 87 01:08:44 EDT From: Richard Mlynarik Subject: Comsat timed-out too quickly To: BUG-COMSAT@AI.AI.MIT.EDU Message-ID: <228035.870716.MLY@AI.AI.MIT.EDU> This message was only queued for about half a day before it was returned to me. Date: Mon, 13 Jul 87 11:09:29 EDT From: Communications Satellite To: MLY at AI.AI.MIT.EDU Re: Msg of Monday, 13 July 1987 00:03-EDT FAILED: BEE at SCRC-STONY-BROOK.ARPA; Host appears to be permanently down or not accepting mail. FAILED: CWH%ILA.Dialnet.Symbolics.COM at SCRC-STONY-BROOK.ARPA; Host appears to be permanently down or not accepting mail. FAILED: DCP at SCRC-STONY-BROOK.ARPA; Host appears to be permanently down or not accepting mail. FAILED: DLA at SCRC-STONY-BROOK.ARPA; Host appears to be permanently down or not accepting mail. FAILED: DLW at SCRC-STONY-BROOK.ARPA; Host appears to be permanently down or not accepting mail. FAILED: joseph at SCRC-STONY-BROOK.ARPA; Host appears to be permanently down or not accepting mail. FAILED: MMCM at SCRC-STONY-BROOK.ARPA; Host appears to be permanently down or not accepting mail. FAILED: Moon at SCRC-STONY-BROOK.ARPA; Host appears to be permanently down or not accepting mail. FAILED: rwg at SCRC-STONY-BROOK.ARPA; Host appears to be permanently down or not accepting mail. FAILED: TK at SCRC-STONY-BROOK.ARPA; Host appears to be permanently down or not accepting mail. Failed message follows: ------- Date: Mon, 13 Jul 87 00:03:33 EDT From: Richard Mlynarik Subject: Not conducive to editing. To: INFO-EXPLORER@AI.AI.MIT.EDU Message-ID: <226709.870713.MLY@AI.AI.MIT.EDU> [...]  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 15 Jul 87 19:48:39 EDT Date: Wed, 15 Jul 1987 19:47 EDT Message-ID: From: Rob Austein To: Alan Bawden Cc: BUG-COMSAT@AI.AI.MIT.EDU In-reply-to: Msg of 15 Jul 1987 16:29-EDT from Alan Bawden Date: Wednesday, 15 July 1987 16:29-EDT From: Alan Bawden I wish that COMSAT did -not- have the feature where it delivers mail to unrecognized user names into random MAIL files on the USERSn directories. It seems like it makes crap to clean up more often than it could possibly do anyone any good.. But Alan, how do you expect random unknown high school students in Virginia to receive their mail on our machines if you disable this?  Date: Wed, 15 Jul 87 16:29:42 EDT From: Alan Bawden To: BUG-COMSAT@AI.AI.MIT.EDU Message-ID: <227841.870715.ALAN@AI.AI.MIT.EDU> I wish that COMSAT di -not- have the feature where it delivers mail to unrecognized user names into random MAIL files on the USERSn directories. It seems like it makes crap to clean up more often than it could possibly do anyone any good.  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 3 Jul 87 03:24:32 EDT Date: Fri, 3 Jul 1987 03:25 EDT Message-ID: From: Rob Austein To: "Pandora B. Berman" Cc: BUG-MAIL@AI.AI.MIT.EDU, JAR@AI.AI.MIT.EDU Subject: more list lossage In-reply-to: Msg of 2 Jul 1987 22:39-EDT from "Pandora B. Berman" FYI. We have had problems before with Yale.ARPA. It runs broken TCP code (intermittently loses the ability to talk to anything but other unix machines) and a broken sendmail.cf file. I've pretty much given up on getting meaningful fixes from them, I don't think they care except when their own users complain. Of course, maybe you'll get lucky....  Date: Thu, 2 Jul 87 23:16:31 EDT From: Jonathan A Rees Subject: more list lossage To: CENT@AI.AI.MIT.EDU cc: BUG-MAIL@AI.AI.MIT.EDU In-reply-to: Msg of Thu 2 Jul 87 22:39:10 EDT from Pandora B. Berman Message-ID: <222982.870702.JAR@AI.AI.MIT.EDU> Sorry about this. There's nothing I can do about it personally besides forward it to Postmaster@yale.arpa -- I only maintain the non-Yale part of the T-Users, Scheme, and T-Discussion lists. The problem you reported a week or two ago seems to have been fixed, by removing the offending address from Yale's T-Users list -- but not by fixing the mailer, which is what they ought to have done. It looks like Yale's mail system is seriously broken. I'll give Yale a call next week. This is outrageous.  Date: Thu, 2 Jul 87 22:39:10 EDT From: "Pandora B. Berman" Subject: more list lossage To: JAR@AI.AI.MIT.EDU cc: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <222960.870702.CENT@AI.AI.MIT.EDU> on MC, .MAIL.;BADREQ T1 and T2 are two msgs i pulled out of the new mail when it became clear they were ping-ponging. it looks like the original problem has something to do with a T-USERS list, rather here or at Yale i'm not sure. please look into this and fix or refer to the proper authority; thanks.  Date: Wed, 1 Jul 87 22:08:37 EDT From: David Vinayak Wallace Subject: how to reply to unknown hosts? To: JAR@AI.AI.MIT.EDU cc: BUG-MAIL@AI.AI.MIT.EDU In-reply-to: Msg of Wed 1 Jul 87 11:52:25 EDT from Jonathan A Rees Message-ID: <222350.870701.GUMBY@AI.AI.MIT.EDU> Date: Wed, 1 Jul 87 11:52:25 EDT From: Jonathan A Rees AI doesn't know host "cel.fmc.com". How in general can I reply to Internet hosts whose addresss are unknown to the ITS's? This has happened to me often enough that a general mechanism seems desirable. E.g. does it work to send it using %'s via, say, Zermatt? I am lothe to support other mailers on a mailing list for comsat bugs, but I think that it's unlikely that COMSAT or the ITSs will be able to use the domain servers for a while to some. So I would suggest using XX (ei.e. via the %-kluge); it's got MMAILR which is also a good mailer, and a domain resolver. I would stay away from reagan and zermatt; the Symbolics mailer is notoriously unreliable, especially in this area.  Date: Wed, 1 Jul 87 11:52:25 EDT From: Jonathan A Rees Subject: how to reply to unknown hosts? To: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <222094.870701.JAR@AI.AI.MIT.EDU> AI doesn't know host "cel.fmc.com". How in general can I reply to Internet hosts whose addresss are unknown to the ITS's? This has happened to me often enough that a general mechanism seems desirable. E.g. does it work to send it using %'s via, say, Zermatt? It would be even nicer if COMSAT or whomever set up the From: field to somehow deal with this automatically, but I can understand why that would be difficult and/or undesirable. Thanks. Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 27 Jun 87 01:04:45 EDT Received: from ai.CEL.FMC.COM (TCP 1201400013) by MC.LCS.MIT.EDU 27 Jun 87 01:01:18 EDT Received: from unixb.CEL.FMC.COM (unixb.ARPA) by ai.CEL.FMC.COM with Sendmail (4.12/4.7) id AA25925; Fri, 26 Jun 87 22:01:01 pdt Received: by unixb.CEL.FMC.COM with Sendmail (4.12/4.7) id AA25954; Fri, 26 Jun 87 22:00:04 pdt From: raulefs@cel.fmc.com (Peter Raulefs) Message-Id: <8706270500.AA25954@unixb.CEL.FMC.COM> Date: 26 Jun 87 22:00:00 PDT (Fri) To: scheme-request@mc.lcs.mit.edu Cc: raulefs@cel.fmc.com Subject: add me to your list I would appreciate if you would add me to your list: raulefs@cel.fmc.com (Arpanet) Thank you!  Received: from DIAMOND.S4CC.Symbolics.COM (TCP 20024231403) by AI.AI.MIT.EDU 1 Jul 87 08:36:29 EDT Received: from KOYAANISQATSI.S4CC.Symbolics.COM (KOYAANISQATSI.S4CC.Symbolics.COM) by DIAMOND.S4CC.Symbolics.COM via INTERNET with SMTP id 101678; 1 Jul 87 08:31:26 EDT Date: Wed, 1 Jul 87 08:30 EDT From: David C. Plummer Subject: [DCP@QUABBIN.SCRC.Symbolics.COM: Ack: question about berkeley TCP/IP] To: bug-comsat@AI.AI.MIT.EDU Included-msgs: The message of 29 Jun 87 17:14 EDT from DCP@QUABBIN.SCRC.Symbolics.COM, <870629171438.1.DCP@KOYAANISQATSI.S4CC.Symbolics.COM> Included-References: The message of 29 Jun 87 14:48 EDT from LISTSERV%MARIST.BITNET@wiscvm.wisc.edu Message-ID: <870701083042.9.DCP@KOYAANISQATSI.S4CC.Symbolics.COM> I thought there was a mailer-jokes mailing list, but I can't find it on ITS. ============================== Date: Mon, 29 Jun 87 17:14 EDT From: David C. Plummer Subject: Ack: question about berkeley TCP/IP To: Revised List Processor cc: tcp-ip@SRI-NIC.ARPA In-Reply-To: The message of 29 Jun 87 14:48 EDT from Revised List Processor What is this crap, why are you sending it to me, and why should I give a damn about the internal state of your mailer? Are other people getting this stuff? Date: Mon, 29 Jun 1987 14:48 EDT From: Revised List Processor (1.5j) Statistics for TCPIP-L mailing (ARPA TCP-IP Discussion Redistribution): Total number of (non-local) outbound files: 7 Total number of outbound 80-chars records: 203 Total resulting network load (link.kbytes): 65.70 Date: Mon, 29 Jun 1987 14:48 EDT From: Revised List Processor (1.5j) Processing your mail (2099) for TCPIP-L...  Date: Mon, 29 Jun 87 00:56:10 EDT From: "Pandora B. Berman" Subject: MX:LISTS MSGS To: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <220966.870629.CENT@AI.AI.MIT.EDU> i think it's broken. i listed the queue, and though this file is 470 blocks long, only 2 msgs were given. i flushed them, and the file did not get updated. i know you feel the KL's mail service is going down the tubes, but it would be nice to clean it up a little as it goes.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 22 Jun 87 22:48:03 EDT Date: Mon, 22 Jun 87 22:45:32 EDT From: "Pandora B. Berman" Subject: lost mail To: JAR@MC.LCS.MIT.EDU cc: BUG-MAIL@MC.LCS.MIT.EDU Message-ID: <247518.870622.CENT@MC.LCS.MIT.EDU> please look at MC:.MAIL.;BADREQ 1. after you shuffle through the 13 blocks of MC and YALE not recognizing each other, you'll find that the original problem is a bad address on the T-USERS list. please fix this. thanks..  Date: Mon, 8 Jun 87 16:55:56 EDT From: "Leigh L. Klotz" To: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <211556.870608.KLOTZ@AI.AI.MIT.EDU> I have put an inquir forwarding address of KLOTZ-BERKELEY into my inquir entry. If I send mail to KLOTZ-BERKELEY, an eqv-list entry in the names file, it ge at Berkeley fine. If I send mail to KLOTZ@AI.AI.MIT.EDU from Berkeley, it comes back to me at the correct Berkeley address. However, if I do :MAIL KLOTZ from AI, it goes into my mail file on AI and does not get toerkeley.  Received: from Think.COM (TCP 1201000006) by AI.AI.MIT.EDU 5 Jun 87 11:03:39 EDT Received: from urania.think.com by Think.COM; Fri, 5 Jun 87 11:02:34 EDT Received: by urania.think.com; Fri, 5 Jun 87 11:02:31 EDT Date: Fri, 5 Jun 87 11:02:31 EDT From: bruce@Think.COM Message-Id: <8706051502.AA06974@urania.think.com> To: SRA@xx.lcs.mit.edu, CENT@ai.ai.mit.edu Cc: Postmaster@Think.COM, Bug-COMSAT@ai.ai.mit.edu, User-A@mc.lcs.mit.edu In-Reply-To: Rob Austein's message of Thu, 4 Jun 1987 23:24 EDT Subject: FTP changes on NAMES > lose big Sigh. I have not tracked down who did it, but it can only be one of several people. I am, however, sure how it happened. We have been having problems with ftp connections via our chaos TCP server, which runs on our gateway, Zarathustra.Think.COM. Evidently someone was pulling NAMES into a lispm zmacs buffer and writing it out from there via that server. Sometimes it gets out of sync on write and breaks the connection. As the maintainer of that software, I take full responsibility for the TCP server bug. It was going to be retired in the next few days anyway. Whoever was editing such a crucial file remotely shouldn't have been. I never change NAMES other than from an ITS machine. I will make it very clear why this is a bad idea in a general announcement here. My apologies. --Bruce Nemnich, Thinking Machines Corporation, Cambridge, MA bruce@think.com, seismo!think!bruce, bjn@mitvma.bitnet; +1 617 876 1111  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 4 Jun 87 23:27:31 EDT Date: Thu, 4 Jun 1987 23:24 EDT Message-ID: From: Rob Austein To: Postmaster@THINK.COM Cc: Bug-COMSAT@AI.AI.MIT.EDU, User-A@MC.LCS.MIT.EDU Subject: FTP changes on NAMES > lose big In-reply-to: Msg of 4 Jun 1987 22:03-EDT from "Pandora B. Berman" [Bug-COMSAT stuff] The BADREQ files were indeed around last night. There's nothing obvious wrong with them, I was going to requeue them but forgot. There was a good NAMES > file around at the time I saw them. I agree that the business of not reading new NAMES > files right away is a bug. I don't know how easy it would be to fix (it seems like it should be easy, but I just bet you have to mess with COMSAT's scheduler to do it, in which case it is probably non-trivial). [User-A stuff: Author now dons ARPANET Host Technical Liaison hat] Would somebody at THINK explain to me just why people at TMC seem to regularly screw around with the mailer on an MIT machine? I mean, not to be rude or anything, but this isn't the first time we've lost due to somebody at THINK demonstrating completely irresponsible behavior wrt MC. I have no objection to non-MIT people using MC for its designated purpose, but they had damned well better be willing to be accountable for their actions; this includes checking for damage when a fileserver connection breaks while twiddling a critical file. I am also disturbed by the lack of courtesy displayed here. If this person had asked us we would have told him/her about the dangers of updating NAMES > via FTP. If this person had even taken the trouble to read the file MC:ACOUNT;TURIST POLICY (as suggested in the comments at the head of NAMES >) s/he would have known not to update via FTP. So it's pretty clear that this was some unsollicited random taking advantage of our (ideologically motivated) public-write filesystem. Doing this is mildly rude; doing this, breaking something, and neither telling anybody nor cleaning up is grounds for declaring this luser persona non gratia. To be blunt, I want to know who, I want to know why, and I want to know what TMC proposes to do to keep this from happening again. Preferably before I get annoyed enough to turn off SMTP and FTP access to MC from your machines. Thanks. --Rob  Date: Thu, 4 Jun 87 22:03:04 EDT From: "Pandora B. Berman" Subject: FTP changes on NAMES > lose big To: BUG-MAIL@AI.AI.MIT.EDU cc: postmaster@THINK.COM Message-ID: <210006.870604.CENT@AI.AI.MIT.EDU> MC COMSAT was in a very sorry state when i just looked at it. at just past 3pm today, someone from over the net wrote several copies of NAMES >. all of them were blank except for one (unfortunately not the last one) which was a one-line complaint about connection being dropped. unhappily, when COMSAT got around to compiling the last one (they all came within a few minutes, so when COMSAT came up for air it grabbed the last one), it decided that a -completely empty- file compiles correctly. so all this afternoon MC has been dropping some mail on the floor -- anything addressed for MC with no forwarding through INQUIR (stuff explicitly addressed for elsewhere, or which had forwardings in inquir entries, was transmitted OK). a lot of this has been DEAD-FLAMES and FONER-MAGAZINES but some of it was real, and will be missed by the folks it was meant for. i fixed the problem by copying the last NAMES from before this spate to NAMES >; COMSAT didn't seem interested in compiling that, so i modified it and wrote it out again, and that worked. i will here reiterate a bug i have noticed before: Once Upon A Time, when a new NAMES file occurred, COMSAT would crunch it down as soon as it finished what it was immediately working on -- current new msg or queued msg or failing attempt to contact foreign host. now, however, COMSAT appears to wait an indeterminate time before processing new NAMES files, and in the mean time continues to operate as if the LIST EQV it's holding is the latest, greatest thing. this is a major loss, and should be fixed. there are a bunch of BADREQ files hanging around; actually most of them look like they're from yesterday morning, but they should be investigated. POSTMASTER@THINK: you are cc'd because your host is implicated. at the time these files were written to MC from across the net, there are several connections from THINK, and only from THINK, transferring files to MC shown on our console log. so it is highly probable that someone at THINK was trying -- unsuccessfully, as explained above -- to modify NAMES >, our mailing-lists file. as you might be able to guess, running with a broken copy of this file can cause major injury to mail in this general area; we're lucky i happened to check on things as soon as i did after the lossage (about 6 hours). please do what you can to figure out who perpetrated this, and inform said luser in no uncertain terms that modifying a NAMES > file by FTP (on any ITS, but especially MC) is not just asking to lose; it's asking for explosions.  Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 30002424620) by AI.AI.MIT.EDU 1 Jun 87 17:41:21 EDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 160900; Mon 1-Jun-87 17:38:25 EDT Date: Mon, 1 Jun 87 17:38 EDT From: David A. Moon Subject: SMTP serving SCRC-RIO-DE-JANEIRO To: Kent M. Pitman cc: BUG-COMSAT@AI.AI.MIT.EDU, CSTACY@AI.AI.MIT.EDU, JAR@AI.AI.MIT.EDU In-Reply-To: <208052.870601.KMP@AI.AI.MIT.EDU> References: <860911211535.2.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-ID: <870601173809.5.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Mon, 1 Jun 87 14:17:02 EDT From: "Kent M. Pitman" In COMSAT in NEX 355, Emacs 162, Teco 1171, ITS 1604 on MIT-AI: Rio (my 3600 at Symbolics) keeps SMTP serving MIT-AI. I finally popped over here to see what the problem was. This is from the stats file: 140607 Unqueueing to host SCRC-RIO-DE-JANEIRO 140608 ICP->SCRC-RIO-DE-JANEIRO (TCP-SMTP) 140610 QID=<206541.870528.JAR@AI.AI.MIT.EDU>... error for ="502 SOML and SAML not implemented.", trying <>....init lost, R="550 This host does not offer mail service." The reason for this is explained in the referenced message, sent in September 1986 to bug-comsat. After a year has gone by I'll probably fix it myself, but so far I've been too busy.  Date: Mon, 1 Jun 87 17:01:09 EDT From: "Jonathan A. Rees" Subject: SMTP serving SCRC-RIO-DE-JANEIRO To: KMP@AI.AI.MIT.EDU cc: BUG-COMSAT@AI.AI.MIT.EDU, CSTACY@AI.AI.MIT.EDU In-reply-to: Msg of Mon 1 Jun 87 14:17:02 EDT from Kent M. Pitman Message-ID: <208128.870601.JAR@AI.AI.MIT.EDU> Date: Mon, 1 Jun 87 14:17:02 EDT From: Kent M. Pitman 140607 Unqueueing to host SCRC-RIO-DE-JANEIRO 140608 ICP->SCRC-RIO-DE-JANEIRO (TCP-SMTP) 140610 QID=<206541.870528.JAR@AI.AI.MIT.EDU>... error for ="502 SOML and SAML not implemented.", trying <>....init lost, R="550 This host does not offer mail service." Additional info: I believe the situation resulted from my having done :QSEND KMP@RIO .... I noticed when I did this that my message got queued, which I thought sort of odd at the time, given that it was a QSEND and not mail.  Date: Mon, 1 Jun 87 14:17:02 EDT From: "Kent M. Pitman" Subject: SMTP serving SCRC-RIO-DE-JANEIRO To: BUG-COMSAT@AI.AI.MIT.EDU cc: KMP@AI.AI.MIT.EDU, CSTACY@AI.AI.MIT.EDU, JAR@AI.AI.MIT.EDU Message-ID: <208052.870601.KMP@AI.AI.MIT.EDU> In COMSAT in NEX 355, Emacs 162, Teco 1171, ITS 1604 on MIT-AI: Rio (my 3600 at Symbolics) keeps SMTP serving MIT-AI. I finally popped over here to see what the problem was. This is from the stats file: 140607 Unqueueing to host SCRC-RIO-DE-JANEIRO 140608 ICP->SCRC-RIO-DE-JANEIRO (TCP-SMTP) 140610 QID=<206541.870528.JAR@AI.AI.MIT.EDU>... error for ="502 SOML and SAML not implemented.", trying <>....init lost, R="550 This host does not offer mail service."  Date: Sat, 30 May 87 13:10:03 EDT From: Jon Solomon To: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <207433.870530.JSOL@AI.AI.MIT.EDU> There is a message in AI's queue that is stuck in its attempt to deliver to BU-CS.BU.EDU. Mail to BUIT1.BU.EDU seems fine, but before we start worrying about whether or not our sendmail is fukt, I'd like to see a copy of the mail that is first in the queue for BU-CS.BU.EDU.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 12 May 87 21:00:35 EDT Received: from PREP.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 12 MAY 87 20:59:13 EDT Received: by PREP.AI.MIT.EDU; Tue, 12 May 87 20:56:48 EDT Date: Tue, 12 May 87 20:56:48 EDT From: tower@PREP.AI.MIT.EDU (Leonard H. Tower Jr.) To: SRA@XX.LCS.MIT.EDU Cc: Bug-MAIL@MC.LCS.MIT.EDU In-Reply-To: Rob Austein's message of Tue 12 May 87 13:59:56-EDT <12301828084.34.SRA@XX.LCS.MIT.EDU> Subject: MC:.MAIL.;NAMED ERR506 Reply-To: tower@prep.ai.mit.edu Organization: Project GNU, Free Software Foundation, 1000 Mass. Ave., Cambridge, MA 02138, USA +1 (617) 876-3296 Home: 36 Porter Street, Somerville, MA 02143, USA +1 (617) 623-7739 Date: Tue 12 May 87 13:59:56-EDT From: Rob Austein Date: Tue, 12 May 87 11:43:11 EDT From: tower@PREP.AI.MIT.EDU (Leonard H. Tower Jr.) --L2155 EVAL error: Error while processing attribute "EQV-LIST" Bad SITE spec - "@GLACIER.STANFORD.EDU" In list: (EAK (R-OPTION NOQC) ; Sender options (EQV-LIST (EAK-M) (EAKCC) ("mips!earl" @GLACIER.STANFORD.EDU))) 1 Errors detected, file NAMES 506 Rejected. I was tempted to delete the offending address, but GLACIER.STANFORD.EDU is a valid host name. Sez who? It's not in the host tables any more, and at the moment that's all MC knows how to use. ------- One can finger glacier from prep, which implies that name servers recognize it. If mc can't recognize it ... -len  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 12 May 87 14:31:57 EDT Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 12 May 87 14:04:32 EDT Date: Tue 12 May 87 13:59:56-EDT From: Rob Austein Subject: MC:.MAIL.;NAMED ERR506 To: tower@PREP.AI.MIT.EDU cc: Bug-MAIL@MC.LCS.MIT.EDU In-Reply-To: Message from "tower@PREP.AI.MIT.EDU (Leonard H. Tower Jr.)" of Tue 12 May 87 11:42:49-EDT Message-ID: <12301828084.34.SRA@XX.LCS.MIT.EDU> Date: Tue, 12 May 87 11:43:11 EDT From: tower@PREP.AI.MIT.EDU (Leonard H. Tower Jr.) --L2155 EVAL error: Error while processing attribute "EQV-LIST" Bad SITE spec - "@GLACIER.STANFORD.EDU" In list: (EAK (R-OPTION NOQC) ; Sender options (EQV-LIST (EAK-M) (EAKCC) ("mips!earl" @GLACIER.STANFORD.EDU))) 1 Errors detected, file NAMES 506 Rejected. I was tempted to delete the offending address, but GLACIER.STANFORD.EDU is a valid host name. Sez who? It's not in the host tables any more, and at the moment that's all MC knows how to use. -------  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 12 May 87 11:46:21 EDT Received: from PREP.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 12 MAY 87 11:45:20 EDT Received: by PREP.AI.MIT.EDU; Tue, 12 May 87 11:43:11 EDT Date: Tue, 12 May 87 11:43:11 EDT From: tower@PREP.AI.MIT.EDU (Leonard H. Tower Jr.) To: bug-mail@mc.lcs.mit.edu Subject: mc:.mail.;named Reply-To: tower@prep.ai.mit.edu Organization: Project GNU, Free Software Foundation, 1000 Mass. Ave., Cambridge, MA 02138, USA +1 (617) 876-3296 Home: 36 Porter Street, Somerville, MA 02143, USA +1 (617) 623-7739 contains: ---------------------------------------------------------------------- --L2155 EVAL error: Error while processing attribute "EQV-LIST" Bad SITE spec - "@GLACIER.STANFORD.EDU" In list: (EAK (R-OPTION NOQC) ; Sender options (EQV-LIST (EAK-M) (EAKCC) ("mips!earl" @GLACIER.STANFORD.EDU))) 1 Errors detected, file NAMES 506 Rejected. ---------------------------------------------------------------------- I was tempted to delete the offending address, but GLACIER.STANFORD.EDU is a valid host name. -len  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 23 Apr 87 22:04:47 EDT Date: Thu, 23 Apr 1987 22:01 EDT Message-ID: From: Rob Austein To: Alan Bawden Cc: BUG-COMSAT@AI.AI.MIT.EDU Subject: MSGS facility desires ITS-style header lines after EXPIRES: field. In-reply-to: Msg of 23 Apr 1987 06:18-EDT from Alan Bawden Date: Thursday, 23 April 1987 06:18-EDT From: Alan Bawden To: BUG-COMSAT@AI.AI.MIT.EDU Re: MSGS facility desires ITS-style header lines after EXPIRES: field. I do not understand why there are -some- messages on .MSGS. for which COMSAT has generated DESTRIB: and EXPIRES: fields, that do not have ITS-style header lines following. Messages sent to BBOARD@XX and Tech-Sq@XX as well as messages forwarded by Arpanet-BBoards-Request seem to be the most frequent offenders. Note that there are plenty of examples of messages where COMSAT has successfully generated an ITS-style header lines for bboard messages generated elsewhere with Network-style headers. There must be some kludge that works -most- of the time. Why not -all- of the time? It would be very nice if someone could figure out what causes this so that the DDT :MSGS command can be restored to full functionality. (Tonight I finally fixed :MSGS and :GMSGS to once again correctly find the DESTRIB: and EXPIRES: fields that had been hidden by Received: fields for the last couple years.) Based on the examples you cite, an examination of MC:.MSGS.;, and inside knowledge of the way mail arrives from XX & Arpanet-BBoards, I would guess that this is an envelope problem. The visible headers in a message from XX or in a message from Arpanet-BBoards are purely text as far as COMSAT is concerned, and do not necessarily have any relation at all to the list of recipents. (Mail from XX comes in via Chaos/SMTP, the other three 20s are still sending Chaos/MAIL.) I have never looked at the internals of COMSAT's :MSGS processing code (and with luck I never will), but I suspect that it depends on the older style of message generated by QMAIL where the distinction between envelope and content is blurred in the headers. At a guess, the kludge that tries to generate an ITS-style header by breaching the envelope is screwing up on XX & ANBB messages because they claim to be from chaosnet hosts (ANBB claims to be from GROSS.AI.MIT.EDU for obscure reasons) and thus the code thinks they should have old-style headers. Ick. It seems to me that trying to keep using the old ITS-style headers in messages is a lost cause. While I would not advocate discarding working code, if anybody is going to put a lot of work into making all the :MSGS stuff work again (a worthwhile project that might deserve reimplementation on other operating systems) I would strongly suggest having the new code understand RFC822 format headers. Oh, and for the most messed up DISTRIB: award I would nominate DISTRIB: *OZ:BOKEN.TXT.1%MIT-OZ --Rob  Date: Thu, 23 Apr 87 06:18:10 EDT From: Alan Bawden Subject: MSGS facility desires ITS-style header lines after EXPIRES: field. To: BUG-COMSAT@AI.AI.MIT.EDU Message-ID: <189549.870423.ALAN@AI.AI.MIT.EDU> I do not understand why there are -some- messages on .MSGS. for which COMSAT has generated DESTRIB: and EXPIRES: fields, that do not have ITS-style header lines following. Messages sent to BBOARD@XX and Tech-Sq@XX as well as messages forwarded by Arpanet-BBoards-Request seem to be the most frequent offenders. Note that there are plenty of examples of messages where COMSAT has successfully generated an ITS-style header lines for bboard messages generated elsewhere with Network-style headers. There must be some kludge that works -most- of the time. Why not -all- of the time? It would be very nice if someone could figure out what causes this so that the DDT :MSGS command can be restored to full functionality. (Tonight I finally fixed :MSGS and :GMSGS to once again correctly find the DESTRIB: and EXPIRES: fields that had been hidden by Received: fields for the last couple years.)  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 22 Apr 87 21:25:12 EDT Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 22 Apr 87 20:43:38 EDT Date: Wed, 22 Apr 1987 20:18 EDT Message-ID: From: Rob Austein To: jbs@EDDIE.MIT.EDU (Jeff Siegal) Cc: Bug-Mail@MC.LCS.MIT.EDU Subject: mailer bug? In-reply-to: Msg of 22 Apr 1987 20:09-EDT from jbs@EDDIE.MIT.EDU (Jeff Siegal) Date: Wednesday, 22 April 1987 20:09-EDT From: jbs@EDDIE.MIT.EDU (Jeff Siegal) To: sra@xx.lcs.mit.edu Re: mailer bug? Script started on Wed Apr 22 20:00:40 1987 eddie% sps -Aw|egrep 25812 | 25812 -AA25812 EDDIE.MIT.EDU: MAIL FROM:<@MC.LCS.MIT.EDU:"slk%VX.LCS.MIT.EDU eddie% script done on Wed Apr 22 20:01:58 1987 Do you know what is causing these damaged MAIL FROM: messages? I have seen it several times now, only from MC and (I think--don't remember for sure) once from XX. Due to a bug in the version of sendmail we are running (yes, I know I should update my sendmail...), either (or both) the unmatched " or the unmatched > causes an infinite loop, which is most annoying. Please send this stuff to Bug-MAIL, not to me personally. I don't know what causes those message and can't check MC's COMSAT log because COMSAT is currently delivering a message to DEAD-HEADS. I'd be very surprised if you were getting the same broken messages from both MC and XX; the mailers have nothing in common except the hardware and the spec that they are trying to implement.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 22 Apr 87 21:22:24 EDT Received: from EDDIE.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 22 APR 87 20:35:33 EDT Received: by EDDIE.MIT.EDU with sendmail-5.31/4.7 id ; Wed, 22 Apr 87 20:34:15 EDT Date: Wed, 22 Apr 87 20:34:15 EDT From: jbs@EDDIE.MIT.EDU (Jeff Siegal) To: SRA@XX.LCS.MIT.EDU, jbs@EDDIE.MIT.EDU Subject: Re: mailer bug? Cc: Bug-Mail@MC.LCS.MIT.EDU You're probably right. There was probably no message from XX, but the problem has happened several times from MC. Please let me know if you find anything  Date: Mon, 20 Apr 87 01:17:42 EDT From: "Pandora B. Berman" Subject: cent.cgp forwards wrong? To: rms%canna.kr@RELAY.CS.NET cc: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <187859.870420.CENT@AI.AI.MIT.EDU> Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 18 Apr 87 05:29:15 EDT Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 18 Apr 87 05:28:55 EDT Received: from relay2.cs.net by RELAY.CS.NET id ae23284; 18 Apr 87 4:27 EDT Received: from sorak.kaist.ac.kr by RELAY.CS.NET id br03880; 18 Apr 87 4:22 AST Received: by sorak.kaist.ac.kr (5.51/4.12) id AA19169; Sat, 18 Apr 87 01:56:50+0900 Received: by canna.kaist.ac.kr (1.1/SMI-3.0DEV3) id AA02999; Sat, 18 Apr 87 01:55:29 PST Date: Sat, 18 Apr 87 01:55:29 PST From: "Richard M. Stallman" To: CENT@MC.LCS.MIT.EDU Subject: cent.cgp forwards wrong? Date: Wed, 15 Apr 87 19:19:37 EDT From: "Pandora B. Berman" Date: Wed, 8 Apr 87 11:03:01 PST From: "Richard M. Stallman" To: cent@MC.LCS.MIT.EDU Reply-To: rms@PREP.AI.MIT.EDU Subject: cent.cgp forwards wrong? I keep trying to send a message to cent.cgp@oz.ai.mit.edu and I get this message mysteriously from mc in return. Perhaps there is an invalid forwarding specified on oz. Perhaps you can find out what is wrong and then get this message through. Date: Tue, 7 Apr 87 04:11:46 EDT From: Communications Satellite Subject: Msg of Tuesday, 7 April 1987 04:11-EDT To: "rms%canna.kr@RELAY.CS.NET"@RELAY.CS.NET ============ A copy of your message is being returned, because: ==== "CENT.CGP" at MC.LCS.MIT.EDU is an unknown recipient. ============ Failed message follows: ============ ...the other is wrong host: CENT.GGP is an address on OZ.AI.MIT.EDU, not on MC.LCS.MIT.EDU. I know this. (I have not yet forgotten the fact that user names on ITS cannot be eight characters long and normally do not contain periods.) In fact, this what I tried to tell you; but you believed MC rather than me. Please read my previous message carefully. you are right, i did not read your msg carefully enough. i did think it was odd that you (who certainly know better) seemed to expect a twenexish address to work on an ITS; i suppose i assumed it was some sort of confused RMS turist. I sent to ...@OZ. I did not write "MC" in the recipient name. I do not understand why MC claims that the message was addressed to cent.cgp@mc, because that was not what I did. The fact that MC is sending back a To: field that is changed incorrectly from what I specified is the problem I am reporting. I have no idea what machine is making the mistake, but I thought it might be a forwarder on OZ. Date: Tue, 7 Apr 87 12:32:19 PST From: "Richard M. Stallman" *** To: cent.cgp@mc.lcs.mit.edu *** altered by some machine (MC? OZ? csnet-relay?) Subject: Emacs on VMS [text of original msg omitted] COMSAT does not change headers in this fashion. nor, i am told, does MMAILR. the standard suspect in such cases is a UNIX. CSNET-RELAY gets enough traffic as a gateway that i would hope it doesn't mangle headers like this any more, but your mail from CANNA is running through at least 2 unices before it reaches there, so i am inclined to suspect them.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 18 Apr 87 14:17:36 EDT Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 18 Apr 87 14:17:03 EDT Date: Sat, 18 Apr 1987 14:13 EDT Message-ID: From: Rob Austein To: Bug-Cobol@XX.LCS.MIT.EDU, Bug-Cobol@WARD.CS.WASHINGTON.EDU, Bug-Random-Program@MC.LCS.MIT.EDU, Bug-Mail@MC.LCS.MIT.EDU cc: Mailer-Error-of-the-Day@MC.LCS.MIT.EDU, JNC@XX.LCS.MIT.EDU, JTW@XX.LCS.MIT.EDU, DHB@XX.LCS.MIT.EDU, JGD@XX.LCS.MIT.EDU, EWR@XX.LCS.MIT.EDU, Yoyos@XX.LCS.MIT.EDU Subject: One "Bug-" too many This has got to be one of the weirder error cascades I've found. It started when I got curious about who had added me to the INFO-COBOL list; I read the XX bboard and had no desire to receive it directly. Well, you see: - INFO-COBOL@CCC expands to "BUG-COBOL@WASHINGTON" (among others). Since CCC isn't on the Internet, it sends this along to MC. - As of two weeks ago (the NIC nickname flush), the name "WASHINGTON" is ambiguous acording to the silly algorithm COMSAT uses; it doesn't know that WASHINGTON.EDU or WASHINGTON.ARPA are the same host. - Due to the strange parsing COMSAT uses to handle things like the infamous "BUG-@" list, COMSAT didn't give up when it couldn't find a host named "WASHINGTON"; instead it mutated "BUG-COBOL@WASHINGTON" to "(BUG COBOL@WASHINGTON)". - Not finding any BUG- list for "COBOL@WASHINGTON", COMSAT did what it does with all homeless bug reports, and sent it to BUG-RANDOM-PROGRAM. Which list I happen to be on. INFO-COBOL-REQUEST, could you please change "BUG-COBOL@WASHINGTON" to "BUG-COBOL@WASHINGTON.EDU"? If you didn't hear about it already, the NIC removed ALL the nicknames without dots from the host tables, as of 1 April 87, so you should also check your list for any addresses that don't have domain format names. Yours in the ongoing support of lower-level languages, --Rob  Date: Wed, 15 Apr 87 22:17:11 EDT From: "Leigh L. Klotz" To: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <185461.870415.KLOTZ@AI.AI.MIT.EDU> When I do :M FOO.PA@XEROX Mail tells me MAIL error - Ambiguous site spec. "xerox"=>{XEROX.ARPA,XEROX.COM} Not knowing which I wanted, I did :HOST XEROX.ARPA and saw that they were the same. Is it hard for mail to figure out that all the choices are the same because it's using some different database or something?  Date: Wed, 15 Apr 87 19:52:40 EDT From: "Pandora B. Berman" Subject: phone msg To: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <185317.870415.CENT@AI.AI.MIT.EDU> Steve Rothwell from UMICH called; he is the postmaster there. they are having a problem with 821 Mail-from. they are receiving two consecutive colons, they think from MC (or from OZ?), which causes them to reject the msg. the last response they found from us on the subject (they thought it was from me, but i'm pretty sure i didn't say this) was a simple "it's your machine's fault"; i didn't have time to dig through the BUG-MAIL archives while he was on the phone, and afterwards i looked but couldn't find such a msg. last msgs to UMICH about mail problems seem to be talking with Chris Moore there. i told Steve that it was unlikely that COMSAT was causing the problem, although i'm not the final authority, and my guess was that some intermediate host was garbling it. he says he's not interested in pointing fingers, he just wants to help fix the problem; he said that 821 is for replying in case of error, so we're unlikely to have noticed the problem directly. his phone # is 313-763-4902. Rob, please talk to the nice man and try to help him figure out where the lossage is.  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 15 Apr 87 13:51:34 EDT Date: Wed, 15 Apr 1987 13:45 EDT Message-ID: From: Rob Austein To: Jonathan A Rees Cc: Bug-Mail@AI.AI.MIT.EDU, utzoo!henry%ai.toronto.edu@RELAY.CS.NET Subject: [utzoo!henry: toronto.edu] In-reply-to: Msg of 15 Apr 1987 11:26-EDT from Jonathan A Rees Date: Wednesday, 15 April 1987 11:26-EDT From: Jonathan A Rees To: SRA@AI.AI.MIT.EDU Please send this stuff to Bug-MAIL, not me personally, ok? You're the third person I've had to tell this to today, I may just stop answering until everybody gives up and leaves me alone.... Sorry to bother you again, but my ignorance on the subject of modern mail seems to be boundless. My question: is it reasonable for the "from" field of a message on Internet to contain a domain that is not known by the ITS's? If there is no bogosity on the sender's part (the people at "toronto.edu" claim they are in the right), how are the ITS's expected to be able to reply to such messages? Date: Tue, 14 Apr 87 19:14:52 EDT From: utzoo!henry at ai.toronto.edu > ...header is not valid because the From: and To: fields contain a domain > (ai.toronto.edu) which is not a known Internet domain... I don't know about the subdomain, but I am assured by the people involved that toronto.edu has been an official Internet domain for about a year now. This is ITS' fault. ITS doesn't have a domain resolver, and even it if did, COMSAT doesn't grok MX RRs. If you (well, I, it's a pain to do) query the domain system about Toronto.EDU, you find that it's delegated to the CSNET people. If you query about AI.Toronto.EDU you find out that CSNET-RELAY.ARPA offers to relay mail there for you. If we had a resolver and COMSAT knew what it was doing, this would cause COMSAT to send the mail off to CSNET-RELAY.ARPA and everybody'd be happy. But we don't so you aren't. If this were just lack of a resolver I'd tell you to use XX as a relay, but XX's mailer doesn't understand MX RRs yet either (operative word is yet, we do have plans to fix this). ITS will not have a resolver until a couple of things happen. One of them is that somebody (other than me) ports the KCC compiler to ITS. This has been discussed at length by the people we thought were likely to do it. Could I interest you in such a task? Didn't think so.... --Rob  Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 30002424620) by AI.AI.MIT.EDU 3 Apr 87 15:57:00 EST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 108637; Fri 3-Apr-87 15:58:50 EST Redistributed-date: Fri, 3 Apr 87 15:58 EST Redistributed-to: BUG-COMSAT@AI.AI.MIT.EDU, CENT@AI.AI.MIT.EDU Resent-Comments: Message retransmitted because it failed to go through the first time. Date: Mon, 30 Mar 87 14:12 EST From: Moon@STONY-BROOK.SCRC.Symbolics.COM Subject: MX COMSAT loses its lunch To: CENT@AI.AI.MIT.EDU cc: DJB@OZ.AI.MIT.EDU, BUG-COMSAT@AI.AI.MIT.EDU In-Reply-To: <175457.870329.CENT@AI.AI.MIT.EDU> Message-ID: <870330141248.4.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Sun, 29 Mar 87 05:38:36 EST From: "Pandora B. Berman" Date: Sat 28 Mar 87 19:16:30-EST From: "Dave Braunegg" Subject: [Communications Satellite : Msg of Saturday, 28 March 1987 17:29-EST] To: bug-comsat@MC.LCS.MIT.EDU Can someone explain to me the meaning of the error FAILED: FOO at MX.LCS.MIT.EDU; Recipient name apparently rejected. Last reply was: {503 Bad sequence, MAIL already seen?} I got a heck of a lot of this error and I don't know why. Date: Sat, 28 Mar 87 17:43:41 EST From: Communications Satellite Subject: Msg of Saturday, 28 March 1987 17:29-EST To: DJB%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU .... FAILED: BROM at MX.LCS.MIT.EDU; Recipient name apparently rejected. Last reply was: {503 Bad sequence, MAIL already seen?} FAILED: DAN at MX.LCS.MIT.EDU; Recipient name apparently rejected. Last reply was: {503 Bad sequence, MAIL already seen?} FAILED: (FILE [ELLEN;Z SAVE]) at MX.LCS.MIT.EDU; Recipient name apparently rejected. Last reply was: {503 Bad sequence, MAIL already seen?} .... Failed message follows: ------- Date: Sat 28 Mar 87 17:23:07-EST From: "Dave Braunegg" Subject: resumes To: INFO-TEX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU [your original msg text omitted] COMSAT on MX had had one of its internal databases munged. apparently the damage occurred a couple weeks ago, but we only noticed it tonight. you probably got this error because your mail, once it arrived on MX, could not reach some of the recipients immediately, so MX's COMSAT tried to put the msg into its queued mail file; since the queue file was broken, COMSAT barfed strangely. Moon fixed the database (LISTS MSGS or LIST MASTER, i think) and MX's COMSAT is happy again.. I doubt that that was the real cause of this. Note that the error messages are coming from MC's Comsat, not from MX's Comsat. It's MX's SMTP server, not MX's Comsat, that said "503 Bad sequence, MAIL already seen?". This means that it thinks MC's Comsat violated SMTP protocol; either MC's Comsat or MX's SMTP server must have been screwed up some how. I think the directory MX:.MAIL.; was full at the time, so maybe someone broke the SMTP server's handling of directory full so that it does this 503 message?