Date: Wed, 1 Apr 87 05:10:45 EST From: Alan Bawden Subject: Congress Decrees To: BUG-COMSAT@AI.AI.MIT.EDU Message-ID: <177242.870401.ALAN@AI.AI.MIT.EDU> Since they changed the law about daylight savings time I had to modify the DATIME library. COMSAT uses DATIME, but it doesn't look to me like it uses the routine in DATIME that understand that law. I presume this means that the only time COMSAT prints a date into mail, and thus must decide whether to print "EDT" or "EST", it is printing the -current- date and time, and so it just relies on the bit that .RYEAR returns? If this is the case, nobody needs to do anything (except me, who still has to fix ITS...), but if not somebody should hack something before next Sunday morning.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 31 Mar 87 20:57:19 EST Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 30002424620) by MC.LCS.MIT.EDU 31 Mar 87 20:59:07 EST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 105677; Tue 31-Mar-87 15:21:36 EST Date: Tue, 31 Mar 87 15:21 EST From: David A. Moon Subject: Reply-To: field expansion To: Jonathan A Rees cc: BUG-comsat@MC.LCS.MIT.EDU In-Reply-To: <176711.870331.JAR@AI.AI.MIT.EDU> Message-ID: <870331152117.1.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Tue, 31 Mar 87 12:06:06 EST From: Jonathan A Rees Is it COMSAT that expands out domain names (e.g AI -> AI.AI.MIT.EDU) in To:, From:, and Cc: fields? How hard would it be to have it do the same thing with the Reply-To: field? I've been assuming for a while now that it did, and it turns out I'm losing. Comsat never alters the headers of mail that passes through it. It's possible for a program to generate mail with a request for Comsat to generate the header, and in that case Comsat puts in full host names (I think). Babyl does not use this feature. I think the :MAIL command does use it. [Note the asymmetry between From and Reply-to fields in the following message header.] Date: Tue, 31 Mar 87 11:59:02 EST From: Jonathan A Rees To: JAR@AI.AI.MIT.EDU reply-to: jar@ai Message-ID: <176705.870331.JAR@AI.AI.MIT.EDU> If this message was sent with Babyl, then it's a Babyl bug.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 31 Mar 87 19:55:25 EST Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 31 Mar 87 18:53:57 EST Date: Tue 31 Mar 87 16:13:50-EST From: Rob Austein Subject: Re: Reply-To: field expansion To: JAR@AI.AI.MIT.EDU cc: BUG-comsat@MC.LCS.MIT.EDU In-Reply-To: <176711.870331.JAR@AI.AI.MIT.EDU> Message-ID: <12290853333.60.SRA@XX.LCS.MIT.EDU> You're confused. REPLY-TO: is specificly exempt from expansion or any other kind of munging in every mailer I've ever seen. This is a feature. You only need to use REPLY-TO: when you are trying to override what all the machines would do anyway (based on the FROM:). So all mailers are told not to second guess you on a REPLY-TO:, since if they knew what you wanted you wouldn't have to use it in the first place. --Rob -------  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 31 Mar 87 12:52:27 EST Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 31 Mar 87 12:09:12 EST Date: Tue, 31 Mar 87 12:06:06 EST From: Jonathan A Rees Subject: Reply-To: field expansion To: BUG-comsat@MC.LCS.MIT.EDU Message-ID: <176711.870331.JAR@AI.AI.MIT.EDU> Is it COMSAT that expands out domain names (e.g AI -> AI.AI.MIT.EDU) in To:, From:, and Cc: fields? How hard would it be to have it do the same thing with the Reply-To: field? I've been assuming for a while now that it did, and it turns out I'm losing. Thanks Jonathan [Note the asymmetry between From and Reply-to fields in the following message header.] Date: Tue, 31 Mar 87 11:59:02 EST From: Jonathan A Rees To: JAR@AI.AI.MIT.EDU reply-to: jar@ai Message-ID: <176705.870331.JAR@AI.AI.MIT.EDU> yow  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 31 Mar 87 03:12:48 EST Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 31 Mar 87 03:15:11 EST Date: Tue, 31 Mar 87 03:12:07 EST From: "Pandora B. Berman" Subject: local excess names To: JAR@AI.AI.MIT.EDU cc: BUG-comsat@MC.LCS.MIT.EDU Message-ID: <176521.870331.CENT@AI.AI.MIT.EDU> Date: Sat, 28 Mar 87 16:39:06 EST From: Jonathan A Rees Subject: NIC forces extended hostnames, thousands homeless To: CENT@AI.AI.MIT.EDU cc: BUG-comsat@MC.LCS.MIT.EDU Does this imply that "Stony-Brook.SCRC.Symbolics.COM" will stop working, and we'll have to say "SCRC-Stony-Brook.ARPA" instead? That's what your message and :HOST STONY-BROOK would imply. Seems like a step backwards. the Symbolics problem is hairy. we gather that they are trying to have something reasonable and general installed as STONY-BROOK's principal name. until that happens, we (alan & sra) are working on patching the local host tables. whenever xx comes up and compiles new tables, by special machinations, STONY-BROOK will have SYMBOLICS.COM as a nickname. Why can't we hang on to local MIT aliases for our own use? So long as local nicknames are never transmitted in mail headers, I don't see how this could cause any problems. Or should the expansion be done by user programs like BABYL rather than be wired into COMSAT or ITS's domain code? I was under the impression that there was some provision for local nicknames in the grand scheme of things. by great effort (and probably a fair amount of kludging), SRA has promised that for the forseeable future, the current set of nicknames for the machines of the AI and LCS subdomains will continue to work locally. he refuses to promise anything about other MIT machines, which is only fair, as he has no control over them. (Is the domain name change already being discussed on some local mailing list somewhere?) i don't know whether it's being discussed elsewhere. i think all the appropriate wizards are here on BUG-MAIL..  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 30 Mar 87 19:02:38 EST Date: Mon, 30 Mar 1987 18:59 EST Message-ID: From: Rob Austein To: "Pandora B. Berman" Cc: BUG-MAIL@AI.AI.MIT.EDU, Chris_Moore@UM.CC.UMICH.EDU Subject: header-people mail problems In-reply-to: Msg of 25 Mar 1987 23:16-EST from "Pandora B. Berman" |----Bad---| v v >>> MAIL From:<@MC.LCS.MIT.EDU,@UDEL.EDU:@localhost:galvin@dewey.udel.edu> <<< 501 Syntax error in parameters. I don't think COMSAT broke the return path. The "localhost" is unix brainrot, probably a bad sendmail.cf file on DEWEY or LOUIE.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 30 Mar 87 16:25:45 EST Received: from REAGAN.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 30 MAR 87 16:08:52 EST Received: from OTIS.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 31612; Mon 30-Mar-87 15:50:23 EST Date: Mon, 30 Mar 87 15:50 EST From: Chris Lindblad Subject: I think I understand now why the Received: lines were weird. To: bug-comsat@MC.LCS.MIT.EDU Message-ID: <870330155028.0.CJL@OTIS.AI.MIT.EDU> I guess BBN.COM ignored the HELO, and used the IP address, so really OZ send the mail through the TCP gateway on MC.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 30 Mar 87 16:18:29 EST Received: from REAGAN.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 30 MAR 87 15:45:51 EST Received: from OTIS.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 31611; Mon 30-Mar-87 15:41:05 EST Date: Mon, 30 Mar 87 15:41 EST From: Chris Lindblad Subject: I thought comsat did Received: lines To: bug-comsat@MC.LCS.MIT.EDU Message-ID: <870330154110.9.CJL@OTIS.AI.MIT.EDU> I thought comsat did "Received:" lines. I guess not. IWBNI it did. Received: from BBN.COM by G.BBN.COM; Mon 30 Mar 87 13:40:24-EST Received: from mc.lcs.mit.edu by BBN.COM id aa13173; 30 Mar 87 13:32 EST Received: from REAGAN.AI.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 30 Mar 87 13:27-EST Received: from OTIS.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 31575; Mon 30-Mar-87 13:28:41 EST  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 30 Mar 87 13:50:42 EST Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 30 Mar 87 13:47:31 EST Date: Mon, 30 Mar 87 13:44:30 EST From: Jonathan A Rees Subject: [JDD: LL-XN] To: BUG-mail@MC.LCS.MIT.EDU Message-ID: <176037.870330.JAR@AI.AI.MIT.EDU> When I do ":HOST LL-XN.ARPA" I get "lookup failed". It used to exist. The postmaster at LL tells me it still exists. What gives? Where should I send questions like this? BUG-MAIL doesn't seem quite right. - Jonathan Date: Mon 30 Mar 1987 13:36:22 EST From: To: jar at ai.ai.mit.edu cc: postmaster at ll.arpa Re: LL-XN Jonathan: LL-XN continues on the Arpanet; the address: LL-XN.ARPA 10:131082 is taken from a recent Arpahost table. Regards, John D Drinan  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 29 Mar 87 18:49:38 EST Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 29 Mar 87 18:52:23 EST Date: Sun, 29 Mar 87 18:49:19 EST From: David Vinayak Wallace Subject: NIC forces extended hostnames, thousands homeless To: JAR@AI.AI.MIT.EDU cc: CENT@AI.AI.MIT.EDU, BUG-comsat@MC.LCS.MIT.EDU In-reply-to: Msg of Sat 28 Mar 87 16:39:06 EST from Jonathan A Rees Message-ID: <175637.870329.GUMBY@AI.AI.MIT.EDU> We can have private nicknames if we fix HOSTS3's MERGE facility, which SRA claims doesn't work. However it seems like it would be easier to write a teco program to read a file which contains nothing but +name and -name amendments to the nic host table. If it disallowed the removal or alteration of a primary name it shouldn't be too hard. But don't hold your breath unless you want to write it. (And if you do write it please breathe while doing so).  Date: Sun, 29 Mar 87 05:38:36 EST From: "Pandora B. Berman" Subject: MX COMSAT loses its lunch To: DJB@OZ.AI.MIT.EDU cc: BUG-COMSAT@AI.AI.MIT.EDU Message-ID: <175457.870329.CENT@AI.AI.MIT.EDU> 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.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 28 Mar 87 19:23:50 EST Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 28 MAR 87 19:22:37 EST 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 Message-ID: <12290100155.77.DJB@OZ.AI.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. Thanks, Dave Return-Path: Received: from XX.LCS.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet with SMTP; 28 Mar 87 17:38-EST Received: from MC.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet with SMTP; 28 Mar 87 17:38-EST 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 Message-ID: <198943.870328@MC.LCS.MIT.EDU> FAILED: CARI at SCRC-STONY-BROOK.ARPA; Recipient name apparently rejected. Last reply was: {550 Recipient CARI@STONY-BROOK.SCRC.Symbolics.COM is not defined on this host.} FAILED: GEOFFM at CSL.SRI.COM; Recipient name apparently rejected. Last reply was: {550 No such local mailbox as "GEOFFM", recipient rejected} 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: FLAVIO at MX.LCS.MIT.EDU; Recipient name apparently rejected. Last reply was: {503 Bad sequence, MAIL already seen?} FAILED: HNB at MX.LCS.MIT.EDU; Recipient name apparently rejected. Last reply was: {503 Bad sequence, MAIL already seen?} FAILED: JFJ at MX.LCS.MIT.EDU; Recipient name apparently rejected. Last reply was: {503 Bad sequence, MAIL already seen?} FAILED: JHS at MX.LCS.MIT.EDU; Recipient name apparently rejected. Last reply was: {503 Bad sequence, MAIL already seen?} FAILED: MEM at MX.LCS.MIT.EDU; Recipient name apparently rejected. Last reply was: {503 Bad sequence, MAIL already seen?} FAILED: MST at MX.LCS.MIT.EDU; Recipient name apparently rejected. Last reply was: {503 Bad sequence, MAIL already seen?} FAILED: MURPH at MX.LCS.MIT.EDU; Recipient name apparently rejected. Last reply was: {503 Bad sequence, MAIL already seen?} FAILED: PALAIS at MX.LCS.MIT.EDU; Recipient name apparently rejected. Last reply was: {503 Bad sequence, MAIL already seen?} FAILED: PANOS at MX.LCS.MIT.EDU; Recipient name apparently rejected. Last reply was: {503 Bad sequence, MAIL already seen?} FAILED: PJG at MX.LCS.MIT.EDU; Recipient name apparently rejected. Last reply was: {503 Bad sequence, MAIL already seen?} FAILED: RGA at MX.LCS.MIT.EDU; Recipient name apparently rejected. Last reply was: {503 Bad sequence, MAIL already seen?} FAILED: RHB at MX.LCS.MIT.EDU; Recipient name apparently rejected. Last reply was: {503 Bad sequence, MAIL already seen?} FAILED: SYP at MX.LCS.MIT.EDU; Recipient name apparently rejected. Last reply was: {503 Bad sequence, MAIL already seen?} FAILED: WGD at MX.LCS.MIT.EDU; Recipient name apparently rejected. Last reply was: {503 Bad sequence, MAIL already seen?} Failed message follows: ------- Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 28 MAR 87 17:29:12 EST 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 Message-ID: <12290079516.77.DJB@OZ.AI.MIT.EDU> Every so often a request comes through for a resume format. I put a couple I came across on TEXLOCAL: on OZ (one is for Plain TeX, the other for LATeX). If anyone wants to add their own resume as a sample for others, feel free to add it to this directory. To make the resume files easy to find and to keep some sense of order to the directory, please add your file with a name beginning with RESUME, e.g., RESUME-DJB.tex, RESUME-FOR-LATEX.STY, etc. Of course, don't write over someone else's file by using their name. (For example, I just wrote RESUME-LATEX.TEX, so don't use that name.) Dave ------- -------  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 28 Mar 87 17:16:22 EST Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 28 Mar 87 16:42:20 EST Date: Sat, 28 Mar 87 16:39:06 EST From: Jonathan A Rees Subject: NIC forces extended hostnames, thousands homeless To: CENT@AI.AI.MIT.EDU cc: BUG-comsat@MC.LCS.MIT.EDU In-reply-to: Msg of 03/27/87 03:29:30 from cent at AI.AI.MIT.EDU Message-ID: <175288.870328.JAR@AI.AI.MIT.EDU> Does this imply that "Stony-Brook.SCRC.Symbolics.COM" will stop working, and we'll have to say "SCRC-Stony-Brook.ARPA" instead? That's what your message and :HOST STONY-BROOK would imply. Seems like a step backwards. Why can't we hang on to local MIT aliases for our own use? So long as local nicknames are never transmitted in mail headers, I don't see how this could cause any problems. Or should the expansion be done by user programs like BABYL rather than be wired into COMSAT or ITS's domain code? I was under the impression that there was some provision for local nicknames in the grand scheme of things. (Is the domain name change already being discussed on some local mailing list somewhere?) Jonathan  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 28 Mar 87 17:12:52 EST Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 28 Mar 87 16:32:59 EST Date: Sat, 28 Mar 87 16:29:47 EST From: Jonathan A Rees Subject: question To: BUG-comsat@MC.LCS.MIT.EDU Message-ID: <175281.870328.JAR@AI.AI.MIT.EDU> Why is it that, in distribution lists, ("#COMSCH.MSG[SCH,LSP]" SAIL.Stanford.Edu) works, but "#COMSCH.MSG[SCH,LSP]"@SAIL.Stanford.Edu doesn't? COMSAT seems to ignore the domain name in the latter, and complains: "#COMSCH.MSG[SCH,LSP]" at MC.LCS.MIT.EDU is an unknown recipient. Curious, - Jonathan  Date: Wed, 25 Mar 87 23:16:12 EST From: "Pandora B. Berman" Subject: header-people mail problems To: Chris_Moore@UM.CC.UMICH.EDU cc: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <173738.870325.CENT@AI.AI.MIT.EDU> Date: Tue, 24 Mar 87 12:07:58 EST From: Chris_Moore@um.cc.umich.edu To: CENT@AI.AI.MIT.EDU Subject: header-people Have we been restored to the header-people list? As close as I can tell this problem is caused by the MC.LCS.MIT.EDU machine inserting an extra ":" into the MAIL FROM address in this message which causes us to reject the message - as we should. --Chris -(Forwarded from: CENT@AI.AI.MIT.EDU, Dated: Fri, 20 Mar 87 00:12:20 EST)- Date: Fri, 20 Mar 87 00:12:20 EST From: "Pandora B. Berman" To: Chris_Moore@UM.CC.UMICH.EDU Cc: HEADER-PEOPLE-REQUEST@AI.AI.MIT.EDU we received the following complaint about a Header-People subsidary list at your host: ---------- To: header-people-request@mc.lcs.mit.edu Subject: Failed Mail Date: Wed, 18 Mar 87 08:08:17 -0500 From: James M Galvin For your information. Jim ------- Forwarded Message From: Mail Delivery Subsystem To: @mc.lcs.mit.edu,@UDEL.EDU,@localhost:galvin@dewey.udel.edu Date: Tue, 17 Mar 87 16:01:42 EST Subject: Returned mail: Remote protocol error ----- Transcript of session follows ----- entering connect configuring for site 'xmts' site 'xmts': configured using script /usr/local/lib/smtp/.scr >>> MAIL From:<@MC.LCS.MIT.EDU,@UDEL.EDU:@localhost:galvin@dewey.udel.edu> <<< 501 Syntax error in parameters. 554> Subject: Re: TCP buffers To: Moon@SCRC-STONY-BROOK.ARPA, KLH@AI.AI.MIT.EDU cc: ALAN@MC.LCS.MIT.EDU, BUG-ITS@MC.LCS.MIT.EDU, BUG-COMSAT@MC.LCS.MIT.EDU In-Reply-To: <870320151939.5.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-ID: <12288011565.22.JTW@MIT-SPEECH> Yow! Anyway, what I was going to say when the message cleverly decided to send itself was that the second TCP buffer problem (which is the more serious - the SYN problem loses packets slowly over time, but when the IMP problem hits you have had it) is due to my driver code's apparent inability to always recover correctly from a dropped ACC interrupt. I haven't had a chance to look at the SYN problem yet, but given what we learned from Dave's stuff it should be fairly easy to find. -------  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 20 Mar 87 19:56:09 EST Received: from SPEECH.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 20 MAR 87 19:58:54 EST Date: Fri 20 Mar 87 19:53:22-EST From: "John Wroclawski" Subject: Re: TCP buffers To: Moon@SCRC-STONY-BROOK.ARPA, KLH@AI.AI.MIT.EDU cc: ALAN@MC.LCS.MIT.EDU, BUG-ITS@MC.LCS.MIT.EDU, BUG-COMSAT@MC.LCS.MIT.EDU In-Reply-To: <870320151939.5.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-ID: <12288009716.22.JTW@MIT-SPEECH> Moon's PEEK mode actually showed two different problems with the TCP buffer stuff. Alan mentioned the first one; there is a path which drops SYN packets on the floor. Dave mentioned the second; the KS IMP driver occasionally forgets what it is supposed to be doing. The secon -------  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 20 Mar 87 16:35:06 EST Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 30002424620) by MC.LCS.MIT.EDU 20 Mar 87 16:23:56 EST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 98275; Fri 20-Mar-87 15:20:04 EST Date: Fri, 20 Mar 87 15:19 EST From: David A. Moon Subject: TCP buffers To: Ken Harrenstien cc: ALAN@MC.LCS.MIT.EDU, BUG-ITS@MC.LCS.MIT.EDU, BUG-COMSAT@MC.LCS.MIT.EDU In-Reply-To: <171046.870320.KLH@AI.AI.MIT.EDU> Message-ID: <870320151939.5.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Fri, 20 Mar 87 01:47:48 EST From: Ken Harrenstien Another approach would be to modify PEEK (or something else) to look at the buffers, including those not on any list. The contents might give you a clue -- perhaps they are all from a particular host, or use a particular protocol, or all have the SYN or FIN bit set, etc. I did that a month or two ago. I don't remember any more what I found out, except that there were a large number of buffers queued for transmission and the IMP wasn't taking them. But I don't remember what was in them. We still have the crash dumps and :p ? should say what the new mode is (1A I think).  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 20 Mar 87 15:31:34 EST Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 20 Mar 87 15:34:47 EST Date: Fri, 20 Mar 87 15:30:42 EST From: Alan Bawden Subject: TCP buffers To: KLH@AI.AI.MIT.EDU cc: BUG-COMSAT@MC.LCS.MIT.EDU, BUG-ITS@MC.LCS.MIT.EDU In-reply-to: Msg of Fri 20 Mar 87 01:47:48 EST from Ken Harrenstien Message-ID: <171296.870320.ALAN@AI.AI.MIT.EDU> I guess it wasn't announced to Bug-ITS when Moon put a mode into PEEK for looking at TCP buffers (type "1A"). After using this mode on running systems and crash dumps it appears that the lost packets are always SYN packets with their Retransmit flag set. JTW points out that the only effect of a bug that causes retransmission of SYNs to get dropped would be that opening connections would time-out more frequently than they should. This doesn't address the issue of why the problem only seems to happen on the KS's and never on the KL.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 20 Mar 87 11:13:57 EST Received: from po3.andrew.cmu.edu (TCP 20000406037) by MC.LCS.MIT.EDU 20 Mar 87 10:56:28 EST Received: by po3.andrew.cmu.edu (5.54/3.15) id for SRA@XX.LCS.MIT.EDU; Fri, 20 Mar 87 10:42:14 EST Received: via switchmail; Fri, 20 Mar 87 10:42:10 est Received: FROM apollo.itc.cmu.edu VIA queuemail ID ; Fri, 20 Mar 87 10:41:17 est Received: FROM apollo.itc.cmu.edu VIA qmail ID ; Fri, 20 Mar 87 10:41:01 est Message-Id: X-Trace: MS Version 3.22 on ibm032 host apollo.itc.cmu.edu, by cfe (469). Date: Fri, 20 Mar 87 10:40:59 est From: cfe#@andrew.cmu.edu (Craig F. Everhart) To: Rob Austein , David Vinayak Wallace Subject: Re: errs in header-people redistribution, bogus envelope info Cc: BUG-MAIL@MC.LCS.MIT.EDU, HEADER-PEOPLE-REQUEST@MC.LCS.MIT.EDU In-Reply-To: Thanks, one and all, for handling the mitre-gateway problem. I should apologize for having overloaded my message with two questions. Yes, my second question was not about how I receive header-people (just fine, thank you very much), but rather how our system might handle our own distribution lists better. It may actually be that the non-BSMTP Bitnet sites look for a Sender: header or some such; it would be too bad if we had to splice one of those in. I guess I was looking for your views/collective wisdom on the point, since MIT has been much more deeply entrenched in the world of distribution lists than we. For a list about mail protocols, it would be great simply to flush those recipients not capable of receiving mail reasonably, since recipients at those sites would presumably be able to do something about moving their site to BSMTP. Maybe it's a reasonable approach to take anyway, even if it's psychologists trying to use computer mail. If you have any leads about setting up Bitnet redistribution sites, that would be real helpful too. Also helpful would be some buzzwords (e.g. LISTSERV) that I could throw at people at such redistribution sites so that it would jog their memories and they'd remember the name of the software that they should run so that they could serve as a redistribution site. Thanks, Craig  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 20 Mar 87 05:41:58 EST Date: Fri, 20 Mar 1987 05:40 EST Message-ID: From: Rob Austein To: David Vinayak Wallace Cc: BUG-MAIL@AI.AI.MIT.EDU, "Pandora B. Berman" , cfe#@ANDREW.CMU.EDU Subject: MITRE-GATEWAY.ARPA In-reply-to: Msg of 20 Mar 1987 05:04-EST from David Vinayak Wallace Er, um, it seems that the IFILE server on MX was trashed during the last outage. Due to the way the automated HOSTS3 table installation works, this means that MX hasn't gotten a new host table for weeks. Nobody was notified because back when the installation job -did- notify people, all the people it notified asked me to shut it up. I copied AI's IFILE server over, verified that it works. A new table is being installed as I type this, at which point MITRE-GATEWAY.ARPA will softly and silently vanish away. Sorry, Gumby.  Date: Fri, 20 Mar 87 05:28:18 EST From: "Pandora B. Berman" Subject: mitre-gateway? To: GUMBY@AI.AI.MIT.EDU cc: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <171129.870320.CENT@AI.AI.MIT.EDU> Date: Fri, 20 Mar 87 05:04 EST From: David Vinayak Wallace Subject: errs in header-people redistribution, bogus envelope info To: Pandora B. Berman cc: BUG-MAIL@AI.AI.MIT.EDU, cfe#@ANDREW.CMU.EDU MX ITS.1578. DDT.1518. TTY 47 2. Lusers, Fair Share = 88% :host mitre-gateway (Please Log In) MITRE-GATEWAY.ARPA "SERVER" System: UNIX CPU: C/70 ARPANET = 10.1.0.111 (Host 1, Imp 111) 1200,,200157 (no services listed) :KILL * that's nice. but AI and MC disagree. i would not be at all surprised at MX's possession of an out-of-date host table. i do not consider indirecting mail through MX particularly wise.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 20 Mar 87 05:20:33 EST Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 20 Mar 87 05:23:35 EST Date: Fri, 20 Mar 1987 05:18 EST Message-ID: From: Rob Austein To: David Vinayak Wallace Cc: BUG-MAIL@MC.LCS.MIT.EDU, cfe#@ANDREW.CMU.EDU, HEADER-PEOPLE-REQUEST@MC.LCS.MIT.EDU Subject: errs in header-people redistribution, bogus envelope info This is the same problem that was screwing Prindeville when he set up his list on MC (CANADA01 was routing all distributed messages back to MC; they claimed that putting in a SENDER: field would fix this, which gives you some idea of the general level of confusion). I don't think there's much to be done for people who won't support BSMTP. I've given up on our equivalent problem, the CHAOS/MAIL protocol, about the only thing I think is worthwhile in this regard is trying to get people to convert to the newer technology. (B)SMTP isn't the end-all of mail protocols, but it's enough better than the first-generation protocols that it's not worth trying to "fix" the old ones. BSMTP on the BITNET has been slowed down somewhat by the WISCVM people. At one point they were doing BSMTP in exactly one direction: you had to use BSMTP for BITNET->Internet mail, and WISCVM would not use BSMTP for Internet->BITNET mail. If this has been fixed I haven't heard about it. Given that, along with the general level of (dis)organization on BITNET, it'll be a while before everybody converts. I figure we should just stop sending mail to the people who don't switch over, thereby giving them an incentive, but people will undoubtably tell me I'm being mean. --Rob  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 20 Mar 87 05:09:17 EST Received: from JONES.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 20 MAR 87 05:08:01 EST Date: Fri, 20 Mar 87 05:04 EST From: David Vinayak Wallace Subject: errs in header-people redistribution, bogus envelope info To: Pandora B. Berman cc: BUG-MAIL@AI.AI.MIT.EDU, cfe#@ANDREW.CMU.EDU In-Reply-To: <171073.870320.CENT@AI.AI.MIT.EDU> Message-ID: <870320050425.5.GUMBY@JONES.AI.MIT.EDU> Date: Fri, 20 Mar 87 02:41:07 EST From: "Pandora B. Berman" Date: Fri, 20 Mar 87 02:19 EST From: David Vinayak Wallace .... Penny: why is MITRE-GATEWAY.ARPA not perfectly adequate, at least for now? it's not known. try doing :host for that. MX ITS.1578. DDT.1518. TTY 47 2. Lusers, Fair Share = 88% :host mitre-gateway (Please Log In) MITRE-GATEWAY.ARPA "SERVER" System: UNIX CPU: C/70 ARPANET = 10.1.0.111 (Host 1, Imp 111) 1200,,200157 (no services listed) :KILL *  Date: Fri, 20 Mar 87 02:41:07 EST From: "Pandora B. Berman" Subject: errs in header-people redistribution, bogus envelope info To: GUMBY@AI.AI.MIT.EDU cc: BUG-MAIL@AI.AI.MIT.EDU, cfe#@ANDREW.CMU.EDU Message-ID: <171073.870320.CENT@AI.AI.MIT.EDU> Date: Fri, 20 Mar 87 02:19 EST From: David Vinayak Wallace Subject: errs in header-people redistribution, bogus envelope info To: Pandora B. Berman cc: cfe#@ANDREW.CMU.EDU, HEADER-PEOPLE-REQUEST@MC.LCS.MIT.EDU, BUG-MAIL@MC.LCS.MIT.EDU .... Penny: why is MITRE-GATEWAY.ARPA not perfectly adequate, at least for now? it's not known. try doing :host for that. On another note, do you have a strategy for redistributing to Bitnet sites that don't support BSMTP (and, thus, discard envelope information)? If a submission to header-people comes in from foo@bar, then the header says From: foo@bar and To: header-people@mc. But you redistribute it, so that the (SMTP) envelope information then says that it's to be delivered to dozens of subscribers. It's a bogus property of these older-protocol Bitnet sites that they discard the envelope information and use only the header information to route mail, and they don't know how to map ``To: header-people@mc.lcs.mit.edu'' into the mailboxes of the local users who are to receive that message. (Our problem is a little more severe, even, since our redistribution lists default to replacing the return-path information (SMTP mail from:) also, and these bogus non-BSMTP Bitnet sites return errors to the address given after the From: line, not to the envelope's return address.) So my question is: do you, as header-people maintainer, have a strategy for dealing with these folks? It's not clear what we can do. Does this mean you're receiving header-people via bitnet or that error messages from bitnet are going to you? Have you tried putting ERRORS-TO: in the headers? If some mailer actually parses the headers it might pay attention to such a thing though probably not. if i understand correctly, he's not complaining about HEADER-PEOPLE lossage here. i think his problem is that at CMU they have weird mail systems which seem to produce errors LIKE some he's seen from bitnet sites which have less-than-edge-of-technology mailers.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 20 Mar 87 02:21:18 EST Received: from JONES.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 20 MAR 87 02:23:33 EST Date: Fri, 20 Mar 87 02:19 EST From: David Vinayak Wallace Subject: errs in header-people redistribution, bogus envelope info To: Pandora B. Berman cc: cfe#@ANDREW.CMU.EDU, HEADER-PEOPLE-REQUEST@MC.LCS.MIT.EDU, BUG-MAIL@MC.LCS.MIT.EDU In-Reply-To: <171040.870320.CENT@AI.AI.MIT.EDU> Message-ID: <870320021955.3.GUMBY@JONES.AI.MIT.EDU> Date: Fri, 20 Mar 87 01:42:30 EST From: "Pandora B. Berman" Date: Thu, 19 Mar 87 10:31:31 est From: cfe#@andrew.cmu.edu (Craig F. Everhart) To: header-people-request@mc.lcs.mit.edu Subject: errs in header-people redistribution Looks like the un-domain-ized MITRE-GATEWAY is no longer recognized. thanks for informing us. this was also reported by some others and i have suspended the offending addresses while i try to trace new ones for those folks. Penny: why is MITRE-GATEWAY.ARPA not perfectly adequate, at least for now? On another note, do you have a strategy for redistributing to Bitnet sites that don't support BSMTP (and, thus, discard envelope information)? If a submission to header-people comes in from foo@bar, then the header says From: foo@bar and To: header-people@mc. But you redistribute it, so that the (SMTP) envelope information then says that it's to be delivered to dozens of subscribers. It's a bogus property of these older-protocol Bitnet sites that they discard the envelope information and use only the header information to route mail, and they don't know how to map ``To: header-people@mc.lcs.mit.edu'' into the mailboxes of the local users who are to receive that message. (Our problem is a little more severe, even, since our redistribution lists default to replacing the return-path information (SMTP mail from:) also, and these bogus non-BSMTP Bitnet sites return errors to the address given after the From: line, not to the envelope's return address.) So my question is: do you, as header-people maintainer, have a strategy for dealing with these folks? It's not clear what we can do. Does this mean you're receiving header-people via bitnet or that error messages from bitnet are going to you? Have you tried putting ERRORS-TO: in the headers? If some mailer actually parses the headers it might pay attention to such a thing though probably not.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 20 Mar 87 01:48:46 EST Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 20 Mar 87 01:51:39 EST Date: Fri, 20 Mar 87 01:47:48 EST From: Ken Harrenstien Subject: TCP buffers To: ALAN@MC.LCS.MIT.EDU cc: BUG-ITS@MC.LCS.MIT.EDU, BUG-COMSAT@MC.LCS.MIT.EDU Message-ID: <171046.870320.KLH@AI.AI.MIT.EDU> One approach for finding out where the buffers are going might be to look at the various meters. If you find a meter which has a count the same as (or close to) the number of buffers that are "lost", then you've found something. Another approach would be to modify PEEK (or something else) to look at the buffers, including those not on any list. The contents might give you a clue -- perhaps they are all from a particular host, or use a particular protocol, or all have the SYN or FIN bit set, etc. Considering the remarkable things that have already been discovered with respect to .HANG and LOCKS, surely yet another long standing mystery will shortly come to light.  Date: Fri, 20 Mar 87 01:42:30 EST From: "Pandora B. Berman" Subject: errs in header-people redistribution, bogus envelope info To: cfe#@ANDREW.CMU.EDU cc: HEADER-PEOPLE-REQUEST@AI.AI.MIT.EDU, BUG-MAIL@AI.AI.MIT.EDU Message-ID: <171040.870320.CENT@AI.AI.MIT.EDU> Date: Thu, 19 Mar 87 10:31:31 est From: cfe#@andrew.cmu.edu (Craig F. Everhart) To: header-people-request@mc.lcs.mit.edu Subject: errs in header-people redistribution Looks like the un-domain-ized MITRE-GATEWAY is no longer recognized. thanks for informing us. this was also reported by some others and i have suspended the offending addresses while i try to trace new ones for those folks. On another note, do you have a strategy for redistributing to Bitnet sites that don't support BSMTP (and, thus, discard envelope information)? If a submission to header-people comes in from foo@bar, then the header says From: foo@bar and To: header-people@mc. But you redistribute it, so that the (SMTP) envelope information then says that it's to be delivered to dozens of subscribers. It's a bogus property of these older-protocol Bitnet sites that they discard the envelope information and use only the header information to route mail, and they don't know how to map ``To: header-people@mc.lcs.mit.edu'' into the mailboxes of the local users who are to receive that message. (Our problem is a little more severe, even, since our redistribution lists default to replacing the return-path information (SMTP mail from:) also, and these bogus non-BSMTP Bitnet sites return errors to the address given after the From: line, not to the envelope's return address.) So my question is: do you, as header-people maintainer, have a strategy for dealing with these folks? in a word, no. in a few more words, One Of These Days Real Soon Now i'm going to ship all the BITNET addresses over to a bitnet host and have a redistribution list set up there -- i'm not sure if this will ease the problem you describe, but i don't see how it can hurt. i have been given a contact on BITNET to run this for me, i just have to get around to it. maybe one of the mail hackers has a suggestion.  Date: Fri, 20 Mar 87 00:26:28 EST From: Ken Harrenstien Subject: AAAUGH! To: GUMBY@AI.AI.MIT.EDU cc: BUG-COMSAT@AI.AI.MIT.EDU, Moon@SCRC-STONY-BROOK.ARPA Message-ID: <170987.870320.KLH@AI.AI.MIT.EDU> Yeah, I'm still around (once in a while). You might be amused to know the real reason behind the way foo@bar is parsed so carefully (as if @ was a legitimate uname character). It so happens that the person in charge of @ at the time insisted quite strongly that BUG-@ should be a valid mailing address. I gave in. If you were to disallow this, as well as %, and leave % alone unless the only thing to the right was your own hostname, then you would probably avoid most of these issues. Quoting needs some careful analysis to figure out just where in the code and data paths you wish to deal with what form of string, and when to convert from one form to the other. I don't think this has ever been done., although doing it will certainly help you clear up the last remaining bits of confusion.  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 18 Mar 87 19:20:11 EST Date: Wed, 18 Mar 1987 19:14 EST Message-ID: From: Rob Austein To: Alan Bawden , hoey@NRL-AIC.ARPA Cc: Bug-COMSAT@AI.AI.MIT.EDU Subject: [hoey@nrl-aic.ARPA: Bad return-path through Internet-MC-OZ-MC-Internet] In-reply-to: Msg of 18 Mar 1987 19:04-EST from Alan Bawden The problem is almost certainly on OZ, either in the hacked up MMAILR they run or in the CHAOS.SMTP server. Both of those were maintained by GZ, now gone, so the bug address is a black hole. OZ needs a new mailer and needs to have some existing monitor code turned on to support said new mailer. I'll do this when I get a chance (how long have I been saying that now?).  Received: from REAGAN.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 18 MAR 87 19:07:17 EST Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 30023; Wed 18-Mar-87 19:04:12 EST Date: Wed, 18 Mar 87 19:04 EST From: Alan Bawden Subject: [hoey@nrl-aic.ARPA: Bad return-path through Internet-MC-OZ-MC-Internet] To: Bug-COMSAT@AI.AI.MIT.EDU Message-ID: <870318190418.9.ALAN@PIGPEN.AI.MIT.EDU> This message wen't to Bug-Random-Program. I couldn't decide if it should go to BUG-COMSAT or to someone at OZ, so I thought I would just forward it to BUG-COMSAT and let you decide. Date: 18 Mar 1987 15:27:16 EST (Wed) From: Dan Hoey Subject: Bad return-path through Internet-MC-OZ-MC-Internet To: BUG-SMTP@mc.lcs.mit.edu I'm sorry if this gets sent to BUG-RANDOM-PROGRAM. It is a report of a problem that probably originates at OZ, but since we on the Internet don't believe in OZ, maybe we have to believe it's MC's problem. Feel free to forward it to BUG-OZ, or whoever will be interested. If no one's interested, I suppose you can ignore it. But it's probably a generic problem with any Internet mailing lists maintained on OZ. The problem comes from mail to SELF-ORG@MC. That goes to OZ to be exploded, then sent back to Internet subscribers via MC again. When we get our copy, the return-path is given as <@MC.LCS.MIT.EDU,@OZ.AI.MIT.EDU:@MC.LCS.MIT.EDU:hoey@nrl-aic.ARPA> ^ Well, the leftmost colon on that return path ought to be a comma. I don't suppose many sites actually look that hard, and since the colon and comma are semantically identical, I don't suppose they should. But UMIX.CC.UMICH.EDU (or maybe UM.CC.UMICH.EDU) looks hard enough to decide it's got a syntax error, and sends it back--addressed to the very return path it barfed on! Perhaps unfortunately, the path works and I get the mail back. So if you have a way of fixing the mailer--probably at OZ--to use comma if the return-path already has a colon in it, that should solve the problem. Or if you want to hang the bag on MC's mailer, as OZ's Internet surrogate, to fix the return path (or even dyke out OZ entirely when it's bounced from the Internet to start with) that would fix it. Or maybe Mailinglist Central should be doing the expansion itself, or maybe UMICH can be convinced to be more forgiving. But the way it is now, maintainers of OZ-based lists like SELF-ORG are just going to have to deny subscriptions to Michiganders until something gets fixed. I'm just now collecting the bounces from my message, to send to SELF-ORG-REQUEST. I'll mention this problem, but maybe you want to look at whether a generic solution is called for. Dan Hoey The headers I got back: >Received: Wed, 18 Mar 87 14:51:18 est from OZ.AI.MIT.EDU (mc.lcs.mit.edu.ARPA) > by nrl-aic.ARPA id AA11767 >Received: from MC.LCS.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet with SMTP; 18 Mar 87 14:51-EST >Received: from umix.cc.umich.edu (TCP 4300200412) by MC.LCS.MIT.EDU 18 Mar 87 14:52:22 EST >Received: by umix.cc.umich.edu (5.54/umix-2.0) > id AA01980; Wed, 18 Mar 87 14:47:25 EST >Date: Wed, 18 Mar 87 14:47:25 EST >From: Mailer-Daemon@umix.cc.umich.edu (Mail Delivery Subsystem) >Subject: Returned mail: Remote protocol error >Message-Id: <8703181947.AA01980@umix.cc.umich.edu> >To: <@MC.LCS.MIT.EDU,@OZ.AI.MIT.EDU:@MC.LCS.MIT.EDU:hoey@nrl-aic.ARPA> > > ----- Transcript of session follows ----- >entering connect >configuring for site 'xmts' >site 'xmts': configured >using script /usr/local/lib/smtp/.scr >>>> MAIL From:<@MC.LCS.MIT.EDU,@OZ.AI.MIT.EDU:@MC.LCS.MIT.EDU:hoey@nrl-aic.ARPA> ><<< 501 Syntax error in parameters. >554 ... Remote protocol error: Bad file number > > ----- Unsent message follows ----- >Received: by umix.cc.umich.edu (5.54/umix-2.0) > id AA01978; Wed, 18 Mar 87 14:47:25 EST >Received: from MC.LCS.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet with SMTP; 18 Mar 87 14:38-EST >Received: from nrl-aic.ARPA (TCP 3200200010) by MC.LCS.MIT.EDU 18 Mar 87 14:35:21 EST >Return-Path: >Received: Wed, 18 Mar 87 14:29:48 est by nrl-aic.ARPA id AA11584 >Date: 18 Mar 1987 14:15:58 EST (Wed) >From: Dan Hoey >Subject: Yet another BIP program >To: self-organization@mc.lcs.mit.edu, isaacson@a.isi.edu >Message-Id: <543093358/hoey@nrl-aic> > [body deleted]  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 17 Mar 87 01:24:56 EST Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 17 Mar 87 01:13:32 EST Date: Tue, 17 Mar 87 01:12:50 EST From: "Pandora B. Berman" Subject: hairy forum address loses big To: JAR@AI.AI.MIT.EDU cc: BUG-comsat@MC.LCS.MIT.EDU Message-ID: <169542.870317.CENT@AI.AI.MIT.EDU> Date: Mon, 16 Mar 87 23:15:51 EST From: Jonathan A Rees Subject: [COMSAT: Msg of Monday, 16 March 1987 18:17-EST] To: BUG-comsat@MC.LCS.MIT.EDU Hi, COMSAT tells me: FAILED: at HI-MULTICS.ARPA; Recipient name apparently rejected.... ----- From MC: JAR; SCHEME LIST : ----- Midford@HI-MULTICS ;Honeywell / Peter Midford Harvey%PCO@HI-MULTICS ; Ron Harvey "{forum >udd>SoftTech>lib>meetings>scheme.forum}"@HI-Multics ; ----- COMSAT's report: ----- Date: Mon, 16 Mar 87 22:07:21 EST From: Communications Satellite Subject: Msg of Monday, 16 March 1987 18:17-EST To: "JAR@AI.AI.MIT.EDU"@AI.AI.MIT.EDU FAILED: at HI-MULTICS.ARPA; Recipient name apparently rejected. Last reply was: {550 The supplied text contains only comments and whitespace. Parsing recipient address} Failed message follows: ------- [original msg omitted] yes, it's that forum address. a portion of the SCHEME list as COMSAT was expanding it: ---------- DEDE%uhcl@1201000005,@1200200136,(FILE {FORUM >UDD>SOFTTECH>LIB>MEETINGS>SCHEME.FORUM})@1200600054,Harvey%PCO@1200200136, ---------- note that the DEDE address is followed by an address composed of a host number with no local user, which is followed by a hairy FILE address at MC's host number (the file bears no resemblance to an ITS file spec), which is followed by the Harvey address; in your indirect file, the addresses are either in this order or reversed, i've forgotten which. the host number with no local address is the same as the host number that the Harvey address is headed for. after expanding the list, COMSAT started delivering: ---------- 182123 Local->MC.LCS.MIT.EDU 182123 TO->[LSPMAI;SCHEME MAIL] 182126 TO->{FORUM >UDD>SOFTTECH>LIB>MEETINGS>SCHEME.FORUM} ---------- i think the copy sent to {FORUM >UDD...@MC was dumped into the bit bucket; i can't find traces of it on the obvious tourist dirs. it happens that during the direct delivery, all mail to HI-MUL was queued for retry. later on, COMSAT tried again: ---------- 220646 Unqueueing to host HI-MULTICS.ARPA 220646 ICP->HI-MULTICS.ARPA (TCP-SMTP) 220651 QID=<191766.870316@MC.LCS.MIT.EDU> 220653 XTO->Midford 220655 XTO->Harvey%PCO 220710 XTO-> ...PERM ERR={550 The supplied text contains only comments and whitespace. Parsing recipient address} 220714 TEXT-> 220721 CMSG ID=<191919.870316@MC.LCS.MIT.EDU> EXP->JAR@AI.AI.MIT.EDU@40700003130 220722 ICP->AI.AI.MIT.EDU (CHAOS-SMTP) 220725 TO->JAR@AI.AI.MIT.EDU 220732 All qmsgs gone for HI-MULTICS.ARPA...NSMBYE timed out ---------- COMSAT was really trying to deliver to a null address at HI-MUL. sorry, no suggestions on how to win; i'm just diagnosing the problem..  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 17 Mar 87 00:36:45 EST Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 16 Mar 87 23:16:35 EST Date: Mon, 16 Mar 87 23:15:51 EST From: Jonathan A Rees Subject: [COMSAT: Msg of Monday, 16 March 1987 18:17-EST] To: BUG-comsat@MC.LCS.MIT.EDU Message-ID: <169457.870316.JAR@AI.AI.MIT.EDU> Hi, COMSAT tells me: FAILED: at HI-MULTICS.ARPA; Recipient name apparently rejected. But I think I'm supplying non-null recipients, so I don't understand either the error message or how to debug this problem. Could someone take a quick look to see if I'm doing something obviously wrong, and/or otherwise offer me some advice on how to debug this? Mailing list "scheme@mc" simply indirects to file MC: JAR; SCHEME LIST. Below are all the HI-MULTICS addresses in that file. Presumably one of them is being misparsed or otherwise misunderstood by COMSAT. The third one does indeed look suspicious, but I know that I have sent mail to this address directly without any problem, and I don't see why COMSAT should have trouble just because it's coming out of a file. Thanks. - Jonathan ----- From MC: JAR; SCHEME LIST : ----- Midford@HI-MULTICS ;Honeywell / Peter Midford Harvey%PCO@HI-MULTICS ; Ron Harvey "{forum >udd>SoftTech>lib>meetings>scheme.forum}"@HI-Multics ; ----- COMSAT's report: ----- Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 16 Mar 87 22:06:59 EST Date: Mon, 16 Mar 87 22:07:21 EST From: Communications Satellite Subject: Msg of Monday, 16 March 1987 18:17-EST To: "JAR@AI.AI.MIT.EDU"@AI.AI.MIT.EDU Message-ID: <191919.870316@MC.LCS.MIT.EDU> FAILED: at HI-MULTICS.ARPA; Recipient name apparently rejected. Last reply was: {550 The supplied text contains only comments and whitespace. Parsing recipient address} Failed message follows: ------- Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 16 Mar 87 17:51:05 EST Date: Mon, 16 Mar 87 17:49:49 EST From: Jonathan A Rees Subject: Revised^3 Report on Scheme; administrivia To: Dan@CIS.UPENN.EDU, scheme@MC.LCS.MIT.EDU In-reply-to: Msg of Mon 16 Mar 87 13:46 EST from Dan Zigmond Message-ID: <169287.870316.JAR@AI.AI.MIT.EDU> Date: Mon, 16 Mar 87 13:46 EST From: Dan Zigmond To: scheme at mc.lcs.mit.edu Re: Revised Revised Revised Report on Scheme How does one get a copy of this new spec? Is it FTPable from somewhere? It's in ACM SIGPLAN Notices, December 1986. You can also get it from the MIT AI Lab Publications Office, 545 Technology Square, Cambridge MA 02139, for $6.00, prepaid; ask for AI Memo 848a. If you want the LaTeX sources, you can get them from MIT-PREP:/scheme/r3rs.tar (that's a Unix "tar" file), but I think you're better off dealing with the hardcopy, unless you want to modify it. Attention new arrivals to the list: rather than bother everyone on the list with requests like this for basic information which has a high probability of having already been posted, please send your easy questions to Scheme-Request@MIT-MC. In particular, I can send you a compendium of implementation announcements, consisting of messages which have been sent to this list. Don't get upset if a week or two goes by without an answer from me, since I tend to deal with scheme-request messages in batches; be patient. Implementors & others: if you want to add or change things in this standard information packet I send out, please let me know. One last thing: I would like for people to get in the habit of sending mail pertaining to the Scheme mailing list to Scheme-Request, not to me personally. This is both to make my own record-keeping easier (messages sent to Scheme-Request are archived) and to be prepared in case someone else ever takes over management of the list either temporarily or permanently. Thanks Jonathan  Date: Tue, 17 Mar 87 00:01:47 EST From: Puff the Magic Dragon Subject: Happy Birthday! To: KSC@AI.AI.MIT.EDU Message-ID: <169492.870317.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 14 Mar 87 05:07:46 EST Date: Sat, 14 Mar 1987 05:02 EST Message-ID: From: Rob Austein To: David Vinayak Wallace Cc: Bug-COMSAT@AI.AI.MIT.EDU Subject: AAAUGH! In-reply-to: Msg of 14 Mar 1987 04:02-EST from David Vinayak Wallace The (MUMBLE @BARF) nonsense is from KLH, and it's complicated. What you want to do is just MUMBLE@BARF, except that guess what happens when BARF isn't a known host? Right, it gets delivered to a local user with uname "MUMBLE@BARF". Or tries to, anyway. You may remember that this happened a lot last winter. The (MUMBLE @BARF) syntax tells COMSAT that BARF is definitely a host. This is a feature, since it tells COMSAT enough that it can compose error messages that mean something to mortals. Unfortunately, it seems that once COMSAT knowns BARF is a a host, it tries to help out and scans mumble for "%". I think. Moon probably understands that part of the code better than I do. So FOO%BAR@BAZ will will do what you want, by fooling COMSAT into leaving the "%" alone, until the day when BAZ disappears from the host tables or the domain world (which happens all too often, I might add, nameservers are flakey). At which point COMSAT will start telling the world that it tried real hard but it couldn't deliver mail to "FOO%BAR@BAZ"@AI.AI.MIT.EDU. Which seems to confuse people, I can't imagine why. Mixing "%" and "!" doesn't really work on any machine, it's completely context sensitive and is not far short of painting a target on your poor message. You are pretty much on your own if you insist on such silliness (ie, your guess is as good as mine). Gumby, if I remember correctly, the syntax I told you NOT to use was (MUMBLE BARF) [no "@" in it], which has all the problems of MUMBLE@BARF and is even more confusing to COMSAT because MUMBLE or BARF might match the name of some R-OPTION. I doubt I told you not to use MUMBLE@BARF because it's what I use myself. Not that it matters. Got all that? Good. Now maybe you can explain it to me.  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 14 Mar 87 04:04:34 EST Received: from MARLEY.AI.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 14 Mar 87 03:59-EST Date: Sat, 14 Mar 87 04:02 EST From: David Vinayak Wallace Subject: AAAUGH! To: David A. Moon cc: BUG-COMSAT@AI.AI.MIT.EDU In-Reply-To: <870311162017.6.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-ID: <870314040209.7.GUMBY@MARLEY.AI.MIT.EDU> Date: Wed, 11 Mar 87 16:20 EST From: David A. Moon Date: Wed, 11 Mar 87 05:40:26 EST From: David Vinayak Wallace How can I convince comsat not to do the stupid %-interpreting so mail to roy%acorn@live-oak.lcs.mit.edu doesn't get sent to ur-acorn? It appears that :mail roy%acorn@oak works, while having (roy%acorn @live-oak.lcs.mit.edu) in a mailing-list file doesn't. Why did you put a space before the atsign? I believe if you remove that space everything will work fine. Because SRA told me to. It wouldn't work for me until I blew away COMSAT to force it to reload the mailing-list file. So what syntax is preferred for sending to foo!bar!baz%quzzux@arpa-host? foo!bar!baz%quzzux@arpa-host (foo!bar!baz%quzzux@arpa-host) ("foo!bar!baz%quzzux"@arpa-host) (foo!bar!baz%quzzux @arpa-host) ("foo!bar!baz%quzzux" @arpa-host) ... ? (how about some more puctuation: %$$#) Actually, I'm both confused and concerned by this (the latter only because I am -REQUEST for a large mailing list with a lot of naive users on it).  Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 30002424620) by AI.AI.MIT.EDU 11 Mar 87 16:23:29 EST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 90819; Wed 11-Mar-87 16:20:26 EST Date: Wed, 11 Mar 87 16:20 EST From: David A. Moon Subject: AAAUGH! To: David Vinayak Wallace cc: BUG-COMSAT@AI.AI.MIT.EDU In-Reply-To: <166642.870311.GUMBY@AI.AI.MIT.EDU> Message-ID: <870311162017.6.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Wed, 11 Mar 87 05:40:26 EST From: David Vinayak Wallace How can I convince comsat not to do the stupid %-interpreting so mail to roy%acorn@live-oak.lcs.mit.edu doesn't get sent to ur-acorn? It appears that :mail roy%acorn@oak works, while having (roy%acorn @live-oak.lcs.mit.edu) in a mailing-list file doesn't. Why did you put a space before the atsign? I believe if you remove that space everything will work fine.  Date: Wed, 11 Mar 87 16:10:52 EST From: David Vinayak Wallace Subject: AAAUGH! To: SRA@XX.LCS.MIT.EDU cc: BUG-COMSAT@AI.AI.MIT.EDU In-reply-to: Msg of Wed 11 Mar 1987 13:50 EST from Rob Austein Message-ID: <166838.870311.GUMBY@AI.AI.MIT.EDU> Date: Wed, 11 Mar 1987 13:50 EST From: Rob Austein To: David Vinayak Wallace cc: BUG-COMSAT at AI.AI.MIT.EDU Re: AAAUGH! How about ("roy%acorn" @live-oak.lcs.mit.edu) Vis (this came from a file containing only that string above): Date: Wed, 11 Mar 87 15:41:27 EST From: Communications Satellite To: "GUMBY@AI.AI.MIT.EDU" at AI.AI.MIT.EDU Re: Msg of Wednesday, 11 March 1987 15:41-EST FAILED: roy at ACORN.CS.ROCHESTER.EDU; Recipient name apparently rejected. Last reply was: {550 Recipient roy@ACORN.CS.ROCHESTER.EDU is not defined on this host.} Failed message follows: ------- Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 11 Mar 87 15:39:14 EST Date: Wed, 11 Mar 87 15:38:08 EST From: David Vinayak Wallace Subject: hello? To: dead-heads-test-list@MC.LCS.MIT.EDU Message-ID: <166821.870311.GUMBY@AI.AI.MIT.EDU> Still having problems...Roy, do you read me?  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 11 Mar 87 13:55:16 EST Date: Wed, 11 Mar 1987 13:50 EST Message-ID: From: Rob Austein To: David Vinayak Wallace Cc: BUG-COMSAT@AI.AI.MIT.EDU Subject: AAAUGH! In-reply-to: Msg of 11 Mar 1987 05:40-EST from David Vinayak Wallace How about ("roy%acorn" @live-oak.lcs.mit.edu)  Date: Wed, 11 Mar 87 05:40:26 EST From: David Vinayak Wallace Subject: AAAUGH! To: BUG-COMSAT@AI.AI.MIT.EDU Message-ID: <166642.870311.GUMBY@AI.AI.MIT.EDU> How can I convince comsat not to do the stupid %-interpreting so mail to roy%acorn@live-oak.lcs.mit.edu doesn't get sent to ur-acorn? It appears that :mail roy%acorn@oak works, while having (roy%acorn @live-oak.lcs.mit.edu) in a mailing-list file doesn't. aaargh!  Date: Fri, 6 Mar 87 10:56:19 EST From: Chris Hanson Subject: This should not have gone to BUG-RANDOM-PROGRAM@MC To: CENT@AI.AI.MIT.EDU cc: BUG-COMSAT@AI.AI.MIT.EDU In-reply-to: Msg of Fri 6 Mar 87 05:23:17 EST from Pandora B. Berman Message-ID: <164264.870306.CPH@AI.AI.MIT.EDU> Date: Fri, 6 Mar 87 05:23:17 EST From: Pandora B. Berman To: CPH at AI.AI.MIT.EDU Date: Thu, 5 Mar 1987 13:47 EST From: Rob Austein To: bug-comsat@AI.AI.MIT.EDU Subject: This should not have gone to BUG-RANDOM-PROGRAM@MC Date: Thu, 5 Mar 87 11:53:00 EST From: Chris Hanson Subject: dist.tar To: clayton@THUMPER.ARPA cc: jinx@GENEVA.AI.MIT.EDU, BUG-cscheme%mit-oz@MC.LCS.MIT.EDU [Text removed --sra] indeed it shouldn't. but what puzzles me is the convoluted address used. from AI you don't need to go via MC to reach OZ; indeed you should avoid doing so, as such indirection only provides extra work for all mailers involved. is "BUG-cscheme%mit-oz@MC.LCS.MIT.EDU" a result of some personal machine thinking it's being clever, or of automatic replying without diddling around with the headers? Gee, it must have been automatic reply. I received this message, which was undoubtedly addressed to bug-cscheme%oz@mc, and replied to it without thinking. On the other hand, all of our hp machines would have sent this mail to the same address since oz is not a tcp host and the domain software isn't implemented yet.  Date: Fri, 6 Mar 87 05:23:17 EST From: "Pandora B. Berman" Subject: This should not have gone to BUG-RANDOM-PROGRAM@MC To: CPH@AI.AI.MIT.EDU cc: BUG-COMSAT@AI.AI.MIT.EDU Message-ID: <164155.870306.CENT@AI.AI.MIT.EDU> Date: Thu, 5 Mar 1987 13:47 EST From: Rob Austein To: bug-comsat@AI.AI.MIT.EDU Subject: This should not have gone to BUG-RANDOM-PROGRAM@MC Date: Thu, 5 Mar 87 11:53:00 EST From: Chris Hanson Subject: dist.tar To: clayton@THUMPER.ARPA cc: jinx@GENEVA.AI.MIT.EDU, BUG-cscheme%mit-oz@MC.LCS.MIT.EDU [Text removed --sra] indeed it shouldn't. but what puzzles me is the convoluted address used. from AI you don't need to go via MC to reach OZ; indeed you should avoid doing so, as such indirection only provides extra work for all mailers involved. is "BUG-cscheme%mit-oz@MC.LCS.MIT.EDU" a result of some personal machine thinking it's being clever, or of automatic replying without diddling around with the headers?  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 5 Mar 87 13:51:03 EST Date: Thu, 5 Mar 1987 13:47 EST Message-ID: From: Rob Austein To: bug-comsat@AI.AI.MIT.EDU Subject: This should not have gone to BUG-RANDOM-PROGRAM@MC Rcvd-Date: 5-Mar-87 13:31:19-EST Return-Path: <@MC.LCS.MIT.EDU:CPH@AI.AI.MIT.EDU> Received: from MC.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet with SMTP; 5 Mar 87 13:31-EST Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 5 Mar 87 11:53:37 EST Date: Thu, 5 Mar 87 11:53:00 EST From: Chris Hanson Subject: dist.tar To: clayton@THUMPER.ARPA cc: jinx@GENEVA.AI.MIT.EDU, BUG-cscheme%mit-oz@MC.LCS.MIT.EDU In-reply-to: Msg of Thu 5 Mar 87 10:48:56 est from jinx at GENEVA.AI.MIT.EDU (Guillermo J. Rozas) Message-ID: <163644.870305.CPH@AI.AI.MIT.EDU> [Text removed --sra]  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 2 Mar 87 16:05:49 EST Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 2 Mar 87 14:44:25 EST Date: Mon, 2 Mar 1987 14:43 EST Message-ID: From: Rob Austein To: "David A. Moon" Cc: bug-mail@MC.LCS.MIT.EDU Subject: Different mailers for different hosts? In-reply-to: Msg of 2 Mar 1987 13:59-EST from David A. Moon I originally put in the (PROTOCOL ADDRESS) stuff in the received lines to handle the case of incoming TCP/SMTP mail from hosts that we'd never heard of (so that at least there'd be a record of the numeric address the message came from). Making it do the same thing for CHAOS/SMTP was just a frill, which is why I never bothered doing anything about CHAOS/MAIL.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 2 Mar 87 14:27:08 EST Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 30002424620) by MC.LCS.MIT.EDU 2 Mar 87 14:02:29 EST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 82014; Mon 2-Mar-87 14:00:48 EST Date: Mon, 2 Mar 87 13:59 EST From: David A. Moon Subject: Different mailers for different hosts? To: David Vinayak Wallace cc: bug-mail@MC.LCS.MIT.EDU In-Reply-To: <870301143010.3.GUMBY@MARLEY.AI.MIT.EDU> Message-ID: <870302135904.5.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Sun, 1 Mar 87 14:30 EST From: David Vinayak Wallace Why does the received: line which MC added not include the address of the sending host while the Received: line which AI added does? ----- Forwarded message follows ----- Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 1 Mar 87 07:22:46 EST Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 1 MAR 87 07:08:39 EST Received: from EDDIE.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 1 Mar 87 07:04-EST Received: by EDDIE.MIT.EDU (5.31/4.7) id AA06585; Thu, 26 Feb 87 18:54:46 EST Received: by rutgers.edu; Thu, 26 Feb 87 17:46:33 EST ----- End forwarded message ----- Probably no one has taught OZ how to use CHAOS SMTP protocol, so the top received line was put on by a CHAOS SMTP server while the second received line was put on by a CHAOS MAIL server. If you're going to start filling up the Received lines with "useful" information, put in the recipients for which it was received. That would be much more useful.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 2 Mar 87 12:04:12 EST Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 2 Mar 87 12:02:12 EST Date: Mon, 2 Mar 1987 12:00 EST Message-ID: From: Rob Austein To: David Vinayak Wallace Cc: bug-mail@MC.LCS.MIT.EDU Subject: Different mailers for different hosts? In-reply-to: Msg of 1 Mar 1987 14:30-EST from David Vinayak Wallace Date: Sunday, 1 March 1987 14:30-EST From: David Vinayak Wallace To: bug-mail@MC.LCS.MIT.EDU Re: Different mailers for different hosts? Why does the received: line which MC added not include the address of the sending host while the Received: line which AI added does? ----- Forwarded message follows ----- Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 1 Mar 87 07:22:46 EST Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 1 MAR 87 07:08:39 EST Received: from EDDIE.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 1 Mar 87 07:04-EST Received: by EDDIE.MIT.EDU (5.31/4.7) id AA06585; Thu, 26 Feb 87 18:54:46 EST Received: by rutgers.edu; Thu, 26 Feb 87 17:46:33 EST ----- End forwarded message ----- OZ sent to MC via CHAOS/MAIL. MC sent to AI via CHAOS/SMTP. Feel free to fix JOBDEV;CHAOS MAIL to include stamps. Maybe even fix both programs to identify themselves properly so that people besides me recognize this.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 1 Mar 87 14:33:33 EST Received: from REAGAN.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 1 MAR 87 14:32:23 EST Received: from MARLEY.AI.MIT.EDU (MARLEY.AI.MIT.EDU) by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 25693; 1 Mar 87 14:29:53 EST Date: Sun, 1 Mar 87 14:30 EST From: David Vinayak Wallace Subject: Different mailers for different hosts? To: bug-mail@MC.LCS.MIT.EDU Message-ID: <870301143010.3.GUMBY@MARLEY.AI.MIT.EDU> Why does the received: line which MC added not include the address of the sending host while the Received: line which AI added does? ----- Forwarded message follows ----- Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 1 Mar 87 07:22:46 EST Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 1 MAR 87 07:08:39 EST Received: from EDDIE.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 1 Mar 87 07:04-EST Received: by EDDIE.MIT.EDU (5.31/4.7) id AA06585; Thu, 26 Feb 87 18:54:46 EST Received: by rutgers.edu; Thu, 26 Feb 87 17:46:33 EST ----- End forwarded message -----  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 24 Feb 87 21:42:19 EST Date: Tue, 24 Feb 1987 21:40 EST Message-ID: From: Rob Austein To: Richard Mlynarik Cc: Bug-COMSAT@AI.AI.MIT.EDU Subject: Dear Mr Mail Wizard In-reply-to: Msg of 24 Feb 1987 17:42-EST from Richard Mlynarik Date: Tuesday, 24 February 1987 17:42-EST From: Richard Mlynarik To: sra@XX.LCS.MIT.EDU Re: Dear Mr Mail Wizard Insert standard flame about sending mail directly to me instead of to Bug-COMSAT.... Could you please explain what the first entry in comsat's log means? (The second one is just here for comparison) Are all messages from un*x boxes automatically dumped on the floor? 144605 InReq: 1 > 1; SPECS:{NET-MAIL-FROM: APPLE-JACKS.AI.MIT.EDU}{RTP:mly@apple-jacks.ai.mit.edu}{TL=1350.}{HDR-FROM:mly@APPLE-JACKS.AI.MIT.EDU} ID=<159013.870224@AI.AI.MIT.EDU> EXP->FEATURE-ENTENNMANS@1200400006::={IGNORED} 144607 CMSG ID=<159014.870224@AI.AI.MIT.EDU> EXP->mly@apple-jacks.ai.mit.edu@20015020017 144608 ICP->APPLE-JACKS.AI.MIT.EDU (TCP-SMTP) 144616 TO->mly@apple-jacks.ai.mit.edu ;;; I never received any mail addressed to mly@apple-jacks, BTW ;;; But this one won: 172427 InReq: 1 > 1; SPECS:{NET-MAIL-FROM: REAGAN.AI.MIT.EDU}{TL=1378.}{HDR-FROM:MLY@AI.AI.MIT.EDU} ID=<159074.870224@AI.AI.MIT.EDU> EXP->FEATURE-ENTENMANNS@1200400006::=(ALAN@1200400006,CENT@1200400006,ED@1200400006,GSB@1200400006::=(GSB@1200400006,GSB%JASPER@40700030303),HIC@30002424620,MLY@1200400006,MOON@1200400006::=(MOON@30002424620),RDZ@1200400006::=(RDZ@1200400006,RDZ@4402000065),SASHA@1200400006::=(sasha@1201000006),JTW@1200400006::=(jtw@40700012035),SRA@1200400006::=(SRA@40700002420)) Sorry if I'm being excessively ignorant.. No, you're not being excessively ignorant. I've seen this before and I've never known exactly what caused it. The code that produces this "::={IGNORED}" message has the enlightening comment "Pseudo-ing without eqv'ing". The context is RCPT processing. Since the code comes to this conclusion by seeing that register B is zero, it may well be that some path through this code bashes register B and this message is totally bogus. Or it may be that apple-jacks used a different syntax in the address it was sending (like "feature-entenmanns@ai@ai" or some such lossage). This kind of thing is hard to debug, because you really need to see the SMTP dialog or the .MAIL.;MAIL file to know what's losing. Can you consistantly produce this? Try sending to MLY@AI from apple-jacks, or something like that. The CMSG code is known to be broken, so it's not surprising that you never got anything at apple-jacks in response to the first message. --Mr. Mail Wizard  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 20 Feb 87 11:38:53 EST Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 20 Feb 87 10:59:59 EST Date: Fri, 20 Feb 87 10:59:37 EST From: Jonathan A Rees Subject: "unknown recipient" or "unrecognized domain"? To: BUG-comsat@MC.LCS.MIT.EDU Message-ID: <157174.870220.JAR@AI.AI.MIT.EDU> COMSAT gets better and better all the time. However, if I remember correctly (a dubious premise), one formerly got an informative message when sending to an unknown host, something like "unrecognized host/domain". Now it seems to just say "unknown recipient", and I had to reflect for a minute to realize the message was from COMSAT and not from the receiving host. Is my memory wrong? If not, what happened? [The problem below is that host name BASS.NOSC.MIL is no longer a recognized alias for NOSC.MIL. Also note the rather peculiar "To:" line.] Thanks, Jonathan Date: Fri, 20 Feb 87 10:48:03 EST From: Communications Satellite To: "JAR@AI.AI.MIT.EDU" at AI.AI.MIT.EDU Re: Msg of Friday, 20 February 1987 10:44-EST ============ A copy of your message is being returned, because: ============ "MARCHETT@BASS.NOSC.MIL" at MC.LCS.MIT.EDU is an unknown recipient. This name came from the expansion of (@FILE [JAR;SCHEME LIST]), from SCHEME "PRIEBE@BASS.NOSC.MIL" at MC.LCS.MIT.EDU is an unknown recipient. This name came from the expansion of (@FILE [JAR;SCHEME LIST]), from SCHEME ============ Failed message follows: ============  Received: from MIT-MULTICS.ARPA (TCP 1200000006) by AI.AI.MIT.EDU 19 Feb 87 19:17:35 EST Date: Thu, 19 Feb 87 19:06 EST From: "Roger A. Roach" Subject: Re: Looping Dead mail (sic) To: Bug-COMSAT@AI.AI.MIT.EDU cc: STEPHEN@RPICICGE.BITNET (Timothy Stephen), Dead-Heads-Request@AI.AI.MIT.EDU, Dead-Flame-Request@AI.AI.MIT.EDU, Postmaster@MIT-MULTICS.ARPA In-Reply-To: Message of 19 Feb 87 16:18 EST from "Rob Austein" Message-ID: <870220000644.228986@MIT-MULTICS.ARPA> These messages are some that we have been manually returning as ITSMTS.RPI @ CSV.RPI has not been responding for weeks and our queue is filling up. The capability to return mail is new and may not be modifying headers correctly. I'll stop returning the mail and will delete it instead. Can someone take the RPI user(s) off of the mailing list (or at least not route it through MIT-Multics). They may have been routed to us as a RPI used to be a MAILNET site, but it isn't anymore. Sorry and thanks.  Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 30002424620) by AI.AI.MIT.EDU 19 Feb 87 16:53:08 EST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 74392; Thu 19-Feb-87 16:50:38 EST Date: Thu, 19 Feb 87 16:49 EST From: David A. Moon Subject: Looping Dead mail (sic) To: Bug-COMSAT@AI.AI.MIT.EDU cc: Timothy Stephen , Dead-Heads-Request@AI.AI.MIT.EDU, Dead-Flame-Request@AI.AI.MIT.EDU, Postmaster@MULTICS.MIT.EDU In-Reply-To: Message-ID: <870219164900.0.MOON@EUPHRATES.SCRC.Symbolics.COM> When I've seen this happen in the past, it was because the foreign mail server would receive the message and die without ever saying it had delivered it (i.e. sending an SMTP reply to the TEXT (I think) command), although in fact it had delivered it. Then of course Comsat would try again later. After some number of tries Comsat eventually gives up and returns the mail to sender. Of course it could also be happening at a later step in the chain, after Comsat is no longer involved. Between the received lines and mailer stats files it should be possible to figure this out.  Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 30002424620) by AI.AI.MIT.EDU 19 Feb 87 16:46:42 EST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 74387; Thu 19-Feb-87 16:44:24 EST Date: Thu, 19 Feb 87 16:42 EST From: David A. Moon To: Rob Austein cc: BUG-COMSAT@AI.AI.MIT.EDU In-Reply-To: <156698.870219.SRA@AI.AI.MIT.EDU> Message-ID: <870219164257.9.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Thu, 19 Feb 87 15:42:31 EST From: Rob Austein There seems to be an awful lot of stuff in AI's queue. I had to have the queue listing delivered to XX because MC wouldn't accept such a large message. See MC: SRA; AI MAIL.Q. Looks like it was all queued today, so I think this doesn't show anything wrong with Comsat, it only shows that poor little AI is being abused to do work that is properly the business of MC, namely mailing list distribution.  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 19 Feb 87 16:19:00 EST Date: Thu, 19 Feb 1987 16:18 EST Message-ID: From: Rob Austein To: STEPHEN%RPICICGE%MULTICS.MIT.EDU@XX.LCS.MIT.EDU (Timothy Stephen) Cc: Bug-COMSAT@AI.AI.MIT.EDU, Dead-Heads-Request@AI.AI.MIT.EDU, Dead-Flame-Request@AI.AI.MIT.EDU, Postmaster@MULTICS.MIT.EDU Reply-To: Bug-COMSAT@AI.AI.MIT.EDU Subject: Looping Dead mail (sic) In-reply-to: Msg of 19 Feb 1987 10:55-EST from STEPHEN@RPICICGE (Timothy Stephen) Rcvd-Date: 19-Feb-87 14:43:39-EST Return-Path: <@MIT-MULTICS.ARPA:STEPHEN@RPICICGE.BITNET> Received: from MIT-MULTICS.ARPA by XX.LCS.MIT.EDU with TCP; Thu 19 Feb 87 14:43:23-EST Received: from RPICICGE(MAILER) by MITVMA (Mailer X1.23) id 0813; Thu, 19 Feb 87 11:19:49 EST Received: by RPICICGE (Mailer X1.23) id 5976; Thu, 19 Feb 87 10:56:17 EST Date: Thu, 19 Feb 87 10:55:21 EST From: STEPHEN@RPICICGE (Timothy Stephen) To: sra@xx.lcs.mit.edu Date: Thu, 19 Feb 87 10:50:29 EST From: STEPHEN@RPICICGE (Timothy Stephen) To: sra@xx.lcs.mit.edu [Yes, this really is what the headers of the message I got looked like!] I have stopped receiving copies of the note that I mentioned yesterday and do not have a copy on file to send you. I am now receiving copies of a new note (over 40 so far) but its headers are not the same as the other one and don't mention "network_server" but perhaps you could suggest who to contact ... A copy is appended. Return-Path: @MIT-MULTICS.ARPA,@AI.AI.MIT.EDU:Mellis%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU Received: from AI.AI.MIT.EDU by MIT-MULTICS.ARPA TCP; 19-Feb-1987 01:22:38-est Received: from OZ.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 18 FEB 87 23:12:36 EST Date: Wed, 18 Feb 1987 23:02 EST Message-ID: Sender: MLY.G.AGM%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU From: "Adam G. Mellis" Subject: bagpipes To: dead-flames@AI.AI.MIT.EDU I remember seeing a bootleg record that listed amoung its songs: The Eleven (w/ bagpipes). Is this the same show (it was early 70s)? Adam Timothy, Thanks for the report. It looks like something is seriously wrong here. Either AI's mail queue has multiple copies of the same message (with idenitical Messages-IDs!) or the binary queue file is messed up and needs to be rebuilt. Have any of the Dead-mumble lists been changed recently in a way that could cause multiple messages? Have any of the old COMSAT hackers seen this lossage before? Somebody should manually dequeue the offending messages at some point. I'm not doing it now because I have no idea what will happen when I tell it to delete the message with message-ID foo and it finds multiple instances. If anybody is feeling more energetic than I am (ie, doesn't have the Scandinavian Death Flu I picked up at Boskone), this might be worth some detective work to figure out what happened. --Rob  Date: Thu, 19 Feb 87 15:42:31 EST From: Rob Austein To: BUG-COMSAT@AI.AI.MIT.EDU Message-ID: <156698.870219.SRA@AI.AI.MIT.EDU> There seems to be an awful lot of stuff in AI's queue. I had to have the queue listing delivered to XX because MC wouldn't accept such a large message. See MC: SRA; AI MAIL.Q.  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 7 Feb 87 20:04:53 EST Date: Sat, 7 Feb 1987 18:45 EST Message-ID: From: Rob Austein To: "David A. Moon" Cc: BUG-MAIL@AI.AI.MIT.EDU, "Pandora B. Berman" , CJL@B.AI.MIT.EDU Subject: symbolics runs amok In-reply-to: Msg of 6 Feb 1987 13:52-EST from David A. Moon The problem was a bad inquire entry on AI and a bad mailing list entry on OZ. Both have been fixed so things should be ok now. HQM should not be doing random and intricate things with his mail forwarding if he can't remember afterwards what it is he has done. This has got to be the most flamage generated by a user error that I have seen in a long time.  Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 30002424620) by AI.AI.MIT.EDU 7 Feb 87 17:04:14 EST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 64228; Fri 6-Feb-87 13:52:33 EST Date: Fri, 6 Feb 87 13:52 EST From: David A. Moon Subject: symbolics runs amok To: Pandora B. Berman cc: SRA@XX.LCS.MIT.EDU, BUG-MAIL@AI.AI.MIT.EDU, CJL@AI.AI.MIT.EDU In-Reply-To: <150068.870206.CENT@AI.AI.MIT.EDU> Message-ID: <870206135236.6.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Fri, 6 Feb 87 05:04:18 EST From: Communications Satellite Subject: Msg of Friday, 6 February 1987 05:04-EST To: CENT@AI.AI.MIT.EDU FAILED: hqm at SCRC-STONY-BROOK.ARPA; Recipient name apparently rejected. Last reply was: {550 Recipient hqm@STONY-BROOK.SCRC.Symbolics.COM is not defined on this host.} ...they don't know who they are! I think you're just being misled by two different names for the same host being put into the error message, one by AI and the other by Stony. It really is true that HQM does not have a mailbox here, since he doesn't work here any more. I think he left two or three months ago, although I could be wrong about the date.  Date: Fri, 6 Feb 87 05:11:01 EST From: "Pandora B. Berman" Subject: symbolics runs amok To: SRA@XX.LCS.MIT.EDU cc: CENT@AI.AI.MIT.EDU, BUG-MAIL@AI.AI.MIT.EDU, CJL@AI.AI.MIT.EDU Message-ID: <150068.870206.CENT@AI.AI.MIT.EDU> Date: Fri, 6 Feb 1987 04:38 EST From: Rob Austein To: "Pandora B. Berman" Cc: BUG-MAIL@AI.AI.MIT.EDU, CJL@AI.AI.MIT.EDU Subject: symbolics runs amok Date: Friday, 6 February 1987 04:19-EST From: "Pandora B. Berman" this looks like a variant on the unix "i refuse to talk to myself" gambit. ---------- Date: Fri 6 Feb 87 02:46:24-EST From: The Mailer Daemon hqm@SCRC-STONY-BROOK.ARPA.Internet: 550 Recipient hqm@STONY-BROOK.SCRC.Symbolics.COM is not defined on this host. No, it's a user error on HQM's part. Take a look at his AI INQUIR entry. ---------- alas, it's not that. i mailed the following directly from AI to HQM@SCRC, and as you can see it was returned with the same error. they changed their ^&^&$%! primary host name, and now they don't know who they are! ---------- Date: Fri, 6 Feb 87 05:04:18 EST From: Communications Satellite Subject: Msg of Friday, 6 February 1987 05:04-EST To: CENT@AI.AI.MIT.EDU FAILED: hqm at SCRC-STONY-BROOK.ARPA; Recipient name apparently rejected. Last reply was: {550 Recipient hqm@STONY-BROOK.SCRC.Symbolics.COM is not defined on this host.} Failed message follows: ------- [failed msg omitted]  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 6 Feb 87 04:39:21 EST Date: Fri, 6 Feb 1987 04:38 EST Message-ID: From: Rob Austein To: "Pandora B. Berman" Cc: BUG-MAIL@AI.AI.MIT.EDU, CJL@AI.AI.MIT.EDU Subject: symbolics runs amok In-reply-to: Msg of 6 Feb 1987 04:19-EST from "Pandora B. Berman" Date: Friday, 6 February 1987 04:19-EST From: "Pandora B. Berman" this looks like a variant on the unix "i refuse to talk to myself" gambit. ---------- Date: Fri 6 Feb 87 02:46:24-EST From: The Mailer Daemon hqm@SCRC-STONY-BROOK.ARPA.Internet: 550 Recipient hqm@STONY-BROOK.SCRC.Symbolics.COM is not defined on this host. No, it's a user error on HQM's part. Take a look at his AI INQUIR entry.  Date: Fri, 6 Feb 87 04:19:38 EST From: "Pandora B. Berman" Subject: symbolics runs amok To: CJL@AI.AI.MIT.EDU cc: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <150051.870206.CENT@AI.AI.MIT.EDU> this looks like a variant on the unix "i refuse to talk to myself" gambit. ---------- Received: from OZ.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 6 FEB 87 02:50:13 EST Date: Fri 6 Feb 87 02:46:24-EST From: The Mailer Daemon To: CENT@AI.AI.MIT.EDU Subject: Message of 6-Feb-87 02:46:16 Message failed for the following: hqm@SCRC-STONY-BROOK.ARPA.Internet: 550 Recipient hqm@STONY-BROOK.SCRC.Symbolics.COM is not defined on this host. ------------ Received: from AI.AI.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet with SMTP; 6 Feb 87 02:46-EST Date: Fri, 6 Feb 87 02:46:39 EST From: "Pandora B. Berman" Subject: AI dialups To: USER-ACCOUNTS@AI.AI.MIT.EDU, HQM@AI.AI.MIT.EDU [msg text omitted]  Date: Mon, 2 Feb 87 11:51:53 EST From: David Vinayak Wallace Subject: [COMSAT: Msg of Sunday, 1 February 1987 20:52-EST] To: ZVONA@AI.AI.MIT.EDU cc: BUG-MAIL@AI.AI.MIT.EDU In-reply-to: Msg of Sun 1 Feb 87 21:03:17 EST from David Chapman Message-ID: <147921.870202.GUMBY@AI.AI.MIT.EDU> Date: Sun, 1 Feb 87 21:03:17 EST From: David Chapman This is a new behavior. This worked last time I sent to the list (some time in the fall) and the list hasn't changed since. That the lossage came from the expansion of a mailing list rather than a direct to: shows that the problem is in comsat, not babyl. (Right?) Date: Sun, 1 Feb 87 20:53:20 EST From: Communications Satellite To: ZVONA at AI.AI.MIT.EDU Re: Msg of Sunday, 1 February 1987 20:52-EST ============ A copy of your message is being returned, because: ============ "KAYVAN%CORY@BERKELEY" at AI.AI.MIT.EDU is an unknown recipient. This name came from the expansion of PAGANISM "OSTER%LAPIS@BERKELEY" at AI.AI.MIT.EDU is an unknown recipient. This name came from the expansion of PAGANISM ============ Failed message follows: ============ Wasn't there a recent system message about the fact that the non-domain names were going to be flushed? There's no longer any host called "Berkeley" but there is one called "Berkeley.EDU". The reason the error message is so weird is that when comsat fails to find the host it attempts to use the whole string as an address (I happen to feel that this heuristic is in questionable taste myself). You can suppress this by using the syntax ("foo%bar" @baz.dom). This will improve your error message, but of course not help the mail get delivered unless there really is such a host.  Date: Sun, 1 Feb 87 21:03:17 EST From: David Chapman Subject: [COMSAT: Msg of Sunday, 1 February 1987 20:52-EST] To: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <147636.870201.ZVONA@AI.AI.MIT.EDU> This is a new behavior. This worked last time I sent to the list (some time in the fall) and the list hasn't changed since. That the lossage came from the expansion of a mailing list rather than a direct to: shows that the problem is in comsat, not babyl. (Right?) Date: Sun, 1 Feb 87 20:53:20 EST From: Communications Satellite To: ZVONA at AI.AI.MIT.EDU Re: Msg of Sunday, 1 February 1987 20:52-EST ============ A copy of your message is being returned, because: ============ "KAYVAN%CORY@BERKELEY" at AI.AI.MIT.EDU is an unknown recipient. This name came from the expansion of PAGANISM "OSTER%LAPIS@BERKELEY" at AI.AI.MIT.EDU is an unknown recipient. This name came from the expansion of PAGANISM ============ Failed message follows: ============ Date: Sun, 1 Feb 87 20:52:17 EST From: David Chapman Subject: MIT Pagan Students Group To: DEVON@AI.AI.MIT.EDU cc: PAGANISM@AI.AI.MIT.EDU, dmh@BORAX.LCS.MIT.EDU, elbows@BORAX.LCS.MIT.EDU, tanstaafl@BORAX.LCS.MIT.EDU, lectroids@LLL-CRG.ARPA In-reply-to: Msg of Sun 1 Feb 87 19:03:36 EST from Devon S. McCullough Message-ID: <147633.870201.ZVONA@AI.AI.MIT.EDU> There's also an (even less active) mailing list mit-psg@ai.ai.mit.edu for PSG announcements. Mail to me to be added.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 31 Jan 87 17:00:15 EST Date: Sat, 31 Jan 87 17:01:01 EST From: Alan Bawden Subject: TCP buffers To: BUG-ITS@MC.LCS.MIT.EDU, BUG-COMSAT@MC.LCS.MIT.EDU Message-ID: <165683.870131.ALAN@MC.LCS.MIT.EDU> I wish we could figure out why ITS consistently dribbles away its TCP buffers until there are none left. I also wish that when this happens, COMSAT didn't exhibit this bizare behavior: 162430 Unqueueing to host THEORY.LCS.MIT.EDU 162431 ICP->THEORY.LCS.MIT.EDU (TCP-SMTP=Bad Greeting="221 BCNU") 162432 Unqueueing to host RED.RUTGERS.EDU 162433 ICP->RED.RUTGERS.EDU (TCP-SMTP=Bad Greeting="221 BCNU") 162434 Unqueueing to host BRL-SEM.ARPA 162435 ICP->BRL-SEM.ARPA (TCP-SMTP=Bad Greeting="221 BCNU") 162435 Unqueueing to host LBL.ARPA 162436 ICP->LBL.ARPA (TCP-SMTP=Bad Greeting="221 BCNU") 162437 Unqueueing to host SDCSVAX.UCSD.EDU 162438 ICP->SDCSVAX.UCSD.EDU (TCP-SMTP=Bad Greeting="221 BCNU") 162439 Unqueueing to host R20.UTEXAS.EDU 162440 ICP->R20.UTEXAS.EDU (TCP-SMTP=Bad Greeting="221 BCNU") 162441 Unqueueing to host SAIL.STANFORD.EDU 162442 ICP->SAIL.STANFORD.EDU (TCP-SMTP=Bad Greeting="221 BCNU") 162444 Unqueueing to host ATHENA.MIT.EDU 162444 ICP->ATHENA.MIT.EDU (TCP-SMTP=Bad Greeting="221 BCNU") 162445 Unqueueing to host CHARON.MIT.EDU 162446 ICP->CHARON.MIT.EDU (TCP-SMTP=Bad Greeting="221 BCNU")  Date: Fri, 30 Jan 87 16:33:49 EST From: David Chapman Subject: the oddessy continues To: BATALI@AI.AI.MIT.EDU cc: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <146967.870130.ZVONA@AI.AI.MIT.EDU> Now (I see) your mail is coming from flair-20, not spar-20... Still loosing. I'll add flair-20 and flair-20.arpa as nicknames for spar-20. (But why doesn't your machine make up its mind about what it's called? Why, in fact, hasn't the acronym FLAIR been eradicated?) Date: Fri, 30 Jan 87 16:27:52 EST From: Communications Satellite To: ZVONA at AI.AI.MIT.EDU Re: Msg of Friday, 30 January 1987 16:27-EST ============ A copy of your message is being returned, because: ============ "BATALI@FLAIR-20" at AI.AI.MIT.EDU is an unknown recipient. ============ Failed message follows: ============ Date: Fri, 30 Jan 87 16:27:52 EST From: David Chapman Subject: final test To: "BATALI@FLAIR-20"@AI.AI.MIT.EDU In-reply-to: Msg of Fri 30 Jan 1987 12:48 PST from John Batali Message-ID: <146958.870130.ZVONA@AI.AI.MIT.EDU> Date: Fri, 30 Jan 1987 12:48 PST From: John Batali To: zvona at mc Re: final test Please reply to this message to see what happens. As far as I can tell, things are working. I've tested oz, ai, mc, xx and speech. Sorry for the trouble it took. But I thank you. All of Spar thanks you. Well, this message came from batali@flair-20, no .arpa (which was the problem last time. The .arpa should be working now. Also your name is no longer ???, which must please you...  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 29 Jan 87 01:19:15 EST Date: Thu, 29 Jan 1987 00:21 EST Message-ID: From: Rob Austein To: David Chapman Cc: BUG-MAIL@AI.AI.MIT.EDU Subject: spar-20.arpa Date: Thursday, 29 January 1987 00:11-EST From: David Chapman To: GUMBY@AI.AI.MIT.EDU cc: BUG-MAIL@AI.AI.MIT.EDU Re: spar-20.arpa Then, is the following from syshst;-this- -too- incorrect, or am I misreading it? One other note: the redundant nicknames for machines have been removed. Ie, where there used to be an entry listing names "MIT-XX.ARPA, MIT-XX, XX", there will now be an entry that only lists "XX". The filters can cons up this kind of trivial name easily, and it turned out to be a lot easier to add the "MIT-"s and ".ARPA"s in the right places than to remove them from the wrong ones. If you re-read this paragraph you will see why HSTXXX does not get this kind of name expansion. Unless of course you want to send mail to MIT-SPAR-20.ARPA, which would, I admit, be kind of interesting.  Date: Thu, 29 Jan 87 00:11:06 EST From: David Chapman Subject: spar-20.arpa To: GUMBY@AI.AI.MIT.EDU cc: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <146202.870129.ZVONA@AI.AI.MIT.EDU> Then, is the following from syshst;-this- -too- incorrect, or am I misreading it? One other note: the redundant nicknames for machines have been removed. Ie, where there used to be an entry listing names "MIT-XX.ARPA, MIT-XX, XX", there will now be an entry that only lists "XX". The filters can cons up this kind of trivial name easily, and it turned out to be a lot easier to add the "MIT-"s and ".ARPA"s in the right places than to remove them from the wrong ones.  Date: Wed, 28 Jan 87 23:28:31 EST From: David Vinayak Wallace Subject: Question marks To: ZVONA@AI.AI.MIT.EDU cc: BATALI@AI.AI.MIT.EDU, BUG-MAIL@AI.AI.MIT.EDU In-reply-to: Msg of Wed 28 Jan 87 17:24:39 EST from David Chapman Message-ID: <146180.870128.GUMBY@AI.AI.MIT.EDU> "BATALI@SPAR-20.ARPA" at AI.AI.MIT.EDU is an unknown recipient. ============ Failed message follows: ============ Date: Wed, 28 Jan 87 16:58:55 EST From: David Chapman Date: Wed, 28 Jan 87 13:00 PST From: ??? To: ZVONA at mc Re: spar-20 Do you know when the "magic" propagation to other MIT machines will happen? It has propagated to all interesting machines except possibly XX, which I can't log into to find out. SPAR-20 was put into the host table but not SPAR-20.ARPA which is what you sent to. Any idea why your from: field is "???"? Looks like that's a problem at your end. Don't worry about this; everything outside the <>'s is comment anyway. MM and BABYL under twenex each have variables for setting this string.  Date: Wed, 28 Jan 87 17:24:39 EST From: David Chapman Subject: [COMSAT: Msg of Wednesday, 28 January 1987 16:58-EST] To: BATALI@AI.AI.MIT.EDU cc: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <146062.870128.ZVONA@AI.AI.MIT.EDU> Date: Wed, 28 Jan 87 16:58:57 EST From: Communications Satellite To: ZVONA at AI.AI.MIT.EDU Re: Msg of Wednesday, 28 January 1987 16:58-EST ============ A copy of your message is being returned, because: ============ "BATALI@SPAR-20.ARPA" at AI.AI.MIT.EDU is an unknown recipient. ============ Failed message follows: ============ Date: Wed, 28 Jan 87 16:58:55 EST From: David Chapman Subject: spar-20 To: "BATALI@SPAR-20.ARPA"@AI.AI.MIT.EDU In-reply-to: Msg of Wed 28 Jan 87 13:00 PST from ??? Message-ID: <146041.870128.ZVONA@AI.AI.MIT.EDU> Date: Wed, 28 Jan 87 13:00 PST From: ??? To: ZVONA at mc Re: spar-20 Do you know when the "magic" propagation to other MIT machines will happen? It has propagated to all interesting machines except possibly XX, which I can't log into to find out. Any idea why your from: field is "???"? Looks like that's a problem at your end.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 27 Jan 87 15:40:21 EST Received: from zarathustra.think.com (TCP 1201000006) by MC.LCS.MIT.EDU 27 Jan 87 14:54:29 EST Received: from erato.Think.COM by zarathustra.think.com; Tue, 27 Jan 87 14:40:20 EST Received: by erato.Think.COM; Tue, 27 Jan 87 14:40:59 EST Date: Tue, 27 Jan 87 14:40:59 EST From: nesheim@Think.COM Message-Id: <8701271940.AA01733@erato.Think.COM> To: JAR@ai.ai.mit.edu Subject: Re: [COMSAT: Msg of Monday, 26 January 1987 11:53-EST] Cc: bug-mail@mc.lcs.mit.edu, postmaster@think.com Yes, the route was strange. Our mailer was temporarily confuzed. It should be OK now. Bill Nesheim  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 27 Jan 87 00:12:21 EST Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 26 Jan 87 23:19:16 EST Date: Mon, 26 Jan 87 19:12:49 EST From: Jonathan A Rees Subject: [COMSAT: Msg of Monday, 26 January 1987 11:53-EST] To: postmaster@ZARATHUSTRA.THINK.COM, BUG-mail@MC.LCS.MIT.EDU cc: gls@ZARATHUSTRA.THINK.COM Message-ID: <145099.870126.JAR@AI.AI.MIT.EDU> I tried sending mail to "GLS@AI.AI.MIT.EDU", which should simply forward to GLS@THINK.COM, and got the below lossage. This has worked within the past month but now seems to lose. It certainly took an interesting route. -Jonathan Date: Mon, 26 Jan 87 11:53:11 EST From: Communications Satellite To: "@ai.ai.mit.edu:JAR@ai.ai.mit.edu" at Think.COM Re: Msg of Monday, 26 January 1987 11:53-EST Message-Id: <144921.870126@AI.AI.MIT.EDU> ============ A copy of your message is being returned, because: ============ "GLS@AI.AI.MIT.EDU.JAR" at AI.AI.MIT.EDU is an unknown recipient. ============ Failed message follows: ============ Received: from zarathustra.think.com (TCP 1201000006) by AI.AI.MIT.EDU 26 Jan 87 11:52:59 EST Received: from Godot.Think.COM by zarathustra.think.com; Mon, 26 Jan 87 11:53:20 EST Received: from zarathustra.think.com by Godot.Think.COM; Mon, 26 Jan 87 11:53:12 EST Received: from AI.AI.MIT.EDU by zarathustra.think.com; Mon, 26 Jan 87 11:53:02 EST Received: from zarathustra.think.com (TCP 1201000006) by AI.AI.MIT.EDU 26 Jan 87 11:51:41 EST Received: from Godot.Think.COM by zarathustra.think.com; Mon, 26 Jan 87 11:52:10 EST Received: from zarathustra.think.com by Godot.Think.COM; Mon, 26 Jan 87 11:38:31 EST Received: from AI.AI.MIT.EDU by zarathustra.think.com; Mon, 26 Jan 87 11:38:24 EST Date: Mon, 26 Jan 87 11:37:28 EST From: Jonathan A Rees Subject: mail lossage To: GLS@ai.ai.mit.edu Message-Id: <144909.870126.JAR@AI.AI.MIT.EDU> A recent message to you bounced. This is a test to see whether the problem is reproducible. You needn't reply since if it doesn't bounce I'll assume it got through (although you may reply if you wish). -Jonathan  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 26 Jan 87 16:51:31 EST Date: Mon, 26 Jan 1987 16:51 EST Message-ID: From: Rob Austein To: David Chapman Cc: BUG-MAIL@AI.AI.MIT.EDU In-reply-to: Msg of 26 Jan 1987 16:17-EST from David Chapman Date: Monday, 26 January 1987 16:17-EST From: David Chapman Sender: ___015@AI.AI.MIT.EDU To: BUG-MAIL@AI.AI.MIT.EDU users3;rg@oz mail Well, I suppose somebody might have typed [RG@OZ] or something like that.  Date: Mon, 26 Jan 87 16:17:40 EST From: David Chapman Sender: ___015@AI.AI.MIT.EDU To: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <145008.870126.___015@AI.AI.MIT.EDU> users3;rg@oz mail ?  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 22 Jan 87 20:30:09 EST Date: Thu, 22 Jan 1987 20:28 EST Message-ID: From: Rob Austein To: Bug-Comsat@AI.AI.MIT.EDU Subject: new COMSAT With fixed multi-line SMTP reply parsing. Installed on all machines, rebooted on some. See STATS file if you care.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 22 Jan 87 16:05:26 EST Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 22 Jan 87 16:05:39 EST Date: Thu, 22 Jan 1987 16:04 EST Message-ID: From: Rob Austein To: "David A. Moon" Cc: Bug-COMSAT@MC.LCS.MIT.EDU, Bug-Mailer@SCRC-STONY-BROOK.ARPA Subject: Bug in parsing CHAOS-SMTP multiline replies In-reply-to: Msg of 22 Jan 1987 01:43-EST from David A. Moon Date: Thursday, 22 January 1987 01:43-EST From: David A. Moon Date: Wed, 21 Jan 1987 02:12 EST From: Rob Austein The reverse path itself is ok. Ie, <@MC.LCS.MIT.EDU:emer@lcs.mit.edu> is a correct return path ... I think this reverse path is one of those that is technically legal but doesn't actually work yet in most implementations. Not so. Most mailers do implement this in the SMTP layer (otherwise nobody would ever get error reports anymore). The RFC822 headers and the average mail composer are something else again, there I suspect you are right. And of course many of the implementations at the SMTP layer are buggy. I'm not sure what you mean by questionable taste. Is all data sent through SMTP supposed to be in a least-common-denominator character set? In a word, yes, if you buy Mills' Principle of Least Astonishment. There is no specific injunction to do so in RFC821, but sending error messages that only people with special hardware can read seems pretty tasteless to me. I'll check with RWS ior CJL about the Lispm path-parsing bug. Thanks. The COMSAT bug has now been fixed, I think. The NTRPLY code was totally random, twice as long as it should have been and did the wrong thing. All I can say is I wish I had some of whatever the author was smoking at the time. I put up a new version of COMSAT on MD, it seems to work (it now reads enough of the message from REAGAN to run out of reply buffer, which it handles properly). I want to test it a little more before declaring this version debugged. I'll send a short message when that happens.  Date: Thu, 22 Jan 87 04:16:36 EST From: Alan Bawden Subject: PEEK shouldn't ever PCLSR anyone To: BUG-COMSAT@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU In-reply-to: Msg of Wed 21 Jan 1987 00:25 EST from Rob Austein Message-ID: <143202.870122.ALAN@AI.AI.MIT.EDU> After fixing PEEK to not needlessly PCLSR device servers a few days ago, I have been periodically watching COMSAT and DQDEV on MC waiting to catch them in the act of getting hung up. This afternoon I found them in the wedged state and was able to figure out what causes the problem. The problem has nothing to do with the BOJ/JOB code, and is not a bug in DQDEV. Actually it is an apparently long-standing timing error in the implementation of .HANG. Specifically, when you did (as DQDEV does) TRNN AC,%FLAG .HANG the code for .HANG knew that the TRNN instruction could never skip unless the C(AC) changed, and since nothing can change a job's accumulators without PCLSRing the job, .HANG could simply hang forever. This is all well and good, except .HANG neglected to run the instruction once itself to be certain that AC hadn't been changed by an interrupt routine that ran -between- the TRNN and the .HANG. I have assembled an ITS with the fix and I will test it the next time I get a chance.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 22 Jan 87 01:46:24 EST Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 30002424620) by MC.LCS.MIT.EDU 22 Jan 87 01:46:32 EST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 48883; Thu 22-Jan-87 01:46:22 EST Date: Thu, 22 Jan 87 01:43 EST From: David A. Moon Subject: Bug in parsing CHAOS-SMTP multiline replies To: Rob Austein cc: BUG-COMSAT@MC.LCS.MIT.EDU, Bug-LISPM%XX.LCS.MIT.EDU@MC.LCS.MIT.EDU, bug-mailer@STONY-BROOK.SCRC.Symbolics.COM In-Reply-To: Message-ID: <870122014343.1.MOON@EUPHRATES.SCRC.Symbolics.COM> I don't intend to send any more mail in this conversation, but I thought I ought to clear up one thing. Date: Wed, 21 Jan 1987 02:12 EST From: Rob Austein Date: Sunday, 18 January 1987 22:24-EST From: "David A. Moon" I saw this in the STATS file: 091917 Unqueueing to host ZERMATT.LCS.MIT.EDU 091918 ICP->ZERMATT.LCS.MIT.EDU (CHAOS-SMTP) 091918 QID=<154990.870112@MC.LCS.MIT.EDU>...error for <@MC.LCS.MIT.EDU:emer@lcs.mit.edu>="501- Bad reverse path: In "FROM:<@MC.LCS.MIT.EDU:emer@lcs.mit.edu>", 501- ", trying <>....init lost, R="501 and no namespace server was contacted because validity checking is inhibited.." 091920 Unqueueing to host WHARTON-10.ARPA The reverse path really is bad, or at least funny-looking, but that's not the bug. It looks to me like Comsat read the first 2 lines of a 3-line reply and thought it had all of it. Then it sent another command and read the third line, thinking it was an error for the second command. The reverse path itself is ok. Ie, <@MC.LCS.MIT.EDU:emer@lcs.mit.edu> is a correct return path that would be generated by Joel Emer sending a message via MC; unfortunately this name ("lcs.mit.edu") is not in the ITS host tables for complicated reasons that I won't explain here. I think this reverse path is one of those that is technically legal but doesn't actually work yet in most implementations. The rest of this seems to be bugs in both COMSAT and Zermatt's mailer. Here is wallpaper from a chat with Zermatt's CHAOS/SMTP via TELNET from XX: 220 ZERMATT.LCS.MIT.EDU SMTP service ready. helo xx 250 ZERMATT.LCS.MIT.EDU mail from:<@mc.lcs.mit.edu:sra@lcs.mit.edu> 501- Bad reverse path: In "from:<@mc.lcs.mit.edu:sra@lcs.mit.edu>", 501- 501- The host named # was not found. 501- No host with that name is already known by the local machine, 501 and no namespace server was contacted because validity checking is inhibited.. quit 221 Goodbye. Now, I don't know what the ^K is really supposed to be (perhaps an UpArrow character pointing at what the server thinks is the begining of the bad part of the reverse-path? if so it's pointing at the "c" of MC) but whatever it is supposed to be it is in pretty questionable taste. It's an up arrow character. It's supposed to be pointing at the character after the second atsign, but there is a bug in the lispm SMTP server; it concatenates "Bad reverse path: " onto the front of the error message it got from another module, without realizing that horizontal column positions in that message might be important. We have the technology to fix this bug but I don't personally know whether we'll bother. I'm not sure what you mean by questionable taste. Is all data sent through SMTP supposed to be in a least-common-denominator character set? MIT used to have lots of terminals that could display that character, but they gave them away to an obscure student organization. There is also some question as to why Zermatt cares whether or not it can find "lcs.mit.edu": the whole point of the funny @mumble:foo@bar syntax is that Zermatt can just ship error messages back via MC without having to know about the rest of the address. Either the return-path parsing code doesn't conform to SMTP or somebody is trying to be too smart. It's not supposed to get an error when parsing that path. I did some experimentation and I think this may be caused by an MIT-specific patch. I'm not positive of that, though. The COMSAT bug is as described by Moon, above. If the buffer is overflowing, then some code which appears to report this condition in the STATS file is broken. I find it somewhat suspicious that whatever caused the truncation happened -just- after the sequence ^K^M^J (yes, I checked, those really are ascii control characters, no high order bit), but I can't find anything obvious here either. I guess somebody is going to have to single step through this code. The relevant code is in NETRTS, around NTRPLY. Bring lunch, this code is a bear. Yecch.  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 21 Jan 87 23:34:42 EST Date: Wed, 21 Jan 1987 23:34 EST Message-ID: From: Rob Austein To: Alan Bawden Cc: Bug-COMSAT@AI.AI.MIT.EDU, Mailer-Error-of-the-Day@MC.LCS.MIT.EDU Subject: Is this better than "Bus error - core dumped"? In-reply-to: Msg of 21 Jan 1987 22:24-EST from Alan Bawden Actually, Alan, that is a very interesting bug report. It indicates that the SMTP receive-a-response-line buffering code does in fact detect overflows, something I was wondering about just yesterday. How kind of CRVAX.SRI.COM to answer my question for me. To fully appreciate what is going on in this bug report, the reader is refered to a document circulated by MKL@NIC, entitled "A day in the life of the Image Invoker" or some such. I think it was on Info-COBOL about a year ago. If you can't find a copy, suffice it to say that this could only happen on the one operating system known with more special purpose frobs in the filesystem (and more orange notebooks) than TOPS-20.  Date: Wed, 21 Jan 87 22:24:55 EST From: Alan Bawden Subject: Is this better than "Bus error - core dumped"? To: BUG-COMSAT@AI.AI.MIT.EDU cc: Mailer-Error-of-the-Day@MC.LCS.MIT.EDU Message-ID: <143059.870121.ALAN@AI.AI.MIT.EDU> I just thought you might be amused at this one. I killed the enclosed message when I saw it producing the following in the STATS file: 200213 Unqueueing to host CRVAX.SRI.COM 200214 ICP->CRVAX.SRI.COM (TCP-SMTP) 200218 QID=<142359.870120@AI.AI.MIT.EDU> 200225 TO->WRING 200254 Foo: NTRBUF Overflow: {%SYSTEM-F-ACCVIO, access violation, reason mask=05, virtual address=026C9150, PC=00022426, PSL=03C00000%SYSTEM-F-ACCVIO, access violation, reason mask=05, virtual address=026C9150, PC=00022426, PSL=03C00000 Improperly handled condition, image exit f}orced. Improperly handled condition, image exit forced. Signal arguments Stack contents Signal arguments Stack contents Number = 00000005 00000029 Number = 00000005 00000029 Name = 0000000C 0003E4E1 Name = 0000000C 0003E4E1 00000005 7FF90504 00000005 7FF90504 026C9150 00000001 026C9150 00000001 00022426 00000002 00022426 00000002 03C00000 00000006 03C00000 00000006 7FF90029 7FF90029 0003E4E1 0003E4E1 020E0029 020E0029 0003E4E1 0003E4E1 Register dump Register dump R0 = 00000001 R1 = 000274F8 R2 = 0003E4E1 R3 = 0003D3DE R0 = 00000001 R1 = 000274F8 R2 = 0003E4E1 R3 = 0003D3DE R4 = 00000000 R5 = 00000000 R6 = 00000006 R7 = 7FF90454 R4 = 00000000 R5 = 00000000 R6 = 00000006 R7 = 7FF90454 R8 = 00000003 R9 = 00000002 R10= 00000000 R11= 00000000 R8 = 00000003 R9 = 00000002 R10= 00000000 R11= 00000000 AP = 7FF90404 FP = 7FF903C4 SP = 7FF90440 PC = 00022426 AP = 7FF90404 FP = 7FF903C4 SP = 7FF90440 PC = 00022426 PSL= 03C00000 PSL= 03C00000 200257 INCOMPLETE, IOC error Enclosed message (could the bad header be causing the problem?): Date: Wed, 21 Jan 87 22:15:24 EST From: Alan Bawden Sender: ALAN' at AI.AI.MIT.EDU To: ALAN at AI.AI.MIT.EDU Re: Request results Message deleted: Received: from ARDEC-LCSS.ARPA.ARPA (TCP 30003004013) by AI.AI.MIT.EDU 20 Jan 87 15:05:42 EST Date: 20 Jan 87 14:47:00 EST From: "CLSTR1::BECK" Subject: recreational math To: "cube-lovers" cc: gerritsen,mailer! Reply-To: "CLSTR1::BECK" BOOKS: Singmaster is editing a series of books for Oxford University Press on Recrreational Mathematics and is requesting input on the following: 1) " I (Singmaster) have embarked on a project to find the sources of classical problems in recreational mathematics. ..... The initial object of this project was to produce a book of sources, translated into english with annotation, for .... However, it now appears that the first stage must be the prpearation of an annotated bibliography of the material. ... draft of paper which outlines the project and some of the material is available. I would be delighted to hear from anyone interested in this project, particularly anyone able to provide info." 2) "I am also compiling a list of mathematical monuments and have a draft article on this." ADDRESS; DAVID SINGMASTER, POLYTECHNIC OF THE SOUTH BANK, LONDON, SE1 OAA, UK >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> BOOKS IN SERIES SO FAR: 1) MATHEMATICAL BYWAYS IN AYLING, BEELING, AND CEILING by Hugh ApSimon, 128 pages; 30 illus, 853201-6, $10 2) THE INS AND OUTS OF PEG SOLITAIRE by John Beasley, 300 pages; 571 illus, 853203-2, $17 3) RUBIK'S CUBIC COMPENDIUM by Erno Rubik et al, 200 pages, 183 illus, 853202-4, $15 CONTENTS: Intro: the fascination of rubik's cube - david singmaster, 1. in play -rubik, 2 the art of cubing - varga, 3. restoration methods and table of processes - keri, 4. mathematics - keri & varga, 5. the universe of the cube - marx, 6. my fingers remember - vekerdy, 7. afterword - singmaster, bibliography & index. 4) SLIDING PIECE PUZZLES by Edward Horden - in preparation. AVAILABLE FROM: Science and Medical Marketing Manager, OXFORD UNIVERSITY PRESS, 200 Madison ave, NY, NY 10016, 212/679-7300 ADD $1.50 for shipping >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> from .........................................  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 21 Jan 87 02:25:19 EST Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 21 Jan 87 02:14:37 EST Date: Wed, 21 Jan 1987 02:12 EST Message-ID: From: Rob Austein To: "David A. Moon" Cc: BUG-COMSAT@MC.LCS.MIT.EDU, Bug-LISPM@XX.LCS.MIT.EDU Subject: Bug in parsing CHAOS-SMTP multiline replies In-reply-to: Msg of 18 Jan 1987 22:24-EST from "David A. Moon" Date: Sunday, 18 January 1987 22:24-EST From: "David A. Moon" I saw this in the STATS file: 091917 Unqueueing to host ZERMATT.LCS.MIT.EDU 091918 ICP->ZERMATT.LCS.MIT.EDU (CHAOS-SMTP) 091918 QID=<154990.870112@MC.LCS.MIT.EDU>...error for <@MC.LCS.MIT.EDU:emer@lcs.mit.edu>="501- Bad reverse path: In "FROM:<@MC.LCS.MIT.EDU:emer@lcs.mit.edu>", 501- ", trying <>....init lost, R="501 and no namespace server was contacted because validity checking is inhibited.." 091920 Unqueueing to host WHARTON-10.ARPA The reverse path really is bad, or at least funny-looking, but that's not the bug. It looks to me like Comsat read the first 2 lines of a 3-line reply and thought it had all of it. Then it sent another command and read the third line, thinking it was an error for the second command. The reverse path itself is ok. Ie, <@MC.LCS.MIT.EDU:emer@lcs.mit.edu> is a correct return path that would be generated by Joel Emer sending a message via MC; unfortunately this name ("lcs.mit.edu") is not in the ITS host tables for complicated reasons that I won't explain here. The rest of this seems to be bugs in both COMSAT and Zermatt's mailer. Here is wallpaper from a chat with Zermatt's CHAOS/SMTP via TELNET from XX: 220 ZERMATT.LCS.MIT.EDU SMTP service ready. helo xx 250 ZERMATT.LCS.MIT.EDU mail from:<@mc.lcs.mit.edu:sra@lcs.mit.edu> 501- Bad reverse path: In "from:<@mc.lcs.mit.edu:sra@lcs.mit.edu>", 501- 501- The host named # was not found. 501- No host with that name is already known by the local machine, 501 and no namespace server was contacted because validity checking is inhibited.. quit 221 Goodbye. Now, I don't know what the ^K is really supposed to be (perhaps an UpArrow character pointing at what the server thinks is the begining of the bad part of the reverse-path? if so it's pointing at the "c" of MC) but whatever it is supposed to be it is in pretty questionable taste. There is also some question as to why Zermatt cares whether or not it can find "lcs.mit.edu": the whole point of the funny @mumble:foo@bar syntax is that Zermatt can just ship error messages back via MC without having to know about the rest of the address. Either the return-path parsing code doesn't conform to SMTP or somebody is trying to be too smart. The COMSAT bug is as described by Moon, above. If the buffer is overflowing, then some code which appears to report this condition in the STATS file is broken. I find it somewhat suspicious that whatever caused the truncation happened -just- after the sequence ^K^M^J (yes, I checked, those really are ascii control characters, no high order bit), but I can't find anything obvious here either. I guess somebody is going to have to single step through this code. The relevant code is in NETRTS, around NTRPLY. Bring lunch, this code is a bear. --Rob  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 21 Jan 87 00:29:12 EST Date: Wed, 21 Jan 1987 00:25 EST Message-ID: From: Rob Austein To: Alan Bawden Cc: BUG-COMSAT@AI.AI.MIT.EDU, BUG-PEEK@AI.AI.MIT.EDU, JTW@AI.AI.MIT.EDU Subject: PEEK shouldn't ever PCLSR anyone In-reply-to: Msg of 18 Jan 1987 22:51-EST from Alan Bawden Date: Sunday, 18 January 1987 22:51-EST From: Alan Bawden In the case of the DQ device screw, I don't really understand why PEEK PCLSRing the -server- would cause any kind of deadlock to be broken. Not that surprising. Remember that DQ: is a very strange file. In particular, see the code that uses register Y in OUTPUT and BOJINT to avoid hanging forever at the SIOT in OUTPUT. I would not be surprised if that code was intimately involved in this bug, I doubt anybody has ever tried to make a JOB device do anything this twisted before.  Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 30002424620) by AI.AI.MIT.EDU 20 Jan 87 23:13:31 EST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 47713; Tue 20-Jan-87 23:11:16 EST Date: Tue, 20 Jan 87 23:08 EST From: David A. Moon Subject: [COMSAT: Msg of Tuesday, 20 January 1987 10:24-EST] To: Rob Austein cc: BUG-MAIL@AI.AI.MIT.EDU, David Chapman In-Reply-To: Message-ID: <870120230834.5.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Tue, 20 Jan 1987 22:37 EST From: Rob Austein Date: Tuesday, 20 January 1987 21:42-EST From: David A. Moon Of course this is grotesque. Much better would be for Comsat, or its fake resolver, to go up a level of domain and find a mail-forwarding agent for that domain, when it doesn't recognize a host name but the host name has dots in it. I disagree. Eg, mail for LCS.MIT.EDU should not be sent to MIT.EDU, mail from MIT.EDU should not be sent to EDU, etc. I don't think we can build a filter that will be able to guess when two names are within the same "site" (in the Lispm sense). The real answer is for me to finish the flinking resolver, for somebody else to make the compiler work on ITS, and for Symbolics to put mail forwarding stuff at the obvious places in the domain tree. For all its faults, the domain stuff does have a way to specify what you really want here: *.SYMBOLICS.COM. nn IN MX nn STONY-BROOK.SCRC.SYMBOLICS.COM. I agree with you. Translating to domain language, what I was suggesting was to simulate that, using arbitrarily kludgey technology, until we have it for real. For instance, Comsat or the DQ device (I'm not sure which) could have a wired-in table of simulated MX records and could look there before parsing a host name. It could be treated inside Comsat much the same way as the Chaosnet-to-Internet gateway mechanism is treated. If Symbolics domain database doesn't already have MX records, I don't know why not. I haven't asked the people here who would know. For all I know as soon as anyone puts an MX in their domain, every Unix on the internet crashes!  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 20 Jan 87 22:41:30 EST Date: Tue, 20 Jan 1987 22:37 EST Message-ID: From: Rob Austein To: "David A. Moon" Cc: BUG-MAIL@AI.AI.MIT.EDU, David Chapman Subject: [COMSAT: Msg of Tuesday, 20 January 1987 10:24-EST] In-reply-to: Msg of 20 Jan 1987 21:42-EST from David A. Moon Date: Tuesday, 20 January 1987 21:42-EST From: David A. Moon Maybe whatever technology is used to extract information from the various MIT namespaces to go into the MIT host table should also be used to extract information from the various Symbolics namespaces, filtering out only the hosts that have the server-machine attribute. In principle this is not too totally bogus an idea. In practice it would would require some work by CJL (or somebody) to set up the namespace dumping, and would require me to make some long-proposed additions to a piece of TECO code I hoped I'd never have to touch again. Of course this is grotesque. Much better would be for Comsat, or its fake resolver, to go up a level of domain and find a mail-forwarding agent for that domain, when it doesn't recognize a host name but the host name has dots in it. I disagree. Eg, mail for LCS.MIT.EDU should not be sent to MIT.EDU, mail from MIT.EDU should not be sent to EDU, etc. I don't think we can build a filter that will be able to guess when two names are within the same "site" (in the Lispm sense). The real answer is for me to finish the flinking resolver, for somebody else to make the compiler work on ITS, and for Symbolics to put mail forwarding stuff at the obvious places in the domain tree. For all its faults, the domain stuff does have a way to specify what you really want here: *.SYMBOLICS.COM. nn IN MX nn STONY-BROOK.SCRC.SYMBOLICS.COM. --Rob  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 20 Jan 87 22:33:56 EST Date: Tue, 20 Jan 1987 22:16 EST Message-ID: From: Rob Austein To: David Chapman cc: BATALI@AI.AI.MIT.EDU, BUG-MAIL@AI.AI.MIT.EDU Subject: I can't type Obviously the filename in my last message (re: SPAR) should have been "AI: SYSHST; HSTXXX >" rather than the garbage I typed.  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 20 Jan 87 22:14:19 EST Date: Tue, 20 Jan 1987 22:07 EST Message-ID: From: Rob Austein To: David Chapman Cc: BATALI@AI.AI.MIT.EDU, BUG-MAIL@AI.AI.MIT.EDU Subject: [COMSAT: Msg of Tuesday, 20 January 1987 09:58-EST] In-reply-to: Msg of 20 Jan 1987 10:00-EST from David Chapman Date: Tuesday, 20 January 1987 10:00-EST From: David Chapman Rob: what would be involved in telling MIT machine what SPAR's internet address is? Properly, this should be added at the NIC. In practice, this might be a real pain. If sufficiently painful, you could add an entry to AI SYSHST: HSTXXX; > instead. HSTXXX is prepended to the NIC table during the compilation process to work around this sort of table lossage.  Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 30002424620) by AI.AI.MIT.EDU 20 Jan 87 21:47:24 EST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 47661; Tue 20-Jan-87 21:44:59 EST Date: Tue, 20 Jan 87 21:42 EST From: David A. Moon Subject: [COMSAT: Msg of Tuesday, 20 January 1987 10:24-EST] To: Rob Austein cc: David Chapman , BUG-MAIL@AI.AI.MIT.EDU In-Reply-To: Message-ID: <870120214220.1.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Tue, 20 Jan 1987 21:29 EST From: Rob Austein As it happens, the problem is indeed that COMSAT doesn't have a resolver. I have seen this lossage enough times for SAPSUCKER that I think it would be reasonable for somebody who knows all the appropriate statistics to add SAPSUCKER to AI: SYSHST; HSTXXX >. Maybe whatever technology is used to extract information from the various MIT namespaces to go into the MIT host table should also be used to extract information from the various Symbolics namespaces, filtering out only the hosts that have the server-machine attribute. Of course this is grotesque. Much better would be for Comsat, or its fake resolver, to go up a level of domain and find a mail-forwarding agent for that domain, when it doesn't recognize a host name but the host name has dots in it.  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 20 Jan 87 21:33:12 EST Date: Tue, 20 Jan 1987 21:29 EST Message-ID: From: Rob Austein To: David Chapman Cc: BUG-MAIL@AI.AI.MIT.EDU Subject: [COMSAT: Msg of Tuesday, 20 January 1987 10:24-EST] In-reply-to: Msg of 20 Jan 1987 20:27-EST from David Chapman As it happens, the problem is indeed that COMSAT doesn't have a resolver. I have seen this lossage enough times for SAPSUCKER that I think it would be reasonable for somebody who knows all the appropriate statistics to add SAPSUCKER to AI: SYSHST; HSTXXX >. Ideally, Symbolics would have added it to the NIC's table (as they should add any machine that is being used as a mail drop), but in these degenerate times I don't really care whether they do or not. --Rob  Date: Tue, 20 Jan 87 20:27:12 EST From: David Chapman Subject: [COMSAT: Msg of Tuesday, 20 January 1987 10:24-EST] To: Moon@SCRC-STONY-BROOK.ARPA cc: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <142482.870120.ZVONA@AI.AI.MIT.EDU> Date: Tue, 20 Jan 87 19:57 EST From: David A. Moon To: David Chapman cc: BUG-MAIL at AI.AI.MIT.EDU Re: [COMSAT: Msg of Tuesday, 20 January 1987 10:24-EST] ============ A copy of your message is being returned, because: "JOSEPH@SAPSUCKER.SCRC.SYMBOLICS.COM" at AI.AI.MIT.EDU is an unknown recipient. ============ Failed message follows: ============ Date: Tue, 20 Jan 87 10:24:30 EST From: David Chapman Subject: favor To: "JOSEPH@SAPSUCKER.SCRC.SYMBOLICS.COM"@AI.AI.MIT.EDU It's hard to evaluate this without knowing what program you used to send the mail and whether or not you typed those quotes and atsign yourself. That is indeed an illegal address syntax for Comsat, but maybe you sent the mail to a legal syntax that was illegally translated to that one. I replied with Babyl. The entry for that message in my babyl file begins: Received: from HARLEM.SCRC.Symbolics.COM (TCP 30002424606) by AI.AI.MIT.EDU 13 Jan 87 21:29:19 EST Date: Tue, 13 Jan 87 21:23 EST From: Joseph R Goldstone Subject: favor To: David Chapman In-Reply-To: <139852.870113.ZVONA@AI.AI.MIT.EDU> Message-ID: <870113212334.2.JOSEPH@HARLEM.SCRC.Symbolics.COM> *** EOOH *** Date: Tue, 13 Jan 87 21:23 EST From: Joseph R Goldstone To: David Chapman Re: favor When I reply to this, Babyl sets up the *mail* buffer as To: Joseph R Goldstone Re: favor --Text follows this line-- So either COMSAT is translating the address, or Babyl is doing it after it's out of my view.  Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 30002424620) by AI.AI.MIT.EDU 20 Jan 87 20:02:36 EST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 47585; Tue 20-Jan-87 20:00:16 EST Date: Tue, 20 Jan 87 19:57 EST From: David A. Moon Subject: [COMSAT: Msg of Tuesday, 20 January 1987 10:24-EST] To: David Chapman cc: BUG-MAIL@AI.AI.MIT.EDU In-Reply-To: <142266.870120.ZVONA@AI.AI.MIT.EDU> Message-ID: <870120195742.3.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Tue, 20 Jan 87 10:26:00 EST From: David Chapman I don't know where the problem with this is, but it's annoying. Lemme guess, it's because SCRC's mailer uses a resolver and comsat doesn't? Date: Tue, 20 Jan 87 10:24:34 EST From: Communications Satellite To: ZVONA at AI.AI.MIT.EDU Re: Msg of Tuesday, 20 January 1987 10:24-EST ============ A copy of your message is being returned, because: ============ "JOSEPH@SAPSUCKER.SCRC.SYMBOLICS.COM" at AI.AI.MIT.EDU is an unknown recipient. ============ Failed message follows: ============ Date: Tue, 20 Jan 87 10:24:30 EST From: David Chapman Subject: favor To: "JOSEPH@SAPSUCKER.SCRC.SYMBOLICS.COM"@AI.AI.MIT.EDU It's hard to evaluate this without knowing what program you used to send the mail and whether or not you typed those quotes and atsign yourself. That is indeed an illegal address syntax for Comsat, but maybe you sent the mail to a legal syntax that was illegally translated to that one. In-reply-to: Msg of Tue 13 Jan 87 21:23 EST from Joseph R Goldstone Message-ID: <142263.870120.ZVONA@AI.AI.MIT.EDU> Date: Tue, 13 Jan 87 21:23 EST From: Joseph R Goldstone To: David Chapman Re: favor Date: Tue, 13 Jan 87 16:34:29 EST From: David Chapman Hi, I have a favor to ask of you. Margret Minsky was raving about how this year's SIGGraph information-for-authors sheet was a model of clarity. Since I'm liable to have to write such a thing one of these days, I'd like to see it; but she's lost hers. If you got one, would it be too much trouble to xerox it and send me a copy? I'd much appreciate. Thanks a bunch. Unfortunately, someone seems to have thrown it out in the last week or two (I posted it down the hall a bit). Nobody else at the Media Lab has a copy? I think copies went to every SigGraph member; you might try Walter Bender, Chris Schmandt, or Prof. Dave Zeltzer. Sorry. I'm a bit pissed; it had some really nice artwork on it. Thanks anyway. If I find a copy, I'll send you a xerox.  Date: Tue, 20 Jan 87 10:26:00 EST From: David Chapman Subject: [COMSAT: Msg of Tuesday, 20 January 1987 10:24-EST] To: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <142266.870120.ZVONA@AI.AI.MIT.EDU> I don't know where the problem with this is, but it's annoying. Lemme guess, it's because SCRC's mailer uses a resolver and comsat doesn't? Date: Tue, 20 Jan 87 10:24:34 EST From: Communications Satellite To: ZVONA at AI.AI.MIT.EDU Re: Msg of Tuesday, 20 January 1987 10:24-EST ============ A copy of your message is being returned, because: ============ "JOSEPH@SAPSUCKER.SCRC.SYMBOLICS.COM" at AI.AI.MIT.EDU is an unknown recipient. ============ Failed message follows: ============ Date: Tue, 20 Jan 87 10:24:30 EST From: David Chapman Subject: favor To: "JOSEPH@SAPSUCKER.SCRC.SYMBOLICS.COM"@AI.AI.MIT.EDU In-reply-to: Msg of Tue 13 Jan 87 21:23 EST from Joseph R Goldstone Message-ID: <142263.870120.ZVONA@AI.AI.MIT.EDU> Date: Tue, 13 Jan 87 21:23 EST From: Joseph R Goldstone To: David Chapman Re: favor Date: Tue, 13 Jan 87 16:34:29 EST From: David Chapman Hi, I have a favor to ask of you. Margret Minsky was raving about how this year's SIGGraph information-for-authors sheet was a model of clarity. Since I'm liable to have to write such a thing one of these days, I'd like to see it; but she's lost hers. If you got one, would it be too much trouble to xerox it and send me a copy? I'd much appreciate. Thanks a bunch. Unfortunately, someone seems to have thrown it out in the last week or two (I posted it down the hall a bit). Nobody else at the Media Lab has a copy? I think copies went to every SigGraph member; you might try Walter Bender, Chris Schmandt, or Prof. Dave Zeltzer. Sorry. I'm a bit pissed; it had some really nice artwork on it. Thanks anyway. If I find a copy, I'll send you a xerox.  Date: Tue, 20 Jan 87 10:00:34 EST From: David Chapman Subject: [COMSAT: Msg of Tuesday, 20 January 1987 09:58-EST] To: BATALI@AI.AI.MIT.EDU, SRA@AI.AI.MIT.EDU cc: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <142253.870120.ZVONA@AI.AI.MIT.EDU> John: well, comsat isn't smart enough to hack this sort of address. Rob: what would be involved in telling MIT machine what SPAR's internet address is? Date: Tue, 20 Jan 87 09:58:48 EST From: Communications Satellite To: ZVONA at AI.AI.MIT.EDU Re: Msg of Tuesday, 20 January 1987 09:58-EST ============ A copy of your message is being returned, because: ============ "BATALI@[128.58.1.2]" at AI.AI.MIT.EDU is an unknown recipient. ============ Failed message follows: ============ Date: Tue, 20 Jan 87 09:58:42 EST From: David Chapman Subject: please reply-to this To: "BATALI@[128.58.1.2]"@AI.AI.MIT.EDU In-reply-to: Msg of Fri 16 Jan 87 18:11 PST from ??? Message-ID: <142250.870120.ZVONA@AI.AI.MIT.EDU> Let's see if this works. It sure looks ugly, regarless of whether it does: Date: Fri, 16 Jan 87 18:11 PST From: ??? Reply-To: Batali at [128.58.1.2] To: zvona at mc Re: please reply-to this To see if this reply-to header works correctly. If it does, perhaps you could update OZ's host table so that it knows that the internet address for SPAR-20 is as given in my reply-to field? (namely: [128.58.1.2]) OZ's host table is driven by REAGAN's, which is driven by the NIC's. So it may not be possible. But I'll see what can be done if this works.  Date: Sun, 18 Jan 87 22:51:43 EST From: Alan Bawden Subject: PEEK shouldn't ever PCLSR anyone To: BUG-COMSAT@AI.AI.MIT.EDU, BUG-PEEK@AI.AI.MIT.EDU cc: JTW@AI.AI.MIT.EDU Message-ID: <141778.870118.ALAN@AI.AI.MIT.EDU> I just found two obvious places in PEEK that would cause a job to get PCLSR'd. The first would PCLSR any job that PEEK suspected might be a MUDDLE job (it had some test involving the contents of the job's accumulators). Despite the comment that threatened to "BREAK THE NECK OF THE ASSHOLE WHO REMOVES ANY CODE HERE WITHOUT CONSULTING ME AND OBTAINING PERMISSION", I removed it. The second would PCLSR any job that PEEK suspected might be an interesting job device server. Any job whose JNAME started with the three characters "JOB" would be PCLSR'd when PEEK went into "C" mode because PEEK used .IOT's on the USR: device to probe around in its memory (to see if it was an MLDEV, or other device server it knows about). I fixed this to use memory mapping instead. In the case of the DQ device screw, I don't really understand why PEEK PCLSRing the -server- would cause any kind of deadlock to be broken. But in any case, now there is a good chance that the next time COMSAT and DQ get into this state, the mere act of discovering the lossage in PEEK (by going into "C" mode to read the STATS file) will not cause the lossage to vanish. Perhaps we will be able to find the problem now.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 18 Jan 87 22:26:50 EST Date: Sun, 18 Jan 87 22:24:48 EST From: "David A. Moon" Sender: ALAN@MC.LCS.MIT.EDU Subject: Bug in parsing CHAOS-SMTP multiline replies To: BUG-COMSAT@MC.LCS.MIT.EDU Message-ID: <158741.870118.ALAN@MC.LCS.MIT.EDU> I saw this in the STATS file: 091917 Unqueueing to host ZERMATT.LCS.MIT.EDU 091918 ICP->ZERMATT.LCS.MIT.EDU (CHAOS-SMTP) 091918 QID=<154990.870112@MC.LCS.MIT.EDU>...error for <@MC.LCS.MIT.EDU:emer@lcs.mit.edu>="501- Bad reverse path: In "FROM:<@MC.LCS.MIT.EDU:emer@lcs.mit.edu>", 501- ", trying <>....init lost, R="501 and no namespace server was contacted because validity checking is inhibited.." 091920 Unqueueing to host WHARTON-10.ARPA The reverse path really is bad, or at least funny-looking, but that's not the bug. It looks to me like Comsat read the first 2 lines of a 3-line reply and thought it had all of it. Then it sent another command and read the third line, thinking it was an error for the second command.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 16 Jan 87 02:06:22 EST Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 16 Jan 87 02:00:06 EST Date: Fri, 16 Jan 1987 01:58 EST Message-ID: From: Rob Austein To: Ramin Zabih Cc: BUG-Mail@MC.LCS.MIT.EDU, JAR@AI.AI.MIT.EDU, ZVONA@AI.AI.MIT.EDU, BillW@SCORE.STANFORD.EDU, Namecallers@MC.LCS.MIT.EDU Subject: AI -> SUSHI mail, again. Date: Friday, 16 January 1987 01:34-EST From: Ramin Zabih I just talked to Bill Westfield, and it may be that AI-SUSHI mail is now working. SUSHI had a cache entry for the AI namespace that directed it to GUTENBERG, which seems to be bogus. I don't know where it came from, but it's gone now, so perhaps things will continue to work. Until last fall, there was no way to give bind special "out of band" data to use to bootstrap itself into knowledge of the database. So a lot of records got added to local machines' initial cache load files with godawful long timeouts (eg, 99999999 which is over three years). Since this was in the cache, anybody who asked bind for that those RRs (which tended to be things like SOA, NS, and A records for each zone) stood some chance of getting the RR with the three year timeout instead of the normal one from the zone load files. GUTENBERG was decommissioned a month or three ago. Bind has been fixed to do the same thing JEEVES does (it has a special list of bootstrap addresses). But there are a lot of old copies of bind around, and the damage has already been done. Keep in mind that the domain system is a distributed database. The only method for invalidating a RR is having the timeout expire. We still have 2.5 years to go before that happens. Short of shutting down EVERY nameserver on the net, AT THE SAME TIME, and flushing this RR if present, there is no way to get rid of the bugger before 1989. Remind you of the giant tapeworm at the end of Shockwave Rider? --Rob  Date: Fri, 16 Jan 87 01:39:40 EST From: "David A. Moon" Subject: Mysterious MC won't shut down crash explained To: ALAN@AI.AI.MIT.EDU cc: BUG-COMSAT@AI.AI.MIT.EDU Message-ID: <140883.870116.MOON@AI.AI.MIT.EDU> You aren't going to like this one damn bit. TMPLOC 44, -LCCBLK,,CCBLK ;aobjn ptr to critical code table for lock hacking looks like it would put an aobjn pointer into location 44, doesn't it? It doesn't. It puts -LCCBLK into location 44 and CCBLK into the next location inline (where it happens to get ignored). This is because ; TMPLOC , - puts argument at given LOC ; without changing location counter outside macro call. DEFINE TMPLOC VAL,?ARG [definition deleted] Why the heck doesn't TMPLOC use a rest-of-line arg? Now -LCCBLK is -1,,777772, an aobjn pointer to a page that is mapped into absolute page 120, which contains whatever it happens to contain. If the PC happens to lie within the bounds of the first word there, the system executes the second word there as an instruction, with the extra added feature (see IODCD1 in ITS) that if the LH is zero, SETOM is substituted. Thus when Comsat executes the .LOGOUT that ALOGO4 puts into its AC 0 when the system job guns it, the unlocking of Comsat's locked switches, if that absolute page contains zeros, will do a SETOM 0. If Comsat doesn't pclsr, that -1 is never seen, but if it does PCLSR out of the .LOGOUT (we still don't know where it pclsred from), it executes that -1 as an instruction, causing the lossage we saw. Yow! It looks like it's been this way for eons. Maybe this also explains why the Comsat locks don't always seem to work right.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 16 Jan 87 01:35:37 EST Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 16 Jan 87 01:32:06 EST Date: Fri, 16 Jan 87 01:34:43 EST From: Ramin Zabih Subject: AI -> SUSHI mail, again. To: SRA@XX.LCS.MIT.EDU cc: JAR@AI.AI.MIT.EDU, ZVONA@AI.AI.MIT.EDU, BUG-Mail@MC.LCS.MIT.EDU In-reply-to: Msg of Tue 13 Jan 1987 18:57 EST from Rob Austein Message-ID: <140879.870116.RDZ@AI.AI.MIT.EDU> I just talked to Bill Westfield, and it may be that AI-SUSHI mail is now working. SUSHI had a cache entry for the AI namespace that directed it to GUTENBERG, which seems to be bogus. I don't know where it came from, but it's gone now, so perhaps things will continue to work. Ramin  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 15 Jan 87 18:01:31 EST Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 15 Jan 87 17:56:35 EST Date: Thu, 15 Jan 1987 17:55 EST Message-ID: From: Rob Austein To: Jonathan A Rees Cc: BUG-comsat@MC.LCS.MIT.EDU Subject: someone please install the new version of COMSAT In-reply-to: Msg of 15 Jan 1987 11:20-EST from Jonathan A Rees Date: Thursday, 15 January 1987 11:20-EST From: Jonathan A Rees To: BUG-comsat@MC.LCS.MIT.EDU Re: someone please install the new version of COMSAT Could someone who knows how to do so please install the new version of COMSAT on MC? It's currently running on AI (SYSNET; COMSAT 559, .MAIL.; COMSAT IV), but not on MC, and the SCHEME@MC mailing list needs the fix. Thanks. COMSAT 559 installed on all ITS machines. This includes 557: CStacy griping about STATS file appearences; 558: Me reorganizing TCPGAT and HDRGAT handling; 559: Moon's recent stuff. 558 appears to be working (I tested it a little on MD before installing elsewhere), so we have a clean way of patching around a down relay machine. Somebody should try out Moon's thing. Backup COMSATs are on AI: COMSAT BACKUP is an unpatched COMSAT 556, COMSAT PAT559 is ^XBACKUP with 559 patch. COMSAT BACKUP on other machines is whatever seemed reasonable. I flushed a lot of OBACKUP, OOBACKU, OOOBACK, etc files. I don't think there's much point in saving more than one back version unless something very odd is going on. We do have good backup tapes, after all. --Rob  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 15 Jan 87 11:28:59 EST Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 15 Jan 87 11:17:19 EST Date: Thu, 15 Jan 87 11:20:21 EST From: Jonathan A Rees Subject: someone please install the new version of COMSAT To: BUG-comsat@MC.LCS.MIT.EDU Message-ID: <140606.870115.JAR@AI.AI.MIT.EDU> Could someone who knows how to do so please install the new version of COMSAT on MC? It's currently running on AI (SYSNET; COMSAT 559, .MAIL.; COMSAT IV), but not on MC, and the SCHEME@MC mailing list needs the fix. Thanks. Jonathan  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 13 Jan 87 19:25:40 EST Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 13 Jan 87 19:07:20 EST Date: Tue, 13 Jan 1987 18:57 EST Message-ID: From: Rob Austein To: Jonathan A Rees Cc: Bug-Mail@MC.LCS.MIT.EDU, RDZ@AI.AI.MIT.EDU, ZVONA@AI.AI.MIT.EDU Subject: AI -> SUSHI mail, again. In-reply-to: Msg of 13 Jan 1987 16:40-EST from Jonathan A Rees If you have any cause to believe that the problem is SUSHI's domain resolver, the person you should talk to is Bill Westfield (BillW@Score). Last I heard, Sushi was running the basicly the same domain code as XX, but I think the mailer lookup routines (HSTNAM.MAC module) are set up with the priorities backwards from XX's; I think Sushi tries domain land first, then tries host tables, whereas XX (and Score, I think) do it the other way round. Who have people been talking to at Sushi? If it wasn't Bill Westfield or (maybe) Stu Grossman, there's probably more to be learned there.... --Rob  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 13 Jan 87 16:53:18 EST Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 13 Jan 87 16:38:06 EST Date: Tue, 13 Jan 87 16:40:38 EST From: Jonathan A Rees Subject: AI -> SUSHI mail, again. To: ZVONA@AI.AI.MIT.EDU cc: RDZ@AI.AI.MIT.EDU, BUG-mail@MC.LCS.MIT.EDU In-reply-to: Msg of Tue 13 Jan 87 15:55:12 EST from David Chapman Message-ID: <139869.870113.JAR@AI.AI.MIT.EDU> Date: Tue, 13 Jan 87 15:55:12 EST From: David Chapman To: JAR at AI.AI.MIT.EDU cc: RDZ at AI.AI.MIT.EDU, BUG-mail at MC.LCS.MIT.EDU Re: AI -> SUSHI mail, again. In-reply-to: Msg of Mon 12 Jan 87 19:29:17 EST from Jonathan A Rees Message-ID: <139843.870113.ZVONA@AI.AI.MIT.EDU> I have reported this problem before, but I thought maybe everyone had just hoped it had gone away by itself. It hasn't. Indeed not... Has the case that this is SUSHI's problem been forcefully made to SUSHI's postmaster? No. I'm not convinced of Moon's diagnosis and I don't feel like I'm in a good position to argue the point. Thanks to Moon, I can now easily route SUSHI messages via other hosts, How do we do this? I'm still supduping to OZ everytime I want to reply to SUSHI mail. You can send to FOO%SUSHI@MC (or @XX or @SCORE or ...) using MAIL or RMAIL. Soon you will be able to do so using BABYL, as soon as I install the latest BABYL :EJ (it is currently sitting in my directory on AI). I'm a bit mystified about the release procedure and have been hoping for help from Foner or someone else on BUG-BABYL, but it isn't forthcoming, so I guess I'll just do it myself and hope for the best.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 13 Jan 87 15:55:39 EST Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 13 Jan 87 15:52:22 EST Date: Tue, 13 Jan 87 15:55:12 EST From: David Chapman Subject: AI -> SUSHI mail, again. To: JAR@AI.AI.MIT.EDU cc: RDZ@AI.AI.MIT.EDU, BUG-mail@MC.LCS.MIT.EDU In-reply-to: Msg of Mon 12 Jan 87 19:29:17 EST from Jonathan A Rees Message-ID: <139843.870113.ZVONA@AI.AI.MIT.EDU> I have reported this problem before, but I thought maybe everyone had just hoped it had gone away by itself. It hasn't. Indeed not... Has the case that this is SUSHI's problem been forcefully made to SUSHI's postmaster? Thanks to Moon, I can now easily route SUSHI messages via other hosts, How do we do this? I'm still supduping to OZ everytime I want to reply to SUSHI mail.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 12 Jan 87 22:18:24 EST Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 30002424620) by MC.LCS.MIT.EDU 12 Jan 87 22:14:49 EST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 42036; Mon 12-Jan-87 22:12:59 EST Date: Mon, 12 Jan 1987, 22:07-EST From: Subject: Unable to deliver letter Message-ID: <870112220750.5.FILE-SERVER@STONY-BROOK.SCRC.Symbolics.COM> To: Moon@STONY-BROOK.SCRC.Symbolics.COM Resent-To: bug-mail@MIT-MC.ARPA Resent-From: David A. Moon Resent-Date: Mon, 12 Jan 87 22:11 EST Resent-Message-ID: <870112221155.1.MOON@EUPHRATES.SCRC.Symbolics.COM> Resent-Comments: I should try to remember not to use domains. Unable to deliver letter to the following recipient: BUG-mail@MC.LCS.MIT.EDU: Host does not provide mail service. ----- Text of letter follows ----- Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 42029; Mon 12-Jan-87 22:07:19 EST Date: Mon, 12 Jan 87 22:06 EST From: David A. Moon Subject: AI -> SUSHI mail, again. To: Jonathan A Rees cc: BUG-mail@MC.LCS.MIT.EDU, ZVONA@AI.AI.MIT.EDU In-Reply-To: <139416.870112.JAR@AI.AI.MIT.EDU> Message-ID: <870112220614.7.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Mon, 12 Jan 87 19:29:17 EST From: Jonathan A Rees I have reported this problem before, but I thought maybe everyone had just hoped it had gone away by itself. It hasn't. Message #1 below demonstrates that MC is able to send to SUSHI. Message #2 below demonstrates that AI is unable to send to SUSHI. My guess is that it is really a function of which host SUSHI communicated with recently and had already encached in some domain cache. It's pretty clear that the problem is entirely inside the Sushi machine, not in the network, because at the same moment that the SMTP server takes over a minute to respond, the Telnet server is working just fine.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 12 Jan 87 20:46:31 EST Received: from ATHENA (TCP 2222000047) by MC.LCS.MIT.EDU 12 Jan 87 20:36:59 EST Received: by ATHENA (5.45/4.7) id AA28107; Mon, 12 Jan 87 20:38:37 EST From: Received: by HADES (5.45/4.7) id AA11452; Mon, 12 Jan 87 20:38:18 EST Date: Mon, 12 Jan 87 20:38:18 EST Message-Id: <8701130138.AA11452@HADES> To: sra@mc.lcs.mit.edu Subject: Funky Header Line Cc: bug-mail@mc.lcs.mit.edu Never mind. Purely local phenomenon. Sendmail at Athena is munging it (as usual). Sigh. -Philip  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 12 Jan 87 19:38:06 EST Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 12 Jan 87 19:26:27 EST Date: Mon, 12 Jan 87 19:29:17 EST From: Jonathan A Rees Subject: AI -> SUSHI mail, again. To: BUG-mail@MC.LCS.MIT.EDU cc: ZVONA@AI.AI.MIT.EDU, JAR@AI.AI.MIT.EDU In-reply-to: Msg of Mon 12 Jan 87 15:45:45-PST from Andy Freeman Message-ID: <139416.870112.JAR@AI.AI.MIT.EDU> I have reported this problem before, but I thought maybe everyone had just hoped it had gone away by itself. It hasn't. Message #1 below demonstrates that MC is able to send to SUSHI. Message #2 below demonstrates that AI is unable to send to SUSHI. How would AI differ from MC in this respect? Thanks to Moon, I can now easily route SUSHI messages via other hosts, so the problem isn't any more difficult to deal with than, say, replying to messages from BITNET. But it is very curious, in any case. - Jonathan Message #1. Date: Mon 12 Jan 87 15:45:45-PST From: Andy Freeman To: JAR at MC.LCS.MIT.EDU Re: test #5 In-Reply-To: <155258.870112.JAR@MC.LCS.MIT.EDU> Message-ID: <12270433758.8.ANDY@Sushi.Stanford.EDU> I just got this. -andy Return-Path: Received: from MC.LCS.MIT.EDU by Sushi.Stanford.EDU with TCP; Mon 12 Jan 87 15:27:13-PST Date: Mon, 12 Jan 87 18:30:46 EST From: Jonathan A Rees Subject: test #5 To: andy@SUSHI.STANFORD.EDU Message-ID: <155258.870112.JAR@MC.LCS.MIT.EDU> Test #5 (sending directly from MC). Message #2. Date: Mon, 12 Jan 87 19:09:02 EST From: Communications Satellite To: JAR at AI.AI.MIT.EDU Re: Msg of Monday, 12 January 1987 18:35-EST Message-ID: <139403.870112@AI.AI.MIT.EDU> FAILED: andy at SUSHI.STANFORD.EDU; Host appears to be permanently down or not accepting mail. Failed message follows: ------- Date: Mon, 12 Jan 87 18:35:08 EST From: Jonathan A Rees Subject: test #6 To: andy@SUSHI.STANFORD.EDU Message-ID: <139363.870112.JAR@AI.AI.MIT.EDU> If you get this I'll invert my wig.  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 11 Jan 87 22:21:33 EST Date: Sun, 11 Jan 1987 22:17 EST Message-ID: From: Rob Austein To: "David A. Moon" Cc: BUG-COMSAT@AI.AI.MIT.EDU Subject: JAR's problem with % syntax in recipients In-reply-to: Msg of 10 Jan 1987 13:07-EST from "David A. Moon" Date: Saturday, 10 January 1987 13:07-EST From: "David A. Moon" .... I believe I no longer know how to assemble and install a Comsat (it used to be easy). All you should have to do is assemble and turn off debugging and experimental-ness. The rest of the magic parameters will be initialized by the boot time code if you just leave them zero like they assemble. So you can use :INSTAL. If this doesn't work, I'd like to know about it.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 11 Jan 87 21:46:32 EST Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 11 Jan 87 21:39:02 EST Date: Sun, 11 Jan 1987 21:38 EST Message-ID: From: Rob Austein To: "Philip A. Prindeville" Cc: BUG-MAIL@MC.LCS.MIT.EDU In-reply-to: Msg of 11 Jan 1987 19:39-EST from "Philip A. Prindeville" Date: Sunday, 11 January 1987 19:39-EST From: "Philip A. Prindeville" To: BUG-MAIL@MC.LCS.MIT.EDU I have a mailing list, and I've noticed that the prefix @MC.LCS.MIT.EDU: gets prepended to addresses. I was wondering if there was a way to disable this? It would make things a little easier for users to reply to mail, etc. Example (enclose actual offending message, please)? I'm not convinced it's MC that's doing this to you. Unless you are talking about the RETURN-PATH header, which is not intended for human consumption.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 11 Jan 87 19:42:13 EST Date: Sun, 11 Jan 87 19:39:10 EST From: "Philip A. Prindeville" To: BUG-MAIL@MC.LCS.MIT.EDU Message-ID: <154742.870111.PAP4@MC.LCS.MIT.EDU> Hi. I have a mailing list, and I've noticed that the prefix @MC.LCS.MIT.EDU: gets prepended to addresses. I was wondering if there was a way to disable this? It would make things a little easier for users to reply to mail, etc. Thanks for any help, -Philip  Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 30002424620) by AI.AI.MIT.EDU 10 Jan 87 16:45:54 EST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 40613; Sat 10-Jan-87 16:41:33 EST Date: Sat, 10 Jan 87 16:40 EST From: David A. Moon Subject: ITS runs with patch To: Rob Austein cc: Mark Crispin , BUG-COMSAT@AI.AI.MIT.EDU, Alan@AI.AI.MIT.EDU In-Reply-To: Message-ID: <870110164024.1.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Sun, 9 Nov 1986 19:19 EST From: Rob Austein Date: Sunday, 9 November 1986 00:35-EST From: Mark Crispin Why is COMSAT or whatever using the return path? It's not. It's doing something much worse. It sees an address like "FOO%BAR@BAZ" and says "Oh, gee, I know who BAR is, I'll save some network overhead for this guy by sending the mail directly there and leave BAZ out of the loop". CStacy claims this code has been in place "forever" (ie, it was there before he started hacking COMSAT). I would have thought that both Moon and KLH had better sense than to implement such a gross misfeature, but I guess even legendary hackers have bad days. Or believe in the tooth fairy & the guaranteed uniqueness of hostnames. I don't know (remember) what has been in there "forever", but what's in there right now does the right thing, which is to only recognize BAR when BAZ is the local host, and not do any such bogus optimization. Unfortunately, Comsat has about four ways to specify @BAZ, and only one of them worked with this. I made another of them work today (separate mail sent to bug-comsat earlier). It looks to be impossible to make the other two work, but they are worthless compatibility-with-the-past features. (You can say (name host) or (name @host) where you would normally say (name@host).)  Date: Sat, 10 Jan 87 13:24:33 EST From: "David A. Moon" Subject: SUSHI.STANFORD.EDU To: RDZ@AI.AI.MIT.EDU, BUG-COMSAT@AI.AI.MIT.EDU Message-ID: <138706.870110.MOON@AI.AI.MIT.EDU> The Telnet server at sushi has much faster response than the SMTP server. The SMTP server opens the connection right away but takes a very long time before printing a greeting, and also takes a very long time to respond to the HELO command. These long times are like a minute or more. But it rejects the foo command as unknown within a few seconds, and at the same time, the telnet server is echoing characters and complaining about my erroneous commands with a delay of only a second or two. So I think the problem is entirely at sushi, not with the network and not with Comsat. If I had to point a finger anywhere in particular, I'd pick Sushi's implementation of domains. Ramin, my advice is to find a better computer.  Date: Sat, 10 Jan 87 13:07:59 EST From: "David A. Moon" Subject: JAR's problem with % syntax in recipients To: BUG-COMSAT@AI.AI.MIT.EDU cc: JAR@AI.AI.MIT.EDU Message-ID: <138701.870110.MOON@AI.AI.MIT.EDU> There were really two problems. One is that the input format generated by :MAIL (the old TO: format rather than the new RCPT: format) wasn't parsed correctly. I fixed that in the source and patched it in the Comsat binary on AI only. I believe I no longer know how to assemble and install a Comsat (it used to be easy). The second problem is with the input format generated by Babyl, which contains a superfluous space before the atsign. Rmail does not generate this space and works. I looked at the relevant parsing code in Comsat, but it looks infeasible to make it do the right to left parsing that would have to be done to realize that there is a host name after the space and therefore the recipient name should be parsed differently. Instead, Jonathan is going to look into getting Babyl fixed to omit the space. If something else in Comsat on AI breaks, blame me.  Date: Fri, 9 Jan 87 18:36:58 EST From: Ramin Zabih Subject: SU-SUSHI To: BUG-MAIL@AI.AI.MIT.EDU cc: ZVONA@AI.AI.MIT.EDU, jjw@SAIL.STANFORD.EDU Message-ID: <138462.870109.RDZ@AI.AI.MIT.EDU> Hi, Mail from MIT to SUSHI seems to be timing out, though SUSHI is up. I think I saw some mail about this problem from ZVONA recently. Does anyone know what the problem is? Ramin  Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 30002424620) by AI.AI.MIT.EDU 8 Jan 87 20:33:18 EST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 39415; Thu 8-Jan-87 20:29:45 EST Date: Thu, 8 Jan 87 20:28 EST From: David A. Moon Subject: whoops, missed the other half of that question To: Alan Bawden cc: SRA@XX.LCS.MIT.EDU, BUG-COMSAT@AI.AI.MIT.EDU In-Reply-To: <138051.870108.ALAN@AI.AI.MIT.EDU> Message-ID: <870108202839.6.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Thu, 8 Jan 87 20:04:03 EST From: Alan Bawden I don't know how to simulate a foreign SMTP user. I use Telnet. The fact that this works tells you something (whether good or bad I can't decide) about the Arpa protocol set.  Date: Thu, 8 Jan 87 20:04:03 EST From: Alan Bawden Subject: whoops, missed the other half of that question To: SRA@XX.LCS.MIT.EDU cc: BUG-COMSAT@AI.AI.MIT.EDU, ALAN@AI.AI.MIT.EDU In-reply-to: Msg of Thu 8 Jan 1987 18:24 EST from Rob Austein Message-ID: <138051.870108.ALAN@AI.AI.MIT.EDU> Date: Thu, 8 Jan 1987 18:24 EST From: Rob Austein ... I read the above as saying that we can do "452 you lose" and .CLOSE, but doing the longer proceedure would be more socially acceptable. This is what I changed the code to do. (I just made it use the same IOC error handler that regular file transfers use.) I didn't install it since I don't know how to test it. (I do know how to simulate a full disk, but I don't know how to simulate a foreign SMTP user.)  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 8 Jan 87 18:58:17 EST Date: Thu, 8 Jan 1987 18:57 EST Message-ID: From: Rob Austein To: alan@AI.AI.MIT.EDU cc: bug-comsat@AI.AI.MIT.EDU Subject: more SMTP trivia There's an exception to the wait-for-QUIT rule, reply code 421 ("temporary error that forces me to go away right now, bye bye"). Maybe the right thing to do is send 421-I ran out of disk space. 421-This should really be a 452 reply but I don't want to 421-wait for you to process that. 421 Aborting connection. and .CLOSE.  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 8 Jan 87 18:25:43 EST Date: Thu, 8 Jan 1987 18:24 EST Message-ID: From: Rob Austein To: alan@AI.AI.MIT.EDU cc: bug-comsat@AI.AI.MIT.EDU Subject: whoops, missed the other half of that question Protocol for closing a connection is a pain. I don't think there isn't any reason why FTP should be typing two CRLFs. But to handle whatever-full errors, SMTP has to do the following: Possibly soak incoming cruft up through . (if a DATA command was in progress); Send a "452 I have no disk space, go away"; Wait for a "QUIT"; Send a "221 Bye Bye". RFC821 specificly states that the server has to wait for the QUIT even if it just reported an error. (This is even justified for disk full errors, for a full implementation of SMTP, because the sender might conceivably want to issue an EXPN to see if it can bypass this losing machine entirely. I admit this is unlikely.) In the next sentence it says that if some server violates the previous sentence the sender should abort any transfer in progress, should assume that any previous transactions are ok (we're covered here), and should pretend that it got a 4xx class error to the current transaction. I read the above as saying that we can do "452 you lose" and .CLOSE, but doing the longer proceedure would be more socially acceptable.  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 8 Jan 87 18:18:08 EST Date: Thu, 8 Jan 1987 18:07 EST Message-ID: From: Rob Austein To: Alan Bawden Cc: BUG-COMSAT@AI.AI.MIT.EDU Subject: FTPS disk full lossage In-reply-to: Msg of 8 Jan 1987 17:55-EST from Alan Bawden 452 is the correct reply code for disk/dev/dir full ("system storage full"). 552 is "storage allocation exceeded".  Date: Thu, 8 Jan 87 17:55:54 EST From: Alan Bawden Subject: FTPS disk full lossage To: SRA@AI.AI.MIT.EDU cc: BUG-COMSAT@AI.AI.MIT.EDU In-reply-to: Msg of Thu 8 Jan 87 16:10:49 EST from Rob Austein Message-ID: <137990.870108.ALAN@AI.AI.MIT.EDU> Date: Thu, 8 Jan 87 16:10:49 EST From: Rob Austein It looks like the problem is disk full, not directory full. Directory full seems to be handled correctly, right after the .CALL OPEN. Disk full errs in the middle of the OUT package, which does a JSR AUTSPY when SIOT fails.... Actually, I think it is DEVICE FULL that we're talking about, and it gets signaled as an IOC error. The interrupt handler for %PIIOC already has code in it to invoke a handler when an IOC error occurs on the output channel. However, there seem to be a couple of problems. First the handler is only in force around one call to OUT: MOVEI T,TOOBIG MOVEM T,MTPIOC ;If any IOC lossage, give user error response. OUT(DC,CRLF,TA(BUFFAR)) SETZM MTPIOC Unfortunately at this point the server has already output a bunch of other stuff into the queue file (everything up to and including the "TEXT;-1" and "Received: ..." lines), so if the disk really is full, the IOC error happens before the server even gets here. The next few problems are with the TOOBIG routine: ;Mail too big, reject it TOOBIG: SETZM MTPIOC ;Unset IOC handler. MOVEI A,[ASCSTR [552 Message is too large to mail; use FTP.]] PUSHJ P,NETREP POPJ P, ;Error return First off, this error message is a lie. The message is not necessarily too large to mail, we just don't have the disk space for it. (In which case using FTP certainly won't help, as the message suggests!) Secondly, the POPJ P, at the end will return to the instruction immediately following the losing IOT/SIOT (it doesn't look like %OPOPC is set), which I can't imagine could be a reasonable thing to do. Especially since the interrupt handler already deleted the half-written queue file and closed the output channel before calling this routine. It's at this point that I imagine it would be reasonable to shut the connection down. The analogous handler for errors during ordinary FTP does: ;;; Note - disk IOC's while writing: err, drop the connection, and don't return. STOBIG: SETZM STOIOC ;Unset IOC handler. OUTS NETO,[ASCSTR [452 File System failure - maybe disk full ]] .NETS NETO, ; Kick it right along... TLNN F,%LCHAOS JSR LOGOUT SYSCAL FINISH,[MOVEI NETO] JFCL JSR LOGOUT If someone will tell me the correct error code for a temporary error of this nature (is it perhaps 452, same as for FTP?), and the protocol for closing your connection in case of lossage (does FTP send two crlfs here for a reason?), I will correct all of this.  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 8 Jan 87 17:52:19 EST Date: Thu, 8 Jan 1987 17:51 EST Message-ID: From: Rob Austein To: "David A. Moon" Cc: ALAN@AI.AI.MIT.EDU, BUG-COMSAT@AI.AI.MIT.EDU Subject: FTPS disk full lossage In-reply-to: Msg of 8 Jan 1987 16:48-EST from David A. Moon Date: Thursday, 8 January 1987 16:48-EST From: David A. Moon .... But aren't disk full and directory full reported as IOC interrupts, not as error returns from a .CALL SIOT? Dunno. I can't find any evidence to support this theory. I didn't think .CALL would ever interrupt to signal errors, but I'm no expert.  Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 30002424620) by AI.AI.MIT.EDU 8 Jan 87 17:04:58 EST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 39116; Thu 8-Jan-87 16:52:14 EST Date: Thu, 8 Jan 87 16:51 EST From: David A. Moon Subject: Grumble. To: Alan Bawden cc: BUG-COMSAT@AI.AI.MIT.EDU In-Reply-To: <137943.870108.ALAN@AI.AI.MIT.EDU> Message-ID: <870108165110.6.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Thu, 8 Jan 87 15:16:58 EST From: Alan Bawden When mail servers get device or directory full errors they seem to just .VALUE. This is a gross loss for a number of reasons. They should nicely explain to the user end that there is temporarily a space problem, and then they should log out. I just killed a mess of mail servers that were uselessly tying up network, disk, and job resources. I've complained about this before, I think. I remember years ago taking out the code to explain nicely to the user end that there was a temporary error, and making the job just .LOGOUT instead. This was because there too many broken user ends that didn't handle temporary errors correctly, but everybody has to be able to handle the network connection going away. I don't know who made it .VALUE instead of quietly disappearing. Maybe there is a debug flag set wrong?  Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 30002424620) by AI.AI.MIT.EDU 8 Jan 87 17:03:46 EST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 39114; Thu 8-Jan-87 16:50:04 EST Date: Thu, 8 Jan 87 16:48 EST From: David A. Moon Subject: FTPS disk full lossage To: Rob Austein cc: ALAN@AI.AI.MIT.EDU, BUG-COMSAT@AI.AI.MIT.EDU In-Reply-To: <137955.870108.SRA@AI.AI.MIT.EDU> Message-ID: <870108164843.5.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Thu, 8 Jan 87 16:10:49 EST From: Rob Austein It looks like the problem is disk full, not directory full. Directory full seems to be handled correctly, right after the .CALL OPEN. Disk full errs in the middle of the OUT package, which does a JSR AUTSPY when SIOT fails. Fixing this cleanly is likely to be a real bear. Probably the simplest thing to do would be to set a flag around the disk output code and teach AUTPSY that disk .IOT/SIOT errors with that flag set are not really fatal but should go jump off to the FILERR code instead. Gack. Anybody have a better idea? Directory full can be signalled while doing output, as well as at .OPEN, since the size of a file's directory entry is a function of the number of blocks in the file in ITS. Most programs handle this by recognizing a particular PC in their IOC interrupt handler and dismissing to an appropriate recovery routine associated with that PC. Maybe that wouldn't work here because OUT has too many levels of modularity, in which case your flag idea would be equivalent. But aren't disk full and directory full reported as IOC interrupts, not as error returns from a .CALL SIOT?  Date: Thu, 8 Jan 87 16:10:49 EST From: Rob Austein Subject: FTPS disk full lossage To: ALAN@AI.AI.MIT.EDU, BUG-COMSAT@AI.AI.MIT.EDU Message-ID: <137955.870108.SRA@AI.AI.MIT.EDU> It looks like the problem is disk full, not directory full. Directory full seems to be handled correctly, right after the .CALL OPEN. Disk full errs in the middle of the OUT package, which does a JSR AUTSPY when SIOT fails. Fixing this cleanly is likely to be a real bear. Probably the simplest thing to do would be to set a flag around the disk output code and teach AUTPSY that disk .IOT/SIOT errors with that flag set are not really fatal but should go jump off to the FILERR code instead. Gack. Anybody have a better idea?  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 8 Jan 87 16:05:38 EST Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 8 Jan 87 15:02:43 EST Date: Thu, 8 Jan 1987 15:04 EST Message-ID: From: Rob Austein To: lear@ARAMIS.RUTGERS.EDU (eliot lear) Cc: bug-comsat@MC.LCS.MIT.EDU Subject: [COMSAT%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU: ] In-reply-to: Msg of 8 Jan 1987 12:56-EST from lear@aramis.rutgers.edu (eliot lear) Date: Thursday, 8 January 1987 12:56-EST From: lear@aramis.rutgers.edu (eliot lear) Um.. Guys, I was told that comsat could handle up to 20k. Was I misinformed or has this changed? Date: Thu, 8 Jan 87 02:46:26 EST From: Communications Satellite Message not sent and not queued; 15 Kbytes is far too large for me. It's not a constant, it depends on a lot of environmental factors. Also depends on how well COMSAT's garbage collector has dealt with events in the life of this COMSAT job. In this case the GC failed (I think it was a large @FILE spec but don't really know). I found a whole bunch of BADREQs this morning, so I flushed the guilty COMSAT, started a new one, and put the messages back in the queue. Your message was probably among them, so it should have been delivered ok. --Rob  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 8 Jan 87 15:22:03 EST Date: Thu, 8 Jan 1987 15:21 EST Message-ID: From: Rob Austein To: Alan Bawden Cc: BUG-COMSAT@AI.AI.MIT.EDU Subject: Grumble. In-reply-to: Msg of 8 Jan 1987 15:16-EST from Alan Bawden Date: Thursday, 8 January 1987 15:16-EST From: Alan Bawden To: BUG-COMSAT@AI.AI.MIT.EDU Re: Grumble. When mail servers get device or directory full errors they seem to just .VALUE. This is a gross loss for a number of reasons. They should nicely explain to the user end that there is temporarily a space problem, and then they should log out. I just killed a mess of mail servers that were uselessly tying up network, disk, and job resources. I've complained about this before, I think. Yup, you have. So have I. And we thought we fixed it, too. I don't suppose you made a crash dump?  Date: Thu, 8 Jan 87 15:16:58 EST From: Alan Bawden Subject: Grumble. To: BUG-COMSAT@AI.AI.MIT.EDU Message-ID: <137943.870108.ALAN@AI.AI.MIT.EDU> When mail servers get device or directory full errors they seem to just .VALUE. This is a gross loss for a number of reasons. They should nicely explain to the user end that there is temporarily a space problem, and then they should log out. I just killed a mess of mail servers that were uselessly tying up network, disk, and job resources. I've complained about this before, I think.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 8 Jan 87 13:44:15 EST Received: from aramis.rutgers.edu (TCP 20001402472) by MC.LCS.MIT.EDU 8 Jan 87 12:52:01 EST Received: by aramis.rutgers.edu; Thu, 8 Jan 87 12:56:29 EST Date: Thu, 8 Jan 87 12:56:29 EST From: lear@aramis.rutgers.edu (eliot lear) Message-Id: <8701081756.AA09157@aramis.rutgers.edu> To: bug-comsat@mc.lcs.mit.edu Subject: [COMSAT%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU: ] Um.. Guys, I was told that comsat could handle up to 20k. Was I misinformed or has this changed? ...eliot Return-Path: Date: Thu, 8 Jan 87 02:46:26 EST From: Communications Satellite To: "@MC.LCS.MIT.EDU:LEAR@RED.RUTGERS.EDU"@mc.lcs.mit.edu Cc: MAIL-MAINTAINERS%MX.LCS.MIT.EDU@mc.lcs.mit.edu Error in input request file. Request too large. Message not sent and not queued; 15 Kbytes is far too large for me. Please use the FTP program to transfer huge files around the network.  Date: Thu, 8 Jan 87 11:35:21 EST From: Jonathan A Rees Subject: Someone please flush this utterly bogus "optimization"! To: Moon@SCRC-STONY-BROOK.ARPA cc: BUG-MAIL@AI.AI.MIT.EDU In-reply-to: Msg of Tue 6 Jan 87 20:21 EST from David A. Moon Message-ID: <137842.870108.JAR@AI.AI.MIT.EDU> Date: Tue, 6 Jan 87 20:21 EST From: David A. Moon Flushing the logic altogether would mean that people at OZ (for example) would no longer be able to receive mail from outside, sent to person%oz@mit-mc. The bug is that somehow it fails to check that the host after the @ is the local host before doing the % processing. Yes, of course I didn't mean to flush % processing altogether, sorry. It would be necessary to check that the host after the @ is the local host. Jonathan  Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 30002424620) by AI.AI.MIT.EDU 6 Jan 87 20:26:40 EST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 37244; Tue 6-Jan-87 20:23:12 EST Date: Tue, 6 Jan 87 20:21 EST From: David A. Moon Subject: Someone please flush this utterly bogus "optimization"! To: Jonathan A Rees cc: BUG-MAIL@AI.AI.MIT.EDU In-Reply-To: <137248.870106.JAR@AI.AI.MIT.EDU> Message-ID: <870106202153.8.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Tue, 6 Jan 87 16:00:45 EST From: Jonathan A Rees This problem has screwed me time after time. Could someone who knows what's going on please remove the code which turns FOO%BAR@BAZ into FOO@BAR? Better, it should be invoked only if BAR is fully qualified, so that at least mail to FOO%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU will get sent directly -- but I realize this might be hard to test for. Simply flushing the logic altogether would be far preferable to the current lossage. Flushing the logic altogether would mean that people at OZ (for example) would no longer be able to receive mail from outside, sent to person%oz@mit-mc. The bug is that somehow it fails to check that the host after the @ is the local host before doing the % processing.  Date: Tue, 6 Jan 87 16:00:45 EST From: Jonathan A Rees Subject: Someone please flush this utterly bogus "optimization"! To: BUG-MAIL@AI.AI.MIT.EDU cc: JAR@AI.AI.MIT.EDU Message-ID: <137248.870106.JAR@AI.AI.MIT.EDU> I sent my message as follows: To: ejs%acorn at live-oak.lcs.mit.edu Cc: scheme-request at mc.lcs.mit.edu, info-scheme%acorn@live-oak.lcs.mit.edu Re: Please add.... --Text follows this line-- And it got bounced as below; it got turned into ejs@acorn, which names a totally different host (Rochester, not Gold Hill). This problem has screwed me time after time. Could someone who knows what's going on please remove the code which turns FOO%BAR@BAZ into FOO@BAR? Better, it should be invoked only if BAR is fully qualified, so that at least mail to FOO%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU will get sent directly -- but I realize this might be hard to test for. Simply flushing the logic altogether would be far preferable to the current lossage. Thanks, Jonathan Date: Tue, 6 Jan 87 15:51:28 EST From: Communications Satellite To: JAR at AI.AI.MIT.EDU Re: Msg of Tuesday, 6 January 1987 15:50-EST Message-ID: <137230.870106@AI.AI.MIT.EDU> FAILED: ejs at ACORN.CS.ROCHESTER.EDU; Recipient name apparently rejected. Last reply was: {550 Recipient ejs@ACORN.CS.ROCHESTER.EDU is not defined on this host.} FAILED: info-scheme at ACORN.CS.ROCHESTER.EDU; Recipient name apparently rejected. Last reply was: {550 Recipient info-scheme@ACORN.CS.ROCHESTER.EDU is not defined on this host.} Failed message follows: ------- Date: Tue, 6 Jan 87 15:50:39 EST From: Jonathan A Rees Subject: Please add.... To: ejs@ACORN.CS.ROCHESTER.EDU cc: info-scheme@ACORN.CS.ROCHESTER.EDU, scheme-request@MC.LCS.MIT.EDU In-reply-to: Msg of Tue 30 Dec 1986 16:46 est from ejs%acorn at live-oak.lcs.mit.edu Message-ID: <137229.870106.JAR@AI.AI.MIT.EDU> Date: Tue, 30 Dec 1986 16:46 est From: ejs%acorn at live-oak.lcs.mit.edu Please add the recipient "info-scheme%acorn@live-oak.lcs.mit.edu" to the scheme mailing list. This is a local redistribution point for the scheme mailing list. Thanks. -- Eric OK. Does this mean I should remove you from the list? Jonathan  Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 30002424620) by AI.AI.MIT.EDU 3 Jan 87 16:56:54 EST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 34427; Sat 3-Jan-87 16:52:15 EST Date: Sat, 3 Jan 87 16:50 EST From: David A. Moon Subject: Flushing %'s To: Jonathan A Rees cc: BUG-MAIL@AI.AI.MIT.EDU In-Reply-To: <135336.861231.JAR@AI.AI.MIT.EDU> Message-ID: <870103165011.0.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Wed, 31 Dec 86 16:07:19 EST From: Jonathan A Rees Could someone explain to me why COMSAT indiscriminately turns FOO%BAR@BAZ into FOO@BAR? I think it's a bug which no one has fixed yet. I still can't get any mail through to SUSHI, and this feature prevents me from doing explicit routing. (I guess I'll try double quotes next.) Good luck.  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 1 Jan 87 23:50:25 EST Date: Thu, 1 Jan 1987 23:50 EST Message-ID: From: Rob Austein To: swa@COMET.LCS.MIT.EDU (Steven Augart) Cc: bug-comsat@AI.AI.MIT.EDU Subject: mail on MX... In-reply-to: Msg of 26 Dec 1986 23:16-EST from swa@COMET.LCS.MIT.EDU (Steven Augart) Date: Friday, 26 December 1986 23:16-EST From: swa@COMET.LCS.MIT.EDU (Steven Augart) I am sending this to bug-comsat@AI because bug-comsat@MX forwards to MC, which appears to be down. Does it really? How broken. The real list is on AI in the first place. To the best of my knowledge (I may be wrong about this), MX sends mail destined for the Internet world (like BORAX.LCS.MIT.EDU) through MC. Close enough. It's more complex than that but doesn't change your argument. While MC remains down, could somebody temporarily change this to go through some other host? Not possible with the old code. I fixed this last week, but didn't install the new version because I had to catch a plane. (I refrain from suggesting such a host, for fear of inviting the wrath of said machine's maintainer.) No comment. --Rob  Date: Thu, 1 Jan 87 21:31:53 EST From: Richard Mlynarik To: BUG-COMSAT@AI.AI.MIT.EDU Message-ID: <135781.870101.MLY@AI.AI.MIT.EDU> These two messages have been sitting around in MC's queue for a long time. I noticed this because I was using one of the machines and it was starting up an smtp server a couple times an hour or so in order to tell MC that lisp machines don't accept mail. How many failures does it take until the message will finally be returned to sender as failed? Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 1 Jan 87 21:12:24 EST MLY@MC.LCS.MIT.EDU (Sent by MLY'@MC.LCS.MIT.EDU) 01/01/87 21:09:53 Re: Request results To: MLY at MC.LCS.MIT.EDU Message deleted: Received: from harvard.HARVARD.EDU (TCP 1200000011) by MC.LCS.MIT.EDU 26 Nov 86 15:35:17 EST Received: by harvard.HARVARD.EDU; Wed, 26 Nov 86 15:35:16 EST Date: Wed, 26 Nov 86 15:35:16 EST Received: by endor.HARVARD.EDU; Wed, 26 Nov 86 15:35:11 EST From: heddaya@harvard.HARVARD.EDU (Abdelsalam Heddaya--aka Solom) To: shafei%tohutmos-III@mc.lcs.mit.edu Subject: Test #1 Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 1 Jan 87 21:12:05 EST MLY@MC.LCS.MIT.EDU (Sent by MLY'@MC.LCS.MIT.EDU) 01/01/87 21:09:33 Re: Request results To: MLY at MC.LCS.MIT.EDU Message deleted: Received: from VX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 4 DEC 86 16:08:20 EST Received: by VX.LCS.MIT.EDU (4.12/4.8) id AA16937; Thu, 4 Dec 86 16:06:00 est Date: Thu, 4 Dec 86 16:06:00 est From: Dana Hajdu To: becker@violin.lcs.mit.e did you just d send me a message?  Date: Wed, 31 Dec 86 16:07:19 EST From: Jonathan A Rees Subject: Flushing %'s To: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <135336.861231.JAR@AI.AI.MIT.EDU> Could someone explain to me why COMSAT indiscriminately turns FOO%BAR@BAZ into FOO@BAR? I still can't get any mail through to SUSHI, and this feature prevents me from doing explicit routing. (I guess I'll try double quotes next.)  Received: from COMET.LCS.MIT.EDU (TCP 2202400102) by AI.AI.MIT.EDU 26 Dec 86 23:18:07 EST Received: by COMET.LCS.MIT.EDU (4.12/4.7); Fri, 26 Dec 86 23:16:48 est Date: Fri, 26 Dec 86 23:16:48 est From: swa@COMET.LCS.MIT.EDU (Steven Augart) Full-Name: Steven Augart Message-Id: <8612270416.AA15248@COMET.LCS.MIT.EDU> To: bug-comsat@ai.ai.mit.edu Subject: mail on MX... I am sending this to bug-comsat@AI because bug-comsat@MX forwards to MC, which appears to be down. To the best of my knowledge (I may be wrong about this), MX sends mail destined for the Internet world (like BORAX.LCS.MIT.EDU) through MC. While MC remains down, could somebody temporarily change this to go through some other host? (I refrain from suggesting such a host, for fear of inviting the wrath of said machine's maintainer) Or is my suggestion totally out to lunch? Thanks, SWA  Date: Wed, 24 Dec 86 23:04:28 EST From: Rob Austein Subject: COMSAT 558 To: BUG-COMSAT@AI.AI.MIT.EDU Message-ID: <134167.861224.SRA@AI.AI.MIT.EDU> I uncoupled the name used in the FOO%BAR@BAZ header hacking from the host number used for TCP relaying (TCPGAT). Both default to HN$MC, of course. The meaning of HDRGAT has changed: zero means as it used to (no relay header munging) but if non-zero it is now expected to be the address of the host to use in the header hacking rather than just -1 or something like that (ie, GATNAM is now set by looking up the string corresponding to the address in HDRGAT). MX, by special dispensation (the Gumby Memorial Kludge) sets HDRGAT but not TCPGAT, so it will use its own IMP interface for outgoing mail (suggestion from Gumby). The code that initializes HDRGAT and TCPGAT now checks to see if there was already a non-zero value there; if so, it leaves it alone. So you can patch a binary temporarily when something like the current MC-KS lossage happens. Patch instructions: TCPGAT: host to really use as TCP gateway HDRGAT: host to claim headers relayed from Lastly, I defined HN$XX so that you can use XX as a mail relay if you want to. I don't advise it as a general thing, but it's better than letting the mail fall on the floor. NONE OF THIS CODE HAS BEEN TESTED. I don't have time to do it before leaving tomrorow morning. Brave souls are encouraged to try it out, at own risk (do find somebody who knows how to assemble a new COMSAT first, though, there's more to it than meets the eye). If nobody has done anything with this code by the time I get back, I'll test it then. --Rob  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 22 Dec 86 10:20:19 EST Received: from decwrl.dec.com (TCP 3201600020) by MC.LCS.MIT.EDU 22 Dec 86 10:22:27 EST Received: from rhea.dec.com by decwrl.dec.com (5.54.3/4.7.34) id AA02949; Mon, 22 Dec 86 07:17:29 PST Message-Id: <8612221517.AA02949@decwrl.dec.com> Date: 22-Dec-1986 0925 From: karger%ultra.DEC@decwrl.DEC.COM To: bug-mail@mc.lcs.mit.edu Subject: FWD: Message of 22-Dec-86 09:07:23 I just tried to send a message to llp-request@mc.lcs.mit.edu to request that my name be removed from the list. (A request that I had made 2 years ago, but had never been done.) Anyway - the mailer on OZ returned the following POETRY to me in an error message. Can you see if something is wrong? Thanks! Paul From: RHEA::DECWRL::"Mailer%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU" "The Mailer Daemon" To: karger%ultra.DEC@decwrl Subj: Message of 22-Dec-86 09:07:23 Received: from DECWRL by DEC-RHEA with SMTP; Mon, 22 Dec 86 06:04-PST Received: from MC.LCS.MIT.EDU by decwrl.dec.com (5.54.3/4.7.34) id AA01688; Mon, 22 Dec 86 06:04:46 PST Date: Mon 22 Dec 86 09:07:34-EST Message-Id: <8612221404.AA01688@decwrl.dec.com> Message failed for the following: survey that endless line of men whose thoughts are not as mine Years 'ere you stood up from rest On my neck the collar prest Years when you lay down your ill I will stand and bear it still Courage lad, 'tis not for long Stand, quit you like stone, be strong!" So I thought his look would say And light on me my troubles lay And I stepped out in flesh and bone Manful, like the man of stone. - A.E. Housman@OZ.AI.MIT.EDU.#Chaos: Can't forward - unknown host "tics" @OZ.AI.MIT.EDU.#Chaos: Can't forward - unknown host "he way I am a Jass-saxophonist, so if you like to jam, please send me mail at naoki@mit-oz. "hope you like jamming, too"" l@dt xx oz ai mc ml md mx@OZ.AI.MIT.EDU.#Chaos: Can't forward - unknown host "e Other Half" MA 02215@OZ.AI.MIT.EDU.#Chaos: Can't forward - unknown host "n, Richard J." Maher-House@OZ.AI.MIT.EDU.#Chaos: Can't forward - unknown host " interests" K>@OZ.AI.MIT.EDU.#Chaos: Can't forward - unknown host "G REL" cstacy@OZ.AI.MIT.EDU.#Chaos: Can't forward - unknown host "tever" ey that endless line of men whose thoughts are not as mine Years 'ere you stood up from rest On my neck the collar prest Years when you lay down your ill I will stand and bear it still Courage lad, 'tis not for long Stand, quit you like stone, be strong!" So I thought his look would say And light on me my troubles lay And I stepped out in flesh and bone Manful, like the man of stone. - A.E. Housman@OZ.AI.MIT.EDU.#Chaos: Can't forward - unknown host "tics" ge@OZ.AI.MIT.EDU.#Chaos: Can't forward - unknown host "nt in Applied Mathematics Thinking of doing vision" ra, Ca@OZ.AI.MIT.EDU.#Chaos: Can't forward - unknown host "R" %?i$$$E8'[$h@OZ.AI.MIT.EDU.#Chaos: Can't forward - unknown host "" s@OZ.AI.MIT.EDU.#Chaos: Can't forward - unknown host "ambridge MA 02141" ur lot? I too would be where I am not I too survey that endless line of men whose thoughts are not as mine Years 'ere you stood up from rest On my neck the collar prest Years when you lay down your ill I will stand and bear it still Courage lad, 'tis not for long Stand, quit you like stone, be strong!" So I thought his look would say And light on me my troubles lay And I stepped out in flesh and bone Manful, like the man of stone. - A.E. Housman@OZ.AI.MIT.EDU.#Chaos: Can't forward - unknown host "nt in Applied Mathematics Thinking of doing vision" me he visto en tal aprieto. Catorce versos dicen que es soneto: burla burlando van los tres delante. Yo pense que no hallara consonante y estoy en la mitad de otro cuarteto. Mas si me veo en el primer terceto no hay cosa en los cuartetos que me espante. Por el primer terceto estoy entrando y parece que entre con pie derecho, pues fin con este verso le voy dando. Ya voy por el segundo, y aun sospecho que voy los trece versos acabando: contad si son catorce, y esta hecho. Lope @OZ.AI.MIT.EDU.#Chaos: Can't forward - unknown host "" .G.BEN@OZ.AI.MIT.EDU.#Chaos: Can't forward - unknown host "" 037@OZ.AI.MIT.EDU.#Chaos: Can't forward - unknown host "n't you have something better to do rather than type whois?" nechuk, Daniel@OZ.AI.MIT.EDU.#Chaos: Can't forward - unknown host "" bert C. Berwick@OZ.AI.MIT.EDU.#Chaos: Can't forward - unknown host "nt in Applied Mathematics Thinking of doing vision" Box 8171, Austin, TX 78712@OZ.AI.MIT.EDU.#Chaos: Can't forward - unknown host "LTICS.ARPA" chalski, Ryszard@OZ.AI.MIT.EDU.#Chaos: Can't forward - unknown host " REL" $E8'[$h@OZ.AI.MIT.EDU.#Chaos: Can't forward - unknown host "" 8171, Austin, TX 78712@OZ.AI.MIT.EDU.#Chaos: Can't forward - unknown host "GZ" er@OZ.AI.MIT.EDU.#Chaos: Can't forward - unknown host "D.LG" l.txt.1@OZ.AI.MIT.EDU.#Chaos: Can't forward - unknown host "t JPL this summer: Jet Propulsion Lab, 510-202 4800 Oak Grove Drive Pasadena, CA 91109 (818) 577-6603" 10 Holts Ave, Somerville, MA 02143@OZ.AI.MIT.EDU.#Chaos: Can't forward - unknown host "" Law Student and retire to study Talmud.@OZ.AI.MIT.EDU.#Chaos: Can't forward - unknown host "" ------------ Received: from MC.LCS.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet with SMTP; 22 Dec 86 09:07-EST Received: from decwrl.dec.com (TCP 3201600020) by MC.LCS.MIT.EDU 22 Dec 86 09:04:54 EST Received: from rhea.dec.com by decwrl.dec.com (5.54.3/4.7.34) id AA01661; Mon, 22 Dec 86 06:00:25 PST Message-Id: <8612221400.AA01661@decwrl.dec.com> Date: 22-Dec-1986 0856 From: karger%ultra.DEC@decwrl.DEC.COM To: llp-request@mc.lcs.mit.edu Subject: FWD: Message of 21-Dec-86 20:07:35 I requested that my name be removed from the LLP list at least two years ago. However, it looks like it is still on the list. Could you please remove karger@marlboro.dec.com or karger@dec-marlboro from the list. Thank you. Paul Karger From: RHEA::DECWRL::"Mailer%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU" "The Mailer Daemon" To: TMPLee.CCS@DOCKMASTER.ARPA Subj: Message of 21-Dec-86 20:07:35 Received: from DECWRL by DEC-RHEA with SMTP; Sun, 21 Dec 86 19:30-PST Received: from DOCKMASTER.ARPA by decwrl.dec.com (5.54.3/4.7.34) id AA24456; Sun, 21 Dec 86 19:30:44 PST Date: Sun, 21 Dec 86 20:16 EST Delivery-Date: 21 Dec 86 20:17 EST Delivery-By: Network_Server.Daemon@DOCKMASTER.ARPA (Mailer%OZ.AI.MIT.EDU@MC.LCS.MIT.) Message-Id: <"861222011645.000000;The Mailer Daemon"@XX.LCS.MIT.EDU> Resent-Date: 21 Dec 86 22:30 EST Resent-From: TMPLee@DOCKMASTER.ARPA Resent-To: karger%ultra.dec@decwrl Resent-Comment: FYI -- a bounceback from a recent note to llp. Resent-Message-Id: <861222033028.582263@DOCKMASTER.ARPA> Message failed for the following: PERKINS@MARLBORO.DEC.COM.Internet: 550 No such local mailbox as "PERKINS", recipient rejected KARGER@MARLBORO.DEC.COM.Internet: 550 No such local mailbox as "KARGER", recipient rejected ------------ Received: from MC.LCS.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet with SMTP; 21 Dec 86 20:07-EST Received: from DOCKMASTER.ARPA (TCP 3200000071) by MC.LCS.MIT.EDU 21 Dec 86 19:57:33 EST Date: Sun, 21 Dec 86 18:06 EST From: TMPLee@DOCKMASTER.ARPA Subject: Re: berkeley and decwrl To: *Hobbit* cc: llp@MC.LCS.MIT.EDU In-Reply-To: Message of 19 Dec 86 16:28 EST from *Hobbit* Message-ID: <861221230651.550244@DOCKMASTER.ARPA> Yes, changing the host names is a pain. My real complaint is that there did not seem to be any mechanism in place at either UTexas or this system or even llp to have notified people that this was happening. And we have not been forced to do it on this system because there isn't yet enough room in our host tables to hold the new addresses, so we're still working with the old ones (or so the system administrators say.) ------- -------  Date: Mon, 22 Dec 86 08:23:11 EST From: David Vinayak Wallace Subject: timeout To: SRA@XX.LCS.MIT.EDU cc: BUG-COMSAT@AI.AI.MIT.EDU In-reply-to: Msg of Sun 21 Dec 1986 22:42 EST from Rob Austein Message-ID: <133594.861222.GUMBY@AI.AI.MIT.EDU> Date: Sun, 21 Dec 1986 22:42 EST From: Rob Austein Are we still timing out massively when talking to CSNET-RELAY and WISCVM? I haven't been reading the STATS files much lately, they're too depressing.... Since I tweaked the timeouts I've been watching this and mail IS getting through to both of those sites. CSNET-RELAY is down (which probably means it'll be down all christmas) so there are a couple of messages waiting to get there but you can't blame comsat for that. Unfortunately there is dead stuff in the queue which has been wating for CRVAX.SRI.COM and SHUSHI.STANFORD.EDU for a lllloooonnnngggg time...  Date: Sun, 21 Dec 86 23:16:01 EST From: Rob Austein Subject: Two bugs To: BUG-COMSAT@AI.AI.MIT.EDU Message-ID: <133397.861221.SRA@AI.AI.MIT.EDU> 1) The STATS file only gets chopped off at the normal 50 blocks if COMSAT gets to an idle state. It has been either down or busy for the last three days, and the STATS file from today is already at 90 blocks. 2) CMSG handling of return-path info is buggy: 092804 InReq: 1 > 1; SPECS:{NET-MAIL-FROM: SRI-NIC.ARPA}{RTP:tcp-ip-RELAY@SRI-NIC.ARPA}{TL=808.} ID=<147066.861217@MC.LCS.MIT.EDU> EXP->MWT@1200600054::=(daniel.g.markt@40700011406),JNC@1200600054::=(JNC@40700002420),GZT.TDF@40700011406,gdtt@40700016260,DCP@1200600054::=(DCP@30002424620) 092813 ICP->SCRC-STONY-BROOK.ARPA (TCP-SMTP=Timeout) 092844 ICP->XX.LCS.MIT.EDU (CHAOS-SMTP) 092847 TO->JNC 092849 ICP->OZ.AI.MIT.EDU (CHAOS-SMTP) 092851 XTO->GZT.TDF 092854 XTO->daniel.g.markt ...PERM ERR={550 No such mailbox as "daniel.g.markt" on OZ.AI.MIT.EDU} 092855 TEXT-> 092856 ICP->CIPG.MIT.EDU (CHAOS-SMTP=Bad state) 092856 ICP->CIPG.MIT.EDU (CHAOS-MAIL) 092856 TO->gdtt 092908 CMSG ID=<147067.861217@MC.LCS.MIT.EDU> EXP->tcp-ip-RELAY@SRI-NIC.ARPA@1200000063 092910 ICP->SRI-NIC.ARPA (TCP-SMTP) 092916 TO->tcp-ip-RELAY@SRI-NIC.ARPA 092919 NTMBEG PERM ERR={500 Syntax error or field too long: RCPT TO:} 092920 Queued: <147066.861217@MC.LCS.MIT.EDU> for SCRC-STONY-BROOK.ARPA Probably the code is just appending the NET-MAIL-FROM value onto the RTP value without bothering to check for an existing "@". Undoubtably this was the right thing to do back in 3,000,000 BC and it was never changed when SMTP was invented.  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 21 Dec 86 22:41:26 EST Date: Sun, 21 Dec 1986 22:42 EST Message-ID: From: Rob Austein To: "Christopher C. Stacy" Cc: BUG-COMSAT@AI.AI.MIT.EDU Subject: STATS typo In-reply-to: Msg of 21 Dec 1986 22:05-EST from "Christopher C. Stacy" Date: Sunday, 21 December 1986 22:05-EST From: "Christopher C. Stacy" Compiling EQV file Gobbling LSR1..., LSRADR: 70000NAMES 393 (6576. wds)... Ok, fixed in the sources. If anybody cares enough they can compile and install a new version. I don't, I can read it just fine as is. Are we still timing out massively when talking to CSNET-RELAY and WISCVM? I haven't been reading the STATS files much lately, they're too depressing....  Date: Sun, 21 Dec 86 22:05:00 EST From: "Christopher C. Stacy" Subject: STATS typo To: BUG-COMSAT@AI.AI.MIT.EDU Message-ID: <133372.861221.CSTACY@AI.AI.MIT.EDU> Compiling EQV file Gobbling LSR1..., LSRADR: 70000NAMES 393 (6576. wds)...  Date: Fri, 19 Dec 86 02:54:39 EST From: Alan@AI,Moon@AI Sender: ALAN@AI.AI.MIT.EDU Subject: OK, I just saw it happen again. To: BUG-COMSAT@AI.AI.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU Message-ID: <132522.861219.ALAN@AI.AI.MIT.EDU> For most of yesterday (Thursday the 18th) COMSAT on MC was catatonic. Our guess is that it was stuck in a JOB device wait (waiting for the DQ device). As soon as Alan looked at the situation COMSAT started running again, so probably something he did caused COMSAT to get PCLSR'd out of the system call for the first time all day, and the second time the timing screw did not occur. The right thing is for someone to fix the last bug in the JOB/BOJ code. A quick fix the COMSAT maintainers might consider, is to take an occasional %PIRLT interrupt to keep its interactions with DQ lubricated. A better fix would be for Alan to finish up the improved Domain Demon interface, so that COMSAT can use it instead, and not be subject to this particular class of ITS bug.  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 16 Dec 86 23:15:23 EST Received: from WHORFIN.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 16 Dec 86 23:13-EST Date: Tue, 16 Dec 86 23:10 EST From: Rob Austein Subject: Yet another bit of broken code To: bug-comsat@AI.AI.MIT.EDU Message-ID: <861216231058.3.SRA@WHORFIN.LCS.MIT.EDU> The following is a listing of MD's queue, just before I flushed the message in question. Note the message ID and failure counts. This was originally a :QSEND, and has been popping up cute little "SMTP serving MD" messages in WHORFIN's wholine ever since. Received: from MD.LCS.MIT.EDU (CHAOS 3132) by MC.LCS.MIT.EDU 16 Dec 86 22:37:14 EST WHORFN@MD.LCS.MIT.EDU (Sent by SRA'@MD.LCS.MIT.EDU) 12/16/86 22:37:23 Re: Request results To: WHORFN at MD.LCS.MIT.EDU WHORFIN.LCS.MIT.EDU: failure cnt 0 <2234.861205.SRA@MD.LCS.MIT.EDU> 5 DEC 1986 0915 EST SRA 11 -> sra at WHORFIN.LCS.MIT.EDU  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 16 Dec 86 18:22:52 EST Date: Tue, 16 Dec 1986 18:25 EST Message-ID: From: Rob Austein To: Phil Agre cc: zvona@AI.AI.MIT.EDU, bug-mail@AI.AI.MIT.EDU Subject: screwy headers In-reply-to: Msg of 16 Dec 1986 17:00-EST from Phil Agre This is a known problem, not specific to ITS. The global cause is the big-endian little-endian war going on between the USA and the UK. In the UK, EDU.MIT.AI.AI would be the correct form. The proximate cause is some machine that (apparently) sits on a raft in the middle of the atlantic ocean and converts from one format to the other. It screws up occasionally. I suspect that machine is run by the UK, but am not sure of this. You can stop barfing now. The problem Zvona was talking about was something else, namely, that COMSAT was written in the days when you could measure the round trip time for a network connection in seconds rather than minutes. COMSAT times out a lot these days.  Received: from BRL-SPARK.ARPA (TCP 30001213404) by AI.AI.MIT.EDU 16 Dec 86 17:26:15 EST Received: from CS.UCL.AC.UK by SPARK.BRL.ARPA id ae04734; 16 Dec 86 17:19 EST Received: from sevax.prg.oxford.ac.uk by mv1.Cs.Ucl.AC.UK via Janet with NIFTP id aa04054; 16 Dec 86 22:04 WET Via: UK.AC.OXFORD.PRG.SEVAX ; Tue, 16 Dec 86 22:00:07 GMT Date: Tue, 16 Dec 86 22:00:07 GMT From: Phil Agre Message-Id: <8612162200.AA28685@UK.AC.OXFORD.PRG.SEVAX (4.12/prgv.16)> To: zvona <@Cs.Ucl.AC.UK:zvona@mit-ai.arpa> Subject: screwy headers Cc: bug-mail <@Cs.Ucl.AC.UK:bug-mail@mit-ai.arpa> I'm not sure what your mail bug is, but if you look at the enclosed message, you'll see that someone somewhere reverses the order of the domain names, producing things like edu.mit.ai.ai etc. I don't know who does this or why, but it could be that the x.y.z between the % and the @ in the address to me needs to be z.y.x instead. I've never looked closely at the address that AGRE@OZ forwards to (it's in the mailing list file on oz and probably ai), but it might be backwards. Maybe the mailer in London thinks in reverse order. I believe that mail to Postmaster at the London machine works, you might inquire if you can't figure it out there. >From ZVONA@edu.mit.ai.ai Mon Dec 15 23:16:59 1986 Via: 000005111500/UCL-CS.FTP.MAIL ; 15 Dec 1986 23:16:52-WET Received: from ucl-cs-vax1 by mv1.Cs.Ucl.AC.UK via Ethernet with SMTP id aa07640; 15 Dec 86 23:06 WET Received: from 44d.cs.ucl.ac.uk by vax1.Cs.Ucl.AC.UK with SMTP id aa07952; 15 Dec 86 23:12 GMT Received: from [10.0.0.44] by 44d.Cs.Ucl.AC.UK via Satnet with SMTP id a018496; 15 Dec 86 23:08 GMT Received: from OZ.AI.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 15 Dec 86 12:13-EST Received: from AI.AI.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet with SMTP; 15 Dec 86 12:09-EST Date: Mon, 15 Dec 86 12:04:59 EST From: David Chapman Subject: COMSAT is losing on SEVAX the same way it loses on SUSHI To: BUG-MAIL@edu.mit.ai.ai Cc: AGRE@edu.mit.ai.ai Message-Id: <130778.861215.ZVONA@AI.AI.MIT.EDU> Sender: ZVONA%ai.ai.mit.edu.#chaos@edu.mit.lcs.xx Status: R I've been corresponding with Agre just fine by sending him mail as agre@ai, which forwards to agre@oz, which forwards to agre%sevax.etc. Mail direct to agre%sevax.etc loses consistently. Date: Sun, 14 Dec 86 05:26:54 EST From: Communications Satellite To: ZVONA at AI.AI.MIT.EDU Re: Msg of Wednesday, 10 December 1986 20:18-EST FAILED: agre%sevax.prg.oxford.ac.uk at CS.UCL.AC.UK; Host appears to be permanently down or not accepting mail. Failed message follows: ------- Date: Wed, 10 Dec 86 20:18:56 EST From: David Chapman To: agre%sevax.prg.oxford.ac.uk@CS.UCL.AC.UK Message-ID: <129032.861210.ZVONA@AI.AI.MIT.EDU> This is to test a comsat bug. If you get it, please mail it back to me (in which case there is no bug). If you don't get it, I'll know that COMSAT fucking up with sevax the same way it's fucking up with sushi. (Why do my fingers always type sexvax, he asked rhetorically.)  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 15 Dec 86 13:29:58 EST Date: Mon, 15 Dec 1986 13:30 EST Message-ID: From: Rob Austein To: David Chapman Cc: BUG-COMSAT@AI.AI.MIT.EDU Subject: fiddlesticks In-reply-to: Msg of 15 Dec 1986 13:02-EST from David Chapman David, What you are seeing is the long timeout problem, I think. CSNET-RELAY is overloaded, and the UK sites are at the other end of a satellite bounce. Gumby and I have been twiddling this lately, I'm going to try some more this evening if I remember (doing it during the day is useless, everything times out).  Date: Mon, 15 Dec 86 13:02:16 EST From: David Chapman Subject: fiddlesticks To: BUG-COMSAT@AI.AI.MIT.EDU Message-ID: <130810.861215.ZVONA@AI.AI.MIT.EDU> Well, I take back what I said about being able to communicate with Agre reliably through OZ. I'm still suspicious, though. Date: Sun 14 Dec 86 14:41:09-EST From: The Mailer Daemon To: ZVONA at AI.AI.MIT.EDU Re: Message of 11-Dec-86 14:14:31 Message undeliverable and dequeued after 3 days: agre%sevax.prg.oxford.ac.uk@CS.UCL.AC.UK.#Internet: Cannot connect to host ------------ Received: from OZ.AI.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 11 Dec 86 14:14-EST Received: from AI.AI.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet with SMTP; 11 Dec 86 14:08-EST Date: Thu, 11 Dec 86 14:07:57 EST From: David Chapman To: AGRE@AI.AI.MIT.EDU Message-ID: <129373.861211.ZVONA@AI.AI.MIT.EDU> You've got a book in the mail from telos press.  Date: Mon, 15 Dec 86 12:04:59 EST From: David Chapman Subject: COMSAT is losing on SEVAX the same way it loses on SUSHI To: BUG-MAIL@AI.AI.MIT.EDU cc: AGRE@AI.AI.MIT.EDU Message-ID: <130778.861215.ZVONA@AI.AI.MIT.EDU> I've been corresponding with Agre just fine by sending him mail as agre@ai, which forwards to agre@oz, which forwards to agre%sevax.etc. Mail direct to agre%sevax.etc loses consistently. Date: Sun, 14 Dec 86 05:26:54 EST From: Communications Satellite To: ZVONA at AI.AI.MIT.EDU Re: Msg of Wednesday, 10 December 1986 20:18-EST FAILED: agre%sevax.prg.oxford.ac.uk at CS.UCL.AC.UK; Host appears to be permanently down or not accepting mail. Failed message follows: ------- Date: Wed, 10 Dec 86 20:18:56 EST From: David Chapman To: agre%sevax.prg.oxford.ac.uk@CS.UCL.AC.UK Message-ID: <129032.861210.ZVONA@AI.AI.MIT.EDU> This is to test a comsat bug. If you get it, please mail it back to me (in which case there is no bug). If you don't get it, I'll know that COMSAT fucking up with sevax the same way it's fucking up with sushi. (Why do my fingers always type sexvax, he asked rhetorically.)  Date: Mon, 15 Dec 86 11:53:20 EST From: David Vinayak Wallace Subject: COMSAT unlocked To: BUG-COMSAT@AI.AI.MIT.EDU Message-ID: <130774.861215.GUMBY@AI.AI.MIT.EDU>  Date: Mon, 15 Dec 86 03:54:54 EST From: David Vinayak Wallace Subject: FINISH losing, timeout retries too often To: BUG-COMSAT@AI.AI.MIT.EDU Message-ID: <130657.861215.GUMBY@AI.AI.MIT.EDU> The following sequence appears frequently in comsat's queue file. This was unaffected by my increasing comsat's timout. 034044 ICP->CRVAX.SRI.COM (TCP-SMTP) 034049 QID=<128455.861209@AI.AI.MIT.EDU> 034050 TO->WRING 034059 FINISH call failed - DEVICE NOT READY...NSMBYE timed out Also, when comsat times out trying to connect to hosts which are down, why does it then try again only a few minutes later? Perhaps it should wait an hour or so? david  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 12 Dec 86 19:32:07 EST Received: from MX.LCS.MIT.EDU (CHAOS 1440) by MC.LCS.MIT.EDU 12 Dec 86 19:32:18 EST Date: Fri, 12 Dec 86 19:33:44 EST From: David Vinayak Wallace Subject: What's the story with CSNET-RELAY? To: JAR@AI.AI.MIT.EDU cc: BUG-MAIL@MX.LCS.MIT.EDU In-reply-to: Msg of Fri 12 Dec 86 18:33:29 EST from Jonathan A Rees Message-ID: <961803.861212.GUMBY@MX.LCS.MIT.EDU> Date: Fri, 12 Dec 86 18:33:29 EST From: Jonathan A Rees CSNET-RELAY has apparently been unreachable for a week or two now. Can anyone tell me why this is the case and whether anything is being done to fix it? (I know it's not a local problem, but thought someone on this list would know.) For once this IS a local problem! I am lengthening the timeouts in COMSAT (holdovers from the earlier NCP age when the arpanet worked and 36-bit dinosaurs were the lords of creation). Unfortunately the timeouts are scattered about (don't forget that the brontosaurus had two brains!), so this is not a 1-minute patch. Perhaps later tonite we will start winning.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 12 Dec 86 18:34:00 EST Received: from MX.LCS.MIT.EDU (CHAOS 1440) by MC.LCS.MIT.EDU 12 Dec 86 18:33:58 EST Received: from AI.AI.MIT.EDU (CHAOS 3130) by MX.LCS.MIT.EDU 12 Dec 86 18:35:24 EST Date: Fri, 12 Dec 86 18:33:29 EST From: Jonathan A Rees Subject: What's the story with CSNET-RELAY? To: BUG-mail@MX.LCS.MIT.EDU Message-ID: <129828.861212.JAR@AI.AI.MIT.EDU> CSNET-RELAY has apparently been unreachable for a week or two now. Can anyone tell me why this is the case and whether anything is being done to fix it? (I know it's not a local problem, but thought someone on this list would know.) I'm also having trouble with many other hosts, e.g. INDIANA.EDU and HPLABS.HP.COM, but this might be mere coincidence. Thanks Jonathan  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 12 Dec 86 18:21:20 EST Date: Fri, 12 Dec 1986 18:13 EST Message-ID: From: Rob Austein To: Bill Long cc: bug-comsat@AI.AI.MIT.EDU, bede@XX.LCS.MIT.EDU Subject: bitnet problems In-reply-to: Msg of 12 Dec 1986 17:19-EST from Bill Long Date: Friday, 12 December 1986 17:19-EST From: Bill Long To: SRA@MC.LCS.MIT.EDU I'm having trouble with an address translation that used to work fine. On MX, the address PPP-UCLA, which should be translated into ILD9EMY%UCLAMVS.BITNET@WISCVM actually results in the following behavior: Date: Fri, 12 Dec 86 16:31 EST From: Communications Satellite Subject: Msg of Friday, 12 December 1986 16:31-EST To: "WJL@MX.LCS.MIT.EDU"@MX ============ A copy of your message is being returned, because: ============ "ILD9EMY%UCLAMVS.BITNET@192.5.2.24" at MC.LCS.MIT.EDU is an unknown recipient. ============ Failed message follows: ============ Received: from MX.LCS.MIT.EDU (CHAOS 1440) by MC.LCS.MIT.EDU 12 Dec 86 16:31:03 EST Date: Fri, 12 Dec 86 16:32:31 EST From: Bill Long To: PPP-UCLA%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU Message-ID: <961769.861212.WJL@MX.LCS.MIT.EDU> This is a test.. ;;;;;;; Bede said you had made some changes at Wiscvm's request. Can you offer any help? -Bill Long Please send COMSAT errors to BUG-COMSAT@its-of-your-choice, not to me personally. I'm not the only person who hacks that program. I don't know what changes Bede is talking about; I don't recall doing anything for WISCVM lately. WISCVM's address changed recently. COMSAT binds name to address when the message is first queued up. For mailing lists (like PPP-UCLA) it binds when it compiles the LIST EQV file. I expect that's your problem. I copied MX:.MAIL.;NAMES > to itself, which will force a recompile of the EQV file and should fix this problem for you. In the long run we should fix COMSAT so that it doesn't bind names to addresses until it's actually opening network connections. --Rob  Date: Thu, 11 Dec 86 03:01:13 EST From: David Vinayak Wallace To: BUG-COMSAT@AI.AI.MIT.EDU Message-ID: <129148.861211.GUMBY@AI.AI.MIT.EDU> may I have the lock to COMSAT? I would like to extend the timeouts so that mail will once again get through to RELAY.CS.NET and WISCVM.WISC.EDU  Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 30002424620) by AI.AI.MIT.EDU 9 Dec 86 20:02:18 EST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 19133; Tue 9-Dec-86 19:42:01 EST Date: Tue, 9 Dec 86 19:41 EST From: David A. Moon Subject: convincing COMSAT to use internet To: Gumby@AI.AI.MIT.EDU cc: Rob Austein , BUG-MAIL@AI.AI.MIT.EDU In-Reply-To: Message-ID: <861209194142.3.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Tue, 9 Dec 1986 18:18 EST From: Rob Austein Date: Monday, 8 December 1986 14:02-EST From: David Vinayak Wallace Huh? No, I'm not crazy. But is there an easy (i.e. non-klugy) way of asking comsat to use internet smtp to talk to 4.x unix hosts rather than chaos mail? There's no unix chaos smtp code, while all (I think) unix 4.x machines on the chaosnet have internet addresses. No. COMSAT is too smart about recognizing the "best" address and too stupid about letting the user force a route. If you care enough to write code you should just write a CHAOS/SMTP listener for unix. Shouldn't be too hard, the Twenex one is only 8 pages long and it's written in MIDAS. And the ITS one is just a few one-line changes to the TCP/SMTP one.  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 9 Dec 86 18:34:07 EST Date: Tue, 9 Dec 1986 18:18 EST Message-ID: From: Rob Austein To: Gumby@AI.AI.MIT.EDU Cc: BUG-MAIL@AI.AI.MIT.EDU Subject: convincing COMSAT to use internet In-reply-to: Msg of 8 Dec 1986 14:02-EST from David Vinayak Wallace Date: Monday, 8 December 1986 14:02-EST From: David Vinayak Wallace Huh? No, I'm not crazy. But is there an easy (i.e. non-klugy) way of asking comsat to use internet smtp to talk to 4.x unix hosts rather than chaos mail? There's no unix chaos smtp code, while all (I think) unix 4.x machines on the chaosnet have internet addresses. No. COMSAT is too smart about recognizing the "best" address and too stupid about letting the user force a route. If you care enough to write code you should just write a CHAOS/SMTP listener for unix. Shouldn't be too hard, the Twenex one is only 8 pages long and it's written in MIDAS.  Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 30002424620) by AI.AI.MIT.EDU 8 Dec 86 16:37:53 EST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 17763; Mon 8-Dec-86 16:34:46 EST Date: Mon, 8 Dec 86 16:34 EST From: David A. Moon Subject: New LUNAR functions To: Rob Austein cc: Bug-COMSAT@AI.AI.MIT.EDU In-Reply-To: Message-ID: <861208163426.2.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Thu, 4 Dec 1986 23:57 EST From: Rob Austein Dave, do you have any objection to making EMACS;LUNAR :EJ a link to MOON;LUNAR :EJ on all ITS machines and installing the new version on all machines? I have no objection. Actually I thought that had been done already, several years ago. I know people other than you screw around with the version on AI, but it -is- your init file, after all, so I thought I should ask your permission.... Perhaps it is time to put the Comsat-hacking parts of this library into a separate library.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 8 Dec 86 14:00:03 EST Received: from MX.LCS.MIT.EDU (CHAOS 1440) by MC.LCS.MIT.EDU 8 Dec 86 14:00:17 EST Date: Mon, 8 Dec 86 14:02:10 EST From: David Vinayak Wallace Subject: convincing COMSAT to use internet To: BUG-MAIL@MX.LCS.MIT.EDU reply-to: Gumby@AI.AI.MIT.EDU Message-ID: <961147.861208.GUMBY@MX.LCS.MIT.EDU> Huh? No, I'm not crazy. But is there an easy (i.e. non-klugy) way of asking comsat to use internet smtp to talk to 4.x unix hosts rather than chaos mail? There's no unix chaos smtp code, while all (I think) unix 4.x machines on the chaosnet have internet addresses. david  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 4 Dec 86 23:57:28 EST Date: Thu, 4 Dec 1986 23:57 EST Message-ID: From: Rob Austein To: Moon@AI.AI.MIT.EDU cc: Bug-COMSAT@AI.AI.MIT.EDU Subject: New LUNAR functions On request from Penny, I added two new routines to LUNAR, Show Exact Message and Kill Exact Message. These are like Show Message and Kill Message except that they take the entire Message-ID (except the angle brackets) as an argument, so you can work around funny Message-IDs (I hope). Dave, do you have any objection to making EMACS;LUNAR :EJ a link to MOON;LUNAR :EJ on all ITS machines and installing the new version on all machines? I know people other than you screw around with the version on AI, but it -is- your init file, after all, so I thought I should ask your permission....  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 4 Dec 86 13:34:06 EST Received: from DEEP-THOUGHT.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 4 DEC 86 13:34:31 EST Date: Thu 4 Dec 86 13:33:53-EST From: Michael Ernst Subject: Problem with MC mailer To: bug-mail@MC.LCS.MIT.EDU cc: ls.srb@DEEP-THOUGHT.MIT.EDU Reply-To: mernst@eddie Message-ID: <12260153367.9.MERNST@DEEP-THOUGHT.MIT.EDU> This message has been received numerous times (three typical headers are shown here). Please delete this message from your mail queue. Thanks. -Mike Message 52 -- ************************ 4-Dec-86 13:15:47-EST,5370;000000000003 Received: from mc.lcs.mit.edu by EDDIE.MIT.EDU (5.31/4.7) id AA11797; Thu, 4 Dec 86 09:21:46 EST Received: from grape-nehi.LCS.MIT.EDU (TCP 2202400115) by MC.LCS.MIT.EDU 2 Dec 86 16:43:21 EST Received: by grape-nehi.LCS.MIT.EDU (5.51/4.8); Tue, 2 Dec 86 16:40:24 EST Received: from DEEP-THOUGHT.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 2 Dec 86 16:18-EST Date: 2 Dec 1986 16:11 EST (Tue) Message-Id: Sender: LS.SRB%DEEP-THOUGHT@grape-nehi.LCS.MIT.EDU Message 53 -- ************************ 4-Dec-86 13:17:40-EST,5370;000000000001 Received: from mc.lcs.mit.edu by EDDIE.MIT.EDU (5.31/4.7) id AA12235; Thu, 4 Dec 86 09:37:55 EST Received: from grape-nehi.LCS.MIT.EDU (TCP 2202400115) by MC.LCS.MIT.EDU 2 Dec 86 16:43:21 EST Received: by grape-nehi.LCS.MIT.EDU (5.51/4.8); Tue, 2 Dec 86 16:40:24 EST Received: from DEEP-THOUGHT.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 2 Dec 86 16:18-EST Date: 2 Dec 1986 16:11 EST (Tue) Message-Id: Sender: LS.SRB%DEEP-THOUGHT@grape-nehi.LCS.MIT.EDU Message 55 -- ************************ 4-Dec-86 13:23:58-EST,5370;000000000001 Received: from mc.lcs.mit.edu by EDDIE.MIT.EDU (5.31/4.7) id AA12596; Thu, 4 Dec 86 09:54:12 EST Received: from grape-nehi.LCS.MIT.EDU (TCP 2202400115) by MC.LCS.MIT.EDU 2 Dec 86 16:43:21 EST Received: by grape-nehi.LCS.MIT.EDU (5.51/4.8); Tue, 2 Dec 86 16:40:24 EST Received: from DEEP-THOUGHT.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 2 Dec 86 16:18-EST Date: 2 Dec 1986 16:11 EST (Tue) Message-Id: Sender: LS.SRB%DEEP-THOUGHT@grape-nehi.LCS.MIT.EDU -------  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 4 Dec 86 03:50:58 EST Date: Thu, 4 Dec 1986 03:52 EST Message-ID: From: Rob Austein To: "Pandora B. Berman" Cc: BUG-COMSAT@AI.AI.MIT.EDU Subject: you, too, can garble QIDs But, as it happens, I didn't. One of my two braincells was operational that day and I typed the entire old-style Message-ID and (SPECIAL-REQUEST) cruftage into one of the lower level routines in LUNAR. Which is what the one useful line of code in M-X Show Message$ does; the other n lines are trying to make up for ITS's lack of a GTHST% jsys.  Date: Thu, 4 Dec 86 02:52:12 EST From: "Pandora B. Berman" Subject: you, too, can garble QIDs To: SRA@XX.LCS.MIT.EDU cc: BUG-COMSAT@AI.AI.MIT.EDU Message-ID: <126250.861204.CENT@AI.AI.MIT.EDU> Date: Wed, 3 Dec 1986 17:00 EST From: Rob Austein To: "David A. Moon" Cc: BUG-COMSAT@AI.AI.MIT.EDU Subject: SEND vs. SMTP .... Er, well, it may not be happening at all. Or rather, I found a completely bizzare clump of messages when I tried to investigate. Here's the portion of the STATS file that got me interested (this is actually from today's file, not the one that I first saw): ---------- 154817 Unqueueing to host GAYE.AI.MIT.EDU 154818 ICP->GAYE.AI.MIT.EDU (CHAOS-SMTP) 154823 QID=<122313.861123@AI.AI.MIT.EDU>...error for <>="550 This host does not offer mail service.", trying <>....init lost, R="550 This host does not offer mail service." 154825 Unqueueing to host PANDA.MIT.EDU 154826 ICP->PANDA.MIT.EDU (CHAOS-SMTP) 154832 QID=<[AI.AI.MIT.EDU].110493.861025.ALAN>...error for ="550 This host does not offer mail service.", trying <>....init lost, R="550 This host does not offer mail service." 154834 Unqueueing to host BUDDY.AI.MIT.EDU 154835 ICP->BUDDY.AI.MIT.EDU (CHAOS-SMTP) 154840 QID=<[AI.AI.MIT.EDU].99582.860927.CCH>...error for ="550 This host does not offer mail service.", trying <>....init lost, R="550 This host does not offer mail service." ---------- Notice anything odd about the second and third QIDs? When I tried to list them, I got the usual "no such message in queue" (I did run the LUNAR primatives manually to get the Message-ID string right, that's not the problem). are you sure you got them right? the host-name stuff is added automtically, so the current lunar library on AI, which GUMBY has frobbed to deal with the newer style of QID (i think this has not been installed elsewhere), is persumably adding the @-host-after when the msg IDs have the host-in-backets-before. what did the NSmsg msg look like?  Date: Wed, 3 Dec 86 21:24:12 EST From: "Pandora B. Berman" Subject: More about COMSAT delay waits To: ZVONA@AI.AI.MIT.EDU cc: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <126102.861203.CENT@AI.AI.MIT.EDU> Date: Tue, 2 Dec 86 14:01:12 EST From: David Chapman Subject: More about sushi (implicating COMSAT) To: BUG-MAIL@AI.AI.MIT.EDU cc: JAR@AI.AI.MIT.EDU OK. I tried sending to sushi from OZ .... Enclosed are: .... (3) a message returned by COMSAT this morning that I sent to sushi yesterday. Why did this one come back after one day when it usually waits for three? .... Third message: Date: Tue, 2 Dec 86 08:41:45 EST From: Communications Satellite To: ZVONA at AI.AI.MIT.EDU Re: Msg of Monday, 1 December 1986 18:17-EST FAILED: watson at SUSHI.STANFORD.EDU; Host appears to be permanently down or not accepting mail. Failed message follows: ------- Date: Mon, 1 Dec 86 18:17:52 EST From: David Chapman To: watson@SUSHI.STANFORD.EDU Message-ID: <124969.861201.ZVONA@AI.AI.MIT.EDU> Test message for COMSAT. Please forward back to me if you get this (which you won't). very simple. COMSAT flushes undelivered mail on a per-host rather than a per-msg basis. in this case, COMSAT couldn't reach SUSHI in N hundred tries (for whatever the current value of N is -- it works out to about three days these days). so after the N hundredth attempt, all mail waiting for SUSHI was flushed, the msg with which the non-transmittal had begun and all others, even though they were newer.  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 3 Dec 86 18:24:59 EST Date: Wed, 3 Dec 1986 18:26 EST Message-ID: From: Rob Austein To: "David A. Moon" Cc: Bug-COMSAT@AI.AI.MIT.EDU Subject: Shushi reprise? Can't connect to wiscvm.wisc.edu In-reply-to: Msg of 3 Dec 1986 12:58-EST from David A. Moon Date: Wednesday, 3 December 1986 12:58-EST From: David A. Moon Does Comsat have a shorter timeout than MMAILR? Maybe these hosts are just very slow. When I connected to Sushi by hand from MIT-MC yesterday to see if it really thinks MC's name is OZ.AI.MIT.EDU (it does not) I noticed it took almost a minute to give the initial greeting and again to respond to the HELO command. Give that man a prize. All units decimal seconds: MMAILR: ICP wait 30 FIN wait 60 Reply wait 300 COMSAT: ICP wait 15 FIN wait 60 HELO wait 120 QUIT wait 5 Send wait 60 Reply wait is a general purpose routine that listens for the response to some transaction (HELO, RCPT, whatever). Send wait is a blanket timeout around the send phase of the transaction (NTMSND/NTSTMO). The MMAILR statistics are from XX (not OZ, although I doubt it matters), and only apply to the TCP/SMTP code. Anybody want to defend the old timeouts or should we just jack them up to deal with 60 round trip times? Gee I wish the Arpanet were usable....  Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 30002424620) by AI.AI.MIT.EDU 3 Dec 86 17:21:24 EST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 14481; Wed 3-Dec-86 17:19:32 EST Date: Wed, 3 Dec 86 17:19 EST From: David A. Moon Subject: SEND vs. SMTP To: Rob Austein cc: BUG-COMSAT@AI.AI.MIT.EDU In-Reply-To: Message-ID: <861203171909.6.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Wed, 3 Dec 1986 17:00 EST From: Rob Austein MMAILR's SMTP code tries again with MAIL if SEND/SAML/SOML fails (or maybe only if it fails with a "not implemented" error, I forget). It should try again with SEND if it tried SOML and got rejected. MMAILR's non-SMTP chaos code has all this hair that GZ and I put in so that it can emulate SAML and SOML by appropriate use of CHAOS/MAIL and CHAOS/SEND. Works surprisingly well. Doing the corresponding thing in SMTP and in Comsat seems to be what I was suggesting. I don't think the spec was really designed for machines that accept sends but not mail. It's a bit late to point this out to Postl, though. Yep, SMTP came out just in time to miss the boat on the networked personal computer revolution. Is this what is still happening, or is it something else now? Er, well, it may not be happening at all. Or rather, I found a completely bizzare clump of messages when I tried to investigate. Here's the portion of the STATS file that got me interested (this is actually from today's file, not the one that I first saw): 154817 Unqueueing to host GAYE.AI.MIT.EDU 154818 ICP->GAYE.AI.MIT.EDU (CHAOS-SMTP) 154823 QID=<122313.861123@AI.AI.MIT.EDU>...error for <>="550 This host does not offer mail service.", trying <>....init lost, R="550 This host does not offer mail service." 154825 Unqueueing to host PANDA.MIT.EDU 154826 ICP->PANDA.MIT.EDU (CHAOS-SMTP) 154832 QID=<[AI.AI.MIT.EDU].110493.861025.ALAN>...error for ="550 This host does not offer mail service.", trying <>....init lost, R="550 This host does not offer mail service." 154834 Unqueueing to host BUDDY.AI.MIT.EDU 154835 ICP->BUDDY.AI.MIT.EDU (CHAOS-SMTP) 154840 QID=<[AI.AI.MIT.EDU].99582.860927.CCH>...error for ="550 This host does not offer mail service.", trying <>....init lost, R="550 This host does not offer mail service." That 550 reply is what you get when you send MAIL, either accidently when you were supposed to send SOML, or on purpose because you're really trying to mail. Notice anything odd about the second and third QIDs? When I tried to list them, I got the usual "no such message in queue" (I did run the LUNAR primatives manually to get the Message-ID string right, that's not the problem). I don't know what caused these phantom messages. I was able to get the first message, and it looks like Gumby doing something random: It looks like Comsat sending a failure message back to the sender, except it's sending to where Gumby was logged in instead of where Gumby's mailbox is. This was using MAIL legitimately; I don't think this is trying to be a SEND at all. On the other hand, why hasn't it timed out after ten days? I'm suspicious that the temporary-error handling and failure counting code still has a bug. Having seen that code, I'm not surprised it has any number of bugs! On the other hand, haven't you and I both combed through it recently. Sigh. Rewrite Comsat in machine-compiled Lisp instead of hand-compiled Lisp? ---------------------------------------------------------------- SRA@AI.AI.MIT.EDU (Sent by WHORFN'@AI.AI.MIT.EDU) 12/03/86 16:06:15 Re: Request results Date: Sun, 23 Nov 86 01:29:09 EST From: Communications Satellite Subject: Msg of Sunday, 23 November 1986 01:29-EST To: "gumby@csli"@GAYE.AI.MIT.EDU Message-ID: <122313.861123@AI.AI.MIT.EDU> ============ A copy of your message is being returned, because: ============ "GUMBY@#ÁI" at AI.AI.MIT.EDU is an unknown recipient. ============ Failed message follows: ============ Received: from GAYE (CHAOS 13131) by AI.AI.MIT.EDU 23 Nov 86 01:29:03 EST from: foo bar baz another test ---------------------------------------------------------------- So I don't really know what's going on, I may be getting worried about a non-bug.  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 3 Dec 86 16:59:01 EST Date: Wed, 3 Dec 1986 17:00 EST Message-ID: From: Rob Austein To: "David A. Moon" Cc: BUG-COMSAT@AI.AI.MIT.EDU Subject: SEND vs. SMTP In-reply-to: Msg of 3 Dec 1986 12:55-EST from David A. Moon Date: Wednesday, 3 December 1986 12:55-EST From: David A. Moon I'm not sure there is an advantage to using SMTP rather than SEND for sending. I think the issue was to use SMTP rather than MAIL for mailing, because MAIL doesn't have return-paths. Wasn't it? Yes and no. That's the primary reason, but there are others. SMTP allows multiple recipients for sends on a single connection, which is a win if you use polygrammes. I don't know if anyone cares. When I looked into this before, there were three problems, two in Comsat and one in the Lispm SMTP server. I don't know about MMAILR. (1) Comsat means to send the SOML command, but it sends MAIL instead due to poor control structure in the recovery from some kind of recoverable return-path problem. Lispms that don't run mailers don't accept MAIL, which is not a bug. (2) If Comsat did send the right command, it would have got the reply "502 SOML and SAML not implemented." I'm not sure if this is a bug in the Lispm SMTP server. (3) When SOML is rejected, Comsat should try SEND, but it doesn't. Well, (1) is clearly a bug. (2) is not; that stuff is optional (although it's silly not to support it if the machine supports sends in general). (3) I'm not so sure about; you are probably right but I can see cases where that would be a lose. MMAILR's SMTP code tries again with MAIL if SEND/SAML/SOML fails (or maybe only if it fails with a "not implemented" error, I forget). MMAILR's non-SMTP chaos code has all this hair that GZ and I put in so that it can emulate SAML and SOML by appropriate use of CHAOS/MAIL and CHAOS/SEND. Works surprisingly well. I don't think the spec was really designed for machines that accept sends but not mail. It's a bit late to point this out to Postl, though. Is this what is still happening, or is it something else now? Er, well, it may not be happening at all. Or rather, I found a completely bizzare clump of messages when I tried to investigate. Here's the portion of the STATS file that got me interested (this is actually from today's file, not the one that I first saw): 154817 Unqueueing to host GAYE.AI.MIT.EDU 154818 ICP->GAYE.AI.MIT.EDU (CHAOS-SMTP) 154823 QID=<122313.861123@AI.AI.MIT.EDU>...error for <>="550 This host does not offer mail service.", trying <>....init lost, R="550 This host does not offer mail service." 154825 Unqueueing to host PANDA.MIT.EDU 154826 ICP->PANDA.MIT.EDU (CHAOS-SMTP) 154832 QID=<[AI.AI.MIT.EDU].110493.861025.ALAN>...error for ="550 This host does not offer mail service.", trying <>....init lost, R="550 This host does not offer mail service." 154834 Unqueueing to host BUDDY.AI.MIT.EDU 154835 ICP->BUDDY.AI.MIT.EDU (CHAOS-SMTP) 154840 QID=<[AI.AI.MIT.EDU].99582.860927.CCH>...error for ="550 This host does not offer mail service.", trying <>....init lost, R="550 This host does not offer mail service." Notice anything odd about the second and third QIDs? When I tried to list them, I got the usual "no such message in queue" (I did run the LUNAR primatives manually to get the Message-ID string right, that's not the problem). I was able to get the first message, and it looks like Gumby doing something random: ---------------------------------------------------------------- SRA@AI.AI.MIT.EDU (Sent by WHORFN'@AI.AI.MIT.EDU) 12/03/86 16:06:15 Re: Request results Date: Sun, 23 Nov 86 01:29:09 EST From: Communications Satellite Subject: Msg of Sunday, 23 November 1986 01:29-EST To: "gumby@csli"@GAYE.AI.MIT.EDU Message-ID: <122313.861123@AI.AI.MIT.EDU> ============ A copy of your message is being returned, because: ============ "GUMBY@#ÁI" at AI.AI.MIT.EDU is an unknown recipient. ============ Failed message follows: ============ Received: from GAYE (CHAOS 13131) by AI.AI.MIT.EDU 23 Nov 86 01:29:03 EST from: foo bar baz another test ---------------------------------------------------------------- So I don't really know what's going on, I may be getting worried about a non-bug.  Received: from VALLECITO.SCRC.Symbolics.COM (TCP 30002424534) by AI.AI.MIT.EDU 3 Dec 86 12:59:12 EST Received: from EUPHRATES.SCRC.Symbolics.COM by VALLECITO.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 76027; Wed 3-Dec-86 12:55:50 EST Date: Wed, 3 Dec 86 12:55 EST From: David A. Moon Subject: SEND vs. SMTP To: Rob Austein cc: BUG-COMSAT@MIT-AI.ARPA In-Reply-To: <960421.861202.SRA@MX.LCS.MIT.EDU>, <960422.861202.SRA@MX.LCS.MIT.EDU> Message-ID: <861203125538.0.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Tue, 2 Dec 86 23:11:42 EST From: Rob Austein Before somebody else points it out, I think I have (partially) broken Chaosnet sends. It seems that there are a lot of Lisp machines that will accept Chaos/SEND connections but not Chaos/SMTP connections (on the grounds that SMTP is a mail protocol). The way I have things set up, Chaos/SMTP is tried before Chaos/SEND. It backs out correctly and uses Chaos/MAIL if the SMTP connection loses and if MAIL is appropriate, but I think it is getting screwed by all the hairy special case code dealing with SENDs. I could reorder things so that it prefers SEND to SMTP, but the last time we went around on this people seemed to believe that we should use SMTP whenever possible. I'm not sure there is an advantage to using SMTP rather than SEND for sending. I think the issue was to use SMTP rather than MAIL for mailing, because MAIL doesn't have return-paths. Wasn't it? So the question is, should I fix COMSAT or should I tell the users of all those lisp machines that they are bozos? If you tell them they are bozos they won't listen. Believe me, I know. Date: Tue, 2 Dec 86 23:17:38 EST From: Rob Austein Sorry, I didn't state that right. The problem is that the offending Lisp Machines are -accepting- the network connection then sending a 5xx SMTP error message saying "I'm sorry, but mommy told me not to talk to mailer daemons, so go away". Both COMSAT and MMAILR commit to using CHAOS/SMTP if the connection reaches an OPN state, on the theory that the foreign machine is claiming to have a working SMTP server if it is accepting the connection. This algorithm doesn't work for people who accept the connection just long enough to tell you that they don't want to talk to you (sort of like an answering machine...). So who's broken? When I looked into this before, there were three problems, two in Comsat and one in the Lispm SMTP server. I don't know about MMAILR. (1) Comsat means to send the SOML command, but it sends MAIL instead due to poor control structure in the recovery from some kind of recoverable return-path problem. Lispms that don't run mailers don't accept MAIL, which is not a bug. (2) If Comsat did send the right command, it would have got the reply "502 SOML and SAML not implemented." I'm not sure if this is a bug in the Lispm SMTP server. (3) When SOML is rejected, Comsat should try SEND, but it doesn't. Is this what is still happening, or is it something else now? By the way, thanks for all the fixing you've been doing lately.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 3 Dec 86 00:16:00 EST Received: from MX.LCS.MIT.EDU (CHAOS 1440) by MC.LCS.MIT.EDU 2 Dec 86 23:39:25 EST Date: Tue, 2 Dec 86 23:11:42 EST From: Rob Austein Subject: SEND vs. SMTP To: BUG-COMSAT@MX.LCS.MIT.EDU Message-ID: <960421.861202.SRA@MX.LCS.MIT.EDU> Before somebody else points it out, I think I have (partially) broken Chaosnet sends. It seems that there are a lot of Lisp machines that will accept Chaos/SEND connections but not Chaos/SMTP connections (on the grounds that SMTP is a mail protocol). The way I have things set up, Chaos/SMTP is tried before Chaos/SEND. It backs out correctly and uses Chaos/MAIL if the SMTP connection loses and if MAIL is appropriate, but I think it is getting screwed by all the hairy special case code dealing with SENDs. I could reorder things so that it prefers SEND to SMTP, but the last time we went around on this people seemed to believe that we should use SMTP whenever possible. So the question is, should I fix COMSAT or should I tell the users of all those lisp machines that they are bozos?  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 3 Dec 86 00:15:20 EST Received: from MX.LCS.MIT.EDU (CHAOS 1440) by MC.LCS.MIT.EDU 2 Dec 86 23:39:15 EST Date: Tue, 2 Dec 86 23:17:38 EST From: Rob Austein Subject: SEND vs. SMTP To: BUG-COMSAT@MX.LCS.MIT.EDU Message-ID: <960422.861202.SRA@MX.LCS.MIT.EDU> Sorry, I didn't state that right. The problem is that the offending Lisp Machines are -accepting- the network connection then sending a 5xx SMTP error message saying "I'm sorry, but mommy told me not to talk to mailer daemons, so go away". Both COMSAT and MMAILR commit to using CHAOS/SMTP if the connection reaches an OPN state, on the theory that the foreign machine is claiming to have a working SMTP server if it is accepting the connection. This algorithm doesn't work for people who accept the connection just long enough to tell you that they don't want to talk to you (sort of like an answering machine...). So who's broken?  Date: Tue, 2 Dec 86 20:59:14 EST From: David Vinayak Wallace Subject: Shushi reprise? Can't connect to wiscvm.wisc.edu To: BUG-TCP@AI.AI.MIT.EDU cc: ZVONA@AI.AI.MIT.EDU, JAR@AI.AI.MIT.EDU, BUG-MAIL@AI.AI.MIT.EDU Message-ID: <125575.861202.GUMBY@AI.AI.MIT.EDU> ITS cannot connect to wiscvm.wisc.edu (the bitnet gaeway) and has not been able to for a week. XX can get there just fine. Phu  Date: Tue, 2 Dec 86 19:07:42 EST From: Rob Austein Subject: CHAOS/SMTP, etcetera To: BUG-COMSAT@AI.AI.MIT.EDU, ALAN@AI.AI.MIT.EDU Message-ID: <125543.861202.SRA@AI.AI.MIT.EDU> Found the bug (bad entry in the protocol definition for NT$CSM). Once that was fixed it worked just fine. Other random things: - AI: SYSNET; COMSAT > jumped version numbers. The new version is 555, which is higher than any previously used on any machine. So (hopefully) we are now back to a monotonicly increasing sequence. - Alan's ^L patch is installed, so the MacLisp maintainers can stop being confused. - The Gumby Memorial Kludge has been installed: if COMSAT is booting on MX it sets TCPGAT and HDRGAT even though it -is- on the Arpanet. This now makes 6 out of 9 MIT PDP-10s speaking CHAOS/SMTP.  Date: Tue, 2 Dec 86 14:01:12 EST From: David Chapman Subject: More about sushi (implicating COMSAT) To: BUG-MAIL@AI.AI.MIT.EDU cc: JAR@AI.AI.MIT.EDU Message-ID: <125407.861202.ZVONA@AI.AI.MIT.EDU> OK. I tried sending to sushi from OZ, and it got through with no problem on the first try. What's odd about this is that the headers suggest that it was forwarded through MC (rather than XX), though the syntax seems pretty nonstandard. I looked in the relevant MC OSTATS file and saw no record of the transaction. So either (a) COMSAT wins on forwarding mail to sushi and not on directly sending it, or (b) the header lies, and the mail was forwarded through XX, or (c) it was sent through MC, and it is sheer coincidence that this message happened to get through, and unconnected to the fact that it originated at OZ. I don't find (c) very likely. The stanford gateway may be losing, but it looks to me like COMSAT is losing independently. Enclosed are: (1) a message from a friend at sushi forwarding back the message I sent from OZ yesterday. (2) a message returned this morning by comsat which I've forwarded back to sushi n times after it was returned. This shows that COMSAT has continuously failed to contact sushi for two weeks (because the message has been in its queue almost constantly for that period). (3) a message returned by COMSAT this morning that I sent to sushi yesterday. Why did this one come back after one day when it usually waits for three? (4) just to add insult to injury, a message returned by COMSAT that I'd sent to watson%sushi@xx, on the theory that that would bypass this lossage, and which COMSAT "optimized" into watson@sushi and consequently bounced. Aargh. First message: Received: from OZ.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 1 DEC 86 20:57:51 EST Received: from XX.LCS.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 1 Dec 86 21:00-EST Received: from Sushi.Stanford.EDU by XX.LCS.MIT.EDU with TCP; Mon 1 Dec 86 20:59:04-EST Date: Mon 1 Dec 86 17:55:01-PST From: Kennita L. Watson Subject: [David Chapman : mail] To: zvona%oz.ai.mit.edu@XX.LCS.MIT.EDU Message-ID: <12259447242.29.WATSON@Sushi.Stanford.EDU> Hello: I think this will work. Kennita --------------- Return-Path: Received: from OZ.AI.MIT.EDU (MC.LCS.MIT.EDU.#Internet) by Sushi.Stanford.EDU with TCP; Mon 1 Dec 86 12:03:29-PST Date: Mon 1 Dec 86 15:07-EST From: David Chapman Subject: mail To: watson@SUSHI.STANFORD.EDU This is a test message. If you get it, please forward it back to me at zvona@ai.ai.mit.edu. I haven't been able to get mail through to you for a month or so. It keeps coming back claiming "host down". Sushi patently hasn't been, so now I think the problem may be AI's mailer. If it turns out that I can get mail through to you from here, I'll forward to you all the mail that has bounced. I'm going to send another one of these from SRI. Please send whichever or both which get through back to me so I can examine the headers and try and see what's going on. Thanks. And hi... Second message: Date: Tue, 2 Dec 86 08:41:18 EST From: Communications Satellite To: ZVONA at AI.AI.MIT.EDU Re: Msg of Saturday, 29 November 1986 13:21-EST FAILED: watson at SUSHI.STANFORD.EDU; Host appears to be permanently down or not accepting mail. Failed message follows: ------- Date: Sat, 29 Nov 86 13:21:45 EST From: David Chapman Subject: [COMSAT: Msg of Monday, 24 November 1986 15:45-EST] To: watson@SUSHI.STANFORD.EDU Message-ID: <124373.861129.ZVONA@AI.AI.MIT.EDU> I wonder how many iterations of this we can go through? Has sushi actually been down, or is this a mailer problem? Or maybe your directory is full and the mailer is refusing to deliver your mail for that reason? Date: Sat, 29 Nov 86 08:19:30 EST From: Communications Satellite To: ZVONA at AI.AI.MIT.EDU Re: Msg of Monday, 24 November 1986 15:45-EST FAILED: watson at SUSHI.STANFORD.EDU; Host appears to be permanently down or not accepting mail. Failed message follows: ------- Date: Mon, 24 Nov 86 15:45:42 EST From: David Chapman Subject: [COMSAT: Msg of Thursday, 20 November 1986 17:05-EST] To: watson@SUSHI.STANFORD.EDU Message-ID: <122823.861124.ZVONA@AI.AI.MIT.EDU> Losing again... Date: Sun, 23 Nov 86 11:08:15 EST From: Communications Satellite To: ZVONA at AI.AI.MIT.EDU Re: Msg of Thursday, 20 November 1986 17:05-EST FAILED: WATSON at SUSHI.STANFORD.EDU; Host appears to be permanently down or not accepting mail. Failed message follows: ------- Date: Thu, 20 Nov 86 17:05:01 EST From: David Chapman Subject: randomness To: WATSON@SUSHI.STANFORD.EDU cc: ZVONA@AI.AI.MIT.EDU In-reply-to: Msg of Tue 18 Nov 86 20:15:54-PST from Kennita L. Watson Message-ID: <[AI.AI.MIT.EDU].121107.861120.ZVONA> <> Third message: Date: Tue, 2 Dec 86 08:41:45 EST From: Communications Satellite To: ZVONA at AI.AI.MIT.EDU Re: Msg of Monday, 1 December 1986 18:17-EST FAILED: watson at SUSHI.STANFORD.EDU; Host appears to be permanently down or not accepting mail. Failed message follows: ------- Date: Mon, 1 Dec 86 18:17:52 EST From: David Chapman To: watson@SUSHI.STANFORD.EDU Message-ID: <124969.861201.ZVONA@AI.AI.MIT.EDU> Test message for COMSAT. Please forward back to me if you get this (which you won't). Fourth message: Date: Tue, 2 Dec 86 08:41:49 EST From: Communications Satellite To: ZVONA at AI.AI.MIT.EDU Re: Msg of Monday, 1 December 1986 22:01-EST FAILED: watson at SUSHI.STANFORD.EDU; Host appears to be permanently down or not accepting mail. Failed message follows: ------- Date: Mon, 1 Dec 86 22:01:10 EST From: David Chapman Subject: last test message (I hope) To: watson@SUSHI.STANFORD.EDU Message-ID: <125077.861201.ZVONA@AI.AI.MIT.EDU> This one checks to see if I can send mail to you from my home machine (AI) by explicitly routing it through a non-COMSAT site.  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 2 Dec 86 07:18:21 EST Date: Tue, 2 Dec 1986 07:12 EST Message-ID: From: Rob Austein To: Bug-COMSAT@AI.AI.MIT.EDU cc: Alan@AI.AI.MIT.EDU Subject: CHAOS/SMTP and ^L and other fun cruft The COMSAT source files that lived in AI: SRA; have moved to appropriate system directories (mostly SYSNET;). FTPS no longer .VALUEs on MD and ML. This has been installed on all five machines. The fix for ^Ls in files has been installed (for completeness I also dealth with ^Ks, not that I expect anybody to be using them). The CHAOS/SMTP sending code in COMSAT sort of works, but only sort of. It seems to throw away some of the headers and all of the text. Eg: :MAIL SRA FOOBAR (from MD) puts the following in my XX mailbox: Return-Path: Received: from MD.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet with SMTP; 2 Dec 86 06:16-EST Sending to a unix machine is somewhat more informative (I think it's getting most of the data from the SMTP envelope though, and sendmail seems not to be updating the Return-Path properly): :MAIL sra@AJAX FOOBAR (again, from MD) yields: Return-Path: <@MC.LCS.MIT.EDU:SRA@MD.LCS.MIT.EDU> Received: from AJAX.LCS.MIT.EDU by XX.LCS.MIT.EDU with TCP; Tue 2 Dec 86 06:32:54-EST Received: from MC.LCS.MIT.EDU (2c00030a) by AJAX.LCS.MIT.EDU (4.12/4.7); Tue, 2 Dec 86 06:32:38 est Date: Tue, 2 Dec 86 06:32:37 est From: @MC.LCS.MIT.EDU:SRA@MD.LCS.MIT.EDU Message-Id: <8612021132.AA18879@AJAX.LCS.MIT.EDU> Received: from MD.LCS.MIT.EDU (CHAOS 3132) by MC.LCS.MIT.EDU 2 Dec 86 06:31:10 EST Apparently-To: So this code hasn't been installed yet (and neither has Alan's ^L fix, because I'd already started working on this when I got his bug report). More later. If this stuff rings any bells, holler. At the moment the sources will not compile a usable COMSAT, but this could be fixed trivially if anybody gave me a reason.  Date: Tue, 2 Dec 86 03:15:56 EST From: Alan Bawden Subject: ^L@AI To: BUG-COMSAT@AI.AI.MIT.EDU Message-ID: <125217.861202.ALAN@AI.AI.MIT.EDU> The parser that COMSAT uses to parse @FILEs should be taught that ^L is just another whitespace character. Currently it parses as the name of a recipient, causing mail to be delivered to ^L@AI. When ^L is converted to SIXBIT this becomes just L, so the mail is delivered to AI:L;L MAIL, confusing the MacLisp maintainers...  Date: Tue, 2 Dec 86 02:38:08 EST From: Rob Austein Subject: Oh foo To: BUG-COMSAT@AI.AI.MIT.EDU Message-ID: <125193.861202.SRA@AI.AI.MIT.EDU> So I went and modified NETRTS to turn on CHAOS/SMTP and set up the priorities and backout code. Assuming that Moon's never-used code works, it should be totally trivial. Can't assemble and test it because SECOND: is offline. See subject line.  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 2 Dec 86 01:26:10 EST Received: from WHORFIN.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 2 Dec 86 01:27-EST Date: Tue, 2 Dec 86 01:25 EST From: Rob Austein Subject: comsat archeology To: bug-mail@AI.AI.MIT.EDU Message-ID: <861202012546.1.SRA@WHORFIN.LCS.MIT.EDU> It seems that setting DEBUG to -2 turns on verbose logging in NETICP:. May do other things as well. Just happened to notice while looking at the code....  Received: from MD.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 2 DEC 86 01:09:45 EST Date: Tue, 2 Dec 86 01:09:33 EST From: Rob Austein Subject: FTPS isn't -quite- a CHAOS/SMTP server To: BUG-MAIL%MD.LCS.MIT.EDU@MC.LCS.MIT.EDU Message-ID: <2174.861202.SRA@MD.LCS.MIT.EDU> It .VALUEs on MD and ML because it can't find its arpanet address, even though it doesn't use it for anything in particular.  Date: Mon, 1 Dec 86 18:25:26 EST From: David Chapman Subject: cold fish To: SRA@XX.LCS.MIT.EDU cc: BUG-MAIL@AI.AI.MIT.EDU, JAR@AI.AI.MIT.EDU In-reply-to: Msg of Mon 1 Dec 1986 17:15 EST from Rob Austein Message-ID: <124988.861201.ZVONA@AI.AI.MIT.EDU> Date: Mon, 1 Dec 1986 17:15 EST From: Rob Austein To: David Chapman cc: BUG-MAIL at AI.AI.MIT.EDU, JAR at AI.AI.MIT.EDU Re: cold fish We have already been around on this once. One of the two subnets that SUSHI is on is flakey. The host tables are set up so that nobody ever gets that address. I manually invoked the DQ: device (like COMSAT would) and got the address that I should have (the one that supposedly works). If for some unknown reason we wanted to reorder the addresses we would have to get the NIC to do it. If my arm were twisted very hard I could be persuaded to remove SUSHI's other address from the tables entirely (I'm already doing this with SIERRA's 10.0.0.0 address because their AN20 unit is down .9 of the time, but the code to do this is really tasteless). Well, I keep forwarding back to sushi the mail that I send that bounces. So COMSAT has continuously failed to get through to sushi for a coulpe of weeks, at least. In other words, the net that COMSAT is trying to get through has been down 1.0 of the time. If you look at the STATS line where COMSAT first saw your message it will tell you what address it is using (HOSTS3 octal format). Here we go (with a new message, but it's failed consistently, so this is presumably the same): 181940 InReq: 1 > 1; SPECS:{J:MAIL}{ZVONA}{TL=32.} ID=<124971.861201.ZVONA@AI.AI.MIT.EDU> EXP->watson@4402000065 181942 ICP->SUSHI.STANFORD.EDU (TCP-SMTP=Timeout) 181958 Queued: <124971.861201.ZVONA@AI.AI.MIT.EDU> for SUSHI.STANFORD.EDU I don't know how to decode 4402000065 into an IP address, and don't know which is the right one, anyway.  Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 1 DEC 86 18:10:20 EST Date: Mon, 1 Dec 1986 18:11 EST Message-ID: From: Rob Austein To: billw@SU-SCORE.ARPA, bug-ftp@SU-SIERRA.ARPA, bug-comsat@AI.AI.MIT.EDU, jar@AI.AI.MIT.EDU Subject: Problems getting to SUSHI I am begining to suspect that the problems we have been seeing with connecting to Sushi for mail from MIT and FTP from Sierra are caused by a routing problem in the stanford gateways (traffic being sent via the 3MB subnet instead of the 10MB subnet), possiblely some gateway sending ICMP redirects or something. The investigations on the MIT end have shown pretty conclusively that COMSAT is asking for the correct address (36.8.0.53), and the symptoms make it look like an intermittant problem. Anybody in a position to investigate this? --Rob  Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 1 DEC 86 18:06:20 EST Date: Mon, 1 Dec 1986 17:57 EST Message-ID: From: Rob Austein To: jar@AI.AI.MIT.EDU, bug-comsat@AI.AI.MIT.EDU Subject: Somehow I don't think this is a local problem Date: Monday, 1 December 1986 17:46-EST From: Alex Bronstein To: bug-ftp@Sierra.Stanford.EDU Re: bug? problem? photo log follows... [PHOTO: Recording initiated Mon 1-Dec-86 2:45PM] @ftp FTP>o sushi ?Unexpected error in connection - End of file reached FTP>o sushi ?Unexpected error in connection - End of file reached FTP>quit @reset ftp @ftp FTP>o sushi ?Unexpected error in connection - End of file reached FTP>quit @pop [PHOTO: Recording terminated Mon 1-Dec-86 2:46PM] Alex  Date: Mon, 1 Dec 86 17:30:41 EST From: Jonathan A Rees Subject: cold fish To: SRA@XX.LCS.MIT.EDU cc: BUG-MAIL@AI.AI.MIT.EDU, ZVONA@AI.AI.MIT.EDU In-reply-to: Msg of Mon 1 Dec 1986 17:15 EST from Rob Austein Message-ID: <124951.861201.JAR@AI.AI.MIT.EDU> Date: Mon, 1 Dec 1986 17:15 EST From: Rob Austein When you say that SUSHI is obviously up, how are you checking this? FINGER? From where? What address is it using? Have you tried doing :TN 25.,SUSHI to see if the SMTP server is in fact answering the phone? Etc. FINGER works from AI. :TN 25.,SUSHI also works from AI, it connects to sushi's smtp server. (I didn't try to ask it to do anything.) SUSHI's supposedly good address does indeed appear first in the list generated by :HOST, which means, I assume, that it occurs first in the host table. What do you mean by "Etc."? Jonathan  Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 1 DEC 86 17:13:26 EST Date: Mon, 1 Dec 1986 17:15 EST Message-ID: From: Rob Austein To: David Chapman Cc: BUG-MAIL@AI.AI.MIT.EDU, JAR@AI.AI.MIT.EDU Subject: cold fish We have already been around on this once. One of the two subnets that SUSHI is on is flakey. The host tables are set up so that nobody ever gets that address. I manually invoked the DQ: device (like COMSAT would) and got the address that I should have (the one that supposedly works). If for some unknown reason we wanted to reorder the addresses we would have to get the NIC to do it. If my arm were twisted very hard I could be persuaded to remove SUSHI's other address from the tables entirely (I'm already doing this with SIERRA's 10.0.0.0 address because their AN20 unit is down .9 of the time, but the code to do this is really tasteless). If you look at the STATS line where COMSAT first saw your message it will tell you what address it is using (HOSTS3 octal format). When you say that SUSHI is obviously up, how are you checking this? FINGER? From where? What address is it using? Have you tried doing :TN 25.,SUSHI to see if the SMTP server is in fact answering the phone? Etc. The only documentation on STATS files that I know about is the code.  Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 30002424620) by AI.AI.MIT.EDU 1 Dec 86 17:04:35 EST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 12413; Mon 1-Dec-86 16:58:19 EST Date: Mon, 1 Dec 86 16:58 EST From: David A. Moon To: David Chapman cc: BUG-MAIL@AI.AI.MIT.EDU, JAR@AI.AI.MIT.EDU In-Reply-To: <124927.861201.ZVONA@AI.AI.MIT.EDU> Message-ID: <861201165801.5.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Mon, 1 Dec 86 16:50:59 EST From: David Chapman Well, every entry in the STATS file that talks about sushi (and there are a LOT of them) is of the form 215356 Unqueueing to host SUSHI.STANFORD.EDU 215357 ICP->SUSHI.STANFORD.EDU (TCP-SMTP=Timeout) Presumably this means that it tried to deliver mail and then timed out and then unqueued (the order in the file is a trifle confusing.) I suspect you have a different idea of the meaning of the word "unqueue" than Comsat has. All it means is that it has some queued mail which it is now trying to deliver. It doesn't mean the mail doesn't stay in the queue if the delivery fails. The funny thing is that I couldn't find any failed delivery attempts that didn't dequeue. Maybe the bug is that it dequeues on the first failure? But that can't be right; it generally has taken three days before I get a failure notification back. Sushi does in fact have two internet addresses, and gumby also suggested that this might be the problem. Is there a way we can permute them, or does the NIC have to do that? Ask SRA (who is on this list and may have already responded). Is there a document somewhere that explains how to parse stats files? I don't see one on MIT-AI: KSC; ?***** *. I guess it's word-of-mouth or search the source for the text "Unqueueing to host" and see what the code in that vicinity does. The comments in the source of Comsat are excellent in most cases.  Date: Mon, 1 Dec 86 16:50:59 EST From: David Chapman To: Moon@SCRC-STONY-BROOK.ARPA cc: BUG-MAIL@AI.AI.MIT.EDU, JAR@AI.AI.MIT.EDU In-reply-to: Msg of Mon 1 Dec 86 16:10 EST from David A. Moon Message-ID: <124927.861201.ZVONA@AI.AI.MIT.EDU> Well, every entry in the STATS file that talks about sushi (and there are a LOT of them) is of the form 215356 Unqueueing to host SUSHI.STANFORD.EDU 215357 ICP->SUSHI.STANFORD.EDU (TCP-SMTP=Timeout) Presumably this means that it tried to deliver mail and then timed out and then unqueued (the order in the file is a trifle confusing.) The funny thing is that I couldn't find any failed delivery attempts that didn't dequeue. Maybe the bug is that it dequeues on the first failure? But that can't be right; it generally has taken three days before I get a failure notification back. Sushi does in fact have two internet addresses, and gumby also suggested that this might be the problem. Is there a way we can permute them, or does the NIC have to do that? Is there a document somewhere that explains how to parse stats files?  Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 30002424620) by AI.AI.MIT.EDU 1 Dec 86 16:12:50 EST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 12319; Mon 1-Dec-86 16:10:42 EST Date: Mon, 1 Dec 86 16:10 EST From: David A. Moon To: David Chapman cc: BUG-MAIL@AI.AI.MIT.EDU, JAR@AI.AI.MIT.EDU In-Reply-To: <124875.861201.ZVONA@AI.AI.MIT.EDU> Message-ID: <861201161024.9.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Mon, 1 Dec 86 14:58:01 EST From: David Chapman I keep sending mail to sushi, and it keeps coming back claiming that the host has been down/not accepting mail for three days. It has in fact been up consistently. It's up now, but the STATS file shows that COMSAT has just unqueued mail to it. Jonathan has had the same problem. It's possible that sushi is not accepting mail from us for some reason, but it is not rejecting net mail in general. So I suspect the problem is at our end. Ideas? The obvious first step is to look in Comsat STATS files for attempts to deliver mail to Sushi that didn't succeed and see what the error was. You could also check for the possibility that it has multiple network addresses registered, but not all of them work. I believe Comsat tries the same address every time rather than switching around among the registered addresses. Look for both Chaosnet and Internet addresses.  Date: Mon, 1 Dec 86 14:58:01 EST From: David Chapman To: BUG-MAIL@AI.AI.MIT.EDU cc: JAR@AI.AI.MIT.EDU Message-ID: <124875.861201.ZVONA@AI.AI.MIT.EDU> I keep sending mail to sushi, and it keeps coming back claiming that the host has been down/not accepting mail for three days. It has in fact been up consistently. It's up now, but the STATS file shows that COMSAT has just unqueued mail to it. Jonathan has had the same problem. It's possible that sushi is not accepting mail from us for some reason, but it is not rejecting net mail in general. So I suspect the problem is at our end. Ideas?  Received: from LIVE-OAK.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 26 NOV 86 00:25:21 EST Received: from PALLADIAN-JASPER.DialNet.Symbolics.COM by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 19231; 26 Nov 86 00:15:46-EST Received: from SHREDDED-WHEAT.Palladian.COM by JASPER.Palladian.COM via CHAOS with SMTP id 20000; 25 Nov 86 17:30:40-EST Date: Tue, 25 Nov 86 17:30 EST From: Christopher C. Stacy Subject: argh! To: David Vinayak Wallace cc: BUG-MAIL@AI.AI.MIT.EDU In-Reply-To: <123374.861125.GUMBY@AI.AI.MIT.EDU> Message-ID: <861125173005.9.CSTACY@SHREDDED-WHEAT.Palladian.COM> Maybe the right thing is for someone to teach BABYL that for this case it needs to use a FAKE-FROM spec instead of an AUTHOR. I don't think that FAKE-FROM changes the return-path's notion of where the message is from though, so it would probably have to output both AUTHOR and FAKE-FROM for it to work. Someone who uses ITS should do an experiment to see if that's right; I don't log in very often and I'm working from memory.  Date: Tue, 25 Nov 86 16:29:36 EST From: David Vinayak Wallace Subject: argh! To: CSTACY@AI.AI.MIT.EDU cc: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <123374.861125.GUMBY@AI.AI.MIT.EDU> Date: Tue, 25 Nov 86 12:20 EST From: Christopher C. Stacy Date: Sun, 23 Nov 86 02:49 EST From: David Vinayak Wallace I sent out the message below and told BABYL "From: Dead-Heads-Request@ai.ai.mit.edu" Why did COMSAT append "@ai.ai.mit.edu" to the address? I might have specified "From: Dead-Heads-Request@mc.lcs.mit.edu"! If it MUST mung the address it should source-route it! In order to diagnose this I would have to see the input request file that BABYL generated for COMSAT to munch. It's not immediately clear whether there is a problem in COMSAT or in BABYL. The queue file BABYL writes is reproduced below. However I just discovered the following unfortunatel paragraph in KSC;?RQFMT: 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} ----- Tear here ----- FROM-PROGRAM:BABYL FROM-XUNAME:GUMBY FROM-UNAME:GUMBY HEADER-FORCE:RFC733 RCPT:(cstacy @AI) SUBJECT: Test message AUTHOR: Gumby@AI.AI.MIT.EDU TEXT;-1 The entire header of this message (as I typed it) is: To: cstacy Re: Test message From: Gumby@AI.AI.MIT.EDU  Received: from LIVE-OAK.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 25 NOV 86 13:10:03 EST Received: from PALLADIAN-JASPER.DialNet.Symbolics.COM by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 18718; 25 Nov 86 13:09:14-EST Received: from SHREDDED-WHEAT.Palladian.COM by JASPER.Palladian.COM via CHAOS with SMTP id 19959; 25 Nov 86 12:21:26-EST Date: Tue, 25 Nov 86 12:20 EST From: Christopher C. Stacy Subject: argh! To: David Vinayak Wallace cc: bug-mail@AI.AI.MIT.EDU In-Reply-To: <861123024920.1.GUMBY@DUANE.AI.MIT.EDU> Message-ID: <861125122051.2.CSTACY@SHREDDED-WHEAT.Palladian.COM> Date: Sun, 23 Nov 86 02:49 EST From: David Vinayak Wallace I sent out the message below and told BABYL "From: Dead-Heads-Request@ai.ai.mit.edu" Why did COMSAT append "@ai.ai.mit.edu" to the address? I might have specified "From: Dead-Heads-Request@mc.lcs.mit.edu"! If it MUST mung the address it should source-route it! In order to diagnose this I would have to see the input request file that BABYL generated for COMSAT to munch. It's not immediately clear whether there is a problem in COMSAT or in BABYL.  Received: from LIVE-OAK.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 25 NOV 86 12:44:11 EST Received: from PALLADIAN-JASPER.DialNet.Symbolics.COM by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 18713; 25 Nov 86 12:44:38-EST Received: from SHREDDED-WHEAT.Palladian.COM by JASPER.Palladian.COM via CHAOS with SMTP id 19958; 25 Nov 86 12:15:56-EST Date: Tue, 25 Nov 86 12:15 EST From: Christopher C. Stacy Subject: Was I bitten by the COMSAT-interprets-% bug? To: David Vinayak Wallace cc: bug-mail@AI.AI.MIT.EDU In-Reply-To: <861123014200.5.GUMBY@GAYE.AI.MIT.EDU> Message-ID: <861125121513.1.CSTACY@SHREDDED-WHEAT.Palladian.COM> Those failure reports look normal to me; COMSAT appears to have parsed the host names that you intended. "RELAY.CS.NET" is just a nickname for CSNET-RELAY, and that's where it claims it was trying to connect to, and it says it was down.  Date: Tue, 25 Nov 86 02:57:28 EST From: David Vinayak Wallace Subject: new lunar To: CENT@AI.AI.MIT.EDU cc: BUG-MAIL@AI.AI.MIT.EDU In-reply-to: Msg of Tue 25 Nov 86 01:22:43 EST from Pandora B. Berman Message-ID: <123151.861125.GUMBY@AI.AI.MIT.EDU> This means you're been using it with no problems on AI? If so, :instal away!  Date: Tue, 25 Nov 86 01:53:12 EST From: "Pandora B. Berman" Subject: Were you bitten by the COMSAT-interprets-% bug? To: GUMBY@AI.AI.MIT.EDU cc: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <123114.861125.CENT@AI.AI.MIT.EDU> Date: Sun, 23 Nov 86 01:42 EST From: David Vinayak Wallace Subject: Was I bitten by the COMSAT-interprets-% bug? To: bug-mail@AI.AI.MIT.EDU The names below are exactly all of our CSNET people and CSNET-RELAY is up as far as I can tell ----- Forwarded message follows ----- Date: Fri, 21 Nov 86 20:58:19 EST From: Communications Satellite Subject: Msg of Tuesday, 18 November 1986 18:04-EST To: GUMBY@AI.AI.MIT.EDU FAILED: ADAR23%VAXTS%rca.com at RELAY.CS.NET; Host appears to be permanently down or not accepting mail. FAILED: ERIC%FOLSM2%sc.intel.com at RELAY.CS.NET; Host appears to be permanently down or not accepting mail. FAILED: JOHNSON%cs.umass.edu at RELAY.CS.NET; Host appears to be permanently down or not accepting mail. FAILED: RGG%FOLSM2%sc.intel.com at RELAY.CS.NET; Host appears to be permanently down or not accepting mail. FAILED: ACTS3%VAXTS%rca.com at RELAY.CS.NET; Host appears to be permanently down or not accepting mail. FAILED: JSPETH%rca.com at RELAY.CS.NET; Host appears to be permanently down or not accepting mail. Failed message follows: ------- [original msg omitted] i believe the answer is no. CSNET-RELAY may have been up when you looked, but i think it was not responding for several days straight last week. i sent some mail to various csnet addresses fri. morning which comsat bounced fri. evening with this host-perm-down error -- which means that comsat had reached the end of its 3- (or 5-, or whatever it is now) day tether, and was bouncing -everything- for CSNET-RELAY. i immediately re-sent the msgs, and they went through within a day.  Date: Tue, 25 Nov 86 01:22:43 EST From: "Pandora B. Berman" Subject: new lunar To: GUMBY@AI.AI.MIT.EDU cc: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <123103.861125.CENT@AI.AI.MIT.EDU> Date: Fri, 21 Nov 86 06:16:18 EST From: David Vinayak Wallace Subject: lunar To: CENT@AI.AI.MIT.EDU There's a new LUNAR on AI:MOON; which I won't :INSTAL unless it doesn't croak. So for I have been unable to induce @ to behaive differently is this installed yet? i expect to need it soon in places other than AI.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 24 NOV 86 22:32:32 EST Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 24 NOV 86 22:26:17 EST Date: Mon, 24 Nov 86 22:26:35 EST From: "Carl C. Hewitt" To: BUG-MAIL@MX.LCS.MIT.EDU Message-ID: <959541.861124.CCH@MX.LCS.MIT.EDU> Hello, Do you know if there is a way to send mail to a host that is not in the host table? I would like to send mail, for example, to ucscc.arpa, but it is relatively new on the net, and all I have is its ethernet address. I can finger and do whoises to it, but can't get mail to it. Can you help? Thanks much. -- Carl  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 24 NOV 86 13:11:08 EST Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 24 NOV 86 13:10:40 EST Date: Mon, 24 Nov 1986 13:17 EST Message-ID: From: Rob Austein To: William "Chops" Westfield Cc: Bug-COMSAT@MC.LCS.MIT.EDU, JAR@AI.AI.MIT.EDU Subject: raw fish In-reply-to: Msg of 24 Nov 1986 12:50-EST from William "Chops" Westfield Date: Monday, 24 November 1986 12:50-EST From: William "Chops" Westfield Is it still not working? Sushi's 3Mb address was only recently (eg wednesday of last week or so) removed from our domain table. Dunno. I just answer the bug mail. ITS doesn't have a real domain resolver yet because I spend too much of my time answering bug mail (no, I'm not complaining, somebody has to do it...).  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 24 NOV 86 13:01:41 EST Received: from Score.Stanford.EDU (TCP 1200600013) by MC.LCS.MIT.EDU 24 Nov 86 12:52:34 EST Date: 24 Nov 1986 09:50-PST Sender: BILLW@SU-SCORE.ARPA Subject: Re: [ANDY: [William "Chops" Westfield : R... From: William "Chops" Westfield To: sra@XX.LCS.MIT.EDU Cc: JAR@AI.AI.MIT.EDU, Bug-COMSAT@MC.LCS.MIT.EDU Message-ID: <[SU-SCORE.ARPA]24-Nov-86 09:50:03.BILLW> In-Reply-To: <861124123643.5.SRA@WHORFIN.LCS.MIT.EDU> Is it still not working? Sushi's 3Mb address was only recently (eg wednesday of last week or so) removed from our domain table. BillW  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 24 NOV 86 12:40:13 EST Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 24 NOV 86 12:39:31 EST Received: from WHORFIN.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 24 Nov 86 12:46-EST Date: Mon, 24 Nov 86 12:36 EST From: Rob Austein Subject: [ANDY: [William "Chops" Westfield : Re: mail from comsat]] To: Jonathan A Rees cc: Bug-COMSAT@MC.LCS.MIT.EDU, BillW@SU-SCORE.ARPA, Andy@SU-SUSHI.ARPA In-Reply-To: <122700.861124.JAR@AI.AI.MIT.EDU> Message-ID: <861124123643.5.SRA@WHORFIN.LCS.MIT.EDU> Date: Mon, 24 Nov 86 11:02:17 EST From: Jonathan A Rees COMSAT can't send mail to SU-SUSHI because it's trying to use an address which doesn't work. Can this be fixed (maybe by telling NIC)? Thanks. Date: Tue 18 Nov 86 11:35:10-PST From: Andy Freeman The 3mb address is 36.36.; the 10mb address is 36.8.. Maybe the comsat people can use this info. Date: 18 Nov 1986 10:20-PST From: William "Chops" Westfield Sigh. Sushi's 3 Mb ethernet adress has been turned off for some time now due to the MJH 3Mb problems. now, why MIT should be using Sushi's 3 Mb address is another question - The 10Mb address is listed first in the host and domain tables. At any rate, we are about to have the 3 Mb addreses removed from the stanford domain table, and this might help... Well, I just checked to see what COMSAT's lookup code is getting (I mean really checked, like with single stepping in DDT). It's getting the 36.8.x.y address, just like it should. So that's not your problem. --Rob  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 24 NOV 86 11:02:28 EST Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 24 NOV 86 11:02:03 EST Date: Mon, 24 Nov 86 11:02:17 EST From: Jonathan A Rees Subject: [ANDY: [William "Chops" Westfield : Re: mail from comsat]] To: BUG-comsat@MC.LCS.MIT.EDU Message-ID: <122700.861124.JAR@AI.AI.MIT.EDU> COMSAT can't send mail to SU-SUSHI because it's trying to use an address which doesn't work. Can this be fixed (maybe by telling NIC)? Thanks. - Jonathan Date: Tue 18 Nov 86 11:35:10-PST From: Andy Freeman To: jar at AI.AI.MIT.EDU Re: [William "Chops" Westfield : Re: mail from comsat] Message-ID: <12255970221.12.ANDY@Sushi.Stanford.EDU> The 3mb address is 36.36.; the 10mb address is 36.8.. Maybe the comsat people can use this info. -andy --------------- Return-Path: Received: from Score.Stanford.EDU by Sushi.Stanford.EDU with TCP; Tue 18 Nov 86 10:23:42-PST Date: 18 Nov 1986 10:20-PST Sender: BILLW@SU-SCORE.ARPA Subject: Re: mail from comsat From: William "Chops" Westfield To: ANDY@Sushi.Stanford.EDU Message-ID: <[SU-SCORE.ARPA]18-Nov-86 10:20:33.BILLW> In-Reply-To: <12255836743.7.ANDY@Sushi.Stanford.EDU> Sigh. Sushi's 3 Mb ethernet adress has been turned off for some time now due to the MJH 3Mb problems. now, why MIT should be using Sushi's 3 Mb address is another question - The 10Mb address is listed first in the host and domain tables. At any rate, we are about to have the 3 Mb addreses removed from the stanford domain table, and this might help... BillW  Received: from REAGAN.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 23 NOV 86 02:49:38 EST Received: from DUANE.AI.MIT.EDU (DUANE.AI.MIT.EDU) by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 12472; 23 Nov 86 02:49:28 EST Date: Sun, 23 Nov 86 02:49 EST From: David Vinayak Wallace Subject: argh! To: bug-mail@AI.AI.MIT.EDU Message-ID: <861123024920.1.GUMBY@DUANE.AI.MIT.EDU> I sent out the message below and told BABYL "From: Dead-Heads-Request@ai.ai.mit.edu" Why did COMSAT append "@ai.ai.mit.edu" to the address? I might have specified "From: Dead-Heads-Request@mc.lcs.mit.edu"! If it MUST mung the address it should source-route it! ----- Forwarded message follows ----- Received: from Godot.Think.COM (TCP 30001264307) by AI.AI.MIT.EDU 23 Nov 86 02:00:57 EST Received: by Godot.Think.COM; Sun, 23 Nov 86 02:58:16 EST Date: Sun, 23 Nov 86 02:58:16 EST From: MAILER-DAEMON@think.com (Mail Delivery Subsystem) Subject: Returned mail: Remote protocol error Message-Id: <8611230758.AA07559@Godot.Think.COM> To: ----- Transcript of session follows ----- >>> MAIL From: <<< 501- Bad reverse path: In "From:", <<< 501- <<< 501 The token ATSIGN was not expected.. 554 dpc@a... Remote protocol error: Bad file number ----- Unsent message follows ----- Received: by Godot.Think.COM; Sun, 23 Nov 86 02:58:16 EST Received: by Zarathustra.Think.COM; Sun, 23 Nov 86 02:58:00 EST Date: Sun, 23 Nov 86 01:50:34 EST From: Dead-Heads-Request@ai.ai.mit.edu Sender: GUMBY@ai.ai.mit.edu Subject: Dead mailing lists reorganised To: DEAD-HEADS@ai.ai.mit.edu Message-Id: <122319.861123.GUMBY@AI.AI.MIT.EDU>  Received: from REAGAN.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 23 NOV 86 01:42:11 EST Received: from GAYE.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 12465; Sun 23-Nov-86 01:42:04 EST Date: Sun, 23 Nov 86 01:42 EST From: David Vinayak Wallace Subject: Was I bitten by the COMSAT-interprets-% bug? To: bug-mail@AI.AI.MIT.EDU Message-ID: <861123014200.5.GUMBY@GAYE.AI.MIT.EDU> The names below are exactly all of our CSNET people and CSNET-RELAY is up as far as I can tell ----- Forwarded message follows ----- Date: Fri, 21 Nov 86 20:58:19 EST From: Communications Satellite Subject: Msg of Tuesday, 18 November 1986 18:04-EST To: GUMBY@AI.AI.MIT.EDU Message-ID: <121801.861121@AI.AI.MIT.EDU> FAILED: ADAR23%VAXTS%rca.com at RELAY.CS.NET; Host appears to be permanently down or not accepting mail. FAILED: ERIC%FOLSM2%sc.intel.com at RELAY.CS.NET; Host appears to be permanently down or not accepting mail. FAILED: JOHNSON%cs.umass.edu at RELAY.CS.NET; Host appears to be permanently down or not accepting mail. FAILED: RGG%FOLSM2%sc.intel.com at RELAY.CS.NET; Host appears to be permanently down or not accepting mail. FAILED: ACTS3%VAXTS%rca.com at RELAY.CS.NET; Host appears to be permanently down or not accepting mail. FAILED: JSPETH%rca.com at RELAY.CS.NET; Host appears to be permanently down or not accepting mail. Failed message follows: ------- Date: Tue, 18 Nov 86 18:04:31 EST From: David Vinayak Wallace Subject: Delete this test message To: DEAD-HEADS@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].119934.861118.GUMBY> Sorry; list topology changed and I want to weed out bogus addresses. ----- End forwarded message -----  Date: Fri, 21 Nov 86 03:32:17 EST From: "Pandora B. Berman" Subject: RFC822-spec MESSAGE-ID's To: GUMBY@AI.AI.MIT.EDU cc: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <121450.861121.CENT@AI.AI.MIT.EDU> Date: Thu, 20 Nov 86 17:32:24 EST From: David Vinayak Wallace Subject: COMSAT should now be generating RFC822-spec MESSAGE-ID's To: jbs@EDDIE.MIT.EDU cc: BUG-MAIL@AI.AI.MIT.EDU As you'll see if you type 1h. you said this would kill the lunar library's ability to deal with queued mail until it was edited to grok the new format; have you done that?  Date: Thu, 20 Nov 86 17:32:24 EST From: David Vinayak Wallace Subject: COMSAT should now be generating RFC822-spec MESSAGE-ID's To: jbs@EDDIE.MIT.EDU cc: BUG-MAIL@AI.AI.MIT.EDU In-reply-to: Msg of Tue 18 Nov 86 23:19:54 EST from jbs at EDDIE.MIT.EDU (Jeff Siegal) Message-ID: <121137.861120.GUMBY@AI.AI.MIT.EDU> As you'll see if you type 1h.  Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 30002424620) by AI.AI.MIT.EDU 19 Nov 86 21:13:30 EST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 4793; Wed 19-Nov-86 20:10:42 EST Date: Wed, 19 Nov 86 20:10 EST From: David A. Moon Subject: tired daemon To: Rob Austein cc: Pandora B. Berman , BUG-COMSAT@AI.AI.MIT.EDU In-Reply-To: <861119140854.4.SRA@WHORFIN.LCS.MIT.EDU> Message-ID: <861119201015.0.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Wed, 19 Nov 86 14:08 EST From: Rob Austein Date: Wed, 19 Nov 86 07:39:38 EST From: "Pandora B. Berman" From: Rob Austein we seem to be getting a lot of badreq files again. i think MX's COMSAT had just been running so long that it had accumulated a lot of in-memory junk, or something like that. i gunned it, started a new one, and fed the badreqs back in, and it transmitted them without a whimper. Well, it's not surprising that restarting COMSAT "fixed" the problem. We've always known it was a garbage collection bug. What's interesting is that (1) it had stopped doing it for months (since I removed CStacy's large fudge factor kludge), (2) it seems to have started doing it again, and (3) Moon was just hacking the garbage collection code. So I thought it was worth pointing out. 1 and 2 are true, but 3 isn't. My change was to make the message-list rotator do what it was commented to, instead of creating a circular list and dropping some messages completely.  Received: from LIVE-OAK.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 19 NOV 86 14:44:22 EST Received: from PALLADIAN-JASPER.DialNet.Symbolics.COM by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 17267; 19 Nov 86 14:36:51-EST Received: from SHREDDED-WHEAT.Palladian.COM by JASPER.Palladian.COM via CHAOS with SMTP id 19435; 19 Nov 86 13:51:48-EST Date: Wed, 19 Nov 86 13:51 EST From: Christopher C. Stacy Subject: tired daemon To: Pandora B. Berman cc: SRA@AI.AI.MIT.EDU, BUG-COMSAT@AI.AI.MIT.EDU In-Reply-To: <[AI.AI.MIT.EDU].120342.861119.CENT> Message-ID: <861119135125.3.CSTACY@SHREDDED-WHEAT.Palladian.COM> Date: Wed, 19 Nov 86 07:39:38 EST From: "Pandora B. Berman" Date: Tue, 18 Nov 86 22:36:39 EST From: Rob Austein To: BUG-COMSAT@MX.LCS.MIT.EDU we seem to be getting a lot of badreq files again. i think MX's COMSAT had just been running so long that it had accumulated a lot of in-memory junk, or something like that. i gunned it, started a new one, and fed the badreqs back in, and it transmitted them without a whimper. The NAMES database is a significant consumer of address space in COMSAT. Because it has been pruned from time to time, I imagine that there is probably not too much crap located immediately in the NAMES file itself. However, there are some large indirect lists (the @FILE specs) in there. When COMSAT slurps in a list from a file to mail to it, it adds it to its in-core name expansion database. When finished with the mail for the list, it does not flush it; that list is now read in to core for all time. Besides eating core, this means that you can't effectively update indirect mailing lists more often than you launch COMSATs. So, there's another bug for someone to fix someday. You could possibly support this theory by looking at the STATS log to see if many large indirect mailing lists were invoked before things started chomping. Meanwhile, COMSAT could be made to check to see how it's doing on memory space, and cleanly die if it gets below some threshold. Then a dragon could start it up on the top of the hour or something. Chris  Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 19 NOV 86 14:15:45 EST Received: from WHORFIN.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 19 Nov 86 14:07-EST Date: Wed, 19 Nov 86 14:08 EST From: Rob Austein Subject: tired daemon To: Pandora B. Berman cc: BUG-COMSAT@AI.AI.MIT.EDU In-Reply-To: <[AI.AI.MIT.EDU].120342.861119.CENT> Message-ID: <861119140854.4.SRA@WHORFIN.LCS.MIT.EDU> Date: Wed, 19 Nov 86 07:39:38 EST From: "Pandora B. Berman" From: Rob Austein we seem to be getting a lot of badreq files again. i think MX's COMSAT had just been running so long that it had accumulated a lot of in-memory junk, or something like that. i gunned it, started a new one, and fed the badreqs back in, and it transmitted them without a whimper. Well, it's not surprising that restarting COMSAT "fixed" the problem. We've always known it was a garbage collection bug. What's interesting is that (1) it had stopped doing it for months (since I removed CStacy's large fudge factor kludge), (2) it seems to have started doing it again, and (3) Moon was just hacking the garbage collection code. So I thought it was worth pointing out.  Date: Wed, 19 Nov 86 07:39:38 EST From: "Pandora B. Berman" Subject: tired daemon To: SRA@AI.AI.MIT.EDU cc: BUG-COMSAT@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].120342.861119.CENT> Date: Tue, 18 Nov 86 22:36:39 EST From: Rob Austein To: BUG-COMSAT@MX.LCS.MIT.EDU we seem to be getting a lot of badreq files again. i think MX's COMSAT had just been running so long that it had accumulated a lot of in-memory junk, or something like that. i gunned it, started a new one, and fed the badreqs back in, and it transmitted them without a whimper.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 18 NOV 86 22:43:41 EST Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 18 NOV 86 22:40:06 EST Date: Tue, 18 Nov 86 22:36:39 EST From: Rob Austein To: BUG-COMSAT@MX.LCS.MIT.EDU Message-ID: <[MX.LCS.MIT.EDU].958646.861118.SRA> we seem to be getting a lot of badreq files again.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 18 NOV 86 17:54:00 EST Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 18 NOV 86 17:50:52 EST Date: Tue, 18 Nov 86 17:53:19 EST From: David Vinayak Wallace Subject: No such host as "SEISMO.CSS.GOV.#Internet,"?? To: CC.BLAIS@R20.UTEXAS.EDU cc: postmaster@R20.UTEXAS.EDU, BUG-mail@MC.LCS.MIT.EDU, rms@PREP.AI.MIT.EDU In-reply-to: Msg of Tue 18 Nov 86 12:38:44-CST from Donald Blais Message-ID: <[AI.AI.MIT.EDU].119923.861118.GUMBY> That looks like an MMAILR error message, and the only machine in the loop (prep, MC, r20, seismo) running MMAILR is R20. You might want to report it to MRC; prehaps you're behind on some mailer patches.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 18 NOV 86 14:00:39 EST Received: from R20.UTEXAS.EDU (TCP 1200200076) by MC.LCS.MIT.EDU 18 Nov 86 13:42:28 EST Date: Tue 18 Nov 86 12:38:44-CST From: Donald Blais Subject: Re: No such host as "SEISMO.CSS.GOV.#Internet,"?? To: rms@PREP.AI.MIT.EDU cc: postmaster@R20.UTEXAS.EDU, bug-mail@MC.LCS.MIT.EDU In-Reply-To: <8611181817.AA29781@prep.ai.mit.edu> Message-ID: <12255959948.56.CC.BLAIS@R20.UTEXAS.EDU> Return-Path: Received: from prep.ai.mit.edu by R20.UTEXAS.EDU with TCP; Tue 18 Nov 86 12:14:42-CST Received: by prep.ai.mit.edu; Tue, 18 Nov 86 13:17:38 EST Date: Tue, 18 Nov 86 13:17:38 EST From: rms@prep.ai.mit.edu (Richard M. Stallman) Message-Id: <8611181817.AA29781@prep.ai.mit.edu> To: postmaster@r20.utexas.edu Subject: No such host as "SEISMO.CSS.GOV.#Internet,"?? MC.LCS.MIT.EDU forwards mail for user KARL to karl@utexas-20.arpa. This is what resulted. It looks like a bug at your end if seismo is not known. But if there is also a problem at MC, please tell bug-mail@MC.LCS.MIT.EDU. Date: Tue 18 Nov 86 02:36:17-CST From: The Mailer Daemon To: rms@prep.ai.mit.edu Subject: PS:[--QUEUED-MAIL--].RETRANSMIT.2586 No such host as "SEISMO.CSS.GOV.#Internet", bad queue file follows: ------- =DELIVERY-OPTIONS:MAIL =NET-MAIL-FROM-HOST:MC.LCS.MIT.EDU.#Internet =RETURN-PATH:@MC.LCS.MIT.EDU:rms@PREP.AI.MIT.EDU =NOTIFY: 19-Nov-86 00:53 =DEQUEUE: 21-Nov-86 00:53 _PREP.AI.MIT.EDU.#Internet rms SEISMO.CSS.GOV.#Internet grebyn!karl Received: from MC.LCS.MIT.EDU by R20.UTEXAS.EDU with TCP; Tue 18 Nov 86 00:53:14-CST Received: from PREP.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 18 NOV 86 01:52:44 EST Received: by prep.ai.mit.edu; Tue, 18 Nov 86 01:47:28 EST Date: Tue, 18 Nov 86 01:47:28 EST From: rms@prep.ai.mit.edu (Richard M. Stallman) To: info-gnu@prep.ai.mit.edu Please be careful not to send a reply to the whole mailing list when you really only want to talk to the sender of another message. ------- Mail to SEISMO from R20.UTEXAS.EDU is currently getting through. I don't know the source of the problem. We update our host table whenever a new one becomes available and at the moment have the following for that site... HOST : 192.12.141.25 : seismo.CSS.GOV,SEISMO.ARPA : SUN-3/160 : UNIX : TCP/TELNET,TCP/FTP,TCP/SMTP,UDP,UDP/DOMAIN : There were problems about a month ago when SEISMO changed their host address and the Hostmaster at SRI-NIC had not yet put it in. Thanks for the report. -- Donald Blais -------  Date: Mon, 17 Nov 86 11:26:51 EST From: David Vinayak Wallace Subject: overlarge requests To: ZVONA@AI.AI.MIT.EDU cc: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].119312.861117.GUMBY> Date: Sun, 16 Nov 86 22:49:55 EST From: David Chapman I sure wish this would give me the headers from the msg so I could do something about it. Date: Sun, 16 Nov 86 13:47:06 EST From: Communications Satellite Error in input request file. Request too large. Message not sent and not queued; 17 Kbytes is far too large for me. Please use the FTP program to transfer huge files around the network. Look in the recent BUG-MAIL archives for a discussion of how to fix this, and why what you ask can't necessarily work. The best place to patch is most likely just before IRQG56.  Date: Sun, 16 Nov 86 22:49:55 EST From: David Chapman Subject: [COMSAT: forwarded] To: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].119166.861116.ZVONA> I sure wish this would give me the headers from the msg so I could do something about it. Date: Sun, 16 Nov 86 13:47:06 EST From: Communications Satellite To: Zvona at AI.AI.MIT.EDU cc: MAIL-MAINTAINERS at MX.LCS.MIT.EDU Error in input request file. Request too large. Message not sent and not queued; 17 Kbytes is far too large for me. Please use the FTP program to transfer huge files around the network.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 12 NOV 86 16:45:45 EST Received: from WHORFIN.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 12 NOV 86 16:23:05 EST Date: Wed, 12 Nov 86 16:20 EST From: Rob Austein Subject: [PALLAS: Automatic removal from list...] To: Christopher C. Stacy cc: Jonathan A Rees , BUG-COMSAT@AI.AI.MIT.EDU In-Reply-To: <861109234321.1.CSTACY@SHREDDED-WHEAT.Palladian.COM> Message-ID: <861112162054.5.SRA@WHORFIN.LCS.MIT.EDU> Date: Sun, 9 Nov 86 23:43 EST From: Christopher C. Stacy If someone had the time, it would be possible in COMSAT to implement an R-OPTION kind of frob that defined the return-path to a maintainer for mailing lists. Maybe it would look something like this in the NAMES file: (INFO-FROBNOIDS (EQV-LIST (SRA XX) (JQLUZ YY)) (R-MAINTAINER (JAR MC))) Then whenever a message was sent to INFO-FROBNOIDS, its return-path would be set to instead of whatever it was originally. Then if there were errors delivering to any of the recipients, only JAR would hear about it, rather than the originator of the message. Excellent idea. Now all we need is a hero to actually write it.  Received: from OZ.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 11 NOV 86 08:37:05 EST Received: from KAREN.AI.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 11 Nov 86 08:32-EST Date: Tue, 11 Nov 86 08:32 EST From: David Vinayak Wallace Subject: A simple solution to the message-too-long problem To: Rob Austein cc: Robert Scheifler , Bug-COMSAT@AI.AI.MIT.EDU In-Reply-To: Message-ID: <861111083215.3.GUMBY@KAREN.AI.MIT.EDU> Date: Mon, 10 Nov 1986 18:31 EST From: Rob Austein Date: Monday, 10 November 1986 18:12-EST From: Robert Scheifler I naively think that sending back the first N lines would adequately identify the message, for N maybe 30, or simply the first page of the file if that is simpler. First N lines of what? Text? Headers? File? Would you like to receive 30 lines of crud that looked like... When comsat looks at the file and discovers that it's too long it could move it elsewhere (like .MAIL2;TOOLON >") and send back a failed-mail message that went something like "Your message was too long for me to deal with; you can get it back by FTPing the file ".MAIL2;TOOLONG 259" some time within the next two weeks. If you have any problems contact postmaster." Puff could GC these messages. Losers who can't FTP will continue to lose. That's what happens now anyway.  Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 30002424620) by AI.AI.MIT.EDU 10 Nov 86 20:22:42 EST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 155221; Mon 10-Nov-86 20:17:24 EST Date: Mon, 10 Nov 86 20:16 EST From: David A. Moon Subject: [COMSAT@MC.LCS.MIT.EDU: Forwarded] To: Rob Austein cc: Robert Scheifler , Bug-COMSAT@AI.AI.MIT.EDU In-Reply-To: Message-ID: <861110201637.7.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Mon, 10 Nov 1986 18:31 EST From: Rob Austein Date: Monday, 10 November 1986 18:12-EST From: Robert Scheifler I naively think that sending back the first N lines would adequately identify the message, for N maybe 30, or simply the first page of the file if that is simpler. First N lines of what? Text? Headers? File? Would you like to receive 30 lines of crud that looked like TO:1200000054M"sra Remember that if you try to parse this file you will probably crash. And the case where the offender doesn't know what message you are talking about probably doesn't justify the amount of code it would take to parse via sequential I/O. It wouldn't hurt to just suck in the first 10,000 characters or so and include that in the failure notifications. Usually the message header and beginning of the text will be in there somewhere. If it turns out you've send back nothing but TO:1200000054M"sra lines, well, that'll give all those Unix mailer folks out there something to send to their equivalent of mailer-error-of-the-day!  Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 10 NOV 86 18:35:47 EST Date: Mon, 10 Nov 1986 18:31 EST Message-ID: From: Rob Austein To: Robert Scheifler Cc: Bug-COMSAT@AI.AI.MIT.EDU Subject: [COMSAT@MC.LCS.MIT.EDU: Forwarded] In-reply-to: Msg of 10 Nov 1986 18:12-EST from Robert Scheifler Date: Monday, 10 November 1986 18:12-EST From: Robert Scheifler I naively think that sending back the first N lines would adequately identify the message, for N maybe 30, or simply the first page of the file if that is simpler. First N lines of what? Text? Headers? File? Would you like to receive 30 lines of crud that looked like TO:1200000054M"sra Remember that if you try to parse this file you will probably crash. And the case where the offender doesn't know what message you are talking about probably doesn't justify the amount of code it would take to parse via sequential I/O. Huh? If the machine doesn't answer, you queue either the original or the fail-response for later processing, yes? You don't understand how COMSAT's queue is maintained. It's essentially a moby lisp form. The message text is a string, the addresses are themselves lists (neatly cross-referenced so that various neat optimizations can take place, like when you finally get a connection to SEISMO.CSS.GOV you can -immediately- dump out every single message that's been queued for that host). It's what makes COMSAT such a winning mailer (particularly for its age); it's really a hand compiled Lisp program. The down side of this is that you have to be able to cons up the lisp form, and you can't do that if the message won't fit into the available memory. There isn't that much memory available on a non-extended PDP-10. There's a lot more than there was in COMSAT III when it also had the entire HOSTS3 binary file mapped in, but there are limits. It could queue up the fail-response. Obviously that's exactly what happens with the fail response that you get now. But it'd have to be short, and I'm not really convinced that its that useful to put a lot of work into generating a fancier fail response. Other people on BUG-COMSAT are hereby invited to disagree with me on this point if they are so inclined (although my willingness to listen is probably directly tied with your willingness to write the code...). --Rob  Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 10 NOV 86 18:17:23 EST Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU with TCP; Mon 10 Nov 86 18:12:03-EST Date: Mon, 10 Nov 86 18:12 EST From: Robert Scheifler Subject: Re: [COMSAT@MC.LCS.MIT.EDU: Forwarded] To: SRA@XX.LCS.MIT.EDU cc: Bug-COMSAT@AI.AI.MIT.EDU In-Reply-To: <12253910887.14.SRA@XX.LCS.MIT.EDU> Message-ID: <861110181217.7.RWS@KILLINGTON.LCS.MIT.EDU> How do you propose it identify the message to you when it has already told you that if it reads in enough of that message to even attempt to process it it will crash? I suppose it could attempt to send it back to you by mapping in one page at a time and sending it down the net connection, but that seems a little extreme. I naively think that sending back the first N lines would adequately identify the message, for N maybe 30, or simply the first page of the file if that is simpler. Not to mention leaving it with no good course of action if your machine doesn't answer the phone. Huh? If the machine doesn't answer, you queue either the original or the fail-response for later processing, yes?  Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 10 NOV 86 18:08:07 EST Date: Mon 10 Nov 86 18:02:55-EST From: Rob Austein Subject: Re: [COMSAT@MC.LCS.MIT.EDU: Forwarded] To: RWS@ZERMATT.LCS.MIT.EDU cc: Bug-COMSAT@AI.AI.MIT.EDU In-Reply-To: <861110172611.5.RWS@KILLINGTON.LCS.MIT.EDU> Message-ID: <12253910887.14.SRA@XX.LCS.MIT.EDU> Date: Mon, 10 Nov 86 17:26 EST From: Robert Scheifler Perhaps I'm blind, but I didn't see anything in the mail message COMSAT sent me that gave me any clue as to which message had been tossed. The thing I forwarded to you was the entire message. In this particular case I could guess, since I only sent one message with one recipient, but ... You're right, I looked it up (these things always get CC'd to the file FAILED STUFF on the .MAIL. directory). All it said was "Jesus H. Christ, that message is 147 kbytes long, find a real life you bozo". Now that I think about it, this is quite consistant with the error. How do you propose it identify the message to you when it has already told you that if it reads in enough of that message to even attempt to process it it will crash? I suppose it could attempt to send it back to you by mapping in one page at a time and sending it down the net connection, but that seems a little extreme. Not to mention leaving it with no good course of action if your machine doesn't answer the phone. The only real alternative would be for FTPS to impose some completely arbitrary limit on the size of incoming network messages (since it has no way of knowing what the actual limit is). This is pretty much contrary to the ITS design philosophy of letting the user shoot himself in the foot if s/he is stupid enough to do so (on the theory that the user might know more than the person who put the stupid limitation into the program). So that's out. (If you are wondering why FTPS can cope with messages that COMSAT can't, it's because (1) FTPS doesn't have as much crud in its address space and (2) FTPS can use sequential I/O on the message whereas COMSAT has to map the whole thing in at once to stuff it into its pseudo-lisp storage area.) I think the theory behind COMSAT's behavior is that if you are doing something this outragously tasteless you either will recognize your error once it is pointed out to you or you are such a complete loser that there is no point trying to explain. There is a point past which any reasonable mailer daemon just has to decide that the user is a bozo and stop trying to do something graceful with the message. It told you that you lost, there are ways of finding out exactly how and what lost (asking), enough already. If it would make you happier I could add the following to the error message: "I didn't even attempt to send your message to any of the recipients. I'm not going to try to send it back to you. If you don't understand what you did wrong please ask BUG-COMSAT (-DON'T- send the message there!)." --Rob -------  Received: from LIVE-OAK.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 10 NOV 86 00:46:14 EST Received: from PALLADIAN-JASPER.DialNet.Symbolics.COM by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 16218; 10 Nov 86 00:41:18-EST Received: from SHREDDED-WHEAT.Palladian.COM by JASPER.Palladian.COM via CHAOS with SMTP id 18595; 9 Nov 86 23:44:52-EST Date: Sun, 9 Nov 86 23:43 EST From: Christopher C. Stacy Subject: [PALLAS: Automatic removal from list...] To: Jonathan A Rees cc: BUG-COMSAT@AI.AI.MIT.EDU In-Reply-To: <[AI.AI.MIT.EDU].116479.861109.JAR> Message-ID: <861109234321.1.CSTACY@SHREDDED-WHEAT.Palladian.COM> If someone had the time, it would be possible in COMSAT to implement an R-OPTION kind of frob that defined the return-path to a maintainer for mailing lists. Maybe it would look something like this in the NAMES file: (INFO-FROBNOIDS (EQV-LIST (SRA XX) (JQLUZ YY)) (R-MAINTAINER (JAR MC))) Then whenever a message was sent to INFO-FROBNOIDS, its return-path would be set to instead of whatever it was originally. Then if there were errors delivering to any of the recipients, only JAR would hear about it, rather than the originator of the message.  Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 9 NOV 86 19:24:36 EST Date: Sun, 9 Nov 1986 19:19 EST Message-ID: From: Rob Austein To: Mark Crispin Cc: BUG-COMSAT@AI.AI.MIT.EDU, Alan@AI.AI.MIT.EDU Subject: ITS runs with patch In-reply-to: Msg of 9 Nov 1986 00:35-EST from Mark Crispin Date: Sunday, 9 November 1986 00:35-EST From: Mark Crispin Why is COMSAT or whatever using the return path? It's not. It's doing something much worse. It sees an address like "FOO%BAR@BAZ" and says "Oh, gee, I know who BAR is, I'll save some network overhead for this guy by sending the mail directly there and leave BAZ out of the loop". CStacy claims this code has been in place "forever" (ie, it was there before he started hacking COMSAT). I would have thought that both Moon and KLH had better sense than to implement such a gross misfeature, but I guess even legendary hackers have bad days. Or believe in the tooth fairy & the guaranteed uniqueness of hostnames. --Rob  Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 9 NOV 86 19:12:04 EST Date: Sun, 9 Nov 1986 19:07 EST Message-ID: From: Rob Austein To: Jonathan A Rees Cc: BUG-COMSAT@AI.AI.MIT.EDU Subject: [PALLAS: Automatic removal from list...] In-reply-to: Msg of 9 Nov 1986 15:31-EST from Jonathan A Rees Date: Sunday, 9 November 1986 15:31-EST From: Jonathan A Rees To: BUG-COMSAT@AI.AI.MIT.EDU Re: [PALLAS: Automatic removal from list...] I don't know whether this makes any sense. If it does then y'all should be aware of this opinion, and if it doesn't then someone would be doing me a favor by telling this person he's wrong. Thanks. - Jonathan Rees Date: Sun 9 Nov 86 11:57:21-PST From: Joseph I. Pallas To: JAR at AI.AI.MIT.EDU Re: Automatic removal from list... In-Reply-To: <[AI.AI.MIT.EDU].115915.861107.JAR> Message-ID: <12253614964.10.PALLAS@Sushi.Stanford.EDU> Your mailer is brain-damaged if it's not capable of directing bounced mail to the list maintainer instead of the sender. Even the much-reviled Unix sendmail can do this. COMSAT is quite capable of doing this. You just have to set it up right. Eg, Arpanet-BBoards messages are sent off with a return-path of "arpanet-bboards-bugs@mc.lcs.mit.edu". I don't know of any mailer, including sendmail, which will do it for a direct redistribution list. You have to use something more complex as a list exploder (a short program, generally). I know of perhaps ten major mailing lists on the entire internet which are set up "correctly". It's more work than just setting up a direct redistribution mailing list, so few people bother. So this guy is correct but is being somewhat obnoxious about it. --Rob  Received: from SUMEX-AIM.ARPA (TCP 1200000070) by AI.AI.MIT.EDU 9 Nov 86 15:45:16 EST Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Sun 9 Nov 86 12:39:36-PST Date: Sat 8 Nov 86 21:35:38-PST From: Mark Crispin Subject: Re: ITS runs with patch To: SRA@XX.LCS.MIT.EDU cc: KS-ITS@AI.AI.MIT.EDU, BUG-COMSAT@AI.AI.MIT.EDU In-Reply-To: Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12253458093.7.MRC@PANDA> Rob - Touche. In fact, there are two bugs: 1) MMailr builds an SMTP return path of the form @SUMEX-AIM.ARPA:MRC@PANDA, even though DoD policy expressly forbids names that are not in the Internet domain from appearing in an address. 2) MMailr trusts the DoD policy, and so ignores the @SUMEX-AIM.ARPA: part and parses MRC@PANDA. Unfortunately, MRC@PANDA means something else in the MIT domain (and, for that matter, in the Stanford domain with the exception of SUMEX-AIM!). Someday I plan on fixing these bugs. Note that either bug by itself is no big deal (Unix sendmail has bug #1), it's the combination that is nasty. Why is COMSAT or whatever using the return path? -- Mark -- -------  Date: Sun, 9 Nov 86 15:31:03 EST From: Jonathan A Rees Subject: [PALLAS: Automatic removal from list...] To: BUG-COMSAT@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].116479.861109.JAR> I don't know whether this makes any sense. If it does then y'all should be aware of this opinion, and if it doesn't then someone would be doing me a favor by telling this person he's wrong. Thanks. - Jonathan Rees Date: Sun 9 Nov 86 11:57:21-PST From: Joseph I. Pallas To: JAR at AI.AI.MIT.EDU Re: Automatic removal from list... In-Reply-To: <[AI.AI.MIT.EDU].115915.861107.JAR> Message-ID: <12253614964.10.PALLAS@Sushi.Stanford.EDU> Your mailer is brain-damaged if it's not capable of directing bounced mail to the list maintainer instead of the sender. Even the much-reviled Unix sendmail can do this. joe  Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 9 NOV 86 00:18:15 EST Date: Sun, 9 Nov 1986 00:14 EST Message-ID: From: Rob Austein To: Mark Crispin Cc: KS-ITS@AI.AI.MIT.EDU, BUG-COMSAT@AI.AI.MIT.EDU Subject: ITS runs with patch In-reply-to: Msg of 8 Nov 1986 15:50-EST from Mark Crispin Date: Saturday, 8 November 1986 15:50-EST From: Mark Crispin I don't know why, but your mailer insists upon replying to MRC@PANDA.MIT.EDU instead of MRC%PANDA@SUMEX-AIM.Stanford.EDU. Is Babyl being too "smart"? Maybe. And maybe MMAILR is being too "stupid". When I get mail from you directly on XX (with the latest and greatest MMAILR, via TCP/SMTP) it still claims that I have mail from "MRC@PANDA.MIT.EDU.#Chaos". More likely it is the old COMSAT "feature" which has been screwing people for years when it thinks it recognizes the BAR in FOO%BAR@BAZ. That code should be dyked out if anybody has the ambition to figure out where it is.  Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 8 NOV 86 12:44:11 EST Date: Sat 8 Nov 86 12:40:05-EST From: Rob Austein Subject: Re: How can I get a copy of the RFCxxx mail header spec? To: JAR@AI.AI.MIT.EDU cc: BUG-COMSAT@AI.AI.MIT.EDU In-Reply-To: <[AI.AI.MIT.EDU].116107.861108.JAR> Message-ID: <12253327831.10.SRA@XX.LCS.MIT.EDU> Well, the cannonical place is of course NIC:RFC:RFCnnn.TXT. But that can be a little hard to reach these days. Some of the RFCs are in NETDOC; on random ITS machines. All of the RFCs you could ever want are in XX:SRC: under the same names as on SRI-NIC. The file RFC-INDEX.TXT is updated automaticly (and thus will be up to date within 24 hours). I forget whether or not you still have an XX account; if not, you can get at this stuff with filenames like XXSRC: ARPANET; RFCnnn TXT from any ITS machine. DDT doesn't grok long filenames, but :PT and the latest version of EMACS do. --Rob -------  Date: Sat, 8 Nov 86 12:01:42 EST From: Jonathan A Rees Subject: How can I get a copy of the RFCxxx mail header spec? To: BUG-COMSAT@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].116107.861108.JAR> Could someone tell me where I can get a copy of the latest spec for the correct syntax of mail headers? I need to be able to send informed and convincing bug reports to losing systems that don't adhere to it. Thanks. - Jonathan  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 7 NOV 86 22:49:59 EST Received: from TOSCANINI.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 7 NOV 86 22:47:45 EST Date: Fri, 7 Nov 86 22:46 EST From: Rob Austein Subject: COMSAT now automaticly figures out FOO%BAR@MC kludge To: bug-comsat@AI.AI.MIT.EDU cc: alan@AI.AI.MIT.EDU Message-ID: <861107224601.2.SRA@WHORFIN.LCS.MIT.EDU> It's a trivial addition to the code which looks up which networks this ITS is on and what the full domain style name is. As a side effect, since the host tables and hardware think that MX (KL) is on both nets, its COMSAT doesn't see any reason to use the kludge. Because of the way I did the patch, it is still possible to have the kludge wired into a particular binary, so we can still do that if anybody feels strongly that MX users should continue to have their mail work. I've got mixed feelings about it; we've been telling these people that they are asking to lose if they use the machine for mail for months now.... If anybody does feel strongly, see my previous message which is still an accurate description of the locations needing patching. The chaos address for MC is available as a new symbol "HN$GAT" so you dont' have to remember what it is. --Rob  Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 30002424620) by AI.AI.MIT.EDU 7 Nov 86 21:59:51 EST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 153627; Fri 7-Nov-86 21:54:42 EST Date: Fri, 7 Nov 86 21:54 EST From: David A. Moon Subject: ALAN@ML To: Rob Austein cc: Alan Bawden , BUG-COMSAT@AI.AI.MIT.EDU In-Reply-To: Message-ID: <861107215421.2.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Fri, 7 Nov 1986 21:27 EST From: Rob Austein I guess nowadays with all these ITS machines around this should be done at boot time rather than as a static patch. Maybe I'll do that instead of patching your version. Great idea. Then I won't screw it up again next time.  Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 7 NOV 86 21:31:20 EST Date: Fri, 7 Nov 1986 21:27 EST Message-ID: From: Rob Austein To: "David A. Moon" Cc: Alan Bawden , BUG-COMSAT@AI.AI.MIT.EDU, SRA@XX.LCS.MIT.EDU Subject: ALAN@ML In-reply-to: Msg of 7 Nov 1986 20:42-EST from David A. Moon Date: Friday, 7 November 1986 20:42-EST From: David A. Moon More likely, there was a patch I was supposed to make on certain machines, rather than just copying the same binary to all the machines. SRA: is this documented any place? Yeah, I wrote this stuff down after prying it out of CSTACY. At the moment all the documentation that I aquired the hard way is in a bunch of files on MC and AI with names that seemed appropriate at 04:30 some morning or another last February. I suppose I should do something about that. In any case, the patch instructions for this one are: TCPGAT/ chaos address of host acting as IP relay HDRGAT/ -1 to force %FOO@BAR headers When last I touched things I had this installed on MX, ML, and MD. I'll install it on those machines. I guess nowadays with all these ITS machines around this should be done at boot time rather than as a static patch. Maybe I'll do that instead of patching your version.  Received: from ALDERAAN.SCRC.Symbolics.COM (TCP 30002424555) by AI.AI.MIT.EDU 7 Nov 86 21:17:09 EST Received: from EUPHRATES.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 18421; Fri 7-Nov-86 20:42:58 EST Date: Fri, 7 Nov 86 20:42 EST From: David A. Moon Subject: ALAN@ML To: Alan Bawden , SRA@XX.LCS.MIT.EDU cc: BUG-COMSAT@AI.AI.MIT.EDU In-Reply-To: <[AI.AI.MIT.EDU].115867.861107.ALAN> Message-ID: <861107204258.6.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Fri, 7 Nov 86 18:11:45 EST From: Alan Bawden Mail generated from ITS sites without Internet access is suddenly claiming to come from ALAN@ML rather than ALAN%ML@MC. Maybe that was the change from version 517, which was what was installed, to version 518, which was the only source. More likely, there was a patch I was supposed to make on certain machines, rather than just copying the same binary to all the machines. SRA: is this documented any place?  Date: Fri, 7 Nov 86 18:11:45 EST From: Alan Bawden Subject: ALAN@ML To: BUG-COMSAT@AI.AI.MIT.EDU In-reply-to: Msg of Fri 7 Nov 86 00:04:44 EST from Alan Bawden Message-ID: <[AI.AI.MIT.EDU].115867.861107.ALAN> Mail generated from ITS sites without Internet access is suddenly claiming to come from ALAN@ML rather than ALAN%ML@MC.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 7 NOV 86 01:36:45 EST Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 6 NOV 86 23:44:54 EST Date: Thu, 6 Nov 86 23:42:51 EST From: "David A. Moon" Subject: Big LISTS MSGS file on MX To: BUG-COMSAT@MX.LCS.MIT.EDU, cent@AI.AI.MIT.EDU Message-ID: <[MX.LCS.MIT.EDU].956840.861106.MOON> (p.s. to earlier message) The name of the file is MX:MOON;GUBBLE >, not GUBBISH. Yes, Comsat is throwing away messages. Here's where Comsat lost message 954879.861026 (after trying it several times on several different occasions, which show up earlier in the stats file). After trying that message once, it tried another message many times and then gave up on both of them, but only returned one of them to sender. The second message is not in the GUBBLE file. 134508 Unqueueing to host MX.LCS.MIT.EDU 134509 QID=<[MX.LCS.MIT.EDU].954879.861026> 134509 TO->MEM...TEMP ERR={DIRECTORY FULL} 134511 QID=<[MX.LCS.MIT.EDU].955192.861028> 134511 TO->MEM...TEMP ERR={DIRECTORY FULL} 134513 QID=<[MX.LCS.MIT.EDU].955192.861028> 134513 TO->MEM...TEMP ERR={DIRECTORY FULL} 134514 QID=<[MX.LCS.MIT.EDU].955192.861028> 134514 TO->MEM...TEMP ERR={DIRECTORY FULL} 134516 QID=<[MX.LCS.MIT.EDU].955192.861028> 134516 TO->MEM...TEMP ERR={DIRECTORY FULL} 134517 QID=<[MX.LCS.MIT.EDU].955192.861028> 134517 TO->MEM...TEMP ERR={DIRECTORY FULL} 134519 QID=<[MX.LCS.MIT.EDU].955192.861028> 134519 TO->MEM...TEMP ERR={DIRECTORY FULL} 134520 QID=<[MX.LCS.MIT.EDU].955192.861028> 134520 TO->MEM...TEMP ERR={DIRECTORY FULL} 134522 QID=<[MX.LCS.MIT.EDU].955192.861028> 134522 TO->MEM...TEMP ERR={DIRECTORY FULL} 134523 QID=<[MX.LCS.MIT.EDU].955192.861028> 134523 TO->MEM...TEMP ERR={DIRECTORY FULL} 134525 QID=<[MX.LCS.MIT.EDU].955192.861028> 134525 TO->MEM...TEMP ERR={DIRECTORY FULL} 134526 QID=<[MX.LCS.MIT.EDU].955192.861028> 134526 TO->MEM...TEMP ERR={DIRECTORY FULL} 134527 QID=<[MX.LCS.MIT.EDU].955192.861028> 134527 TO->MEM...TEMP ERR={DIRECTORY FULL} 134529 QID=<[MX.LCS.MIT.EDU].955192.861028> 134529 TO->MEM...TEMP ERR={DIRECTORY FULL} 134530 QID=<[MX.LCS.MIT.EDU].955192.861028> 134530 TO->MEM...TEMP ERR={DIRECTORY FULL} 134532 QID=<[MX.LCS.MIT.EDU].955192.861028> 134532 TO->MEM...TEMP ERR={DIRECTORY FULL} 134533 QID=<[MX.LCS.MIT.EDU].955192.861028> 134533 TO->MEM...TEMP ERR={DIRECTORY FULL} 134535 QID=<[MX.LCS.MIT.EDU].955192.861028> 134535 TO->MEM...TEMP ERR={DIRECTORY FULL}...Giving up. 134535 CMSG ID=<[MX.LCS.MIT.EDU].955207.861028> EXP->INFO-MAC-REQUEST@1200000070 134536 ICP->SUMEX-AIM.ARPA (CHAOS-MAIL via MC.LCS.MIT.EDU) 134536 TO->INFO-MAC-REQUEST 134543 QID=<[MX.LCS.MIT.EDU].955192.861028>... no rcpts for host! 134543 All qmsgs gone for MX.LCS.MIT.EDU Using this information, I was able to construct a reproducible test case and find the problem. In Comsat 520, I fixed some highly confused code in QUESND (very confused about what was supposed to be in register C) which would garble the list of queued messages for a host, usually making it circular, in some cases. I'm testing and installing that Comsat on all 5 MIT machines now. This should make Gumby and/or HQM happy.  Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 7 NOV 86 00:44:37 EST Date: Fri, 7 Nov 1986 00:40 EST Message-ID: From: Rob Austein To: Alan Bawden Cc: Bug-COMSAT@AI.AI.MIT.EDU Subject: Failed cube-lovers mail In-reply-to: Msg of 6 Nov 1986 23:08-EST from Alan Bawden Date: Thursday, 6 November 1986 23:08-EST From: Alan Bawden To: Bug-COMSAT@AI.AI.MIT.EDU Re: Failed cube-lovers mail What COMSAT is -trying- to tell us here is that the hostnames given for "CUBE-LOVERS-INCOMING" and "RIOLO" in the file ALAN;CUBE PEOPLE were not found anywhere. It would be nice if this error message actually said that the problem was that a -host- was unknown rather than a -user-, and if it actually mentioned the unknown host. Date: Thu, 6 Nov 86 15:11:03 EST From: Communications Satellite Subject: Msg of Thursday, 6 November 1986 15:06-EST To: hoey@NRL-AIC.ARPA Message-Id: <[AI.AI.MIT.EDU].115159.861106> ============ A copy of your message is being returned, because: ============ "CUBE-LOVERS-INCOMING" at AI.AI.MIT.EDU is an unknown recipient. This name came from the expansion of (@FILE [ALAN;CUBE PEOPLE]), from CUBE-LOVERS "RIOLO" at AI.AI.MIT.EDU is an unknown recipient. This name came from the expansion of (@FILE [ALAN;CUBE PEOPLE]), from CUBE-LOVERS Will try sending to the file "USERS3;RIOLO MAIL". ============ Failed message follows: ============ Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 6 NOV 86 15:06:54 EST Received: from nrl-aic (TCP 3200200010) by MC.LCS.MIT.EDU 6 Nov 86 15:02:30 EST Date: 6 Nov 1986 13:41:48 EST (Thu) From: Dan Hoey Subject: Magic To: Cube-lovers@mit-mc.ARPA Message-Id: <531686509/hoey@nrl-aic> I paraphrase from KLH. If you use the format "(FOO BAR)" and "BAR" is not a known host, COMSAT has no way of telling if BAR is a bogus host or a bogus R-OPTION or what. If you use the syntax "(FOO @BAR)" or even (god forbid) "FOO@BAR" it will work just fine; COMSAT will be able to deduce from context that the unrecognized token was intended to be a hostname and will take appropriate action. I am reminded of the argument that no CPU should ever have more than a few registers because programmer will go crazy trying to figure out what to do with the extra registers....  Received: from REAGAN.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 6 NOV 86 23:12:18 EST Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 10425; Thu 6-Nov-86 23:08:32 EST Date: Thu, 6 Nov 86 23:08 EST From: Alan Bawden Subject: Failed cube-lovers mail To: Bug-COMSAT@AI.AI.MIT.EDU In-Reply-To: <531694487/hoey@nrl-aic> Message-ID: <861106230840.5.ALAN@PIGPEN.AI.MIT.EDU> What COMSAT is -trying- to tell us here is that the hostnames given for "CUBE-LOVERS-INCOMING" and "RIOLO" in the file ALAN;CUBE PEOPLE were not found anywhere. It would be nice if this error message actually said that the problem was that a -host- was unknown rather than a -user-, and if it actually mentioned the unknown host. Date: Thu, 6 Nov 86 15:11:03 EST From: Communications Satellite Subject: Msg of Thursday, 6 November 1986 15:06-EST To: hoey@NRL-AIC.ARPA Message-Id: <[AI.AI.MIT.EDU].115159.861106> ============ A copy of your message is being returned, because: ============ "CUBE-LOVERS-INCOMING" at AI.AI.MIT.EDU is an unknown recipient. This name came from the expansion of (@FILE [ALAN;CUBE PEOPLE]), from CUBE-LOVERS "RIOLO" at AI.AI.MIT.EDU is an unknown recipient. This name came from the expansion of (@FILE [ALAN;CUBE PEOPLE]), from CUBE-LOVERS Will try sending to the file "USERS3;RIOLO MAIL". ============ Failed message follows: ============ Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 6 NOV 86 15:06:54 EST Received: from nrl-aic (TCP 3200200010) by MC.LCS.MIT.EDU 6 Nov 86 15:02:30 EST Date: 6 Nov 1986 13:41:48 EST (Thu) From: Dan Hoey Subject: Magic To: Cube-lovers@mit-mc.ARPA Message-Id: <531686509/hoey@nrl-aic>  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 6 NOV 86 21:52:51 EST Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 6 NOV 86 21:44:49 EST Date: Thu, 6 Nov 86 21:42:42 EST From: "David A. Moon" Subject: Big LISTS MSGS on MX To: BUG-COMSAT%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU, cent@AI.AI.MIT.EDU Message-ID: <[MX.LCS.MIT.EDU].956777.861106.MOON> LISTS MSGS on MX is full of messages that are not on the QUEUE, but were never delivered. It looks to me like they are all messages that are queued for local mailboxes and got errors trying to deliver to those mailboxes. Either comsat screwed up and lost these out of its queue, or it returned the messages to sender but forgot to delete them from MASTER. I didn't see any sign of them in FAILED STUFF. The fact that MEM is getting mail on MX but hasn't logged in since May makes this a little easier to debug. Maybe this is related to the bug where if there is a file error on a local mailbox, Comsat gives up too quickly? See the file MX:MOON;GUBBISH > for the contents of LISTS MSGS in slightly readable form. Generated with the ASCMSG routine inside COMSAT.  Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 4 NOV 86 20:40:16 EST Date: Tue, 4 Nov 1986 20:30 EST Message-ID: From: Rob Austein To: "Pandora B. Berman" Cc: BUG-MAIL@AI.AI.MIT.EDU Subject: 294 blocks of what? In-reply-to: Msg of 4 Nov 1986 05:22-EST from "Pandora B. Berman" Looks like the worlds largest collection of worthless garbage. See KL:SRA;GUBBLE >. Manually GC'ing doesn't help. If you really care the easiest thing to do would be flush the existing files and make new ones, given that the current ones are empty. I don't intend to try and debug this. It's not life or death, and that's pretty much the only reason I'll undertake a serious expedition into COMSAT's guts.  Date: Tue, 4 Nov 86 05:22:50 EST From: "Pandora B. Berman" Subject: 294 blocks of what? To: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].114081.861104.CENT> ok. i can believe that comsat is sometimes not the neatest daemon around, and thus sometimes leaves more LISTS MSGS around than necessary, simply because it doesn't clean up sufficiently cleverly or whatever. but 294 blocks worth of nothing, as i am being informed this morning by MX?: ---------- Received: from MX.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 4 NOV 86 05:15:46 EST CENT@MX.LCS.MIT.EDU (Sent by CENT'@MX.LCS.MIT.EDU) 11/04/86 05:11:57 Re: Request results To: CENT at MX.LCS.MIT.EDU ----------  Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 30002424620) by AI.AI.MIT.EDU 3 Nov 86 12:14:13 EST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 148706; Mon 3-Nov-86 12:07:32 EST Date: Mon, 3 Nov 86 12:05 EST From: David A. Moon Subject: Re: Its not April 1st, but it is almost Halloween To: John Wroclawski cc: ALAN@AI.AI.MIT.EDU, SRA@XX.LCS.MIT.EDU, BUG-COMSAT@AI.AI.MIT.EDU In-Reply-To: <12251222508.24.JTW@MIT-SPEECH> Message-ID: <861103120515.9.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Fri 31 Oct 86 11:55:12-EST From: "John Wroclawski" So, COMSAT doesn't have some sort of timeout on its network connections? It does, but maybe it's broken in some particular case. Like, maybe someone added some code somewhere to turn off the timer and forgot to turn it back on again. The only horrible thing the IMP could do that I can think of off the top of my head is supposed to have a timeout in the driver. I am sure that this timeout has fired i the past because I have seen the resulting system message. I am not sure that it correctly informs TCP of the fact. This is trickified because said horrible thing should not necessarily be a fatal error. Why do you suppose PCLSRing comsat would wake it up? The Chaos code pclsrs the job whenever the state (open/closed) of the connection changes, for precisely this reason. Perhaps the TCP code needs the same treatment. Doing it this way makes the wait conditions simpler, by only testing for what you're really waiting for (e.g. space in the output window) without having to test for all possible exceptions, too.  Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 31 OCT 86 12:48:10 EST Date: Fri, 31 Oct 1986 12:42 EST Message-ID: From: Rob Austein To: "John Wroclawski" Cc: ALAN@AI.AI.MIT.EDU, BUG-COMSAT@AI.AI.MIT.EDU Subject: Its not April 1st, but it is almost Halloween In-reply-to: Msg of 31 Oct 1986 11:55-EST from "John Wroclawski" Sometimes COMSAT uses PI timers, sometimes it uses NETBLK. I'm postulating that some part of ITS misbehaved and some system call (perhaps NETBLK, perhaps something else) never returned. PCLSRing broke it out of exec context and either the uuo was one that fails when you PCLSR from it or the monitor code decided not to wedge this time when the call was restarted. The thing that makes me suspicious is that I have seen an increase in frequency of the XX-hangs-in-IP-rxmt-fork bug since the arpanet deteriorated so badly. I'm pretty sure that the IMPs are -not- behaving according to spec (ie, your detailed knowledge of what they can and can't do is probably irrelevant). Either that or there's some bad state that every single 1822-TCP implementation forgot about, because we've seen this "oh gee I forgot about this host, sorry about that" bug on ITS, 20X, and CGW. I vaugely recall Spencer Love complaining about some non-spec IMP lossage; I would assume that it doesn't crash Multics because the IP code isn't in the Multics kernal.  Received: from SPEECH.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 31 OCT 86 11:56:36 EST Date: Fri 31 Oct 86 11:55:12-EST From: "John Wroclawski" Subject: Re: Its not April 1st, but it is almost Halloween To: ALAN@AI.AI.MIT.EDU, SRA@XX.LCS.MIT.EDU cc: BUG-COMSAT@AI.AI.MIT.EDU Message-ID: <12251222508.24.JTW@MIT-SPEECH> So, COMSAT doesn't have some sort of timeout on its network connections? The only horrible thing the IMP could do that I can think of off the top of my head is supposed to have a timeout in the driver. I am sure that this timeout has fired i the past because I have seen the resulting system message. I am not sure that it correctly informs TCP of the fact. This is trickified because said horrible thing should not necessarily be a fatal error. Why do you suppose PCLSRing comsat would wake it up? -------  Date: Fri, 31 Oct 86 03:34:11 EST From: Alan Bawden Subject: Its not April 1st, but it is almost Halloween To: SRA@XX.LCS.MIT.EDU cc: BUG-COMSAT@AI.AI.MIT.EDU, JTW@AI.AI.MIT.EDU In-reply-to: Msg of Fri 31 Oct 1986 02:13 EST from Rob Austein Message-ID: <[AI.AI.MIT.EDU].112787.861031.ALAN> Date: Fri, 31 Oct 1986 02:13 EST From: Rob Austein Date: Friday, 31 October 1986 01:56-EST From: Alan Bawden ... Seems most likely that COMSAT spent the day waiting for its current TCP connection (to CSNET Relay, I think) to do something. That I'll believe without even trying hard. The IMP probably spazzed and left the TCP code in some horrible state that can't possibly happen because everybody knows IMPs don't do this horrible thing, it says so right here in the manual that every 1822 TCP implementation makes the fatal mistake of believing. And I just bet that running PEEK caused COMSAT to be PCLSR'd, thus breaking it out of the wedged state. Give that man a prize! I'll bet this is exactly what happened. PEEK isn't supposed to cause jobs to get PCLSR'd but it could have been something else I did. Or it could simply be that my logging in created enough activity that I caused some of COMSAT's pages to get swapped out, which would cause it to get PCLSR'd.  Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 31 OCT 86 02:16:45 EST Date: Fri, 31 Oct 1986 02:13 EST Message-ID: From: Rob Austein To: Alan Bawden Cc: BUG-COMSAT@AI.AI.MIT.EDU Subject: Its not April 1st, but it is almost Halloween In-reply-to: Msg of 31 Oct 1986 01:56-EST from Alan Bawden Date: Friday, 31 October 1986 01:56-EST From: Alan Bawden ... Seems most likely that COMSAT spent the day waiting for its current TCP connection (to CSNET Relay, I think) to do something. That I'll believe without even trying hard. The IMP probably spazzed and left the TCP code in some horrible state that can't possibly happen because everybody knows IMPs don't do this horrible thing, it says so right here in the manual that every 1822 TCP implementation makes the fatal mistake of believing. And I just bet that running PEEK caused COMSAT to be PCLSR'd, thus breaking it out of the wedged state.  Date: Fri, 31 Oct 86 01:56:24 EST From: Alan Bawden Subject: Its not April 1st, but it is almost Halloween To: SRA@XX.LCS.MIT.EDU cc: BUG-COMSAT@AI.AI.MIT.EDU In-reply-to: Msg of Thu 30 Oct 1986 17:36 EST from Rob Austein Message-ID: <[AI.AI.MIT.EDU].112750.861031.ALAN> Date: Thu, 30 Oct 1986 17:36 EST From: Rob Austein Was there a disk space problem? That could (maybe) have caused this kind of lossage if enough of the error recovery code is broken. There was plenty of space in .MAIL., and plenty of space on the disk as a whole. Mail certainly accumulated in MAIL files for a couple of hours after COMSAT went to lunch with no problem. The log seems to be quite clear the COMSAT wasn't doing anything that required the allocation of disk space anyway. Seems most likely that COMSAT spent the day waiting for its current TCP connection (to CSNET Relay, I think) to do something.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 30 OCT 86 17:40:05 EST Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 30 OCT 86 17:38:05 EST Date: Thu, 30 Oct 1986 17:36 EST Message-ID: From: Rob Austein To: Alan Bawden Cc: BUG-COMSAT@MC.LCS.MIT.EDU Subject: Its not April 1st, but it is almost Halloween In-reply-to: Msg of 30 Oct 1986 17:07-EST from Alan Bawden Was there a disk space problem? That could (maybe) have caused this kind of lossage if enough of the error recovery code is broken.  Date: Thu, 30 Oct 86 17:33:05 EST From: David Vinayak Wallace Subject: early timeout To: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].112568.861030.GUMBY> Just because my mail file is locked because some loser has it locked, comsat shouldn't bounce mail for me after 15 minutes! For example: Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 30 OCT 86 17:21:52 EST Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 30 OCT 86 17:19:45 EST Date: Thu, 30 Oct 86 17:21:29 EST From: Communications Satellite Subject: Msg of Thursday, 30 October 1986 17:09-EST To: ALAN@MC.LCS.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].112562.861030> FAILED: GUMBY at AI.AI.MIT.EDU; I gave up on sending this after 201 "temporary" errors. Failed message follows: ------- Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 30 OCT 86 17:08:54 EST Date: Thu, 30 Oct 86 17:07:02 EST From: Alan Bawden Subject: Its not April 1st, but it is almost Halloween To: BUG-COMSAT@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].117363.861030.ALAN> I quote from MC:.MAIL.;OSTATS 298:  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 30 OCT 86 17:08:54 EST Date: Thu, 30 Oct 86 17:07:02 EST From: Alan Bawden Subject: Its not April 1st, but it is almost Halloween To: BUG-COMSAT@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].117363.861030.ALAN> I quote from MC:.MAIL.;OSTATS 298: ... 052047 Date is now: 10/29/86 05:20:46 052047 Note: Gobbling LSR1 database, LSRADR: 0 052048 Unqueueing to host USC-CSE.USC.EDU 052049 ICP->USC-CSE.USC.EDU (TCP-SMTP=Timeout) 052105 Unqueueing to host ERNIE.BERKELEY.EDU 052105 ICP->ERNIE.BERKELEY.EDU (TCP-SMTP=Timeout) 052121 Unqueueing to host MONET.MIT.EDU 052121 ICP->MONET.MIT.EDU (CHAOS-MAIL=Timeout) 052138 Unqueueing to host RELAY.CS.NET 052138 ICP->RELAY.CS.NET (TCP-SMTP=Timeout) 043251 InReq: 1 > 1; SPECS:{NET-MAIL-FROM: SCRC-QUABBIN.ARPA}{RTP:@QUABBIN.SCRC.Symbolics.COM,@SU-SCORE.ARPA:GOLUB@Score.Stanford.EDU}{TL=2948.}{HDR-FROM:UF7099%USU.BITNET@WISCVM.WISC.EDU} ID=<[MC.LCS.MIT.EDU].116374.861030> EXP->RP@1200600054::=(RP@40700001440) 043259 ICP->MX.LCS.MIT.EDU (CHAOS-MAIL) 043300 TO->RP 043301 InReq: 2 > 1; ... Why does the date seem to have jumped backwards by an hour? Because COMSAT did -nothing- for 23 hours! That's 4:32:51 on October 30th that COMSAT is picking up that new queued mail. Are you ready for another puzzle? OK, guess how I happen to have noticed this. I logged in, ran PEEK to see what COMSAT was up to, and just -happened- to catch it in the act of starting to deliver its first piece of mail in 23 hours. You think maybe there was some screwup with the STATS file? Nope. The existing queue of .MAIL.;MAIL files really did stretch back to the previous morning. It's almost as if COMSAT was goofing off, noticed I was logged in checking up on it, and thought, "Whoops! There's ALAN, I better get back to work!". During this time DVRSPL and Puff were running just fine. TCP gateway servers were starting and stopping all the time. Zillions of mail servers had run (although, of course, mail was being refused for much of the day because there was a backlog of MAIL files). Nothing unusual appears on the system console. I logged in at 4:27 and a new HOSTS3 was written at 4:31. Conceivably I may have deleted something from .MAIL. before I ran PEEK and discovered the situation.  Received: from XX.LCS.MIT.EDU (TCP 1200000054) by AI.AI.MIT.EDU 29 Oct 86 01:44:32 EST Date: Wed, 29 Oct 1986 01:42 EST Message-ID: From: Rob Austein To: David Vinayak Wallace Cc: BUG-MAIL@AI.AI.MIT.EDU Subject: Received: referring to bogus host In-reply-to: Msg of 28 Oct 1986 20:01-EST from David Vinayak Wallace Date: Tuesday, 28 October 1986 20:01-EST From: David Vinayak Wallace ... IWBNI the SMTP server or whomever put the host number in the Received: line when the HELO host is unknown. This is especially relevent in this age of unix machines whose mailers can most politely be referred to as, um, unpredictable. Ok, I just made the receieved line uglier.  Date: Tue, 28 Oct 86 20:01:08 EST From: David Vinayak Wallace Subject: Received: referring to bogus host To: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].111823.861028.GUMBY> I got the following message which I can't reply to. IWBNI the SMTP server or whomever put the host number in the Received: line when the HELO host is unknown. This is especially relevent in this age of unix machines whose mailers can most politely be referred to as, um, unpredictable. Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 28 OCT 86 19:46:33 EST Received: from erebus by MC.LCS.MIT.EDU 28 Oct 86 19:44:45 EST Date: Tue, 28 Oct 86 16:47:20 pst From: Dire Wolf To: gumby@MC.lcs.mit.edu Subject: Attempt at communication... Hello, hello, is anybody OUT THERE!!?? Jerry Garcia Band & Kingfish on Halloween yippy yay!!!!!!  Date: Sun, 12 Oct 86 00:59:30 EDT From: Richard Mlynarik Subject: 45 blocks of received headers deleted To: BUG-MAILER@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].105885.861012.MLY> bug-mailer@mc => bug-random-program@ai => mc => ... I defined bug-mailer@ai Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 10 OCT 86 16:07:04 EDT Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 10 OCT 86 16:07:23 EDT Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 10 OCT 86 16:06:38 EDT [zillions of headers] Date: Fri, 10 Oct 86 16:07:02 EDT From: Henry Lieberman Subject: [COMSAT: Msg of Thursday, 9 October 1986 16:39-EDT] To: BUG-MAILER@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].104257.861010.HENRY> Date: Fri, 10 Oct 86 10:31:52 EDT From: Communications Satellite To: HENRY at AI.AI.MIT.EDU Re: Msg of Thursday, 9 October 1986 16:39-EDT FAILED: Levitt at MEDIA-LAB.MIT.EDU; Funny reply from foreign host after sending message. Last reply was: {-Error queueing message: (Resetting uid)451 queuename: Cannot create "qf~Z20764" in "/usr/spool/mqueue": No such file or directory } Failed message follows: ------- Date: Thu, 9 Oct 86 16:39:54 EDT From: Henry Lieberman Subject: Stepper demo To: Levitt@MEDIA-LAB.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].103863.861009.HENRY> Sorry we didn't get the Coral Lisp stepper demo going til after you had to leave. I'd like to come over and give you a demo sometime, perhaps tomorrow afternoon if you'll be around.  Date: Wed, 8 Oct 86 22:56:07 EDT From: "Pandora B. Berman" Subject: forward = resend To: SRA@XX.LCS.MIT.EDU cc: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].103554.861008.CENT> surely this should have gone to bug-mail rather than to h-p-req... ---------- Date: Wed, 8 Oct 1986 22:33 EDT From: Rob Austein To: "Pandora B. Berman" Cc: HEADER-PEOPLE-REQUEST@AI.AI.MIT.EDU Subject: bad h-p addresses I think you are missing the point. The whole business with ReSent headers is short hand for "this message should never have ended up in my mailbox but since it did through some (human, machine, cosmic) error, I would like to pass it along to the mailbox where it should have gone without touching any of the original headers and in such a way that I can pretend it wasn't ever delivered to me because I never want to hear about it again". In particular, it is a -design- -feature- that replying to a ReSent message will go to the original sender rather than the person who resent. Ie, the fact that I resent instead of forwarded is a hint I don't -want- you to reply to me. At least that's the way I have mostly seen it used. In any case, I am totally uninterested in the autopsy unless it involves COMSAT lossage, nor do I need appologies or thanks or whatever since I am well aware that any large mailing list generally has a few broken addresses on it at any given time and since it is clearly to everbody's benefit if I pass such information along to the -request address. Maybe we should add some R-OPTION to comsat that will bash the SMTP return path to some specific value so that bug reports go directly to the list coordinator instead of the poor luser who attempted to use the list? This is sort of what steff was suggesting some time back, although he didn't know the technical details of what he was asking for. GSB and I do this manually (via TECO) for Arpanet-BBoards but it would be nice to have some way to do it for non-moderated lists. --Rob  Date: Wed, 8 Oct 86 22:10:28 EDT From: "Pandora B. Berman" Subject: Why am I getting hassled about someone else's undeliverable mail? To: TIM@AI.AI.MIT.EDU cc: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].103539.861008.CENT> Date: Wed, 1 Oct 86 17:09:39 EDT From: Tim McNerney Subject: Why am I getting hassled about someone else's undeliverable mail? To: BUG-MAIL@AI.AI.MIT.EDU I have received several notices about a piece of mail sent by TIM@CIS.UPENN.EDU. It seems as though some mailer has "got the wrong man." Date: Sat 27 Sep 86 10:49:37-EDT From: The Mailer Daemon To: TIM at MC.LCS.MIT.EDU Re: Message of 25-Sep-86 10:19:30 Message undelivered after 2 days -- will try for another 1 day: MTHOME@G.BBN.COM.#Internet: No such directory name ------------ Received: from MC.LCS.MIT.EDU by G.BBN.COM; Thu 25 Sep 86 10:19:48-EDT Received: from linc.cis.upenn.edu by MC.LCS.MIT.EDU 25 Sep 86 09:53:06 EDT Posted-Date: Thu, 25 Sep 86 09:42 EDT Message-Id: <8609251352.AA02609@linc.cis.upenn.edu> From: Tim Finin Subject: prolog in scheme To: scheme@mc.lcs.mit.edu Date: Thu, 25 Sep 86 09:42 EDT basically, BBNG seems to have been having header-chewing problems. this is not the first one i've seen. it may be fixed by now.  Date: Sun, 5 Oct 86 02:28:07 EDT From: Ken Harrenstien Subject: mail to foo%bar @ modes To: SRA@XX.LCS.MIT.EDU cc: RK@AI.AI.MIT.EDU, BUG-MAIL@AI.AI.MIT.EDU, Tague@MULTICS.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].102219.861005.KLH> The foo%host@host2 syntax is difficult because COMSAT, unlike most other mailers, sits in the middle -- it is responsible for parsing "foo%host" addresses into "foo" at "host" -- otherwise MIT-OZ mail would never be delivered. Thus '%' must be recognized and interpreted. But at the same time it is expected to pass along, without parsing, things like "foo%host" at "host2". The distinction isn't always clear, particularly because it used to be true that '%' was an acceptable synonym for '@' in ALL contexts within the ITS mail system, and foo@host@host2@host3 was/is interpreted as a valid syntax. This can be fixed in various ways. For example, the name parsing code could be made context dependent so that '%' is only recognized if the higher-level hostname is a "known" system (self, or another ITS). Thus "foo%ai@bar.edu" would not parse out the "ai" since "bar.edu" is an unknown context, but "foo%oz@ai.ai.mit.edu" would evaluate directly to foo@oz since the higher-level host context is known. Good luck.  Date: Sat, 4 Oct 86 02:44:51 EDT From: "Pandora B. Berman" Subject: old trashed LISTS MSGS To: CENT@AI.AI.MIT.EDU cc: ALAN@AI.AI.MIT.EDU, BUG-MAIL@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].101955.861004.CENT> Date: Thu, 28 Aug 86 02:14:08 EDT From: "Pandora B. Berman" Subject: old trashed LISTS MSGS To: SRA@XX.LCS.MIT.EDU cc: ALAN@AI.AI.MIT.EDU, BUG-MAIL@AI.AI.MIT.EDU Date: Mon, 25 Aug 1986 10:31 EDT From: Rob Austein To: "Pandora B. Berman" Cc: ALAN@AI.AI.MIT.EDU, BUG-MAIL@AI.AI.MIT.EDU Subject: blast from past has blown by I looked at the dead files on MX (""LIST * and "LISTS MSGS). Without a lot of work on somebody's part it's hopeless. The pointers in "LISTS MSGS are partially trashed, and the emergency dump-LISTS-MSGS-in-ascii routine can't read the file any better than the rest of COMSAT. I did run the file through a program that just dumped out the ascii strings in it; the result is in MX: .MAIL.; "LISTS ^Q ^Q TEXT. I looked at a few of the messages in there (admidst the truely worthless atoms and the other flotsam and jetsam of free storage). Two were COMSAT bug reports, one was a TWG VAX/VMS bug report, and one was a copy of the message where Geof Cooper decided to send the complete source code of his "tiny-tcp" to TCP-IP@NIC. At that point my stomach rebeled (somebody must have agreed with me because shortly thereafter there was a massive power glitch that killed both MX and XX). I vote for punting the files and forgetting about it. If there's somebody who feels this is a sacred trust, you're welcome to try to salvage messages from "LISTS TEXT if you can figure out where they are supposed to go. i poked through the "LISTS TEXT file (emacs, search for from:). it looks like the addresses before the headers are the expansion of the address list, while those after are the ones still needing delivery. there are a bunch of bug-mail msgs (which i recall seeing already), a lotta info-vax, a good dozen Physics, a couple ai-list (sole contents, part of a several msg bibliography), two tcp-ip (missed only a few subscribers), and a couple telecom. i won't mention the Kin one, or the test msgs to hp bobcats which wasted so much of comsat's time before these files were trashed, or... there appeared to be only a few personal msgs, and nothing still timely or really worth saving (assuming the large lists have archives, which i'm sure they do). so i agree -- let's flush these, and pretend the KL swallowed them whole... ok, it's been over a month. i have deleted the "prefixed files. they are on (readable) tape if ever we want them.  Date: Wed, 1 Oct 86 17:09:39 EDT From: Tim McNerney Subject: Why am I getting hassled about someone else's undeliverable mail? To: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].100913.861001.TIM> I have received several notices about a piece of mail sent by TIM@CIS.UPENN.EDU It seems as though some mailer has "got the wrong man." Date: Sat 27 Sep 86 10:49:37-EDT From: The Mailer Daemon To: TIM at MC.LCS.MIT.EDU Re: Message of 25-Sep-86 10:19:30 Message undelivered after 2 days -- will try for another 1 day: MTHOME@G.BBN.COM.#Internet: No such directory name ------------ Received: from MC.LCS.MIT.EDU by G.BBN.COM; Thu 25 Sep 86 10:19:48-EDT Received: from linc.cis.upenn.edu by MC.LCS.MIT.EDU 25 Sep 86 09:53:06 EDT Posted-Date: Thu, 25 Sep 86 09:42 EDT Message-Id: <8609251352.AA02609@linc.cis.upenn.edu> From: Tim Finin Subject: prolog in scheme To: scheme@mc.lcs.mit.edu Date: Thu, 25 Sep 86 09:42 EDT  Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU 29 Sep 86 18:23:18 EDT Date: Mon, 29 Sep 1986 18:27 EDT Message-ID: From: Rob Austein To: David Vinayak Wallace Cc: BUG-MAIL@AI.AI.MIT.EDU, RK@AI.AI.MIT.EDU, Tague@MULTICS.MIT.EDU Subject: mail to foo%bar @ modes In-reply-to: Msg of 29 Sep 1986 16:32-EDT from David Vinayak Wallace Date: Monday, 29 September 1986 16:32-EDT From: David Vinayak Wallace Does COMSAT look inside ""'s? (i.e. can't you win with "foo%bar"@baz? Dunno. Maybe.  Received: from MX.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 29 SEP 86 16:33:54 EDT Date: Mon, 29 Sep 86 16:32:37 EDT From: David Vinayak Wallace Subject: mail to foo%bar @ modes To: SRA@XX.LCS.MIT.EDU cc: Tague@MULTICS.MIT.EDU, BUG-MAIL@AI.AI.MIT.EDU, RK@AI.AI.MIT.EDU In-reply-to: Msg of Mon 29 Sep 1986 14:08 EDT from Rob Austein Message-ID: <[MX.LCS.MIT.EDU].950020.860929.GUMBY> Does COMSAT look inside ""'s? (i.e. can't you win with "foo%bar"@baz?  Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU 29 Sep 86 14:04:20 EDT Date: Mon, 29 Sep 1986 14:08 EDT Message-ID: From: Rob Austein To: "Richard Kovalcik, Jr." Cc: BUG-MAIL@AI.AI.MIT.EDU, Tague@MULTICS.MIT.EDU Subject: mail to foo%bar @ modes In-reply-to: Msg of 29 Sep 1986 12:28-EDT from "Richard Kovalcik, Jr." Date: Monday, 29 September 1986 12:28-EDT From: "Richard Kovalcik, Jr." Unless I am hallucinating mail to foo%bar @ modes is no longer automatically forwarded to modes for processing. Is this correct? It seems that if ITS "knows" about bar, it will attempt to send it directly. Is there a way around this (mis-) feature? No, you are not hallucinating. Somebody really did install all the DWIM to support this misfeature. I've been bitten by it too. It isn't a recent change though, I'm the only person who's touched COMSAT for most of a year, and -I- certainly didn't put that in. You might be able to work around it by using two "%" signs (in some meaningful fashion, of course). If I remember correctly there's some comments in the guts saying that the code only groks one "%" and if anybody doesn't like it they can tell it to the Marines. --Rob  Date: Mon, 29 Sep 86 12:28:23 EDT From: "Richard Kovalcik, Jr." Subject: mail to foo%bar @ modes To: BUG-MAIL@AI.AI.MIT.EDU cc: RK@AI.AI.MIT.EDU, Tague@MULTICS.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].100045.860929.RK> Unless I am hallucinating mail to foo%bar @ modes is no longer automatically forwarded to modes for processing. Is this correct? It seems that if ITS "knows" about bar, it will attempt to send it directly. Is there a way around this (mis-) feature? Specifically mail to *multics hasn't been getting to mitbb%bco @ mit-multics because ITS has been trying to send it directly to bco-multics which isn't on the arpanet yet. Thanks in advance for your help in straightening this out. -Rick  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 28 SEP 86 13:56:17 EDT Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU 28 Sep 86 13:55:15 EDT Date: Sun, 28 Sep 1986 14:01 EDT Message-ID: From: Rob Austein To: bug-comsat@MC.LCS.MIT.EDU Subject: oh foo Just happened to be reading protocol documentation. The Message-ID: field as used by COMSAT is not legal syntax: it's supposed to look like a fully specified address. Eg: Wrong: <[MC.LCS.MIT.EDU]123456.456788.MUMBLE> Right: <123456.456788.MUMBLE@MC.LCS.MIT.EDU> This might need to be fixed if we decide to implement TCP/NNTP.  Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU 19 Sep 86 15:23:30 EDT Date: Thu, 18 Sep 1986 17:09 EDT Message-ID: From: Rob Austein To: David Chapman Cc: bug-comsat@AI.AI.MIT.EDU, dph@AI.AI.MIT.EDU In-reply-to: Msg of 18 Sep 1986 14:44-EDT from David Chapman Date: Thursday, 18 September 1986 14:44-EDT From: David Chapman To: bug-comsat@AI.AI.MIT.EDU cc: dph@AI.AI.MIT.EDU, sra@AI.AI.MIT.EDU AI's COMSAT repeatedly crashed and burned this morning. It would crash immediately after being started up. It fixed itself mysteriously this afternoon. Not that all mysterious. There was an AI namespace problem (now fixed) which caused AI's IP address to vanish from the host tables. So, at 4AM, XX faithfully compiled a new table and installed it on AI. At that point AI's COMSAT went unstable because the LISTS EQV and LSR1 files had a whole bunch of references to AI's IP address. JTW and I fixed this around 13:15 today. I will make sure that the next table to be installed on AI does not reflect this bogosity. (A whole bunch of mail bounced out of XX's MAILQ because of this same problem; AI.AI.MIT.EDU.#Internet no longer existed.)  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 19 SEP 86 12:57:52 EDT Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 19 SEP 86 12:47:48 EDT Date: Fri, 19 Sep 1986 12:17 EDT Message-ID: From: Rob Austein To: Bug-Mail@MC.LCS.MIT.EDU, Postmaster@MC.LCS.MIT.EDU Subject: (*MSG *foo)@MC Did somebody recently screw around with the *MIT/*MAC mailing lists to produce this lossage? If you did, be informed that nobody in the world besides ITS understands what the hell that parenthesis notation means anymore (everybody else thinks it means "comment"), and that you are probably causing things to break somewhere. Of course I suppose some enviromental change could be causing COMSAT to resurect this formerly useful format from the dustbin of history.  Date: Fri, 19 Sep 86 02:04:11 EDT From: "Pandora B. Berman" Subject: Mail Q To: AFB@AI.AI.MIT.EDU cc: BUG-MAIL@AI.AI.MIT.EDU, bug-mail@OZ.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].95894.860919.CENT> Date: Thu 18 Sep 86 22:22-EDT From: "Aaron F. Bobick" Subject: Mail Q To: user-a@MC.LCS.MIT.EDU (Sent this msg here because I didn't know any other "official" address.) I assume that mail to go out over the Arpanet queues up on MC somewhere. If I have sent a message from OZ, and I want to check if its hanging around, is there a way to check the queue on MC? Also, sometimes a message seems to disappear for a while. (Today, a message I sent out at 8PM arrived at 8:30PM - but one sent this afternoon is still not there.) Thanks -- aaron Date: Fri, 19 Sep 86 01:14 EDT From: David Vinayak Wallace Subject: Mail Q To: Aaron F. Bobick cc: user-a@MC.LCS.MIT.EDU Mail questions should go to BUG-MAIL rather than USER-A. The answer is Yes, if you want to learn how to read queue output. It's not hard, just not generally useful for this sort of thing. Of course, that only works if you KNOW the mail went out through MC. checking the mail queue on an ITS can tell whether your msg has gone out from there or is still hanging around. looking at the MC queue is not hard; the relevant question, as gumby points out, is whether your mail went out through there, or through some other arpa/chaos gateway like AI or XX (look at the From: header on your original msg -- most mail sent on OZ gets a via-XX return path added to your original address). what data do you have that your mail did go through MC? e.g., did you send it to a mailing list that lives on MC? as to differences in delivery time: did your two msgs go to the exact same address? to different addresses at the same host? to different destinations via the same gateway? or to totally different places? COMSAT (the ITS mailer) can only transmit mail to hosts willing to take it, and sometimes, for a variety of reasons, perfectly valid hosts are temporarily unwilling to accept incoming mail. COMSAT will try transmitting newly-received mail once immediately; if the destination won't accept it, but indicates a temporary error condition, COMSAT will put the rejected msg in its retry queue. periodically COMSAT will attempt to resend the msg until either the msg is accepted by its destination host, or the host-looks-dead limit is reached (this takes several days). in the latter case, your mail would be returned to you with a note that the destination host has been refusing connections for long enough that it seems to have long-term trouble. MMAILR (the Twenex mailer) does the same sort of thing. current circumstances may be delaying your mail: there is some arpanet traffic problem that seems to be centered at MIT but is affecting other parts of the net. the symptoms are problems transmitting mail, long delays during net connections, and lost connections due to excessive delays; this has been going on for several days. BBN, who maintain the net, are looking into the situation; they're going to check out the MIT IMPs early fri. morning.  Received: from NRTC-GREMLIN.NORTHROP.COM by AI.AI.MIT.EDU 18 Sep 86 16:20:51 EDT Received: from nrtc-gremlin by NRTC-GREMLIN.NORTHROP.COM id a005446; 18 Sep 86 13:15 PDT To: "Pandora B. Berman" cc: HEADER-PEOPLE-REQUEST@ai.ai.mit.EDU, BUG-MAIL@ai.ai.mit.EDU Subject: Re: header-people mail losing In-reply-to: Your message of Thu, 18 Sep 86 03:27:09 -0400. <[AI.AI.MIT.EDU].95479.860918.CENT> Date: Thu, 18 Sep 86 13:15:11 -0700 Message-ID: <5443.527458511@nrtc-gremlin.northrop.com> From: Einar Stefferud OK, I will just shovel off any more bad address notices that come my way. No problem. Maybe one day someone will fix COMSAT to short circuit all this multi person coordination to deal with these things. The solution is trivial enough, to just insert a new Return-Path: header-people-request@ai.ai.mit.edu Cheers - Stef  Received: from REAGAN.AI.MIT.EDU by AI.AI.MIT.EDU 18 Sep 86 16:10:38 EDT Received: from KAREN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 3380; Thu 18-Sep-86 14:44:59 EDT Date: Thu, 18 Sep 86 14:44 EDT From: David Chapman To: bug-comsat@AI.AI.MIT.EDU cc: dph@AI.AI.MIT.EDU, sra@AI.AI.MIT.EDU Message-ID: <860918144456.3.ZVONA@KAREN.AI.MIT.EDU> AI's COMSAT repeatedly crashed and burned this morning. It would crash immediately after being started up. It fixed itself mysteriously this afternoon.  Date: Thu, 18 Sep 86 03:27:09 EDT From: "Pandora B. Berman" Subject: header-people mail losing To: stef@NRTC-GREMLIN.ARPA cc: HEADER-PEOPLE-REQUEST@AI.AI.MIT.EDU, BUG-MAIL@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].95479.860918.CENT> thanks for your reports of losing mail to LLL-TIS-B and BNL. however, i suspect that these are not hard failures; apparently there has been severe congestion on the net this past week. BBN is working on the problem, but i don't know the prognosis. so for the moment i am going to leave those addresses on the list; if you have further problems with them (or with others), please let us know and we'll look at the situation again.  Date: Tue, 16 Sep 86 07:08:47 EDT From: "Pandora B. Berman" Subject: missing OSTATS files To: RAY@AI.AI.MIT.EDU cc: ALAN@AI.AI.MIT.EDU, BUG-MAIL@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].94600.860916.CENT> Date: Sun, 14 Sep 86 11:02:49 EDT From: Ray Hirschfeld Subject: missing OSTATS files To: ALAN@AI.AI.MIT.EDU cc: BUG-MAIL@AI.AI.MIT.EDU Oops, this is my doing but I forgot to report it. Comsat crashed because the .mail. directory was full, so I moved the OSTATS files to my directory (on MC) and relaunched it. They're still there, waiting for somebody to do the right thing with them. I hope this didn't screw anything up; it seemed better than leaving the mailer broken. i have flushed the OSTATS files ray moved to his dir. it's worthwhile to note, rob, that MC had not been backed up for four or five days when ray saw comsat having trouble, so your little deletion-deamon had not swallowed any OSTATS recently. i found about 16 on ray's dir -- i must admit i didn't think comsat generated them quite that fast. i suspect this volume was due more to the combination of the net lossage (MC just kept trying and trying to deliver the mail) and the problems COMSAT has about accelerated time than a standard result of comsat function. as alan pointed out, flushing NAMES > except for the most recent few (including the most recent successfully-compiled one) and their corresponding NAMED ERR files is a valid space-saver, as is (in more stringent circumstances) flushing all but the most recent couple OSTATS files. By the way, the queue was so huge that comsat ran out of memory and went down in flames when I tried to show it. when the queued mail is over, say, 400 blocks, trying to show the queue is a real bad idea and will cause comsat to crash. i'm not sure of the exact size because my largest recent experience with the limit was with the pre-austeinized, post-stacified, crippled version we got to use last winter. there is a tool for examining msgs in excessively large queues; i have a reference to it somewhere but in my current burned out state don't feel up to finding it.  Date: Mon, 15 Sep 86 12:06:35 EDT From: Alan Bawden Subject: missing OSTATS files To: RAY@AI.AI.MIT.EDU cc: SRA@XX.LCS.MIT.EDU, BUG-MAIL@AI.AI.MIT.EDU In-reply-to: Msg of Sun 14 Sep 1986 21:48 EDT from Rob Austein Message-ID: <[AI.AI.MIT.EDU].94189.860915.ALAN> Date: Sun, 14 Sep 1986 21:48 EDT From: Rob Austein It should not be necessary to delete (or rename) -any- OSTATS files on MC anymore. There's an hourly DRAGON job that does it. I suppose in really extreme cases it might be necessary to delete OSTATS more recent than four days, but you should definitely think twice about it. I would have helped, in this case, to have deleted some of the NAMED ERRnnn files. This is harder to do automatically, but if a human -reads- the most recent one, and it says that there were no errors, it is generally safe to delete all but that very last one. It also would have helped to GC the NAMES files themselves. My algorithm for doing that is hard to explain, but as long as you don't delete the most recent one COMSAT compiled without error, -and- the most recent one written, you can't do too much damage. In any case, send mail to BUG-MAIL if you do anything to the .MAIL. directory other than write new NAMES > and MAIL > files. The only complaint I would add is that by removing -all- of the ostats files from .MAIL., the version numbers were forced to start counting from 1 again. While I have everyone's attention, let me also explain for how to recognize, and remedy, this TCP buffer lossage: If you suspect something is wrong with MC's TCP, run PEEK and type "A". Observe the line that says: "N buffers (M free)". If M is 0 and N is large, like 160, then probably MC is out of TCP buffers. The easiest remedy is simply to take the system down and bring it back up again. Since MC has no regular users, this doesn't inconvenience anyone.  Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU 14 Sep 86 21:50:11 EDT Date: Sun, 14 Sep 1986 21:48 EDT Message-ID: From: Rob Austein To: Ray Hirschfeld Cc: ALAN@AI.AI.MIT.EDU, BUG-MAIL@AI.AI.MIT.EDU Subject: missing OSTATS files In-reply-to: Msg of 14 Sep 1986 11:02-EDT from Ray Hirschfeld It should not be necessary to delete (or rename) -any- OSTATS files on MC anymore. There's an hourly DRAGON job that does it. I suppose in really extreme cases it might be necessary to delete OSTATS more recent than four days, but you should definitely think twice about it. In any case, send mail to BUG-MAIL if you do anything to the .MAIL. directory other than write new NAMES > and MAIL > files.  Date: Sun, 14 Sep 86 11:02:49 EDT From: Ray Hirschfeld Subject: missing OSTATS files To: ALAN@AI.AI.MIT.EDU cc: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].93891.860914.RAY> ALAN@MC.LCS.MIT.EDU 09/13/86 20:14:16 Re: .MAIL. directory Please do not ever delete -all- of the OSTATS files on the .MAIL. directory. Don't delete -any- OSTATS file unless it has been backed up to tape. And don't even think about deleting anything if you don't know what you are doing. Got that? Oops, this is my doing but I forgot to report it. Comsat crashed because the .mail. directory was full, so I moved the OSTATS files to my directory (on MC) and relaunched it. They're still there, waiting for somebody to do the right thing with them. I hope this didn't screw anything up; it seemed better than leaving the mailer broken. I'm not sure it helped any for comsat to run, since MC seemed to have no outgoing TCP sockets for some reason, and mail would fail with a strange "Bad Greeting" message plus what looked like a copy of the previous error message. At least new mail was able to come in instead of backing up, even though a lot of it ended up stuck in the queue. By the way, the queue was so huge that comsat ran out of memory and went down in flames when I tried to show it. Ray  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 13 SEP 86 21:40:30 EDT Received: from ML.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 13 SEP 86 21:19:54 EDT Received: from AI.AI.MIT.EDU by ML.AI.MIT.EDU via Chaosnet; 13 SEP 86 21:04:42 EDT Date: Sat, 13 Sep 86 21:08:22 EDT From: Alan Bawden Subject: When you run out of TCP buffers. To: BUG-ITS@ML.AI.MIT.EDU cc: BUG-COMSAT@ML.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].93646.860913.ALAN> There must be a path through the ITS TCP code that fails to free a buffer somehow. Twice I have seen MC run itself completely out of buffers. (See the dump MC:CRASH;CRASH TCPFUL, for an example.) In the most recent example, ITS had been running for 35 days before this happened, which might be relevant, although in the previous case it had only been running for 10 days. Bug-COMSAT: COMSAT behaves weirdly when this happens. Take a look at some of the recent stats files on MC. Like for -every- host it tries to contact with TCP it reports: Bad Greeting="+" or somesuch.  Received: from REAGAN.AI.MIT.EDU by AI.AI.MIT.EDU 11 Sep 86 22:14:41 EDT Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 2704; Thu 11-Sep-86 22:11:45 EDT Date: Thu, 11 Sep 86 22:11 EDT From: Alan Bawden Subject: [ALAN@AI.AI.MIT.EDU: Request results] To: Bug-COMSAT@AI.AI.MIT.EDU Message-ID: <860911221149.5.ALAN@PIGPEN.AI.MIT.EDU> When I tell COMSAT to list its Queue these days it usually includes a couple of instances of the following: SCRC-EUPHRATES: <[AI.AI.MIT.EDU].92943.860910.RDZ> 10 SEP 1986 2115 EDT RDZ 516 -> moon at SCRC-EUPHRATES -> Bad LN in list! VAX1.ACS.UDEL.EDU: failure cnt 100 <[AI.AI.MIT.EDU].92839.860910> 10 SEP 1986 1509 EDT @ARDEC-LCSS.ARPA 1232 -> jethro at VAX1.ACS.UDEL.EDU Which certainly doesn't look good to me. (BTW, -Don't- delete that entry for SCRC-EUPHRATES now that I have drawn your attention to it. Moon asked that we leave it there for him.)  Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM by AI.AI.MIT.EDU 11 Sep 86 21:20:49 EDT Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 79274; Thu 11-Sep-86 21:15:41 EDT Date: Thu, 11 Sep 86 21:15 EDT From: David A. Moon Subject: Two Comsat bugs To: bug-comsat@AI.AI.MIT.EDU Message-ID: <860911211535.2.MOON@EUPHRATES.SCRC.Symbolics.COM> In this code NSMINI: MOVE A,[ASCNT [MAIL]] ; Assume Mailing. SKIPE SORMSW ; Hmmm, really sending? JRST [ SKIPLE SENDSW ; Figure out what kind. MOVE A,[ASCNT [SAML]] ; 1 => Send And Mail. SKIPE SENDSW MOVE A,[ASCNT [SEND]] ;-1 => Send only. SKIPN SENDSW MOVE A,[ASCNT [SOML]] ; 0 => Send Or Mail. JRST .+1 ] OUT(NETO,TC(A),(" FROM:"),LABR,CALL(NSMRTP),RABR,EOL,FRC) .NETS NETO, ; Record the SMTP transaction. OUT(NETD,TC(A),(" FROM:"),LABR,CALL(NSMRTP),RABR,EOL) CALL NTR2XX ; Get reply code. CAIA JRST POPJ1 ; Success! CAIGE A,500. ; Bad syntax or something? RET ; No, assume temp err. ;**here** CSTAT (,(|...error for |),LABR,CALL(NSMRTP),RABR,(|="|),CALL(NTRSHO),(|", trying <>.|),frc) OUT(NETO,("RSET"),EOL,FRC) .NETS NETO, ; Some sites apparently want to reset CALL NTR2XX ; Should always win. NOP ; Eh? OUT(NETO,("MAIL FROM:<>"),EOL,FRC) ; This path is always valid. .NETS NETO, OUT(NETD,("MAIL FROM:<>"),EOL) ; Record SMTP transaction CALL NTR2XX RET JRST POPJ1 If control reaches "**here**", it forgets which verb it was using (selected at the beginning) and uses MAIL when it tries the second time. The second bug is that if it 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 here get treated as temporary errors even if in fact they were really permanent errors.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 11 SEP 86 16:48:27 EDT Date: Thu, 11 Sep 86 16:46:47 EDT From: Rob Austein To: BUG-COMSAT@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].85629.860911.SRA> The IMPs are misbehaving (see MIT-IP-PEOPLE archives for details). It seems that when COMSAT can't open a TCP connection because the IMP is wedged, it logs a line like: ICP>D.ISI.EDU (TCP-SMTP=Bad Greeting="+Mail queueued successfully") Presumably some buffer isn't getting zeroed between transactions, since this is obviously a CHAOS-MAIL protocol reply.  Date: Thu, 28 Aug 86 02:14:08 EDT From: "Pandora B. Berman" Subject: old trashed LISTS MSGS To: SRA@XX.LCS.MIT.EDU cc: ALAN@AI.AI.MIT.EDU, BUG-MAIL@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].88499.860828.CENT> Date: Mon, 25 Aug 1986 10:31 EDT From: Rob Austein To: "Pandora B. Berman" Cc: ALAN@AI.AI.MIT.EDU, BUG-MAIL@AI.AI.MIT.EDU Subject: blast from past has blown by I looked at the dead files on MX (""LIST * and "LISTS MSGS). Without a lot of work on somebody's part it's hopeless. The pointers in "LISTS MSGS are partially trashed, and the emergency dump-LISTS-MSGS-in-ascii routine can't read the file any better than the rest of COMSAT. I did run the file through a program that just dumped out the ascii strings in it; the result is in MX: .MAIL.; "LISTS ^Q ^Q TEXT. I looked at a few of the messages in there (admidst the truely worthless atoms and the other flotsam and jetsam of free storage). Two were COMSAT bug reports, one was a TWG VAX/VMS bug report, and one was a copy of the message where Geof Cooper decided to send the complete source code of his "tiny-tcp" to TCP-IP@NIC. At that point my stomach rebeled (somebody must have agreed with me because shortly thereafter there was a massive power glitch that killed both MX and XX). I vote for punting the files and forgetting about it. If there's somebody who feels this is a sacred trust, you're welcome to try to salvage messages from "LISTS TEXT if you can figure out where they are supposed to go. i poked through the "LISTS TEXT file (emacs, search for from:). it looks like the addresses before the headers are the expansion of the address list, while those after are the ones still needing delivery. there are a bunch of bug-mail msgs (which i recall seeing already), a lotta info-vax, a good dozen Physics, a couple ai-list (sole contents, part of a several msg bibliography), two tcp-ip (missed only a few subscribers), and a couple telecom. i won't mention the Kin one, or the test msgs to hp bobcats which wasted so much of comsat's time before these files were trashed, or... there appeared to be only a few personal msgs, and nothing still timely or really worth saving (assuming the large lists have archives, which i'm sure they do). so i agree -- let's flush these, and pretend the KL swallowed them whole...  Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU 25 Aug 86 13:45:41 EDT Date: Mon, 25 Aug 1986 13:42 EDT Message-ID: From: Rob Austein To: "Pandora B. Berman" Cc: ALAN@AI.AI.MIT.EDU, BUG-MAIL@AI.AI.MIT.EDU Subject: blast from past has blown by In-reply-to: Msg of 23 Aug 1986 03:25-EDT from "Pandora B. Berman" Date: Saturday, 23 August 1986 03:25-EDT From: "Pandora B. Berman" ALL the MC/MX badreqs from this spring have now been sent along. i'm not sure whether i should send another arpanet-bbs msg commending the world for their patience with our lossage, or just lie low and let them slowly exhale with relief as no more appear. It might not be a bad idea for us to send off one last message informing the world of the state of ITS dependent things. There were so many conflicting versions coming out in such a short time that there are a lot of people still confused about what happened (which machines are dead, which are reincarnated, which things got transplanted where, which services we still provide and which we don't, like free MACSYMA!). On the other hand, keeping quiet now that things have mostly blown over has a certain appeal....  Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU 25 Aug 86 10:41:49 EDT Date: Mon, 25 Aug 1986 10:31 EDT Message-ID: From: Rob Austein To: "Pandora B. Berman" Cc: ALAN@AI.AI.MIT.EDU, BUG-MAIL@AI.AI.MIT.EDU Subject: blast from past has blown by In-reply-to: Msg of 23 Aug 1986 03:25-EDT from "Pandora B. Berman" I looked at the dead files on MX (""LIST * and "LISTS MSGS). Without a lot of work on somebody's part it's hopeless. The pointers in "LISTS MSGS are partially trashed, and the emergency dump-LISTS-MSGS-in-ascii routine can't read the file any better than the rest of COMSAT. I did run the file through a program that just dumped out the ascii strings in it; the result is in MX: .MAIL.; "LISTS ^Q ^Q TEXT. I looked at a few of the messages in there (admidst the truely worthless atoms and the other flotsam and jetsam of free storage). Two were COMSAT bug reports, one was a TWG VAX/VMS bug report, and one was a copy of the message where Geof Cooper decided to send the complete source code of his "tiny-tcp" to TCP-IP@NIC. At that point my stomach rebeled (somebody must have agreed with me because shortly thereafter there was a massive power glitch that killed both MX and XX). I vote for punting the files and forgetting about it. If there's somebody who feels this is a sacred trust, you're welcome to try to salvage messages from "LISTS TEXT if you can figure out where they are supposed to go.  Date: Sat, 23 Aug 86 23:01:25 EDT From: Alan Bawden Subject: blast from past has blown by To: BUG-MAIL@AI.AI.MIT.EDU cc: CENT@AI.AI.MIT.EDU In-reply-to: Msg of Sat 23 Aug 86 03:25:41 EDT from Pandora B. Berman Message-ID: <[AI.AI.MIT.EDU].87095.860823.ALAN> Date: Sat, 23 Aug 86 03:25:41 EDT From: Pandora B. Berman speaking of which, could someone with talent take a look at "LIST files on MC:.MAIL.;? I presume she means MX:.MAIL.;. Specifically these files: 1 ""LIST QUEUE 2 5/20/86 13:14:55 1 ""LIST MASTER 5 5/20/86 13:15:28 0 ""LIST REMIND 1 2/14/86 17:17:46 15 "LISTS MSGS 407 5/20/86 12:20:24 they're from when DEC sweettalked us into trying to use unit 1 while another of the RP04s was broken in late may; unit 1 coughed and locked some blocks in here, or something, making the files unusable in their current state.... Right. These files are actually -copies- of the files that were trashed, containing as many of the bits from the originals as ITS was able to read back from the busted disk. Probably they contain a couple of isolated blocks of garbage. COMSAT was crashing when these were installed as its working database, so presumably at least one of the gubbled blocks contained something more important than the text of a message to bandykins.  Date: Sat, 23 Aug 86 03:25:41 EDT From: "Pandora B. Berman" Subject: blast from past has blown by To: BUG-MAIL@AI.AI.MIT.EDU cc: ALAN@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].86954.860823.CENT> ALL the MC/MX badreqs from this spring have now been sent along. i'm not sure whether i should send another arpanet-bbs msg commending the world for their patience with our lossage, or just lie low and let them slowly exhale with relief as no more appear. speaking of which, could someone with talent take a look at "LIST files on MC:.MAIL.;? they're from when DEC sweettalked us into trying to use unit 1 while another of the RP04s was broken in late may; unit 1 coughed and locked some blocks in here, or something, making the files unusable in their current state. however, the consensus seemed to be that someone could probably diddle a small number of bits there carefully and by that means allow most of the queued msgs caught in this black hole to escape -- all except the ones that actually were damaged. alan may remember more than i do, as he had to create new LIST files on instructions from KLH.  Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU 21 Aug 86 16:05:58 EDT Date: Thu, 21 Aug 1986 16:03 EDT Message-ID: From: Rob Austein To: BARTH@AI.AI.MIT.EDU Cc: BUG-MAIL@AI.AI.MIT.EDU, CENT@AI.AI.MIT.EDU Subject: bad header In-reply-to: Msg of 21 Aug 1986 03:18-EDT from "Pandora B. Berman" Date: Wed, 20 Aug 86 02:02:33 EDT From: Richard Barth To: CENT@AI.AI.MIT.EDU Another question, I'm afraid. I got the following back from the handicaps net, indicating it had a bad header for one reason or another. Would you please give it a quick once-over and tell me if there is anything I need to do differently? Received: by NDSUVM1 (Mailer X1.23) id 1594; Fri, 15 Aug 86 23:02:37 CDT Received: from AI.AI.MIT.EDU by wiscvm.wisc.edu on 08/15/86 at 23:00:46 CDT Date: Sat, 16 Aug 86 00:01:46 EDT Sender: List Processor Reply-to: Distribution List From: Richard Barth Subject: Address wanted for "AMPUTEE SHOE EXCHANGE" To: Ben Broder (Distribution: L-HCAP) Message-ID: <[AI.AI.MIT.EDU].84306.860816.BARTH> <=== This was the problem... I don't see anything obviously wrong with the header. It might just be some idiot piece of bitnet mailer software that thinks it has knowledge of every possible header in a mail message and barfs if it sees one it doesn't recognize. Or it might be something totally different. You should have sent in the text of the mailer's complaint along with the suposedly bad header. Your "this is the problem" arrow is useless without the text of the complaint and the headers indicating which mailer was complaining. Without this information there is no point in trying to debug further. (In other words, if you don't understand the bug and want to get an analysis from someone who does, don't censor the example you are providing; if you understood the error message you wouldn't need the expert, right?)  Date: Thu, 21 Aug 86 03:18:32 EDT From: "Pandora B. Berman" Subject: bad header To: BARTH@AI.AI.MIT.EDU cc: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].86154.860821.CENT> Date: Wed, 20 Aug 86 02:02:33 EDT From: Richard Barth To: CENT@AI.AI.MIT.EDU Another question, I'm afraid. I got the following back from the handicaps net, indicating it had a bad header for one reason or another. Would you please give it a quick once-over and tell me if there is anything I need to do differently? Many thanks ------------ Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 19 AUG 86 23:39:14 EDT Received: from MIT-MULTICS.ARPA by MC.LCS.MIT.EDU 19 Aug 86 23:37:52 EDT Received: from NDSUVM1(MAILER) by MITVMA (Mailer X1.23) id 1801; Tue, 19 Aug 86 23:33:48 EDT Received: by NDSUVM1 (Mailer X1.23) id 5541; Tue, 19 Aug 86 22:30:01 CDT Received: by NDSUVM1 (Mailer X1.23) id 5491; Tue, 19 Aug 86 22:29:15 CDT Date: Tue, 19 Aug 86 22:26:00 CDT Sender: (NU021172@NDSUVM1) via List Processor Reply-to: Distribution List From: Marty Hoag The following did not get to about half the L-HCAP list due to a bad mail header. This may be a problem with the original senders mail system or with LISTSERV. The original sender might want to check with their local support people. (I apologize to those of you on BITNET/NetNorth/EARN/ Asianet who already got this). Received: by NDSUVM1 (Mailer X1.23) id 1594; Fri, 15 Aug 86 23:02:37 CDT Received: from AI.AI.MIT.EDU by wiscvm.wisc.edu on 08/15/86 at 23:00:46 CDT Date: Sat, 16 Aug 86 00:01:46 EDT Sender: List Processor Reply-to: Distribution List From: Richard Barth Subject: Address wanted for "AMPUTEE SHOE EXCHANGE" To: Ben Broder (Distribution: L-HCAP) Message-ID: <[AI.AI.MIT.EDU].84306.860816.BARTH> <=== This was the problem... [text of barth's msg removed] that looks fine to me. but i'm not an expert. maybe someone on this list can give you more exact advice.  Date: Wed, 20 Aug 86 20:05:27 EDT From: "Pandora B. Berman" Subject: reemergence of old messages To: HBR@OZ.AI.MIT.EDU cc: BUG-MAIL@AI.AI.MIT.EDU, bug-mail@OZ.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].86009.860820.CENT> Date: Mon 18 Aug 86 14:33:40-EDT From: "Howard B. Reubenstein" Subject: Mistaken resending of messages To: bug-mail%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU, bug-mail@MC.LCS.MIT.EDU Message follows: ------- Date: Sun 13 Apr 1986 20:05-PST From: AIList Moderator Kenneth Laws Reply-to: AIList@SRI-AI Subject: AIList Digest V4 #86 To: AIList@SRI-AI AIList Digest Monday, 14 Apr 1986 Volume 4 : Issue 86 -------- I just got back from AAAI and found about 30 old issues of ailist in my mailer. It looks like MX is picking up MCs old queue?? I don't really know what has happened during the demise of MC, but it is annoying to get all these repeats and it also seems possible that this could go on forever since it looks like MX is picking old messages off MC and sending them through MC again which means it might pick them up yet again at a later date. Any help is appreciated what you are seeing is not a mail loop or a fukt queue. this is what is going on: starting last Christmas, and until early May, COMSAT had trouble swallowing msgs over a certain size (2-3 ITS blocks, which is pretty small by large-mailing-list standards). many msgs during that period, including the AILIST mail you refer to, could not be transmitted by the old MC, and so were stored in an auxiliary directory while we were waiting for the resident COMSAT hacker to fix it. during this wait, MC and MX traded names. once COMSAT was fixed, we started retransmitting these lost msgs (as announced to Arpanet-BBoards -- a copy of this msg is available if you missed it), in spates determined by COMSAT's activity with current mail and the accessibility of the lost mail. unfortunately, much of it had been migrated to tape, and in the middle of this retransmission MX's tape drive broke, and was down for a month, extending the retransmission delay. you note that these are repeats of digests you have already seen. that was because someone involved with that list found an alternate path for it to use, not involving MC/MX. much of the lost mail we have been retransmitting was not so fortunate -- for many recipients this is the first time they are seeing the msgs in question. we apologize for any inconvenience you may be encountering. we are almost finished with this retransmission, so you shouldn't be finding old digests turning up for too much longer.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 18 AUG 86 14:41:11 EDT Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 18 AUG 86 14:30:41 EDT Date: Mon 18 Aug 86 14:33:40-EDT From: "Howard B. Reubenstein" Subject: Mistaken resending of messages To: bug-mail%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU, bug-mail@MC.LCS.MIT.EDU cc: HBR%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU Message-ID: <12231841777.79.HBR@OZ.AI.MIT.EDU> Message follows: ------- 9-Aug-86 04:15:07-EDT,18281;000000000001 Received: from MC.LCS.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 9 Aug 86 04:14-EDT Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 9 AUG 86 04:05:45 EDT Received: from SRI-AI.ARPA by MC.LCS.MIT.EDU 14 Apr 86 01:19:28 EST Date: Sun 13 Apr 1986 20:05-PST From: AIList Moderator Kenneth Laws Reply-to: AIList@SRI-AI US-Mail: SRI Int., 333 Ravenswood Ave., Menlo Park, CA 94025 Phone: (415) 859-6467 Subject: AIList Digest V4 #86 To: AIList@SRI-AI AIList Digest Monday, 14 Apr 1986 Volume 4 : Issue 86 -------- I just got back from AAAI and found about 30 old issues of ailist in my mailer. It looks like MX is picking up MCs old queue?? I don't really know what has happened during the demise of MC, but it is annoying to get all these repeats and it also seems possible that this could go on forever since it looks like MX is picking old messages off MC and sending them through MC again which means it might pick them up yet again at a later date. Any help is appreciated - Howard -------  Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU 16 Aug 86 15:25:00 EDT Date: Sat 16 Aug 86 15:30:42-EDT From: Rob Austein Subject: address reformation To: RAY@AI.AI.MIT.EDU, bede@XX.LCS.MIT.EDU cc: BUG-MAIL@AI.AI.MIT.EDU In-Reply-To: <[AI.AI.MIT.EDU].84385.860816.RAY> Message-ID: <12231327871.49.SRA@XX.LCS.MIT.EDU> Date: Sat, 16 Aug 86 08:05:12 EDT From: Ray Hirschfeld I sent mail from AI to a mailing list on AJAX that I'm on. When I got it back I noticed that the mailer had used something funny for my return address. I've attached the header. Is it supposed to do this? Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 16 AUG 86 07:42:50 EDT Received: from AJAX.LCS.MIT.EDU by MC.LCS.MIT.EDU 16 Aug 86 07:41:31 EDT Received: from AI.AI.MIT.EDU (600020a) by AJAX.LCS.MIT.EDU (4.12/4.7); Sat, 16 Aug 86 07:38:24 edt Date: Sat, 16 Aug 86 07:40:28 EDT From: Ray Hirschfeld AI is listed in AJAX's /etc/chaoshosts file. So AJAX thinks AI is a chaos only host. It does this address reformation so that when luser1@oz sends to loser2@berkeley via AJAX, loser2 can respond. Bede, you should be using XX:CHAOSHOSTS.CHAOS-ONLY for your /etc/chaoshosts file. --Rob -------  Date: Sat, 16 Aug 86 08:05:12 EDT From: Ray Hirschfeld Subject: address reformation To: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].84385.860816.RAY> I sent mail from AI to a mailing list on AJAX that I'm on. When I got it back I noticed that the mailer had used something funny for my return address. I've attached the header. Is it supposed to do this? Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 16 AUG 86 07:42:50 EDT Received: from AJAX.LCS.MIT.EDU by MC.LCS.MIT.EDU 16 Aug 86 07:41:31 EDT Received: from AI.AI.MIT.EDU (600020a) by AJAX.LCS.MIT.EDU (4.12/4.7); Sat, 16 Aug 86 07:38:24 edt Date: Sat, 16 Aug 86 07:40:28 EDT From: Ray Hirschfeld Subject: Berkeley 4.3 To: dms@HERMES.AI.MIT.EDU Cc: eunuchs@AJAX.LCS.MIT.EDU, saj@PREP.AI.MIT.EDU, sundar@HERMES.AI.MIT.EDU, cjl@REAGAN.AI.MIT.EDU In-Reply-To: Msg of Fri 15 Aug 86 08:22:31 EDT from dms at HERMES.AI.MIT.EDU (David M. Siegel) Message-Id: <[AI.AI.MIT.EDU].84380.860816.RAY>  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 14 AUG 86 02:06:16 EDT Date: Thu, 14 Aug 86 02:05:24 EDT From: Rob Austein Subject: I installed MC: DRAGON; HOURLY GCMAIL To: BUG-MAIL@MC.LCS.MIT.EDU, POSTMASTER@MC.LCS.MIT.EDU, MAGIC-DRAGON-KEEPER@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].66493.860814.SRA> This is a program which implements (a lame version of) Moon's suggestion for keeping the OSTATS files under control. It flushes any OSTATS files in .MAIL.; which are backed up, aren't set "don't reap", and are older than a hardwired time limit (currently four days). It seemed to work ok in debug mode. Penny just did a backup of MC, so this seems a good time to try it out. If anybody notices anything weird happening, first delete HOURLY GCMAIL, then ask questions. --Rob  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 14 AUG 86 00:34:44 EDT Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 14 AUG 86 00:33:01 EDT Received: from MC.LCS.MIT.EDU by MX.LCS.MIT.EDU via Chaosnet; 14 AUG 86 00:32:18 EDT Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU 14 Aug 86 00:31:42 EDT Date: Thu, 14 Aug 1986 00:38 EDT Message-ID: From: Rob Austein To: "Keith F. Lynch" Cc: BUG-MAIL%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU In-reply-to: Msg of 14 Aug 1986 00:10-EDT from "Keith F. Lynch" Date: Thursday, 14 August 1986 00:10-EDT From: "Keith F. Lynch" To: BUG-MAIL%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU cc: KFL%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU When sending mail to users on ucbvax.berkeley.edu or ohio-state.edu from MX, I get a message that warns me that "this site is not a server" or something like that, and asks me if I want to send anyway. There was no such message two days ago. Ignore it. The message has been in the code for a long time. It was triggered today by a bogus host table. Said host table will be superceded in about 15 minutes (I was going to let it wait till tonight at 4am when it would happen by itself, but what the hell).  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 14 AUG 86 00:11:58 EDT Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 14 AUG 86 00:11:01 EDT Date: Thu, 14 Aug 86 00:10:21 EDT From: "Keith F. Lynch" To: BUG-MAIL%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU cc: KFL%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU Message-ID: <[MX.LCS.MIT.EDU].940764.860814.KFL> When sending mail to users on ucbvax.berkeley.edu or ohio-state.edu from MX, I get a message that warns me that "this site is not a server" or something like that, and asks me if I want to send anyway. There was no such message two days ago. This is causing problems for me because my mail is being sent by a program on my PC which dials up and logs in. Of course, it went down in flames when hit by those error messages, since it didn't know how to respond. Is there something wrong with sending to those machines from MX? I use MX rather than AI because MX is usually less loaded. How can I send to those machines? Can I get a list of which hosts generate such a message, so that I can simply insert a Y in my upload file in the right places? Thanks for your help. ...Keith  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 29 JUL 86 15:47:30 EDT Date: Tue, 29 Jul 86 15:49:27 EDT From: Alan Bawden Subject: MC:.MAIL.; To: BUG-MAIL@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].54986.860729.ALAN> was full again today. Again I was lucky enough to notice almost immediately. Lots of OSTATS files that were on backup tape were easily deletable. Also, NAMES > had had unbalanced parenthesis since last Friday, perhaps when that happens COMSAT should send mail to someone so we notice? I suppose it could also send mail when its directory gets full by writing to AI:.MAIL.;...  Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM by AI.AI.MIT.EDU 24 Jul 86 19:18:06 EDT Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 49456; Thu 24-Jul-86 18:46:43 EDT Date: Thu, 24 Jul 86 18:46 EDT From: David A. Moon Subject: MC To: Alan Bawden cc: SRA@XX.LCS.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU, BUG-MAIL@AI.AI.MIT.EDU In-Reply-To: <[AI.AI.MIT.EDU].75103.860724.ALAN> Message-ID: <860724184615.3.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Thu, 24 Jul 86 15:15:31 EDT From: Alan Bawden Date: Thu, 24 Jul 1986 13:53 EDT From: Rob Austein MC seems to have stopped talking to its IMP.... MC's IMP cable was half unplugged at the IMP end. PEEK on MC claims that there are no free packet buffers, all sockets in use, but shows nobody using the net. Who claimed all sockets were in use? I guess some program told you this because both conditions return the same error code. I don't actually understand why unplugging the IMP cable should cause all the buffers to get used up. There is a crash dump in MC:CRASH;CRASH TCPFUL if a TCP wizard wants to tell us. (This happened on MC once before, see MC:CRASH;CRASH TCP.) Maybe all the packet buffers were full of packets waiting to be sent to the IMP. Maybe a cable fell off ... Very good! I gunned COMSAT on MC so that it wouldn't time out all the messages in its queue trying to send through a broken interface. But of course Puff launched another one within an hour. By the way, I believe the NET command in LOCK still resets the network, cycling HOST MASTER READY on the IMP cable. That wouldn't have plugged the cable back in in this case of course, but might still have been a useful thing to try. I hope this command works on KS's.  Date: Thu, 24 Jul 86 15:15:31 EDT From: Alan Bawden Subject: MC To: SRA@XX.LCS.MIT.EDU, BUG-ITS@AI.AI.MIT.EDU cc: BUG-MAIL@AI.AI.MIT.EDU In-reply-to: Msg of Thu 24 Jul 1986 13:53 EDT from Rob Austein Message-ID: <[AI.AI.MIT.EDU].75103.860724.ALAN> Date: Thu, 24 Jul 1986 13:53 EDT From: Rob Austein MC seems to have stopped talking to its IMP.... MC's IMP cable was half unplugged at the IMP end. PEEK on MC claims that there are no free packet buffers, all sockets in use, but shows nobody using the net. Who claimed all sockets were in use? I guess some program told you this because both conditions return the same error code. I don't actually understand why unplugging the IMP cable should cause all the buffers to get used up. There is a crash dump in MC:CRASH;CRASH TCPFUL if a TCP wizard wants to tell us. (This happened on MC once before, see MC:CRASH;CRASH TCP.) Maybe a cable fell off ... Very good! I gunned COMSAT on MC so that it wouldn't time out all the messages in its queue trying to send through a broken interface. But of course Puff launched another one within an hour.  Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU 24 Jul 86 14:18:57 EDT Date: Thu, 24 Jul 1986 13:53 EDT Message-ID: From: Rob Austein To: bug-its@AI.AI.MIT.EDU, bug-mail@AI.AI.MIT.EDU Subject: MC MC seems to have stopped talking to its IMP. XX isn't having any trouble with this, so it's (probably) not BBN doing something random. Attempting to connect to 10.3.0.44 causes the IMP to claim that MC is down. PEEK on MC claims that there are no free packet buffers, all sockets in use, but shows nobody using the net. Maybe a cable fell off the LH/DH or maybe something else. I gunned COMSAT on MC so that it wouldn't time out all the messages in its queue trying to send through a broken interface.  Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM by AI.AI.MIT.EDU 22 Jul 86 17:13:49 EDT Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 47372; Tue 22-Jul-86 14:53:09 EDT Date: Tue, 22 Jul 86 14:52 EDT From: David A. Moon Subject: "permanently" down? To: Jonathan A Rees cc: BUG-MAIL@AI.AI.MIT.EDU In-Reply-To: <[AI.AI.MIT.EDU].73517.860721.JAR> Message-ID: <860722145236.7.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Mon, 21 Jul 86 20:03:25 EDT From: Jonathan A Rees Does the following mean that COMSAT decides after only 4 hours (look at the dates) that a host is "permanently down"? That seems pretty impatient to me. - Jonathan Date: Mon, 21 Jul 86 19:23:07 EDT From: Communications Satellite To: JAR at AI.AI.MIT.EDU Re: Msg of Monday, 21 July 1986 15:25-EDT Message-ID: <[MC.LCS.MIT.EDU].47945.860721> FAILED: SCHEME at RADC-TOPS20.ARPA; Host appears to be permanently down or not accepting mail. Failed message follows: ... Perhaps another message had been queued to it for a week, and when the host hadn't responded to a week's worth of trying to connect, all messages were discarded, including ones that hadn't been waiting for a week. If that's what happened, I think it's right. On the other hand, maybe the timing inside Comsat is just all screwed up.  Date: Mon, 21 Jul 86 20:03:25 EDT From: Jonathan A Rees Subject: "permanently" down? To: BUG-MAIL@AI.AI.MIT.EDU In-reply-to: Msg of Mon 21 Jul 86 19:23:07 EDT from Communications Satellite Message-ID: <[AI.AI.MIT.EDU].73517.860721.JAR> Does the following mean that COMSAT decides after only 4 hours (look at the dates) that a host is "permanently down"? That seems pretty impatient to me. - Jonathan Date: Mon, 21 Jul 86 19:23:07 EDT From: Communications Satellite To: JAR at AI.AI.MIT.EDU Re: Msg of Monday, 21 July 1986 15:25-EDT Message-ID: <[MC.LCS.MIT.EDU].47945.860721> FAILED: SCHEME at RADC-TOPS20.ARPA; Host appears to be permanently down or not accepting mail. Failed message follows: ...  Received: from BRL-ADM.ARPA by AI.AI.MIT.EDU 16 Jul 86 15:45:43 EDT Date: Wed, 16 Jul 86 15:43:28 EDT From: Einar Stefferud (Consultant) To: SRA@xx.lcs.mit.edu cc: stef@BRL.ARPA, bug-mail@ai.ai.mit.edu, header-people-request@ai.ai.mit.edu Subject: Re: bad addresses Well, I am just an innocent bystander, who is getting back tons of those failure messages, which I cannot do anything with, so I merely forwarded them to someone that might be able to do something useful with them, like eliminate the address that consistently fails on every message I send to header-people, from the header-people address list. It is sort of too bad that you prefer to point out to me in this situation that I should just bear with the mess. As a distribution list administrator for other lists, I must say that I always find it reasonable to simply remove addesses that consistently fail, because keeping them in there when they only fail is pretty pointless. It is my practice to forward failure messages to you who can and might do something to remove the offending addresses. Please do remove this one, or lean on the downstream site that is allowing a bad address to reflect back to the originators. Or, better yet, fix COMSAT to not reflect back to originators in the first place. And no,. I don't want to hear about how all this is someone else's fault, and how you can't fix it, and .... Please just don't bother to include me in your reply. Thanks - Stef  Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU 16 Jul 86 13:13:58 EDT Date: Wed, 16 Jul 1986 13:09 EDT Message-ID: From: Rob Austein To: Einar Stefferud Cc: BUG-MAIL@AI.AI.MIT.EDU, HEADER-PEOPLE-REQUEST@AI.AI.MIT.EDU Subject: bad addresses Date: Wednesday, 16 July 1986 11:49-EDT From: Einar Stefferud Well, I get this Sweillam@uw-blue-chip.apa.#Internet every time I send something to Header-People --- So, it is quite a case of hiccups, I'd say. Stef Anything.Mumble.#Internet is a Twenexism. It was being generated by WASHINGTON.ARPA's MMAILR, not AI's COMSAT. What Penny was refering to was the (FOO%BAR.BITNET @WISCVM) lossage, which is indeed (as near as I can tell) a timing screw somewhere in the depths of COMSAT. It doesn't happen often anymore, so don't hold your breath waiting for it to get fixed. --Rob  Received: from BRL-ADM.ARPA by AI.AI.MIT.EDU 16 Jul 86 11:49:51 EDT Date: Wed, 16 Jul 86 11:49:47 EDT From: Einar Stefferud (Consultant) To: "Pandora B. Berman" cc: HEADER-PEOPLE-REQUEST@ai.ai.mit.edu, BUG-MAIL@ai.ai.mit.edu, stef@BRL.ARPA Subject: Re: bad addresses Well, I get this Sweillam@uw-blue-chip.apa.#Internet every time I send something to Header-People --- So, it is quite a case of hiccups, I'd say. Stef  Date: Wed, 16 Jul 86 05:43:20 EDT From: "Pandora B. Berman" Subject: bad addresses To: stef@NRTC-GREMLIN.ARPA cc: HEADER-PEOPLE-REQUEST@AI.AI.MIT.EDU, BUG-MAIL@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].70987.860716.CENT> Date: Fri 11 Jul 86 23:30:01-PDT From: The Mailer Daemon To: stef@nrtc-gremlin Subject: Message of 11-Jul-86 23:29:15 Resent-To: header-people-request@mc.lcs.mit.EDU Resent-Date: Fri, 11 Jul 86 23:51:54 -0700 Resent-From: Einar Stefferud Message failed for the following: Sweillam@UW-BLUECHIP.ARPA.#Internet: 550 ... User unknown ------------ To: Jacob_Palme_QZ%QZCOM.MAILNET@mit-multics.ARPA, header-people@ai.ai.mit.EDU Subject: Re: A protocol for distribution lists and their managements Date: Fri, 11 Jul 86 23:19:13 -0700 From: Einar Stefferud [original msg to Header-People omitted] thank you for reporting this problem. the offending address has been suspended. Date: Sat, 12 Jul 86 03:07:49 EDT From: Communications Satellite Subject: Msg of Saturday, 12 July 1986 03:03-EDT To: "stef@nrtc-gremlin"@nrtc-gremlin Resent-To: postmaster@mc.lcs.mit.EDU Resent-Date: Sat, 12 Jul 86 00:32:22 -0700 Resent-From: Einar Stefferud ============ A copy of your message is being returned, because: =========== ------ 1 error trying to parse the file DSK:KSC;HEADER PEOPLE --L62 EVAL error: Bad SITE spec - "@WISCVM" In list: (HEADER%UMASS.BITNET @WISCVM) ------ ============ Failed message follows: ============ To: header-people@ai.ai.mit.EDU Subject: Its not the fault of Internet Mail -- Re: AMIGO Date: Fri, 11 Jul 86 23:50:03 -0700 From: Einar Stefferud [original msg to Header-People omitted] doubtless someone on BUG-MAIL will correct me if i'm wrong, but i'm pretty sure this error is due to COMSAT hiccuping, and does not reflect reality.  Date: Tue, 15 Jul 86 18:12:43 EDT From: Richard Mlynarik Subject: host-lookup lossage To: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].70566.860715.MLY> I typed t to readdress something I was sending with :mail The new address I specified was "foo@think" I got: "Error; Ambiguous site spec. "think"=>{think.arpa,think.com}" think.arpa and think.com are the same machine (according to the :host program, at least)  Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU 7 Jul 86 13:40:21 EDT Date: Mon, 7 Jul 1986 13:40 EDT Message-ID: From: Rob Austein To: "Pandora B. Berman" Cc: BUG-MAIL@AI.AI.MIT.EDU Subject: something's still broken Date: Monday, 7 July 1986 01:07-EDT From: David A. Moon You could check by sending a message to a host that is not up, waiting for it to get queued, and then doing m-X Show Queue. The other thing that is not obvious is that messages for Internet hosts that can't be sent immediately from MX, ML, and MD are being queued on MC rather than the local machine. On MX this is a little silly because the machine can in fact speak TCP, but then we are lying to it by telling it to gate through MC. MX is just following orders (appropriate for a machine named after a warhead...). Look in MC: SRA; WHORFN BABYL for results of M-X Show Queue$ done after sending messages to DM and AI-11 from MX.  Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM by AI.AI.MIT.EDU 7 Jul 86 01:26:51 EDT Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 36298; Mon 7-Jul-86 01:08:13 EDT Date: Mon, 7 Jul 86 01:07 EDT From: David A. Moon Subject: something's still broken To: Pandora B. Berman cc: SRA@XX.LCS.MIT.EDU, BUG-MAIL@AI.AI.MIT.EDU In-Reply-To: <[AI.AI.MIT.EDU].66173.860707.CENT> Message-ID: <860707010740.3.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Mon, 7 Jul 86 00:04:46 EDT From: "Pandora B. Berman" [BUG-FOO removed] Date: Thu, 3 Jul 1986 12:26 EDT From: Rob Austein To: "Pandora B. Berman" Cc: BUG-FOO@AI.AI.MIT.EDU, BUG-MAIL@AI.AI.MIT.EDU Subject: something's broken You might think COMSAT was broken but you'd be wrong. LUNAR was broken. I fixed the version in AI: MOON; (since the other version is broken on -all- ITSs nowadays) and installed on all five machines. well, i tried Show Queue on MX again. MX still has a 43-block LISTS MSGS, but still produces the following greatly informative queue listing: ---------- Received: from MX.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 6 JUL 86 23:47:46 EDT CENT@MX.LCS.MIT.EDU (Sent by CENT'@MX.LCS.MIT.EDU) 07/06/86 23:47:29 Re: Request results To: CENT at MX.LCS.MIT.EDU ---------- I looked at LIST QUEUE with tools that I barely remembered how to use and it seems to be empty. I think there are no messages queued on MX. Hardly surprising since there are no longer four billion people all sending their mail through that machine. Evidently someone broke Comsat so that it doesn't garbage collect LISTS MSGS if there is nothing in it. You could check by sending a message to a host that is not up, waiting for it to get queued, and then doing m-X Show Queue.  Date: Mon, 7 Jul 86 00:04:46 EDT From: "Pandora B. Berman" Subject: something's still broken To: SRA@XX.LCS.MIT.EDU cc: BUG-FOO@AI.AI.MIT.EDU, BUG-MAIL@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].66173.860707.CENT> Date: Thu, 3 Jul 1986 12:26 EDT From: Rob Austein To: "Pandora B. Berman" Cc: BUG-FOO@AI.AI.MIT.EDU, BUG-MAIL@AI.AI.MIT.EDU Subject: something's broken You might think COMSAT was broken but you'd be wrong. LUNAR was broken. I fixed the version in AI: MOON; (since the other version is broken on -all- ITSs nowadays) and installed on all five machines. well, i tried Show Queue on MX again. MX still has a 43-block LISTS MSGS, but still produces the following greatly informative queue listing: ---------- Received: from MX.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 6 JUL 86 23:47:46 EDT CENT@MX.LCS.MIT.EDU (Sent by CENT'@MX.LCS.MIT.EDU) 07/06/86 23:47:29 Re: Request results To: CENT at MX.LCS.MIT.EDU ----------  Date: Sat, 5 Jul 86 21:35:44 EDT From: David Chapman Subject: headers To: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].65932.860705.ZVONA> This can't be right. Why does one Devon get %MC and not the other? And how about me? Date: Wed, 2 Jul 86 07:15:42 EDT From: Devon S. McCullough To: ZVONA at MX.LCS.MIT.EDU cc: DEVON at MX.LCS.MIT.EDU ...  Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU 3 Jul 86 15:24:33 EDT Date: Thu, 3 Jul 1986 15:25 EDT Message-ID: From: Rob Austein To: "Pandora B. Berman" Cc: BUG-MAIL@AI.AI.MIT.EDU Subject: comsat continuous fondling Penny, This is still another symptom of the same scheduler (or clock or whatever) bug. Basicly it thinks time runs faster than it used to. I agree that it should be fixed. I don't have time to do it at the moment. I doubt it is anything I did, more likely a result of the modifications in the scheduler code about a year ago to cope with MC's massive mail overloading. I'll look at it when I get a chance, but don't hold your breath, I've got other things I have to do, not all of them related to ITS. --Rob  Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU 3 Jul 86 12:26:06 EDT Date: Thu, 3 Jul 1986 12:26 EDT Message-ID: From: Rob Austein To: "Pandora B. Berman" Cc: BUG-FOO@AI.AI.MIT.EDU, BUG-MAIL@AI.AI.MIT.EDU Subject: something's broken In-reply-to: Msg of 2 Jul 1986 22:47-EDT from "Pandora B. Berman" You might think COMSAT was broken but you'd be wrong. LUNAR was broken. I fixed the version in AI: MOON; (since the other version is broken on -all- ITSs nowadays) and installed on all five machines.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 2 JUL 86 23:11:59 EDT Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 2 JUL 86 22:14:58 EDT Date: Wed, 2 Jul 86 22:16:10 EDT From: "Pandora B. Berman" Subject: comsat continuous fondling To: BUG-MAIL%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU Message-ID: <[MX.LCS.MIT.EDU].931002.860702.CENT> comsat stutters when it can't deliver a piece of mail locally (usually the cause is directory full). in this condition, comsat continually tries to deliver the mail, about once a second, until it runs through its 200 tries (or whatever the number is), and then gives up and coughs the msg back to the author -- see the ostats files for the past day or two on MX. this is broken; comsat didn't used to be this stupid. i'm pretty sure that the previous, more rational strategy, was to try once, get this dir-full temporary error, and then give up for a minute, or until the next time the local machine rose to the top of the queued-mail-machines list. comsat stopped following this saner algorithm sometime in the past year or so; perhaps some of the mods preparatory to the domain-world move fucked over the code? whatever the cause, this should be fixed.  Date: Wed, 2 Jul 86 23:02:30 EDT From: "Pandora B. Berman" Subject: i think it's comsat To: BUG-MAIL@AI.AI.MIT.EDU cc: BUG-FOO@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].65064.860702.CENT> ---------- Received: from MD.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 2 JUL 86 22:55:16 EDT CENT@MD.LCS.MIT.EDU (Sent by CENT'@MD.LCS.MIT.EDU) 07/02/86 22:54:28 Re: Request results To: CENT at MD.LCS.MIT.EDU ---------- well, MD's LISTS MSGS was under 1 block and produced the above queued-msg list. manual inspection of the file shows it contains english for only one msg, the july 1 monthly msg from Puff to Magic-Dragon-Keeper about the ersatz accounting files. the thing is, Magic-Dragon-Keeper@MD forwards to Magic-Dragon-Keeper@MC, and i received the msg in question on 1 July. so i think the problem is that COMSAT doesn't clean up after itself sufficiently thoroughly.  Date: Wed, 2 Jul 86 22:47:28 EDT From: "Pandora B. Berman" Subject: something's broken To: BUG-MAIL@AI.AI.MIT.EDU cc: BUG-FOO@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].65056.860702.CENT> ---------- Received: from MX.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 2 JUL 86 22:40:27 EDT CENT@MX.LCS.MIT.EDU (Sent by CENT'@MX.LCS.MIT.EDU) 07/02/86 22:39:40 Re: Request results To: CENT at MX.LCS.MIT.EDU ---------- the above is the entire msg that i just received when i tried to list COMSAT's queue on MX. this is absurd; LISTS MSGS there is 40 blocks long. either the lunar library is broken on MX (works fine on AI), or comsat is lying to M-X Show Queue about its contents, or MX's COMSAT has regressed to infancy and forgotten how to clean up its messes. please fix.  Date: Wed, 2 Jul 86 21:40:00 EDT From: "Pandora B. Berman" Subject: old AIList mail To: "GAVAN@LADY-BIRD.SCRC.SYMBOLICS.COM"@AI.AI.MIT.EDU cc: BUG-COMSAT@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].65016.860702.CENT> Date: Tue, 1 Jul 86 17:59 EDT From: Gavan Duffy Subject: [AIList-REQUEST@SRI-AI: AIList Digest V4 #43] To: Bug-Comsat@MIT-MC.ARPA Apparently, The old MC received this message on March 4, became MX and sent it to the new MC on July 1. How much more mail is hiding inside the bowels of MX? as was announced in an ARPANET-BBOARDS msg a couple weeks ago, (the old) MC swallowed quite a bit of mail this spring due to COMSAT problems. now that COMSAT has been fixed, we are retransmitting this mail, at a somewhat leisurely pace to avoid overloading either COMSAT or anyone's mailbox. we hope to finish this project sometime in the next week. a copy of the announcement is available if you missed it.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 1 JUL 86 18:04:45 EDT Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM by MC.LCS.MIT.EDU 1 Jul 86 18:02:29 EDT Received: from EAGLE.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 33866; Tue 1-Jul-86 17:59:29 EDT Date: Tue, 1 Jul 86 17:59 EDT From: Gavan Duffy Subject: [AIList-REQUEST@SRI-AI: AIList Digest V4 #43] To: Bug-Comsat@MIT-MC.ARPA Message-ID: <860701175917.7.GAVAN@EAGLE.SCRC.Symbolics.COM> Apparently, The old MC received this message on March 4, became MX and sent it to the new MC on July 1. How much more mail is hiding inside the bowels of MX? Received: from SCRC-RIVERSIDE.ARPA by LADY-BIRD.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 4834; Tue 1-Jul-86 08:01:36-EDT Received: from REAGAN.AI.MIT.EDU (MIT-REAGAN.ARPA) by RIVERSIDE.SCRC.Symbolics.COM via INTERNET with SMTP id 31282; 1 Jul 86 08:01:03 EDT Received: from MC.LCS.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 37982; Tue 1-Jul-86 08:03:37-EDT Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 1 JUL 86 07:50:36 EDT Received: from SRI-AI.ARPA by MC.LCS.MIT.EDU 4 Mar 86 07:03:36 EST Date: Tue 4 Mar 1986 00:12-PST From: AIList Moderator Kenneth Laws Reply-to: AIList@SRI-AI US-Mail: SRI Int., 333 Ravenswood Ave., Menlo Park, CA 94025 Phone: (415) 859-6467 Subject: AIList Digest V4 #43 To: AIList@SRI-AI ... ad nauseum  Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU 1 Jul 86 16:26:22 EDT Date: Tue, 1 Jul 1986 16:27 EDT Message-ID: From: Rob Austein To: Ken Harrenstien Cc: BUG-COMSAT@AI.AI.MIT.EDU, JAR@AI.AI.MIT.EDU Subject: [COMSAT: Msg of Sunday, 29 June 1986 14:59-EDT] In-reply-to: Msg of 1 Jul 1986 02:22-EDT from Ken Harrenstien Huh, that (FOO @BAR) hack is useful to know about. Maybe I should teach the TECO code I'm writing to add "@" signs where appropriate. Now if only we could get people creating -new- lists to use this syntax and fully specified hostnames we'd be all set....  Received: from CSNET-RELAY.ARPA by AI.AI.MIT.EDU 1 Jul 86 09:20:22 EDT Received: from bu-cs.bu.edu by CSNET-RELAY.ARPA id aa09289; 1 Jul 86 9:18 EDT Received: by bu-cs.bu.edu (5.31/4.7) id AA12026; Tue, 1 Jul 86 09:15:20 EDT Return-Path: Received: by buit1.bu.edu (5.31/4.7) id AA29099; Tue, 1 Jul 86 09:15:07 EDT Date: Tue, 1 Jul 86 09:15:07 EDT From: Jon Solomon Message-Id: <8607011315.AA29099@buit1.bu.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 Tue, 1 Jul 86 00:34:34 EDT Subject: [Mailer@BBNA.ARPA: Message of 26-Jun-86 03:19:55] The point is I shouldn't be getting this message at all. It belongs in the -REQUEST box of the list. If someone has time to hack on it this would be a useful fix for COMSAT. --jsol  Date: Tue, 1 Jul 86 02:22:21 EDT From: Ken Harrenstien Subject: [COMSAT: Msg of Sunday, 29 June 1986 14:59-EDT] To: SRA@XX.LCS.MIT.EDU cc: JAR@AI.AI.MIT.EDU, BUG-COMSAT@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].63983.860701.KLH> In general you should be using an address of the form (FOO @BAR) in preference to (FOO BAR) because the first form forces COMSAT to interpret BAR as a hostname (and complain if it's unknown). The second form merely treats BAR as some strange R-OPTION if it is not a known hostname.  Date: Tue, 1 Jul 86 00:34:34 EDT From: "Pandora B. Berman" Subject: [Mailer@BBNA.ARPA: Message of 26-Jun-86 03:19:55] To: jsol%BU-cs.BU.EDU@CSNET-RELAY.ARPA cc: HEADER-PEOPLE-REQUEST@AI.AI.MIT.EDU, BUG-MAIL@AI.AI.MIT.EDU, postmaster@BBNA.ARPA Message-ID: <[AI.AI.MIT.EDU].63911.860701.CENT> Date: Sun, 29 Jun 86 20:11:28 EDT From: Jon Solomon To: header-people-request@MC.LCS.MIT.EDU, bug-mail@MC.LCS.MIT.EDU Subject: [Mailer@BBNA.ARPA: Message of 26-Jun-86 03:19:55] I am getting mail for SOLOMON@MIT for some reason. I am known there as jsol and jsol alone. This one in particular looks like a mailer bug. Date: Sun 29 Jun 86 03:38:45-EDT From: The Mailer Daemon To: solomon@AI.AI.MIT.EDU Subject: Message of 26-Jun-86 03:19:55 Message undeliverable and dequeued after 3 days: *PS:MAIL.TXT@A.BBN.COM.#Internet: Append access required ------------ Received: from BBN.COM by A.BBN.COM; Thu 26 Jun 86 03:19:58-EDT Received: from ai.ai.mit.edu by BBN.COM id a009654; 26 Jun 86 3:17 EDT Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 26 JUN 86 01:39:21 EDT Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 26 JUN 86 01:40:32 EDT Received: from gjetost.wisc.edu by MC.LCS.MIT.EDU 26 Feb 86 18:10:35 EST Date: Wed, 26 Feb 86 17:10:05 cst From: Marvin Solomon Received: by gjetost.wisc.edu; Wed, 26 Feb 86 17:10:05 cst Reply-To: solomon@CRYS.WISC.EDU To: header-people@MC.LCS.MIT.EDU Subject: Re: Mail looping [original msg text omitted] you are getting mail for SOLOMON@ITS. i haven't checked, but presumably there is no address SOLOMON defined in AI's mailing list file. so COMSAT sends any mail for SOLOMON to everyone having that last name in his inquir entry, on the theory that maybe one of them is the SOLOMON in question; this is a feature. why this error msg was going to SOLOMON@AI is another matter entirely. the original msg was sent by SOLOMON@.WISC.EDU, and includes a proper-looking Reply-To: header. i think BBNA coughed when it consed up this error msg, stripping the host info off the Reply-To: header and replacing it with the most recent host the mail had come from, AI. this is a bug at BBNA and should be fixed. for that matter, maybe someone at BBNA should tell BTHOMAS to fix the access on his mail file so he can receive mail; on the other hand, perhaps his mail file is shut down that way, so he can't get mail, deliberately and for a legit reason.  Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU 30 Jun 86 14:43:18 EDT Date: Mon, 30 Jun 1986 14:42 EDT Message-ID: From: Rob Austein To: Jonathan A Rees Cc: BUG-COMSAT@AI.AI.MIT.EDU Subject: [COMSAT: Msg of Sunday, 29 June 1986 14:59-EDT] In-reply-to: Msg of 29 Jun 1986 16:12-EDT from Jonathan A Rees Date: Sunday, 29 June 1986 16:12-EDT From: Jonathan A Rees To: BUG-COMSAT@AI.AI.MIT.EDU Re: [COMSAT: Msg of Sunday, 29 June 1986 14:59-EDT] Can someone tell me why I got this error message? The distribution file MC:JAR;SCHEME LIST clearly says (HARVEY%PCO CISL-SERVICE-MULTICS). It shouldn't be trying to send to MC at all. - Jonathan Date: Sun, 29 Jun 86 15:04:14 EDT From: Communications Satellite To: JAR at AI.AI.MIT.EDU Re: Msg of Sunday, 29 June 1986 14:59-EDT ============ A copy of your message is being returned, because: ============ "HARVEY%PCO" at MC.LCS.MIT.EDU is an unknown recipient. This name came from the expansion of (@FILE [JAR;SCHEME LIST]), from SCHEME ============ Failed message follows: ============ CISL-SERVICES-MULTICS no longer exists. The NIC merged their host table entry in with MIT-MULTICS (because MIT-MULTICS has agreed to handle mail for them). The TECO code that merges the MIT and NIC tables doesn't handle this case correctly (and probably never will, long story). So as far as the ITS machines are concerned the hostname CISL-SERVICES-MULTICS no longer exists. Sorry. You should change the offending address to MIT-MULTICS.ARPA, although in this case that may not work (since MULTICS may not know how to forward to PCO, wherever that is). I've been working on some code that can be run over mailing list files to cannonicalize hostnames in that file. It takes the form of some TECO code (to isolate and mark hostnames in the file) and some C code to do the actual cannonicalization. It's working for 20x mailing list files, needs a little work before it can be used on ITS mailing list files because I've never used TECO to parse Lisp structured files before. We will probably need this Real Soon Now because there has been a lot of talk of removing -all- the short nicknames from the NIC host table.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 29 JUN 86 20:10:13 EDT Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 29 Jun 86 20:09:27 EDT Received: from bu-cs.bu.edu by CSNET-RELAY.ARPA id ab00203; 29 Jun 86 20:14 EDT Received: by bu-cs.bu.edu (5.31/4.7) id AA20565; Sun, 29 Jun 86 20:11:39 EDT Return-Path: Received: by buit1.bu.edu (5.31/4.7) id AA27402; Sun, 29 Jun 86 20:11:28 EDT Date: Sun, 29 Jun 86 20:11:28 EDT From: Jon Solomon Message-Id: <8606300011.AA27402@buit1.bu.edu> To: header-people-request@MC.LCS.MIT.EDU, bug-mail@MC.LCS.MIT.EDU Subject: [Mailer@BBNA.ARPA: Message of 26-Jun-86 03:19:55] I am getting mail for SOLOMON@MIT for some reason. I am known there as jsol and jsol alone. This one in particular looks like a mailer bug. Return-Path: Date: Sun 29 Jun 86 03:38:45-EDT From: The Mailer Daemon To: solomon@AI.AI.MIT.EDU Subject: Message of 26-Jun-86 03:19:55 Message undeliverable and dequeued after 3 days: *PS:MAIL.TXT@A.BBN.COM.#Internet: Append access required ------------ Received: from BBN.COM by A.BBN.COM; Thu 26 Jun 86 03:19:58-EDT Received: from ai.ai.mit.edu by BBN.COM id a009654; 26 Jun 86 3:17 EDT Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 26 JUN 86 01:39:21 EDT Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 26 JUN 86 01:40:32 EDT Received: from gjetost.wisc.edu by MC.LCS.MIT.EDU 26 Feb 86 18:10:35 EST Date: Wed, 26 Feb 86 17:10:05 cst From: Marvin Solomon Message-Id: <8602262310.AA01092@gjetost.wisc.edu> Received: by gjetost.wisc.edu; Wed, 26 Feb 86 17:10:05 cst Reply-To: solomon@CRYS.WISC.EDU To: header-people@MC.LCS.MIT.EDU Subject: Re: Mail looping ...I suggest that each SUB-LIST exploder also replace the Message-ID with a new Message-ID. What if I accidentally get two compies of a message? If they've come through different forwarders there'll be no way for my mail reader do detect this condition and delete excess copies. The problem is worse than you indicate. I'm less worried about you being annoyed by seeing the same message twice than I am about the network being fooded due to a cycle in mailing lists (which, by the way, could result in you getting hundreds of copies of the message). Suppose the list LISTA@HOSTA contains LISTB@HOSTB (along with hundred of other addresses) and LISTB@HOSTB contains LISTA@HOSTA. Suppose I send a message to LISTA@HOSTA. Under the proposed scheme, HOSTA would put on its own message id, say mid1, and send copies to all members of the list, including LISTB@HOSTB. HOSTB would replace mid1 with its own message-id (say mid2) and forward a copy to LISTA@HOSTA. The HOSTA exploder wouldn't recognize the message as one it sent, so it would strip mid2 and replace it with mid3 and send it back to HOSTB. The message would bop back and forth forever, each time generating hundreds of copies. How about this alternative: Each exploder maintains a list of message-id's of all messages it's exploded in recent history (a couple of days should be plenty), and refuses to resend a message with an id on the list. If EITHER of the exploders in the above scenario followed this algorithm, the loop is broken, unless the other exploder either (1) held on to a message for a very long time before relaying it (long enough for the "smart" exploder to forget the message) or (2) messed with the message-id. In case (1), at least the looping would be very slow. In case (2), I fail to see how any solution would work (short of some sort of hashing on the message body). As I see it, the moral of the story is Nobody should EVER mess with a Message-id when relaying mail. (Adding a Message-id if none is there is a different matter). -------  Date: Sun, 29 Jun 86 16:12:11 EDT From: Jonathan A Rees Subject: [COMSAT: Msg of Sunday, 29 June 1986 14:59-EDT] To: BUG-COMSAT@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].63337.860629.JAR> Can someone tell me why I got this error message? The distribution file MC:JAR;SCHEME LIST clearly says (HARVEY%PCO CISL-SERVICE-MULTICS). It shouldn't be trying to send to MC at all. - Jonathan Date: Sun, 29 Jun 86 15:04:14 EDT From: Communications Satellite To: JAR at AI.AI.MIT.EDU Re: Msg of Sunday, 29 June 1986 14:59-EDT ============ A copy of your message is being returned, because: ============ "HARVEY%PCO" at MC.LCS.MIT.EDU is an unknown recipient. This name came from the expansion of (@FILE [JAR;SCHEME LIST]), from SCHEME ============ Failed message follows: ============ Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 29 JUN 86 14:59:40 EDT Date: Sun, 29 Jun 86 14:58:30 EDT From: Jonathan A Rees Subject: [INGRIA@G.BBN.COM: Scheme for LISPM] To: INGRIA@BBNG.ARPA cc: SGR@SCRC-STONY-BROOK.ARPA, Scheme@MC.LCS.MIT.EDU In-reply-to: Msg of Fri 27 Jun 86 17:02 EDT from Stephen G. Rowley Message-ID: <[AI.AI.MIT.EDU].63300.860629.JAR> Date: Thu, 26 Jun 1986 16:47 EDT Message-ID: From: INGRIA@G.BBN.COM To: INFO-LISPM@MC.LCS.MIT.EDU Subject: Scheme for LISPM Does anyone have an implementation of Scheme that runs on LISPMs? It would be useful for us to have a version that runs on Rel6 on 36XXs. Thanks in advance. I wrote one last summer. It's not great for development, since there are no debugging facilities besides TRACE, but it works. It is written in Common Lisp, but it has been comditionalized to make it also work in Rel 6 Symbolics Common Lisp (which is full of bugs). If you're at BBN, you should contact Don Allen and get a copy from him. Otherwise contact me (JAR@MIT-AI) and I'll give you more information. Jonathan  Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU 24 Jun 86 12:05:52 EDT Date: Tue, 24 Jun 1986 12:07 EDT Message-ID: From: Rob Austein To: David Vinayak Wallace Cc: BUG-comsat@AI.AI.MIT.EDU Subject: @'s in @file's In-reply-to: Msg of 24 Jun 1986 03:13-EDT from David Vinayak Wallace Date: Tuesday, 24 June 1986 03:13-EDT From: David Vinayak Wallace To: BUG-comsat@AI.AI.MIT.EDU Re: @'s in @file's This shouldn't have lost as it did ... "DM@UNIX.BBN.COM" at AI.AI.MIT.EDU is an unknown recipient. This name came from the expansion of ... "FERBERM@YALEVMX.ARPA" at AI.AI.MIT.EDU is an unknown recipient. This name came from the expansion of ... UNIX.BBN.COM and YALEVMX.ARPA are not in the host tables. Either somebody screwed up adding those addresses or the NIC (at the request of BBN and YALE, I would imagine, judging from recent history and the demise of THINK as a nickname for THINK.COM) has removed those names. This, btw, has been a trend recently. Short names are being phased out of the NIC tables. Not en masse, yet, but I don't expect that day is too far off. When COMSAT can't find a hostname it trys the entire string as a local name on the off-chance that somebody was braindamaged enough to put an "@" into a local mailbox name. This is in the same catagory of bending over backwards as delivering mail to unknown unames to GUESTn; uname MAIL. I have been told that This Is A Feature. Certainly it is harmless since it is quite clear that what COMSAT is really objecting to is the hostnames.  Received: from MX.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 24 JUN 86 03:13:59 EDT Date: Tue, 24 Jun 86 03:13:42 EDT From: David Vinayak Wallace Subject: @'s in @file's To: BUG-comsat@AI.AI.MIT.EDU Message-ID: <[MX.LCS.MIT.EDU].928937.860624.GUMBY> This shouldn't have lost as it did (except for the first one): Date: Sun, 22 Jun 86 00:25:33 EDT From: Communications Satellite To: Gumby at MC.LCS.MIT.EDU Re: Msg of Sunday, 22 June 1986 00:23-EDT ============ A copy of your message is being returned, because: ============ "HENRY-NEWS" at AI.AI.MIT.EDU is an unknown recipient. This name came from the expansion of (@FILE [GREGOR;LOCAL DEAD]), from LOCAL-DEAD-HEADS, from (@FILE [GREGOR;DEAD HEADS]), from DEAD-HEADS "DM@UNIX.BBN.COM" at AI.AI.MIT.EDU is an unknown recipient. This name came from the expansion of (@FILE [GREGOR;LOCAL DEAD]), from LOCAL-DEAD-HEADS, from (@FILE [GREGOR;DEAD HEADS]), from DEAD-HEADS "FERBERM@YALEVMX.ARPA" at AI.AI.MIT.EDU is an unknown recipient. This name came from the expansion of (@FILE [GREGOR;LOCAL DEAD]), from LOCAL-DEAD-HEADS, from (@FILE [GREGOR;DEAD HEADS]), from DEAD-HEADS ============ Failed message follows: ============  Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU 19 Jun 86 23:33:09 EDT Date: Thu 19 Jun 86 23:35:36-EDT From: Rob Austein Subject: HOSTS3 table and the KL's arpanet address To: ALAN@AI.AI.MIT.EDU cc: BUG-COMSAT@AI.AI.MIT.EDU, BUG-NETWRK@AI.AI.MIT.EDU In-Reply-To: <[AI.AI.MIT.EDU].59260.860619.ALAN> Message-ID: <12216211794.13.SRA@XX.LCS.MIT.EDU> Namespace teething pains. Nobody ever told Zermatt about the KL's Arpanet address. I just did (first emergency road test of the rodent free namespace editor). Assuming Zermatt gets around to dumping the new table before 4am, the table bug should be fixed. -------  Date: Thu, 19 Jun 86 22:48:58 EDT From: Alan Bawden To: SRA@AI.AI.MIT.EDU cc: BUG-COMSAT@AI.AI.MIT.EDU, BUG-NETWRK@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].59260.860619.ALAN> A lot of programs on the KL that use TCP were crashing (including COMSAT). I tracked this down to the fact that the latest HOSTS3 table does not include the KL's Internet address, only its Chaosnet address. I don't know exactly what all the other programs were doing (mostly random TCP servers), but COMSAT was trying to learn what the name of the machine it was running on was by looking 10.1.0.6 up in the HOSTS3 table. It wasn't there, so COMSAT died. I rolled HOSTS3 on the KL back to the previous version. I hope the -next- version has an Internet address for the KL...  Date: Thu, 19 Jun 86 19:58:28 EDT From: "Pandora B. Berman" Subject: old mail To: DAVIS@AI.AI.MIT.EDU cc: BUG-MAIL@AI.AI.MIT.EDU, BUG-SYSTEM@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].59198.860619.CENT> Date: Tue 17 Jun 86 15:57-EDT From: Randall Davis Subject: old mail To: bug-system%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU I've been getting old copies of info-space mailing list mailings (from Jan and now Fed) over the past couple of days. It's been happening roughly since the crash when the mail queue was damaged. When is the redundancy likely to end? Is there anything to be done to cut off the useless mail? this has nothing to do with OZ's mail queue, but is instead the result of the retransmission of mail lost on (the old) MC this spring, as announced in a msg to arpanet-bboards a few weeks ago (a copy is available if you missed it). you are fortunate to be on a mailing list which did not absolutely depend on MC as a transmission step and which chose to retransmit immediately, by other paths, those msgs which did not go through the first time. most recipients of this mail are seeing it for the first time; we regret that you are encoutering redundancy. the retransmission process should be completed in about another week.  Date: Sat, 14 Jun 86 13:36:38 EDT From: Rob Austein Subject: New DQXDEV installed To: BUG-COMSAT@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].56779.860614.SRA> This should speed up NAMES > compilation a bit (it only checks for new host tables every five minutes instead of every pass). Maybe. Installed on AI, MC, MX. Not a major disaster if ML and MD don't have it, only makes a difference for heavy traffic. --Rob  Date: Fri, 13 Jun 86 18:32:30 EDT From: "Pandora B. Berman" Subject: slow turn around To: "CWR@WHITE.SWW.SYMBOLICS.COM"@AI.AI.MIT.EDU cc: "BUG-MAILER@WHITE"@AI.AI.MIT.EDU, BUG-MAIL@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].56475.860613.CENT> Date: Fri, 13 Jun 86 10:00 PDT From: Craig W. Reynolds Subject: slow turn around To: Bug-Mailer@WHITE, Postmaster@MIT-MC.ARPA cc: cwr@WHITE Date: Fri, 13 Jun 86 05:08:09 EDT From: Communications Satellite [I'm not sure if this has anything to do with Bug-Mailer or if there is such an addressee as Postmaster@MIT-MC, but I'll give it a try.] (of course there's a postmaster@MC -- postmaster is a customary if not required address at internet hosts.) Gee, I hate to be picky, but isn't it a little excessive that it took six months for me to be notified that this message didn't get though? the retransmission of quite a few msgs which got lost on MC this spring was explained in a msg to ARPANET-BBOARDS a couple weeks ago; a copy of this msg is available if you missed it. BTW: I doubt very much that I actually typed those "\"s in the original version of the TO line. It looks like this has been ponging around the net for a while: To: "@SCRC-YUKON.ARPA:cwr@WHITE.SWW.Symbolics.COM"@SCRC-YUKON.ARPA cc: MAIL-MAINTAINERS%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU Error in input request file. Parsing error: Bad format. Line stopped at is: TO:""\\\\\\\"psych36@ucscc.uucp\\\\\\\"%ucbvax.edu"@MIT-MC.ARPA Message not sent and not queued;text of bad file follows: -------- NET-MAIL-FROM-HOST:30002424403 RETURN-PATH:@SCRC-YUKON.ARPA:cwr@WHITE.SWW.Symbolics.COM TO:""\\\\\\\"psych36@ucscc.uucp\\\\\\\"%ucbvax.edu"@MIT-MC.ARPA TEXT;-1 Received: from SCRC-YUKON.ARPA by MC.LCS.MIT.EDU 21 Jan 86 13:44:50 EST Received: from WHITE.SWW.Symbolics.COM by SCRC-YUKON.ARPA via CHAOS with CHAOS-MAIL id 189944; Tue 21-Jan-86 13:43:28-EST Received: from GREEN.SWW.Symbolics.COM by WHITE.SWW.Symbolics.COM via CHAOS with CHAOS-MAIL id 167761; Tue 21-Jan-86 10:43:51-PST Date: Tue, 21 Jan 86 10:44 PST From: Craig W. Reynolds Subject: facial animation/simulation  To: "\"psych36@ucscc.uucp\"%ucbvax.edu"@MIT-MC.ARPA cc: cwr@WHITE Supersedes: <860120144040.3.CWR@GREEN.SWW.Symbolics.COM>, <860120145811.5.CWR@GREEN.SWW.Symbolics.COM>, <860120184102.5.CWR@GREEN.SWW.Symbolics.COM> Message-ID: <860121104406.6.CWR@GREEN.SWW.Symbolics.COM> Fonts: CPTFONT, CPTFONTI, CPTFONTCB . . . COMSAT would not have inserted the "\"s. they must have been added before the msg reached an ITS.  Date: Wed, 11 Jun 86 00:09:02 EDT From: Lee Parks To: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].54923.860611.LSP> For some reason when I logged in this evening, :gmsgs (I presume it was :gmsgs) truncated my mail file to 0 blocks. I would be much obliged if it could be retrieved froma recent backup tape or otherwise. Thx. -lee  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 9 JUN 86 17:02:23 EDT Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM by MC.LCS.MIT.EDU 9 Jun 86 16:56:27 EDT Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 17907; Mon 9-Jun-86 16:08:46 EDT Date: Mon, 9 Jun 86 16:08 EDT From: David A. Moon Subject: MC:.MAIL.; To: Alan Bawden cc: BUG-COMSAT@MIT-MC.ARPA In-Reply-To: <[MC.LCS.MIT.EDU].14020.860609.ALAN> Message-ID: <860609160809.4.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Mon, 9 Jun 86 15:08:47 EDT From: Alan Bawden I just happened to be sitting here next to MC's system console when COMSAT died because .MAIL. got full. Given that in general nobody is using MC as their home machine, it could have been days before anyone noticed. This problem hadn't occured to me before. The directory was mostly full of OSTATS files. Make a PFTHMG DRAGON "DAILY" (or "WEEKLY"?) file that moves the OSTATS to another directory? Another idea we use at Symbolics is to make mailer problems send interactive messages (notifications) to a canned list of people and machines. Chaosnet SEND protocol is pretty easy to use.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 9 JUN 86 17:02:15 EDT Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM by MC.LCS.MIT.EDU 9 Jun 86 16:56:20 EDT Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 17906; Mon 9-Jun-86 16:08:34 EDT Date: Mon, 9 Jun 86 16:07 EDT From: David A. Moon Subject: MC:.MAIL.; To: Alan Bawden cc: BUG-COMSAT@MIT-MC.ARPA In-Reply-To: <[MC.LCS.MIT.EDU].14020.860609.ALAN> Message-ID: <860609160758.3.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Mon, 9 Jun 86 15:08:47 EDT From: Alan Bawden I just happened to be sitting here next to MC's system console when COMSAT died because .MAIL. got full. Given that in general nobody is using MC as their home machine, it could have been days before anyone noticed. This problem hadn't occured to me before. The directory was mostly full of OSTATS files. Make a PFTHMG DRAGON "DAILY" (or "WEEKLY"?) file that moves the OSTATS to another directory? Another idea we use at Symbolics is to make mailer programs send interactive messages (notifications) to a canned list of people and machines. Chaosnet SEND protocol is pretty easy to use.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 9 JUN 86 15:22:14 EDT Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 9 JUN 86 15:18:23 EDT Date: Fri, 6 Jun 86 18:21:50 EDT From: "Devon S. McCullough" Subject: This message ended up at MX, but inquire says it should go to AI To: BUG-MAIL@MX.LCS.MIT.EDU, BUG-COMSAT@MX.LCS.MIT.EDU Message-ID: <[MX.LCS.MIT.EDU].924965.860606.DEVON> Date: Fri, 6 Jun 86 00:56:30 EDT From: "Devon S. McCullough" To: DEVON%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU Message-ID: <[MX.LCS.MIT.EDU].924828.860606.DEVON> test So something is still broken. Once again I ran INQUIR and set the "changed" bit without changing anything, in hopes of fixing this. I am sure there are others who may be wondering why they aren't getting very much mail lately, since some mail ends up at AI, and some at MX.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 9 JUN 86 15:07:36 EDT Date: Mon, 9 Jun 86 15:08:47 EDT From: Alan Bawden Subject: MC:.MAIL.; To: BUG-COMSAT@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].14020.860609.ALAN> I just happened to be sitting here next to MC's system console when COMSAT died because .MAIL. got full. Given that in general nobody is using MC as their home machine, it could have been days before anyone noticed. This problem hadn't occured to me before. The directory was mostly full of OSTATS files.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 6 JUN 86 00:34:29 EDT Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 6 JUN 86 00:34:07 EDT Date: Fri, 6 Jun 86 00:33:58 EDT From: David Vinayak Wallace Subject: bizarre mail To: BUG-MAIL@MX.LCS.MIT.EDU In-reply-to: Msg of Thu 5 Jun 86 14:57:00 cdt from Joe Ramey Message-ID: <[MX.LCS.MIT.EDU].924818.860606.GUMBY> It had to be a unix bug. To quote P.T. Barnum: "There's a Unix user born every minute."  Received: from MX.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 5 JUN 86 23:57:13 EDT Date: Thu, 5 Jun 86 23:56:55 EDT From: "Devon S. McCullough" To: ZVONA@AI.AI.MIT.EDU cc: BUG-INQUIR@AI.AI.MIT.EDU, BUG-MAIL@AI.AI.MIT.EDU In-reply-to: Msg of Mon 2 Jun 86 18:02:11 EDT from David Chapman Message-ID: <[MX.LCS.MIT.EDU].924800.860605.DEVON> Date: Mon, 2 Jun 86 18:02:11 EDT From: David Chapman To: DEVON at MX.LCS.MIT.EDU cc: BUG-MAIL at AI.AI.MIT.EDU, BUG-INQUIR at AI.AI.MIT.EDU Date: Sun, 1 Jun 86 20:27:22 EDT From: Devon S. McCullough To: BUG-MAIL%MX.LCS.MIT.EDU at MC.LCS.MIT.EDU my mail was being diverted to MX, so I ran INQUIR and changed my phone number, and this seemed to fix the problem. Bet I'm not the only one. Yeah, several people's INQUIR mail addresses got changed to MX bogusly. I don't know why; probably has to do with the databases being out of phase. You fixed it by changing your PHONE NUMBER?!!? I don't believe that. It is true. In other words, by making a random change I caused inquir to update my net address to the same thing it was before, which SEEMED to fix the problem. But your reply was misdelivered to MX, so I guess I'd better have my login file look for mail at both places and warn me.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 5 JUN 86 17:30:02 EDT Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 5 Jun 86 17:25:51 EDT Received: from ti-csl by csnet-relay.csnet id aa09782; 5 Jun 86 17:20 EDT Received: by tilde id AA16171; Thu, 5 Jun 86 14:57:00 cdt Date: Thu, 5 Jun 86 14:57:00 cdt From: Joe Ramey To: Bug-Mail%mc.lcs.mit.edu@CSNET-RELAY.ARPA, Postmaster%mc.lcs.mit.edu@CSNET-RELAY.ARPA, Postmaster%oz%xx.lcs.mit.edu@CSNET-RELAY.ARPA, Postmaster@CSNET-RELAY.ARPA Subject: Re: bizarre mail The problem is at ti-csl in the Unix pmdf software. I have reported the problem to cic@csnet-relay, and have just about fixed it here anyway. Let me know if this happens again. Joe Ramey Texas Instruments, Dallas  Date: Thu, 5 Jun 86 02:10:35 EDT From: "Pandora B. Berman" Subject: I received this message for some reason; looks like a mailer bug To: GYRO@AI.AI.MIT.EDU cc: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].51881.860605.CENT> yes, this is already known about.  Date: Thu, 5 Jun 86 01:55:37 EDT From: "Scott W. Layson" Subject: I received this message for some reason; looks like a mailer bug To: jkr@OZ.AI.MIT.EDU cc: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].51865.860605.GYRO> Date: Tue, 3 Jun 86 11:06:15 cdt From: John Maeda To: jkr%mit-oz at MC.LCS.MIT.EDU okay glen I hope this gets to you; I had written you a real l ong letter but I have no idea how to save it from this version of EMACS running on this uLTRIX machine ... (must be a ti-professional playing "multi-user") ... so I'm really ticked, I just hope this gets to you. jtm  Date: Wed, 4 Jun 86 19:31:36 EDT From: David Chapman Subject: Oh fiddlesticks To: BUG-MAIL@AI.AI.MIT.EDU, KFL@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].51501.860604.ZVONA> The canonical MX NAMES file was living on my directory on AI for the last two weeks. It never got copied back because MX was down and then I thought I'd done it and hadn't. I think that using SRCCOM I've gotten everything sorted out again.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 4 JUN 86 17:06:22 EDT Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 4 JUN 86 17:06:04 EDT Received: from MC.LCS.MIT.EDU by MX.LCS.MIT.EDU via Chaosnet; 4 JUN 86 17:03:05 EDT Received: from SRI-BISHOP.ARPA by MC.LCS.MIT.EDU 4 Jun 86 17:01:18 EDT Received: from XITLCATL.ARPA by SRI-BISHOP.ARPA via CHAOS with CHAOS-MAIL id 24660; Wed 4-Jun-86 14:02:03-PDT Date: Wed, 4 Jun 86 14:01 PDT From: David Chapman Subject: MC->MX .mail.;names > To: KFL%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU, BUG-MAIL%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU In-Reply-To: <[MX.LCS.MIT.EDU].923936.860602.KFL> Message-ID: <860604140151.1.ZVONA@XITLCATL.ARPA> Date: Mon, 2 Jun 86 21:13:02 EDT From: Keith F. Lynch To: BUG-MAIL%MX.LCS.MIT.EDU at MC.LCS.MIT.EDU cc: KFL%MX.LCS.MIT.EDU at MC.LCS.MIT.EDU I don't know if this is really a bug, but I just noticed that the .MAIL.; NAMES > files on MX claims to belong only on MC. ...Keith I could have sworn I fixed this. I suspect my change got over-written. Let's hope nothing else got lost.  Date: Wed, 4 Jun 86 01:44:12 EDT From: "Devon S. McCullough" To: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].51082.860604.DEVON> Things are still not quite right. MC never used to harass me with those worthless "Queued" messages which are now cluttering up my mailbox.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 3 JUN 86 15:39:25 EDT Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU 3 Jun 86 15:35:44 EDT Date: Tue, 3 Jun 1986 15:36 EDT Message-ID: From: Rob Austein Reply-To: Postmaster@MC.LCS.MIT.EDU To: Postmaster@CSNET-RELAY.ARPA, Bug-Mail@MC.LCS.MIT.EDU, Postmaster%oz@XX.LCS.MIT.EDU, Postmaster%ti-csl.csnet@CSNET-RELAY.ARPA, Postmaster%tilde%ti-csl.csnet@CSNET-RELAY.ARPA cc: Jonathan A Rees , Rich Wales , JKR@OZ.AI.MIT.EDU, scheme-lovers@LOCUS.UCLA.EDU, bugs@LOCUS.UCLA.EDU, John Maeda Subject: bizarre mail Ok folks, here's the postmortem. Apologies for the wide distribution. Any followup should be restricted to postmasters and bug-mail types. Just before noon today (EDT), three messages came in to MC.LCS.MIT.EDU from CSNET-RELAY.ARPA. The first two had the same text, a personal message intended for JKR@OZ.AI.MIT.EDU. The first was delivered to JKR, but the second was sent to SCHEME@MC.LCS.MIT.EDU. Here's a condensed version of COMSAT's log, translated slightly for them as don't like reading 36-bit octal host numbers. Log times reflect the gross amount of time required to deliver to the entire SCHEME mailing list. 11:48:52 InReq: 1 > 1; SPECS:{NET-MAIL-FROM: CSNET-RELAY.ARPA}{RTP:maeda%tilde%ti-csl.csnet@CSNET-RELAY.ARPA}{TL=629.}{HDR-FROM:maeda%tilde%ti-csl.csnet@CSNET-RELAY.ARPA} ID=<[MC.LCS.MIT.EDU].9933.860603> EXP->jkr@OZ.AI.MIT.EDU 11:49:01 InReq: 2 > 1; SPECS:{NET-MAIL-FROM: CSNET-RELAY.ARPA}{RTP:Asrivastava%ti-csl.csnet@CSNET-RELAY.ARPA}{TL=629.}{HDR-FROM:maeda%tilde%ti-csl.csnet@CSNET-RELAY.ARPA} ID=<[MC.LCS.MIT.EDU].9934.860603> EXP->SCHEME@MC.LCS.MIT.EDU 12:18:00 InReq: 1 > 1; SPECS:{NET-MAIL-FROM: CSNET-RELAY.ARPA}{RTP:maeda%tilde%ti-csl.csnet@CSNET-RELAY.ARPA}{TL=2134.}{HDR-FROM:maeda%tilde%ti-csl.csnet@CSNET-RELAY.ARPA} ID=<[MC.LCS.MIT.EDU].9935.860603> EXP->eln@OZ.AI.MIT.EDU The second entry is the bogus one. This says that the message had an SMTP return path "Asrivastava%ti-csl.csnet@CSNET-RELAY.ARPA" but the text was "From: maeda%tilde%ti-csl.csnet@CSNET-RELAY.ARPA". Either there's a bug (at ti-csl or csnet-relay) or somebody is spoofing. --Rob Austein (on behalf of Postmaster@MC.LCS.MIT.EDU)  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 3 JUN 86 12:58:39 EDT Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 3 JUN 86 12:56:42 EDT Date: Tue, 3 Jun 86 12:56:52 EDT From: Jonathan A Rees Subject: [maeda%tilde%ti-csl.csnet: forwarded] To: BUG-mail@MC.LCS.MIT.EDU, JKR@OZ.AI.MIT.EDU Message-ID: <[MX.LCS.MIT.EDU].924083.860603.JAR> I don't understand why this message got sent to me. I especially don't understand why there's no Received: line saying that OZ received the message from MC; apparently MC didn't send it to OZ like it should have. Is MC's mailer trying to be too smart about %'s or something? - Jonathan Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 3 JUN 86 12:16:47 EDT Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 3 Jun 86 11:48:51 EDT Received: from ti-csl by csnet-relay.csnet id ac20037; 3 Jun 86 11:38 EDT Received: by tilde id AA02583; Tue, 3 Jun 86 11:06:15 cdt Date: Tue, 3 Jun 86 11:06:15 cdt From: John Maeda To: jkr%mit-oz@MC.LCS.MIT.EDU okay glen I hope this gets to you; I had written you a real l ong letter but I have no idea how to save it from this version of EMACS running on this uLTRIX machine ... (must be a ti-professional playing "multi-user") ... so I'm really ticked, I just hope this gets to you. jtm  Received: from REAGAN.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 3 JUN 86 09:26:18 EDT Received: from MARLEY.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 34474; Tue 3-Jun-86 09:27:12-EDT Date: Tue, 3 Jun 86 09:26 EDT From: Daniel Weise Subject: [From: ??: FREE: queen size mattress] To: bug-comsat@AI.AI.MIT.EDU cc: dcb@AI.AI.MIT.EDU Message-ID: <860603092601.1.DANIEL@MARLEY.AI.MIT.EDU> What caused the lossage exhibited in the from field of this message. I am not DCB and he is not me. Would this occur if someone explicitly poked "daniel" into the from field? -- Daniel Received: from OZ.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 2 JUN 86 17:39:09 EDT Received: from AI.AI.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 2 Jun 86 17:33-EDT Date: Mon, 2 Jun 86 17:34:16 EDT From: Daniel Weise @AI.AI.MIT.EDU> Sender: DCB@AI.AI.MIT.EDU Subject: FREE: queen size mattress To: ALL-AI@OZ.AI.MIT.EDU cc: DCB@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].50278.860602.DCB> The mattress and box springs, etc., have been taken. The first person who responded to the message is taking the set; the next two are in line in case the first person (for whatever reason) decides not to follow through. So thanks, but please no more messages. dan  Received: from MX.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 2 JUN 86 21:13:12 EDT Date: Mon, 2 Jun 86 21:13:02 EDT From: "Keith F. Lynch" To: BUG-MAIL%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU cc: KFL%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU Message-ID: <[MX.LCS.MIT.EDU].923936.860602.KFL> I don't know if this is really a bug, but I just noticed that the .MAIL.; NAMES > files on MX claims to belong only on MC. ...Keith  Date: Mon, 2 Jun 86 18:02:11 EDT From: David Chapman To: DEVON@MX.LCS.MIT.EDU cc: BUG-MAIL@AI.AI.MIT.EDU, BUG-INQUIR@AI.AI.MIT.EDU In-reply-to: Msg of Sun 1 Jun 86 20:27:22 EDT from Devon S. McCullough Message-ID: <[AI.AI.MIT.EDU].50303.860602.ZVONA> Date: Sun, 1 Jun 86 20:27:22 EDT From: Devon S. McCullough To: BUG-MAIL%MX.LCS.MIT.EDU at MC.LCS.MIT.EDU my mail was being diverted to MX, so I ran INQUIR and changed my phone number, and this seemed to fix the problem. Bet I'm not the only one. Yeah, several people's INQUIR mail addresses got changed to MX bogusly. I don't know why; probably has to do with the databases being out of phase. You fixed it by changing your PHONE NUMBER?!!? I don't believe that.  Received: from MX.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 1 JUN 86 20:27:28 EDT Date: Sun, 1 Jun 86 20:27:22 EDT From: "Devon S. McCullough" To: BUG-MAIL%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU Message-ID: <[MX.LCS.MIT.EDU].923605.860601.DEVON> my mail was being diverted to MX, so I ran INQUIR and changed my phone number, and this seemed to fix the problem. Bet I'm not the only one.  Received: from MX.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 31 MAY 86 20:12:33 EDT Date: Sat, 31 May 86 20:13:12 EDT From: David Vinayak Wallace Subject: -fund- vs. -lisp- To: CENT@AI.AI.MIT.EDU cc: BUG-MAIL@AI.AI.MIT.EDU In-reply-to: Msg of Sat 31 May 86 02:19:01 EDT from Pandora B. Berman Message-ID: <[MX.LCS.MIT.EDU].923383.860531.GUMBY> Date: Sat, 31 May 86 02:19:01 EDT From: Pandora B. Berman why do the NAMES > files now all have -fundamental- mode lines at the top? it seems to me that they used to have -lisp- mode lines, which made indenting a whole lot easier. is there any reason why i should not change them to -lisp-? It makes things SIGNIFICANTLY faster for people who use lisp machines because the lisp machine tries to parse the file as it reads it. Also, it complains when saving it because the file has unbalanced parentheses (the ;'s in file names are interpreted as comment characters). I don't use a lisp machine to edit the mailer database, but in light of MC's login policy this I imagine most people will. If there were a way to specify local modes in zwei you could set the syntax of the [] characters to be the same as ", and you could use lisp mode.  Date: Sat, 31 May 86 15:40:05 EDT From: "Christopher C. Stacy" Subject: bogus host address in message To: GUMBY@AI.AI.MIT.EDU cc: BUG-COMSAT@AI.AI.MIT.EDU, postmaster@PREP.AI.MIT.EDU, postmaster@OZ.AI.MIT.EDU In-reply-to: Msg of Tue 27 May 86 07:22:37 EDT from David Vinayak Wallace Message-ID: <[AI.AI.MIT.EDU].49347.860531.CSTACY> I believe that PREP should have caught it before it went out. Certainly other hosts should not be altering the contents of a message (such as the header lines) they are processing.  Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU 31 May 86 13:50:10 EDT Date: Sat, 31 May 1986 13:49 EDT Message-ID: From: Rob Austein To: "Pandora B. Berman" Cc: BUG-MAIL@AI.AI.MIT.EDU Subject: the same old complaint In-reply-to: Msg of 31 May 1986 07:20-EDT from "Pandora B. Berman" Date: Saturday, 31 May 1986 07:20-EDT From: "Pandora B. Berman" To: BUG-MAIL@AI.AI.MIT.EDU Re: the same old complaint i finally got around to trying to send out the famous old badreqs. actually got two through. the next two, however, got waylaid by comsat and put out to pasture as BADREQs again. i have removed them back to CENT0;, where they are #3 and #4; COMSAT this morning (just before 7, i think) saw them as BADREQs 5 & 6. the problem is the same old size supposedly too large -- at 5 and 8 blocks. MX's LISTS MSGS is nice and small, its NAMES > isn't that large, not even the stats file was enormous. what's the state of the world here? does MX have all the latest bells and whistles? I found a couple more in MX:.MAIL.;. Once again, renaming them back to MAIL > worked just fine. Yes, MX's COMSAT has the 22. block fudge factor code nop'd out. I guess I'm going to have to go back and try to understand the (complicated) algorithm used to decide whether or not a file is too big. There are some magic numbers that appear to have been scaled downwards, or at least that is my guess on seeing something like: FUDING: 2 ;; Maximum # of foobars per dingbat (6) But that still doesn't explain why the size limit varies with the barometric pressure. Sigh.  Date: Sat, 31 May 86 07:20:11 EDT From: "Pandora B. Berman" Subject: the same old complaint To: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].49231.860531.CENT> i finally got around to trying to send out the famous old badreqs. actually got two through. the next two, however, got waylaid by comsat and put out to pasture as BADREQs again. i have removed them back to CENT0;, where they are #3 and #4; COMSAT this morning (just before 7, i think) saw them as BADREQs 5 & 6. the problem is the same old size supposedly too large -- at 5 and 8 blocks. MX's LISTS MSGS is nice and small, its NAMES > isn't that large, not even the stats file was enormous. what's the state of the world here? does MX have all the latest bells and whistles?  Date: Sat, 31 May 86 02:19:01 EDT From: "Pandora B. Berman" Subject: -fund- vs. -lisp- To: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].49142.860531.CENT> why do the NAMES > files now all have -fundamental- mode lines at the top? it seems to me that they used to have -lisp- mode lines, which made indenting a whole lot easier. is there any reason why i should not change them to -lisp-?  Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU 30 May 86 12:34:46 EDT Date: Fri, 30 May 1986 12:34 EDT Message-ID: From: Rob Austein To: "David A. Moon" Cc: BUG-COMSAT@AI.AI.MIT.EDU In-reply-to: Msg of 30 May 1986 12:28-EDT from "David A. Moon" From the date on it, I assume it is a relic of the couple of weeks when DQDEV was spazzing out and some forwarded mail was getting delivered locally instead. Not to worry unless you find an example more recent than mid-May.  Date: Fri, 30 May 86 12:28:33 EDT From: "David A. Moon" To: BUG-COMSAT@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].48728.860530.MOON> Any idea why there is a file AI:MOON;MOON MAIL when my mail has always been forwarded elsewhere?  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 30 MAY 86 11:35:23 EDT Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU 30 May 86 11:29:58 EDT Date: Fri 30 May 86 11:29:25-EDT From: Karen R. Sollins Subject: Re: KL COMSAT reconfigured To: JNC@XX.LCS.MIT.EDU cc: SRA@MC.LCS.MIT.EDU, pooor-mx@AI.AI.MIT.EDU, BUG-MAIL@MC.LCS.MIT.EDU In-Reply-To: <12210711153.11.JNC@XX.LCS.MIT.EDU> Message-ID: <12210836715.25.SOLLINS@XX.LCS.MIT.EDU> I assumed that the lcs.mit.edu subdomain did the right thing by MX. I think it should. -------  Received: from MX.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 30 MAY 86 01:20:07 EDT Date: Fri, 30 May 86 01:20:44 EDT From: David Vinayak Wallace Subject: COMSAT appears to be ignoring NOQC again To: SRA@XX.LCS.MIT.EDU cc: BUG-COMSAT@AI.AI.MIT.EDU In-reply-to: Msg of Thu 29 May 1986 17:36 EDT from Rob Austein Message-ID: <[MX.LCS.MIT.EDU].922777.860530.GUMBY> Date: Thu, 29 May 1986 17:36 EDT From: Rob Austein Date: Wednesday, 28 May 1986 07:30-EDT From: David Vinayak Wallace Re: COMSAT appears to be ignoring NOQC again What makes you say that? The only machine I've caught doing this is MC, which was doing it because somebody cleverly flushed my entry in NAMES >. Because I sent a bunch of messages and got queue notifications. Perhaps they were actually coming from MC? Next time it happens I'll look.  Date: Fri, 30 May 86 00:19:02 EDT From: Alan Bawden Subject: [DCP: moving new concentrator code to KL/MX] To: BUG-MINITS@MC.LCS.MIT.EDU cc: BUG-COMSAT@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].48420.860530.ALAN> This went to Bug-Random-Program for some reason. Bug-MINITS does exist on MC, so why didn't AI forward it there? Date: Thu, 29 May 86 17:51 EDT From: David C. Plummer To: David Chapman , BUG-MINITS at MIT-AI.ARPA cc: RDZ at MIT-AI.ARPA, CJL at MIT-AI.ARPA Re: moving new concentrator code to KL/MX Date: Thu, 29 May 86 13:29:52 EDT From: David Chapman I can't seem to make this work. The .install files call CHCOPY with MC in the command line. Does CHCOPY look at the host table, or does it have a hardwired theory of where MC is? I couldn't find out, because the sources are not where they were when it was assembled (OZ:). In any case, though MC and MX are both up, putting either on the command line caused CHCOPY to lose -- with a LOS in the one case and a Connection Refused in the other. Any ideas? It opens CHA:MC or some such and is completely inside the monitor. Maybe OZ has ancient chaos host tables?  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 30 MAY 86 00:00:39 EDT Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU 29 May 86 23:59:58 EDT Date: Thu 29 May 86 23:59:41-EDT From: "J. Noel Chiappa" Subject: Re: KL COMSAT reconfigured To: SRA@MC.LCS.MIT.EDU, sollins@XX.LCS.MIT.EDU, pooor-mx@AI.AI.MIT.EDU, BUG-MAIL@MC.LCS.MIT.EDU cc: JNC@XX.LCS.MIT.EDU In-Reply-To: <[MC.LCS.MIT.EDU].5519.860529.SRA> Message-ID: <12210711153.11.JNC@XX.LCS.MIT.EDU> IMP port 1/6 is perfectly legal to use; it's enabled and our sponsor is paying for it. I don't think that's an issue. The name might be. Any reason not to just have the LCS.MIT.EDU namespace do the right thing for MX, and if the NIC won't put it in their table, tough noogies? People should be using domains anyway. -------  Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU 29 May 86 17:37:20 EDT Date: Thu, 29 May 1986 17:36 EDT Message-ID: From: Rob Austein To: David Vinayak Wallace Cc: BUG-COMSAT@AI.AI.MIT.EDU Subject: COMSAT appears to be ignoring NOQC again In-reply-to: Msg of 28 May 1986 07:30-EDT from David Vinayak Wallace Date: Wednesday, 28 May 1986 07:30-EDT From: David Vinayak Wallace To: BUG-COMSAT@AI.AI.MIT.EDU Re: COMSAT appears to be ignoring NOQC again What makes you say that? The only machine I've caught doing this is MC, which was doing it because somebody cleverly flushed my entry in NAMES >.  Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU 29 May 86 17:36:18 EDT Date: Thu, 29 May 1986 17:35 EDT Message-ID: From: Rob Austein To: "Pandora B. Berman" Cc: BUG-COMSAT@AI.AI.MIT.EDU, user-a@MC.LCS.MIT.EDU In-reply-to: Msg of 28 May 1986 07:12-EDT from "Pandora B. Berman" Date: Wednesday, 28 May 1986 07:12-EDT From: "Pandora B. Berman" dave, i think you're excessively worried about COMSAT's competition for the load. as i said before, it's probably better to be stingy first and then be able to loosen up a little, rather than to attempt the reverse. but before going on this way i would like a little more in the way of hard data or at least well-backed opinion -from comsat maintainers- on just how empty a KS comsat needs/prefers to run -- well -- close to continuously. it seems a shameful waste to have one of four perfectly good ITSs tabu on the grounds that -we don't know how much load comsat can compete well with-. I don't think we should be putting any users at all on MC until things have settled down, which they have not. The TCP <-> Chaos protocol converter isn't being used much (OZ seems to be using the KL still), and I expect that to be a factor (20 OZoids TELNETing to SAIL via MC, Bandykin messages being transmitted by OZ's TCP-Chaos gateway hack, etcetera). There are other things that haven't settled down yet either (like the domain resolver hasn't been written yet, the doverspooler doesn't run on MC yet, etcetera). The avowed purpose of MC is to provide essential services that can't be gotten elsewhere. If, when we are all done loading the machine down, there are some cycles left over, fine. BUT WE AREN'T DONE YET. I doubt we will be able to give an informed answer to your question for months. In view of the amount of work it has been to evict the KL's user community (most of them tourists, for crissake), do you really want to create another community that we may have to flush in a few months?  Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU 29 May 86 17:23:47 EDT Date: Thu, 29 May 1986 17:20 EDT Message-ID: From: Rob Austein To: David Chapman cc: alan@AI.AI.MIT.EDU, bug-comsat@AI.AI.MIT.EDU Subject: User%MX@MC, right? In-reply-to: Msg of 27 May 1986 17:54-EDT from David Chapman Date: Tuesday, 27 May 1986 17:54-EDT From: David Chapman To: ALAN@AI.AI.MIT.EDU cc: BUG-COMSAT@AI.AI.MIT.EDU Re: User%MX@MC, right? So why isn't MX in the NIC host table or wherever the hell it has to be for Joe Foo at U Peoria to mail to it? Because it would take about a year to push through the paper work to get the NIC to admit we are allowed to use that IMP port. Not feasible.  Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU 29 May 86 17:11:47 EDT Date: Thu, 29 May 1986 17:10 EDT Message-ID: From: Rob Austein To: David Vinayak Wallace Cc: BUG-COMSAT@AI.AI.MIT.EDU, postmaster@OZ.AI.MIT.EDU, postmaster@PREP.AI.MIT.EDU Subject: bogus host address in message In-reply-to: Msg of 27 May 1986 07:22-EDT from David Vinayak Wallace Date: Tuesday, 27 May 1986 07:22-EDT From: David Vinayak Wallace There's no such host as OZ. One of these mailers should have caught it. Received: from MX.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; ... Received: from OZ.AI.MIT.EDU by MX.LCS.MIT.EDU via Chaosnet; ... Received: from PREP.AI.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; ... Received: by PREP.AI.MIT.EDU; Fri, 23 May 86 16:55:06 EDT Date: Fri, 23 May 86 16:55:06 EDT From: x@PREP.AI.MIT.EDU (Dean Elsner) To: gumby@oz Subject: PARC Interim 3-Lisp manual: borrowed from your shelf Well, prep didn't catch it because of the well-known bug in the way 4.2 sendmail and bind interact. Borax (for example) wouldn't have caught it either. This where it really should have happened, but there's no use beating a dead horse. The two COMSATs didn't reformat it, I assume, because it was an incoming network message. I'm not sure if this is a feature or not. I thought OZ's Chaos MAISER would have reformatted, but I guess I was wrong. The TCP MAISER would have, I think, but the Chaos MAISER is a much simpler beast.  Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU 29 May 86 02:25:46 EDT Date: Thu 29 May 86 02:24:42-EDT From: Rob Austein Subject: Re: previous message To: GUMBY@AI.AI.MIT.EDU cc: Moon@SCRC-STONY-BROOK.ARPA, BUG-COMSAT@AI.AI.MIT.EDU In-Reply-To: <[AI.AI.MIT.EDU].47748.860529.GUMBY> Message-ID: <12210475407.40.SRA@XX.LCS.MIT.EDU> Date: Thu, 29 May 86 02:09:59 EDT From: David Vinayak Wallace ... Because we're more efficient at MIT, COMSAT tries 200 times over a period of 10 minutes. It is not news that sometime in the last year or so COMSAT's scheduler broke and nobody noticed because of the extreme beating MC was taking. Or maybe these frisky little KS's have faster clocks. I assume this is the same bug as is causing the unmapping of LSR1 every 15 seconds. -------  Date: Thu, 29 May 86 02:09:59 EDT From: David Vinayak Wallace Subject: previous message To: Moon@SCRC-STONY-BROOK.ARPA cc: BUG-COMSAT@AI.AI.MIT.EDU In-reply-to: Msg of Wed 28 May 86 13:33 EDT from David A. Moon Message-ID: <[AI.AI.MIT.EDU].47748.860529.GUMBY> Date: Wed, 28 May 86 13:33 EDT From: David A. Moon Date: Wed, 28 May 86 06:35:20 EDT From: David Vinayak Wallace ... FAILED: OAF at MX.LCS.MIT.EDU; I gave up on sending this after 201 "temporary" errors. Failed message follows: It turns out this error was "Directory Full." I don't think that should be a temporary error. Why should someone on the other side of the galaxy get mail bounced back to them just because some slob's directory needs to be cleaned up? I think it's right for directory-full to be a temporary error, meaning try 200 times (over a period of a few days) before deciding it's permanent rather than giving up right away. Because we're more efficient at MIT, COMSAT tries 200 times over a period of 10 minutes.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 29 MAY 86 00:58:30 EDT Date: Thu, 29 May 86 00:58:10 EDT From: Rob Austein Subject: KL COMSAT reconfigured To: sollins@XX.LCS.MIT.EDU, pooor-mx@AI.AI.MIT.EDU, BUG-MAIL@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].5519.860529.SRA> The KL is now running a COMSAT configured as if it were a chaos-only machine. It uses MC (Chaos 3131) as its gateway. This will load the KS a little more for outgoing net traffic, but will do the right thing for headers (we are -not- going to get the NIC to put MX in the tables before the poor thing melts down) and is probably the right thing politically anyway, since it cuts down on the amount of (unapproved) traffic through IMP port 1/6. I haven't messed with FTPS or anything like that, so anybody who knows enough to talk to 10.1.0.6 will still win. --Rob  Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM by AI.AI.MIT.EDU 29 May 86 00:13:11 EDT Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 9904; Wed 28-May-86 13:38:54 EDT Date: Wed, 28 May 86 13:33 EDT From: David A. Moon Subject: previous message To: David Vinayak Wallace cc: BUG-COMSAT@AI.AI.MIT.EDU In-Reply-To: <[AI.AI.MIT.EDU].47147.860528.GUMBY> Message-ID: <860528133332.0.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Wed, 28 May 86 06:35:20 EDT From: David Vinayak Wallace Received: from MX.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 28 MAY 86 05:59:02 EDT Date: Wed, 28 May 86 05:57:56 EDT From: Communications Satellite Subject: Msg of Wednesday, 28 May 1986 05:49-EDT To: GUMBY@AI.AI.MIT.EDU Message-ID: <[MX.LCS.MIT.EDU].922205.860528> FAILED: OAF at MX.LCS.MIT.EDU; I gave up on sending this after 201 "temporary" errors. Failed message follows: ------- It turns out this error was "Directory Full." I don't think that should be a temporary error. Why should someone on the other side of the galaxy get mail bounced back to them just because some slob's directory needs to be cleaned up? I think it's right for directory-full to be a temporary error, meaning try 200 times (over a period of a few days) before deciding it's permanent rather than giving up right away.  Date: Wed, 28 May 86 07:30:01 EDT From: David Vinayak Wallace Subject: COMSAT appears to be ignoring NOQC again To: BUG-COMSAT@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].47167.860528.GUMBY>  Date: Wed, 28 May 86 07:12:19 EDT From: "Pandora B. Berman" To: ZVONA@AI.AI.MIT.EDU cc: BUG-COMSAT@AI.AI.MIT.EDU, user-a@MC.LCS.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].47162.860528.CENT> Date: Tue, 27 May 86 15:16:19 EDT From: David Chapman To: RDZ@MC.LCS.MIT.EDU cc: ACCOUNTS-NOTIFICATION@MC.LCS.MIT.EDU Date: Mon, 26 May 86 02:59:38 EDT From: Ramin Zabih To: ACCOUNTS-NOTIFICATION at MC.LCS.MIT.EDU I set the following account: Was: PSZ USER [OK] + ! ZF Peter Szolovits [Date Unknown] Is: PSZ USER [OK] + ! ZF Peter Szolovits [Date Unknown] [new password] This sets a bad precedent. Having told him he can get mail on MC, it's reasonable, but we should think hard and collectively before telling anyone else they can. dave, i think you're excessively worried about COMSAT's competition for the load. as i said before, it's probably better to be stingy first and then be able to loosen up a little, rather than to attempt the reverse. but before going on this way i would like a little more in the way of hard data or at least well-backed opinion -from comsat maintainers- on just how empty a KS comsat needs/prefers to run -- well -- close to continuously. it seems a shameful waste to have one of four perfectly good ITSs tabu on the grounds that -we don't know how much load comsat can compete well with-. limiting use is one thing, forbidding it is another. i am reminded of a bit out of Mad Magazine, years ago, i think comparing families of the time with the preceding generation: grandmother's house: living room furniture has slipcovers. grandmother told her kids, "Stay out of the living room. Don't you know the living room is for company?" mother's house: living room furniture has plastic covers over the slipcovers. mom announces, "Stay out of the living room. Don't you know the living room is for nobody?"  Date: Wed, 28 May 86 06:35:20 EDT From: David Vinayak Wallace Subject: previous message To: BUG-COMSAT@AI.AI.MIT.EDU In-reply-to: Msg of Wed 28 May 86 06:19:00 EDT from David Vinayak Wallace Message-ID: <[AI.AI.MIT.EDU].47147.860528.GUMBY> Received: from MX.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 28 MAY 86 05:59:02 EDT Date: Wed, 28 May 86 05:57:56 EDT From: Communications Satellite Subject: Msg of Wednesday, 28 May 1986 05:49-EDT To: GUMBY@AI.AI.MIT.EDU Message-ID: <[MX.LCS.MIT.EDU].922205.860528> FAILED: OAF at MX.LCS.MIT.EDU; I gave up on sending this after 201 "temporary" errors. Failed message follows: ------- It turns out this error was "Directory Full." I don't think that should be a temporary error.  Date: Wed, 28 May 86 06:19:00 EDT From: David Vinayak Wallace Subject: lost message To: OAF@AI.AI.MIT.EDU, BUG-COMSAT@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].47135.860528.GUMBY> Received: from MX.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 28 MAY 86 05:59:02 EDT Date: Wed, 28 May 86 05:57:56 EDT From: Communications Satellite Subject: Msg of Wednesday, 28 May 1986 05:49-EDT To: GUMBY@AI.AI.MIT.EDU Message-ID: <[MX.LCS.MIT.EDU].922205.860528> FAILED: OAF at MX.LCS.MIT.EDU; I gave up on sending this after 201 "temporary" errors. Failed message follows: ------- Received: from AI.AI.MIT.EDU by MX.LCS.MIT.EDU via Chaosnet; 28 MAY 86 05:49:52 EDT Date: Wed, 28 May 86 05:49:01 EDT From: David Vinayak Wallace Subject: KS-ITS mailing list To: KS-ITS-ONLY-PEOPLE@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].47124.860528.GUMBY> The KS's have arrived and ITS runs on them, so we're folding the KS-ITS list into INFO-ITS. You're not on INFO-ITS nor BUG-ITS. Unless I hear from you in the next few days I'll put you on INFO-ITS. david  Date: Wed, 28 May 86 03:14:33 EDT From: "Pandora B. Berman" Subject: FAILED STUFF To: ZVONA@AI.AI.MIT.EDU cc: BUG-COMSAT@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].47079.860528.CENT> Date: Wed, 28 May 86 02:06:40 EDT From: David Vinayak Wallace Subject: FAILED STUFF To: ZVONA@MC.LCS.MIT.EDU cc: BUG-COMSAT@MC.LCS.MIT.EDU Date: Tue, 27 May 86 15:46:39 EDT From: David Chapman What is protocol for dealing with FAILED STUFF? I've been taking care of it since mostly it's been my fault. Should I delete it whenever I fix all the bugs, or what? Remove messages from it once you've taken care of them (by sending them somewhere, or whatever). Let the file shrink to (one hopes) emptyness. when i have time to do this (which hasn't happened much recently), i run RMAIL on FAILED STUFF; those msgs which seem at all important (or even neutral), i send along to the intended destination if i can figure out a good address for it; otherwise i return them to the authors, with a short explanation of why they lost, better addresses to try, etc. if there are a lot in relatively quick succession from the same author all losing for the same reason, i usually just return one or two with an explanation of how to try to win, and simply flush all the rest unless they seem to be important. when i reach the end of the file, having deleted all the msgs i have dealt with, RMAIL won't let me save my version of the now-empty file, so i quit the job and delete the file. then i do the same thing to FAILED NETORG. actually, a slight refinement i now recall is that first, i rename these files to FAILED OSTUFF and ONET, so that new losing mail can accumulate even while i am taking care of the older stuff. there's nothing wrong with not having these FAILED files; COMSAT will create them if (when) it needs to.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 28 MAY 86 02:07:51 EDT Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 28 MAY 86 02:07:29 EDT Date: Wed, 28 May 86 02:06:40 EDT From: David Vinayak Wallace Subject: FAILED STUFF To: ZVONA@MC.LCS.MIT.EDU cc: BUG-COMSAT@MC.LCS.MIT.EDU In-reply-to: Msg of Tue 27 May 86 15:46:39 EDT from David Chapman Message-ID: <[MX.LCS.MIT.EDU].922134.860528.GUMBY> Date: Tue, 27 May 86 15:46:39 EDT From: David Chapman What is protocol for dealing with FAILED STUFF? I've been taking care of it since mostly it's been my fault. Should I delete it whenever I fix all the bugs, or what? Remove messages from it once you've taken care of them (by sending them somewhere, or whatever). Let the file shrink to (one hopes) emptyness.  Date: Tue, 27 May 86 18:08:39 EDT From: Alan Bawden Subject: User%MX@MC, right? To: ZVONA@AI.AI.MIT.EDU cc: BUG-COMSAT@AI.AI.MIT.EDU In-reply-to: Msg of Tue 27 May 86 17:54:01 EDT from David Chapman Message-ID: <[AI.AI.MIT.EDU].46738.860527.ALAN> Date: Tue, 27 May 86 17:54:01 EDT From: David Chapman So why isn't MX in the NIC host table or wherever the hell it has to be for Joe Foo at U Peoria to mail to it? Not my department. (Like I said beofre, I might even be mistaken.) Does this mean that Poor Old Joe Foo also can't supdup to it? There will be a lot of unhappy people. Yup.  Date: Tue, 27 May 86 17:54:01 EDT From: David Chapman Subject: User%MX@MC, right? To: ALAN@AI.AI.MIT.EDU cc: BUG-COMSAT@AI.AI.MIT.EDU In-reply-to: Msg of Tue 27 May 86 16:56:46 EDT from Alan Bawden Message-ID: <[AI.AI.MIT.EDU].46697.860527.ZVONA> So why isn't MX in the NIC host table or wherever the hell it has to be for Joe Foo at U Peoria to mail to it? Does this mean that Poor Old Joe Foo also can't supdup to it? There will be a lot of unhappy people.  Date: Tue, 27 May 86 16:56:46 EDT From: Alan Bawden Subject: User%MX@MC, right? To: BUG-COMSAT@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].46663.860527.ALAN> (The problem with Bug-COMSAT was that the forwarding address on MC was missing, not that the entire mailing list was gone. Indeed the list lives on AI, because that's where COMSAT is hacked these days.) Mail generated by users on MX (the KL) claims to be from User@MX, which won't work outside of MIT. Instead it should be User%MX@MC. (Right? This stuff is so confusing these days.)  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 27 MAY 86 15:47:01 EDT Date: Tue, 27 May 86 15:46:39 EDT From: David Chapman To: BUG-COMSAT@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].4457.860527.ZVONA> What is protocol for dealing with FAILED STUFF? I've been taking care of it since mostly it's been my fault. Should I delete it whenever I fix all the bugs, or what?  Date: Tue, 27 May 86 13:57:15 EDT From: David Chapman Subject: [COMSAT: Msg of Thursday, 22 May 1986 19:36-EDT] To: ALAN@AI.AI.MIT.EDU cc: BUG-COMSAT@AI.AI.MIT.EDU In-reply-to: Msg of Thu 22 May 86 20:15:34 EDT from Alan Bawden Message-ID: <[AI.AI.MIT.EDU].46525.860527.ZVONA> Date: Thu, 22 May 86 20:15:34 EDT From: Alan Bawden To: BUG-COMSAT at AI.AI.MIT.EDU Re: [COMSAT: Msg of Thursday, 22 May 1986 19:36-EDT] Seems like somebody forgot to move Bug-COMSAT to MC. It's ITS-specific, right? So it lives on AI, right?  Date: Tue, 27 May 86 07:22:37 EDT From: David Vinayak Wallace Subject: bogus host address in message To: BUG-COMSAT@AI.AI.MIT.EDU, postmaster@OZ.AI.MIT.EDU, postmaster@PREP.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].46361.860527.GUMBY> There's no such host as OZ. One of these mailers should have caught it. Received: from MX.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 24 MAY 86 21:16:25 EDT Received: from OZ.AI.MIT.EDU by MX.LCS.MIT.EDU via Chaosnet; 24 MAY 86 21:10:15 EDT Received: from PREP.AI.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 23 May 86 16:55-EDT Received: by PREP.AI.MIT.EDU; Fri, 23 May 86 16:55:06 EDT Date: Fri, 23 May 86 16:55:06 EDT From: x@PREP.AI.MIT.EDU (Dean Elsner) To: gumby@oz Subject: PARC Interim 3-Lisp manual: borrowed from your shelf  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 23 MAY 86 20:58:04 EDT Received: from ATHENA by MC.LCS.MIT.EDU 23 May 86 20:58:05 EDT Received: by ATHENA (5.45/4.7) id AA04873; Fri, 23 May 86 20:56:50 EDT Received: by ACHILLES (5.15/4.7) id AA14124; Fri, 23 May 86 20:56:55 EDT Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 7404; Fri 23-May-86 18:03:43 EDT Date: Fri, 23 May 86 17:46 EDT From: David A. Moon Subject: [ANDY: [Jonathan A Rees : LOAD]] To: Jonathan A Rees Cc: BUG-comsat@MC.LCS.MIT.EDU In-Reply-To: <[AI.AI.MIT.EDU].44841.860522.JAR> Message-Id: <860523174644.6.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Thu, 22 May 86 21:03:15 EDT From: Jonathan A Rees This is not a bug report, it is merely a question. Maybe I don't understand what Return-paths are for. I sent this from a Lisp Machine. My home machine is AI. I would have expected the return-path to be JAR@MC.... or JAR@ZERMATT.... or JAR@LIVE-OAK... or even JAR@JOE-LOUIS.... or something like that. Why does it say NET-ORIGIN? Return-Path: Received: from MC.LCS.MIT.EDU by su-sushi.arpa with TCP; Thu 22 May 86 08:55:15-PDT Received: from LIVE-OAK.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 22 MAY 86 11:53:10 EDT Received: from JOE-LOUIS.LCS.MIT.EDU by MIT-LIVE-OAK.ARPA via CHAOS with CHAOS-MAIL id 1622; Thu 22-May-86 11:51:29-EDT Date: Thu, 22 May 86 11:51 EDT From: Jonathan A Rees Subject: LOAD To: rrrs-authors@MIT-MC.ARPA Message-ID: <"860522115129.3.jar@AI"@JOE-LOUIS.LCS.MIT.EDU> It's because the first step in transmitting the mail (the last Received: line) used the CHAOS-MAIL protocol. That protocol, designed long ago, doesn't transmit a return-path. When the message arrived at MC without a return-path, Comsat defaulted to NET-ORIGIN; I think any reply sent back to that will end up at Postmaster. I'm not sure why Comsat didn't default to the contents of the from field -- either I'm confused in thinking that it usually does so, or something unusual happened to prevent it, like the spasticity in host name lookup that's been happening a lot lately due to partial switchover to domains. I forget whether the software running on LIVE-OAK supports SMTP protocol over CHAOS medium (SMTP has a return-path). If it does, you can add this line to LIVE-OAK's namespace description to cause SMTP to be used in preference to CHAOS-MAIL: SERVICE STORE-AND-FORWARD-MAIL CHAOS SMTP Also make sure MC has this in its namespace description (I think I installed the CHAOS SMTP server there myself).  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 22 MAY 86 21:03:27 EDT Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 22 MAY 86 21:03:44 EDT Date: Thu, 22 May 86 21:03:15 EDT From: Jonathan A Rees Subject: [ANDY: [Jonathan A Rees : LOAD]] To: BUG-comsat@MC.LCS.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].44841.860522.JAR> This is not a bug report, it is merely a question. Maybe I don't understand what Return-paths are for. I sent this from a Lisp Machine. My home machine is AI. I would have expected the return-path to be JAR@MC.... or JAR@ZERMATT.... or JAR@LIVE-OAK... or even JAR@JOE-LOUIS.... or something like that. Why does it say NET-ORIGIN? Thanks in advance for explaining this to me. Even after 8 years using Arpanet electronic mail, including 3 years at MIT, some things are still mysterious to me. - Jonathan Date: Thu 22 May 86 14:12:47-PDT From: Andy Freeman To: jar at AI.AI.MIT.EDU Re: [Jonathan A Rees : LOAD] Is net-origin a generic return path or is something odd going on? (I first thought it had something to do with another arpa mailing list.) -andy ps - This is the header of your message. Return-Path: Received: from MC.LCS.MIT.EDU by su-sushi.arpa with TCP; Thu 22 May 86 08:55:15-PDT Received: from LIVE-OAK.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 22 MAY 86 11:53:10 EDT Received: from JOE-LOUIS.LCS.MIT.EDU by MIT-LIVE-OAK.ARPA via CHAOS with CHAOS-MAIL id 1622; Thu 22-May-86 11:51:29-EDT Date: Thu, 22 May 86 11:51 EDT From: Jonathan A Rees Subject: LOAD To: rrrs-authors@MIT-MC.ARPA Message-ID: <"860522115129.3.jar@AI"@JOE-LOUIS.LCS.MIT.EDU>  Date: Thu, 22 May 86 20:15:34 EDT From: Alan Bawden Subject: [COMSAT: Msg of Thursday, 22 May 1986 19:36-EDT] To: BUG-COMSAT@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].44818.860522.ALAN> Seems like somebody forgot to move Bug-COMSAT to MC. Date: Thu, 22 May 86 19:36:31 EDT From: Alan Bawden To: BUG-COMSAT@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].1999.860522.ALAN> It's been a while since I looked at a COMSAT corpse (there were so many of them for a while there that it didn't seem worth it), but I just took a look at one on MC (the KS) that looks unfamialiar to to me. It didn't leave anything in AUTPSY, for some reason we seem to have abandoned that mechanism here it the future. It looks to me like some UUO got an MPV while probing around in some datastructures. Perhaps its worth a look? CRASH;BURNUP 1 would seem to be where it dumped itself.  Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU 22 May 86 01:24:18 EDT Date: Thu, 22 May 1986 01:24 EDT Message-ID: From: Rob Austein To: "Pandora B. Berman" Cc: BUG-MAIL@AI.AI.MIT.EDU Subject: comsat hung In-reply-to: Msg of 21 May 1986 23:49-EDT from "Pandora B. Berman" Oh, right. That's the bug where COMSAT PCLSRs for some reason at exactly the wrong point and when DQXDEV SIOTs it hangs forever because the request has been invalidated. I fixed this at one point but never installed the fixed binary, for some reason which has now escaped me. I just installed the binary on AI, MC (KS), and MD. ML and MX (KL) will have to wait until they are up (":COPY AI:SRA;DQXDEV BIN,DSK:" will do the right thing). If this loses really badly while I am at Stanford, reassemble the next to highest version and install that (and be prepared to .GUN as needed). The fix should work though, assuming that I understand the syndrome.  Date: Wed, 21 May 86 23:49:31 EDT From: "Pandora B. Berman" Subject: comsat hung To: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].44366.860521.CENT> AI comsat was sitting there compiling a new NAMES >, and had been for 15 minutes. which is ridiculous. IV was in RENMWO and JOB.07 was in BOJSO, and neither did anything for several minutes while i watched. so i blew IV out of the water and launched another, which behaved more prettily. the old JOB.07 is still around, if you want to check it out.  Date: Wed, 21 May 86 20:57:17 EDT From: "Pandora B. Berman" Subject: duplicated message To: KLOTZ@AI.AI.MIT.EDU cc: BUG-COMSAT@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].44249.860521.CENT> Date: Tue, 20 May 86 14:40:19 EDT From: "Leigh L. Klotz" Subject: duplicated message To: BUG-COMSAT@AI.AI.MIT.EDU Somehow I got two copies of this message, even though it originated on an ITS an I get my mail on an ITS (the same machine, even). I'm not on BUG-DUMP and it isn't eqv to BUG-RANDOM-PROGRAM, but anyway that shouldn't matter. Looking at the Received: lines on the second message (absent on the first) it seems that the second one bounced through MC somehow. I don't know if this is related to the address change or if it's a real problem. I had changed my address to AI a little before that, had it changed to KL on me, and then changed it back to AI myself all before I got this message. ---------- Date: Mon, 12 May 86 04:45:31 EDT From: "Pandora B. Berman" Subject: we got problems To: BUG-DUMP@AI.AI.MIT.EDU cc: KS-ITS@AI.AI.MIT.EDU [msg omitted] ---------- Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 12 MAY 86 04:50:00 EDT Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 12 MAY 86 04:47:58 EDT Date: Mon, 12 May 86 04:45:31 EDT From: "Pandora B. Berman" Subject: we got problems To: BUG-DUMP@AI.AI.MIT.EDU cc: KS-ITS@AI.AI.MIT.EDU [msg omitted] there have been several shifts of official bug-host between AI and MC in the past week. perhaps at the moment i sent this msg, AI was the bug-host, but lacked most of the bug- lists. so it went to bug-random-program instead, and that bounced to the KL either through your temporary address change, or because bug-random-program@AI explicitly directed to the KL. basically, we've had problems of this sort for a week as we have prepared for The Move. be glad it wasn't anything worse.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 21 MAY 86 18:01:22 EDT Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU 21 May 86 17:58:43 EDT Date: Wed, 21 May 1986 17:58 EDT Message-ID: From: Rob Austein To: bug-mail@MC.LCS.MIT.EDU Subject: COMSAT source locks I am hereby releasing my locks on COMSAT and friends. Whether or not anybody has the courage to touch any of them after what I have done to them is another question entirely.... At some point I may need to lock sources again to do resolver development, but that will be a while yet.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 21 MAY 86 15:45:31 EDT Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU 21 May 86 15:43:34 EDT Date: Wed, 21 May 1986 15:43 EDT Message-ID: From: Rob Austein To: David Chapman Cc: BUG-MAIL@MC.LCS.MIT.EDU, CENT@MC.LCS.MIT.EDU, GSB@MC.LCS.MIT.EDU In-reply-to: Msg of 21 May 1986 12:58-EDT from David Chapman It worked ok last night when I resent the losing messages to *BBOARD@KS.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 21 MAY 86 15:09:28 EDT Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU 21 May 86 15:10:05 EDT Date: Wed, 21 May 1986 15:09 EDT Message-ID: From: Rob Austein To: David Chapman Cc: BUG-MAIL@MC.LCS.MIT.EDU In-reply-to: Msg of 21 May 1986 15:06-EDT from David Chapman Presumably knutsen@sri-unix.arpa would know.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 21 MAY 86 15:05:26 EDT Date: Wed, 21 May 86 15:06:15 EDT From: David Chapman To: BUG-MAIL@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].963.860521.ZVONA> Anyone know what this is about and if it is still used? ;Offered to try to find a way to get incompletely-addressed etc. messages thru. (FAILED-USENET-MAIL (EQV-LIST (knutsen SRI-UNIX)))  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 21 MAY 86 12:58:16 EDT Date: Wed, 21 May 86 12:58:53 EDT From: David Chapman To: SRA@MC.LCS.MIT.EDU, CENT@MC.LCS.MIT.EDU, BUG-MAIL@MC.LCS.MIT.EDU, GSB@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].855.860521.ZVONA> Date: Sat, 17 May 86 11:19:35 EDT From: Rob Austein Subject: mailing list lossage To: ZVONA@MC.LCS.MIT.EDU cc: BUG-MAIL@MC.LCS.MIT.EDU, CENT@MC.LCS.MIT.EDU,GSB@MC.LCS.MIT.EDU ARGH!!!! I sent through several arpanet-bboards messages that had been waiting for human attention. MX faithfully delivered them all... to everwhere but MIT, because *BBOARD@MC expands to the MC :MSGS file and nothing else. David, I don't know what you intended here so I'm not going to touch. Could you fix this to whatever you really intended and let me, gsb, or cent know so we can remail the MIT copies of these messages? Thanks.... don't jump on zvona, i think -i- was the latest person to diddle with the *msg lists, when i went around adding ML and MD everywhere. I can't figure out what happened here. I haven't touched *BBOARD; so far as I can tell there has never been a time when it did not expand into all the right places. Have you tried again since?  Date: Tue, 20 May 86 14:40:19 EDT From: "Leigh L. Klotz" Subject: duplicated message To: BUG-COMSAT@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].43082.860520.KLOTZ> Somehow I got two copies of this message, even though it originated on an ITS an I get my mail on an ITS (the same machine, even). I'm not on BUG-DUMP and it isn't eqv to BUG-RANDOM-PROGRAM, but anyway that shouldn't matter. Looking at the Received: lines on the second message (absent on the first) it seems that the second one bounced through MC somehow. I don't know if this is related to the address change or if it's a real problem. I had changed my address to AI a little before that, had it changed to KL on me, and then changed it back to AI myself all before I got this message. Date: Mon, 12 May 86 04:45:31 EDT From: "Pandora B. Berman" Subject: we got problems To: BUG-DUMP@AI.AI.MIT.EDU cc: KS-ITS@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].37609.860512.CENT> ML has caught MX's lassitude. this morning i dumped both of them incrementally. neither of them twiddled any backed-up bits after the .TAPE0; dir. dave, please work on this. Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 12 MAY 86 04:50:00 EDT Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 12 MAY 86 04:47:58 EDT Date: Mon, 12 May 86 04:45:31 EDT From: "Pandora B. Berman" Subject: we got problems To: BUG-DUMP@AI.AI.MIT.EDU cc: KS-ITS@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].37609.860512.CENT> ML has caught MX's lassitude. this morning i dumped both of them incrementally. neither of them twiddled any backed-up bits after the .TAPE0; dir. dave, please work on this.  Received: from SPEECH.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 20 MAY 86 02:33:04 EDT Date: Tue 20 May 86 02:34:50-EDT From: "John Wroclawski" Subject: Re: I have good news, and bad news To: ALAN@AI.AI.MIT.EDU, POOOR-MC@AI.AI.MIT.EDU, BUG-COMSAT@AI.AI.MIT.EDU, ZVONA@AI.AI.MIT.EDU, KARENS@AI.AI.MIT.EDU Message-ID: <12208117956.19.JTW@MIT-SPEECH> From: Alan Bawden The single -new- problem is that unit #2 is now exhibiting one of the canonical RP04 lossages: it is unable to fully retract its cleaning brushes. This can be fixed by someone who I fixed this. It isn't going to last forever; there's a pretty sick bearing in there. -------  Date: Tue, 20 May 86 01:38:49 EDT From: Alan Bawden Subject: I have good news, and bad news To: POOOR-MC@AI.AI.MIT.EDU, BUG-COMSAT@AI.AI.MIT.EDU, ZVONA@AI.AI.MIT.EDU, KARENS@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].42865.860520.ALAN> Well, there wasn't anything wrong with MC's processor after all. No irreplaceable processor boards were lost. The single -new- problem is that unit #2 is now exhibiting one of the canonical RP04 lossages: it is unable to fully retract its cleaning brushes. This can be fixed by someone who knows what they are doing in about 5 minutes. All we have to do is find someone like that. Until unit #2 gets fixed, Moon and I figured we would simply move pack 1 from unit #2 to unit #1, and take pack 13 (SECOND) off-line. You may recall that unit #1 is the one DEC replaced last month because they couldn't fix the old unit #1. Since then I have been warning people not to create new files on pack 13 because I was under the impression that it had been mis-formatted by the old drive. Well, I was wrong, and tonight we learned just how wrong in a slightly painful way. After ITS had run for an hour or so, it filled pack 0 up to a point where it thought it might be a good idea to switch to creating files on pack 1 for a while. At this point Alan learns that what DEC had convinced him of last month was in fact not true. Unit #1 really -is- still broken. It can read files just fine, but something like one out of every hundred blocks it writes are unreadable. So now we have a few files on pack 1 that contain locked and unreadable blocks, and probably a few more that are unreadable that ITS hasn't discovered yet. The most important known casualty is .MAIL.; LISTS MSGS (COMSAT's database of queued mail). This is a familiar story these days. DEC can't fix it, so your filesystem gets gubble written in it. Fortunately, the ITS filesystem is built from pretty stern stuff, so although we might lose a file or two, the whole thing is much less likely to crumble around our ears. So here is where we stand: MC's filesystem contains a couple of bruises, but nothing severe. However we can't really run MC untill one of the drives gets fixed (unit #2 should be easy, as I said before) without risking further damage to the filesystem. A few cycles from a COMSAT wizard will be required to either fix its database and get COMSAT running again, or to at least rescue the mail currently trapped in its queue (I can explain the nature of the lossage further in person). The most important thing we can get from MC right now is to empty the last valuable stuff from its filesystem, and to use it to copy 7 track tapes. I know how we can safely accomplish both of these tasks using the 1.5 RP04's we have left, but I would rather not get into that here, and I hope we won't need to. I would recommend that the IMP reconfiguration take place as soon as possible so that we can bring the MC KS online. We can't really make the KS be MC until Zvona finishes with the great mailing list migration. He estimated to me today that he had about 8 hours work to go, but he was handicapped by not having access to the mailing lists file on MC. Fortunately while MC was up Penny grabbed a copy, so now AI:.MAIL.;.MCNEW NAMES contains a copy of the NAMES file currently on the KL. (We should give Zvona a medal when he finishes this job. (Zvona: if you need any more files from the KL, I'll be happy to get them back for you!)) Question: We are going to need a mess of tapes for copying MC's GFR tapes to 9-track tapes and also for doing a last full dump to 9-track (and perhaps copying a couple more older full dumps to 9-track). How does one go about obtaining such large numbers of tapes? Who's going to pay for it? If I truck on down to the stock room and ask for 100 reels of tape, I presume they will want some kind of coherent story about who should be charged for it...  Date: Tue, 20 May 86 01:29:56 EDT From: "Pandora B. Berman" Subject: mailing list lossage To: SRA@AI.AI.MIT.EDU cc: BUG-MAIL@AI.AI.MIT.EDU, GSB@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].42862.860520.CENT> Date: Sat, 17 May 86 11:19:35 EDT From: Rob Austein Subject: mailing list lossage To: ZVONA@MC.LCS.MIT.EDU cc: BUG-MAIL@MC.LCS.MIT.EDU, CENT@MC.LCS.MIT.EDU,GSB@MC.LCS.MIT.EDU ARGH!!!! I sent through several arpanet-bboards messages that had been waiting for human attention. MX faithfully delivered them all... to everwhere but MIT, because *BBOARD@MC expands to the MC :MSGS file and nothing else. David, I don't know what you intended here so I'm not going to touch. Could you fix this to whatever you really intended and let me, gsb, or cent know so we can remail the MIT copies of these messages? Thanks.... don't jump on zvona, i think -i- was the latest person to diddle with the *msg lists, when i went around adding ML and MD everywhere. when MC was up tonight i snarfed a copy of MC:NAMES > into AI:.MCNEW NAMES, so at least we can see what's there. i can't offhand see anything wrong with the syntax there; someone else should check. oh, also i copied the BUG-MAIL internal lists to AI, so mailing this out will actually reach people.  Received: from SAPSUCKER.SCRC.Symbolics.COM by AI.AI.MIT.EDU 19 May 86 14:15:36 EDT Received: from EUPHRATES.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 21610; Mon 19-May-86 14:13:07 EDT Date: Mon, 19 May 86 14:13 EDT From: David A. Moon Subject: ADS-UNIX To: SRA@MIT-XX.ARPA, BUG-MAIL@MIT-AI.ARPA cc: Devon S. McCullough In-Reply-To: <[MC.LCS.MIT.EDU].918096.860517.DEVON> Message-ID: <860519141309.8.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Sat, 17 May 86 03:57:40 EDT From: "Devon S. McCullough" Date: Fri, 16 May 1986 03:57 EDT From: Rob Austein To: Devon S. McCullough cc: BUG-MAIL at MC.LCS.MIT.EDU Date: Thursday, 15 May 1986 21:13-EDT From: "Devon S. McCullough" To: BUG-MAIL@MC.LCS.MIT.EDU i did MAIL^K it said To: I said mab@aids it said Error; Ambigous site spec. "aids"=>{AIDS-UNIX,AIDS-UNIX.ARPA} which happen to be one and the same. Cheer up, soon COMSAT will really be using domains and then you won't have to worry about this because it will no longer be possible even in theory to do what you seem to think is the right thing here. In the meantime, you might try using the nickname "ads" instead of "aids", which has the advantage of being in the host table. :host aids AIDS-UNIX.ARPA (ADS, ADS-UNIX, AIDS-UNIX) "SERVER" System: UNIX CPU: VAX-11/780 ARPANET = 10.2.0.56 (Host 2, Imp 56) 1200,,400070 TCP/TELNET, TCP/FTP, TCP/SMTP, ICMP, TCP/FINGER :KILL * Huh, you are right, it's not in there. This is strange since mailing to AIDS works fine in EMACS. Is that a bug or a DWIM? It's long past time the broken host-name parsing code in QMAIL was removed. It has been more than ten years now since this code was necessary (since Comsat accepted host names instead of numbers). Maybe the problem is just finding someone who can figure out how to remove it without breaking the program.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 17 MAY 86 11:21:27 EDT Date: Sat, 17 May 86 11:19:35 EDT From: Rob Austein Subject: mailing list lossage To: ZVONA@MC.LCS.MIT.EDU cc: BUG-MAIL@MC.LCS.MIT.EDU, CENT@MC.LCS.MIT.EDU, GSB@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].918196.860517.SRA> ARGH!!!! I sent through several arpanet-bboards messages that had been waiting for human attention. MX faithfully delivered them all... to everwhere but MIT, because *BBOARD@MC expands to the MC :MSGS file and nothing else. David, I don't know what you intended here so I'm not going to touch. Could you fix this to whatever you really intended and let me, gsb, or cent know so we can remail the MIT copies of these messages? Thanks.... --Rob  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 17 MAY 86 03:59:27 EDT Date: Sat, 17 May 86 03:57:40 EDT From: "Devon S. McCullough" To: SRA@XX.LCS.MIT.EDU cc: BUG-MAIL@MC.LCS.MIT.EDU In-reply-to: Msg of Fri 16 May 1986 03:57 EDT from Rob Austein Message-ID: <[MC.LCS.MIT.EDU].918096.860517.DEVON> Date: Fri, 16 May 1986 03:57 EDT From: Rob Austein To: Devon S. McCullough cc: BUG-MAIL at MC.LCS.MIT.EDU Date: Thursday, 15 May 1986 21:13-EDT From: "Devon S. McCullough" To: BUG-MAIL@MC.LCS.MIT.EDU i did MAIL^K it said To: I said mab@aids it said Error; Ambigous site spec. "aids"=>{AIDS-UNIX,AIDS-UNIX.ARPA} which happen to be one and the same. Cheer up, soon COMSAT will really be using domains and then you won't have to worry about this because it will no longer be possible even in theory to do what you seem to think is the right thing here. In the meantime, you might try using the nickname "ads" instead of "aids", which has the advantage of being in the host table. :host aids AIDS-UNIX.ARPA (ADS, ADS-UNIX, AIDS-UNIX) "SERVER" System: UNIX CPU: VAX-11/780 ARPANET = 10.2.0.56 (Host 2, Imp 56) 1200,,400070 TCP/TELNET, TCP/FTP, TCP/SMTP, ICMP, TCP/FINGER :KILL * Huh, you are right, it's not in there. This is strange since mailing to AIDS works fine in EMACS. Is that a bug or a DWIM?  Date: Sat, 17 May 86 01:26:58 EDT From: "Pandora B. Berman" Subject: *msgs To: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].42168.860517.CENT> i have copied the *MSG stuff into NAMES > on MD and ML, and fixed the others to know of them.  Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU 16 May 86 15:03:50 EDT Date: Fri, 16 May 1986 15:01 EDT Message-ID: From: Rob Austein To: David Chapman Cc: ALAN@AI.AI.MIT.EDU, BUG-MAIL-AND-POSTMASTER@MC.LCS.MIT.EDU, BUG-MAIL@AI.AI.MIT.EDU Subject: [CSTACY: EQVLEN fudge blocks] In-reply-to: Msg of 16 May 1986 11:35-EDT from David Chapman COMSAT sources now list HN$MC as BUGHST. COMSAT binaries on MC, AI, MX, and MD now have HN$MC patched in as BUGHST. ML is down or off the net. When it comes back could somebody copy MD:.MAIL.;COMSAT IV to MD:, please? It has to be from MD unless you know the right locations to patch for chaos-only machine. MC's COMSAT has the 22 block fudge factor code NOP'd out. Have to wait a few days to see if this makes a difference.  Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU 16 May 86 14:45:52 EDT Date: Fri, 16 May 1986 14:41 EDT Message-ID: From: Rob Austein To: David Chapman Cc: ALAN@AI.AI.MIT.EDU, BUG-MAIL-AND-POSTMASTER@MC.LCS.MIT.EDU, BUG-MAIL@AI.AI.MIT.EDU Subject: [CSTACY: EQVLEN fudge blocks] In-reply-to: Msg of 16 May 1986 11:35-EDT from David Chapman You want an authoritative decision? OK. IT IS HEREBY PROCLAIMED THAT HENCEFORTH ALL BUG LISTS SHALL RESIDE ON THE MACHINE KNOWN AS MC, ADDRESS 10.3.0.44. SUITABLE FORWARDING ENTRIES SHOULD BE SET UP. That any better? I'll fix COMSAT to believe this theory.  Date: Fri, 16 May 86 11:35:51 EDT From: David Chapman Subject: [CSTACY: EQVLEN fudge blocks] To: ALAN@AI.AI.MIT.EDU cc: BUG-MAIL-AND-POSTMASTER@MC.LCS.MIT.EDU, SRA@XX.LCS.MIT.EDU, BUG-MAIL@AI.AI.MIT.EDU In-reply-to: Msg of Wed 14 May 86 13:48:51 EDT from Alan Bawden Message-ID: <[AI.AI.MIT.EDU].41888.860516.ZVONA> Someone should authoritatively declare what BUGHST is so I can do something sensible about it. If BUGHST is MC, I can still move the lists to KS by putting in pointers for all of them on KL.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 16 MAY 86 04:00:38 EDT Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU 16 May 86 03:58:21 EDT Date: Fri, 16 May 1986 03:57 EDT Message-ID: From: Rob Austein To: "Devon S. McCullough" Cc: BUG-MAIL@MC.LCS.MIT.EDU In-reply-to: Msg of 15 May 1986 21:13-EDT from "Devon S. McCullough" Date: Thursday, 15 May 1986 21:13-EDT From: "Devon S. McCullough" To: BUG-MAIL@MC.LCS.MIT.EDU i did MAIL^K it said To: I said mab@aids it said Error; Ambigous site spec. "aids"=>{AIDS-UNIX,AIDS-UNIX.ARPA} which happen to be one and the same. Cheer up, soon COMSAT will really be using domains and then you won't have to worry about this because it will no longer be possible even in theory to do what you seem to think is the right thing here. In the meantime, you might try using the nickname "ads" instead of "aids", which has the advantage of being in the host table.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 15 MAY 86 21:15:30 EDT Date: Thu, 15 May 86 21:13:44 EDT From: "Devon S. McCullough" To: BUG-MAIL@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].916803.860515.DEVON> i did MAIL^K it said To: I said mab@aids it said Error; Ambigous site spec. "aids"=>{AIDS-UNIX,AIDS-UNIX.ARPA} which happen to be one and the same.  Date: Wed, 14 May 86 13:48:51 EDT From: Alan Bawden Subject: [CSTACY: EQVLEN fudge blocks] To: SRA@XX.LCS.MIT.EDU, ZVONA@AI.AI.MIT.EDU cc: BUG-MAIL-AND-POSTMASTER@MC.LCS.MIT.EDU, BUG-MAIL@AI.AI.MIT.EDU In-reply-to: Msg of Wed 14 May 86 13:28:27 EDT from David Chapman Message-ID: <[AI.AI.MIT.EDU].40919.860514.ALAN> Date: Wed, 14 May 86 13:28:27 EDT From: David Chapman Date: Wed, 14 May 1986 12:40 EDT From: Rob Austein BUGHST is AI again.... The BUGHST problem hadn't occurred to me [I've said ``the X problem hadn't occured to me'' a lot in the last few days!]. Next batch of stuff I move will be all the BUG- lists. To AI, right? Or, at least, I will guarantee that AI has a pointer for everything, if it goes to KS instead. I though we had all agreed that since Bug-FOO mailing lists no longer tended to have anything to do with programs maintained on ITS, there was no reason for AI (the canonical home for ITS software) to be the bug host. I thought we had agreed that "MC", in whatever hardware it was wearing at the moment, was to continue to be the bug host. There are a ton of Bug-FOO mailing lists, and no reason why they shouldn't continue to be gatewayed through the same machine as all rest of the world's mailing lists.  Date: Wed, 14 May 86 13:28:27 EDT From: David Chapman Subject: [CSTACY: EQVLEN fudge blocks] To: SRA@XX.LCS.MIT.EDU cc: BUG-MAIL-AND-POSTMASTER@MC.LCS.MIT.EDU, ALAN@AI.AI.MIT.EDU, BUG-MAIL@AI.AI.MIT.EDU In-reply-to: Msg of Wed 14 May 1986 12:40 EDT from Rob Austein Message-ID: <[AI.AI.MIT.EDU].40907.860514.ZVONA> Date: Wed, 14 May 1986 12:40 EDT From: Rob Austein To: Alan Bawden cc: BUG-MAIL-AND-POSTMASTER at MC.LCS.MIT.EDU, BUG-MAIL at AI.AI.MIT.EDU Re: [CSTACY: EQVLEN fudge blocks] BUGHST is AI again. This was originally an oversight on my part, but since the bug lists are in the process of being moved I'm not sure it's wrong anymore. Obvously BUG-MAIL hasn't been moved though. Zvona, what is the status of all the list moving? Bug-foo lists in particular. If we can publicly agree on where the frigging bug host is I'll make sure that the sources and all running COMSATs have that address. In the meantime, people, please be patient with things going to bug-random-program, ok? This mailing list migration business is going to take a while; I've spent about three full time days on it so far and am about half done. The BUGHST problem hadn't occurred to me [I've said ``the X problem hadn't occured to me'' a lot in the last few days!]. Next batch of stuff I move will be all the BUG- lists. To AI, right? Or, at least, I will guarantee that AI has a pointer for everything, if it goes to KS instead.  Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU 14 May 86 12:43:20 EDT Date: Wed, 14 May 1986 12:40 EDT Message-ID: From: Rob Austein To: Alan Bawden Cc: BUG-MAIL-AND-POSTMASTER@MC.LCS.MIT.EDU, BUG-MAIL@AI.AI.MIT.EDU Subject: [CSTACY: EQVLEN fudge blocks] In-reply-to: Msg of 14 May 1986 12:34-EDT from Alan Bawden BUGHST is AI again. This was originally an oversight on my part, but since the bug lists are in the process of being moved I'm not sure it's wrong anymore. Obvously BUG-MAIL hasn't been moved though. Zvona, what is the status of all the list moving? Bug-foo lists in particular. If we can publicly agree on where the frigging bug host is I'll make sure that the sources and all running COMSATs have that address. In the meantime, people, please be patient with things going to bug-random-program, ok?  Date: Wed, 14 May 86 12:34:30 EDT From: Alan Bawden Subject: [CSTACY: EQVLEN fudge blocks] To: BUG-MAIL-AND-POSTMASTER@MC.LCS.MIT.EDU, BUG-MAIL@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].40888.860514.ALAN> I found this in my mailbox. I'm not on BUG-MAIL. BUG-MAIL is based on AI now, but it includes BUG-MAIL-AND-POSTMASTER, for which there isn't an entry in AI's NAMES file. This should get forwarded to MC, as a BUG- message, where BUG-MAIL-AND-POSTMASTER -is- defined. But I'm not on that list either. My guess is that somehow on its way to MC and back to AI this got converted to mail to BUG-RANDOM-PROGRAM. Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 14 MAY 86 09:13:59 EDT Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 14 MAY 86 09:11:55 EDT Date: Wed, 14 May 86 09:12:25 EDT From: "Christopher C. Stacy" Subject: EQVLEN fudge blocks To: SRA@AI.AI.MIT.EDU cc: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].40545.860514.CSTACY> I put that fudge factor in because the algorithm used there seemed to be off by that much all the time, but I never quite figured out why. So, you might try taking it out and seeing if you can see what's going on. The worst that could happen is that the input requests will think they are going to fit, and then don't.  Date: Wed, 14 May 86 09:12:25 EDT From: "Christopher C. Stacy" Subject: EQVLEN fudge blocks To: SRA@AI.AI.MIT.EDU cc: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].40545.860514.CSTACY> I put that fudge factor in because the algorithm used there seemed to be off by that much all the time, but I never quite figured out why. So, you might try taking it out and seeing if you can see what's going on. The worst that could happen is that the input requests will think they are going to fit, and then don't.  Date: Mon, 12 May 86 20:28:17 EDT From: David Chapman To: BUG-MAIL@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].911062.860512.ZVONA> For historical interest, a copy of the old MC:.MAIL.;NAMES > is in AI:KSC;OLDMC NAMES. Within a few days, most of it will be gone: moved to MX, AI, or simply deleted.  Date: Mon, 12 May 86 09:55:07 EDT From: Rob Austein Subject: Some 3 block MAIL > files are more equal than others To: BUG-MAIL@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].910492.860512.SRA> COMSAT still seems to think that some 3 block (and larger) MAIL > files are too big. This is odd, since twenty minutes later the same file renamed from BADREQ to MAIL will go just fine. I found one interesting bit of code down in the guts. Is there anybody still on this list who knows why the EQVLEN routine adds a fudge factor of 22. blocks iff LIST EQV file isn't in core?  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 12 MAY 86 03:50:42 EDT Date: Mon, 12 May 86 03:51:29 EDT From: "Pandora B. Berman" Subject: more mail procedure To: ZVONA@AI.AI.MIT.EDU cc: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].37603.860512.CENT> Date: Thu, 8 May 86 14:58:19 EDT From: David Chapman To: CENT@AI.AI.MIT.EDU I've gotten started on the mailing list migration. thanks. Occurs to me that a lot of archives in personal directories must be moved also. yup. suggestions? of course, there's only so much we can do...  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 11 MAY 86 09:43:58 EDT Date: Sun, 11 May 86 09:44:43 EDT From: Rob Austein Subject: COMSAT and DQXDEV To: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].37299.860511.SRA> Well, I finished DQXDEV and installed it everywhere to replace DQDEV (both still exist on all machines, DEVICE;JOBDEV DQ now points to DQXDEV). This will probably cause all mail on all ITS machines to lose completely but just might fix some of the randomness that has been happening lately.  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 9 MAY 86 23:20:51 EDT Date: Fri, 9 May 86 23:21:08 EDT From: Alan Bawden Subject: God may not place dice but COMSAT sure does.... To: SRA@XX.LCS.MIT.EDU cc: BUG-COMSAT@AI.AI.MIT.EDU In-reply-to: Msg of Thu 8 May 1986 23:19 EDT from Rob Austein Message-ID: <[AI.AI.MIT.EDU].36999.860509.ALAN> Date: Thu, 8 May 1986 23:19 EDT From: Rob Austein As near as I can tell, running DQDEV is like rolling dice. A certain percentage of queries fail, pretty much at random.... Yuck. Well look, after I get this paper in the mail (should happen sometime during the next week), let's decide how to replace DQDEV with something that has all the right properties (including working all of the time).  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 9 MAY 86 14:37:44 EDT Date: Fri, 9 May 86 14:38:02 EDT From: Ray Hirschfeld Subject: weird error from borax To: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].36801.860509.RAY> Date: Thu, 8 May 86 19:04:02 EDT From: MAILER-DAEMON at BORAX.LCS.MIT.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 BORAX.LCS.MIT.EDU (4.12/4.7); Thu, 8 May 86 19:03:58 edt Date: Thu, 8 May 86 19:04:02 EDT From: Ray Hirschfeld Subject: third floor printer To: (*MSG *MAC)@AI.AI.MIT.EDU Cc: sollins@XX.LCS.MIT.EDU Message-Id: <[AI.AI.MIT.EDU].36410.860508.RAY> The third floor printer, charmin, is back in operation, thanks to Scott Jones in the AI lab, from whom I was able to borrow a drum cartridge. They are low on cartridges too and cannot give us any more. More cartridges are on back order by our supplier. For now this is our very last one. PLEASE DO NOT USE CHARMIN UNLESS YOU ABSOLUTELY MUST. SEND ALL BUT FINAL COPIES TO ANOTHER PRINTER.  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 8 MAY 86 23:21:14 EDT Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU 8 May 86 23:21:24 EDT Date: Thu, 8 May 1986 23:19 EDT Message-ID: From: Rob Austein To: Alan Bawden Cc: BUG-COMSAT@AI.AI.MIT.EDU Subject: God may not place dice but COMSAT sure does.... In-reply-to: Msg of 8 May 1986 23:06-EDT from Alan Bawden Alan, As near as I can tell, running DQDEV is like rolling dice. A certain percentage of queries fail, pretty much at random. The more times you query a particular name, the greater your chances that that name will get lucky and barf in your face. SCRC gets massive amounts of mail from us. So they get lucky a lot. I'm sure there's some pattern to this PI driven DQDEV lossage, if only my tiny mind could encompass it. On the other hand, I probably wouldn't be good for much afterwards.... Yes, mail to SCRC does still work, on alternate Wednesdays. In fact, the same COMSAT talking to the same DQDEV will often be quite capable of answering the query, if you give it time to calm down. (For them as are keeping score, I saw a new one the other day -- a BURNUP on AI caused because DQDEV crapped out looking up DQ:HOSTS3;IN;PTR;6.0.2.10.IN-ADDR.ARPA. I was impressed....)  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 8 MAY 86 23:06:40 EDT Date: Thu, 8 May 86 23:06:55 EDT From: Alan Bawden Subject: [COMSAT: forwarded] To: BUG-COMSAT@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].36483.860508.ALAN> Date: Thu, 8 May 86 22:30:07 EDT From: Communications Satellite Error in input request file. Parsing error: Bad SITE spec - "@SCRC" Line stopped at is: RCPT:(fun @SCRC) So what the hell is wrong with this? Does the name "SCRC" -never- work any more? It seems to be in the HOSTS3 table.  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 8 MAY 86 21:17:53 EDT Date: Thu, 8 May 86 21:02:58 EDT From: Daniel Huttenlocher To: BUG-COMSAT@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].36445.860508.DPH> comsat on AI just sent me mail about queuing and unqueing a piece of mail I sent to NYU-AFC8, but I have the NOQC R-OPTION set, so it shouldn't have (and usually doesn't).  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 7 MAY 86 20:12:07 EDT Date: Wed, 7 May 86 20:12:01 EDT From: David Chapman Subject: Bitch, Whine, COMPLAIN! To: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].35825.860507.ZVONA> COMSAT doesn't know where Xerox is. OZ doesn't know where Xerox is. I sure hope %xerox.com@xx works... Date: Wed, 7 May 86 19:08:32 EDT From: Communications Satellite To: ZVONA at AI.AI.MIT.EDU cc: MAIL-MAINTAINERS at AI.AI.MIT.EDU Error in input request file. Parsing error: Bad SITE spec - "@XEROX.COM" Line stopped at is: RCPT:(deKleer.pa @XEROX.COM) Message not sent and not queued;text of bad file follows: -------- FROM-PROGRAM:BABYL FROM-XUNAME:ZVONA FROM-UNAME:ZVONA HEADER-FORCE:RFC733 AUTHOR:ZVONA RCPT:(deKleer.pa @XEROX.COM) TEXT;-1 Hi, I've accepted the CSLI money that Stan hassled for me, and so am declining your offer. But I'd like to spend about two-thirds of the summer at Xerox working on the same stuff anyway; I take it that's ok. I'd like to thank you very much for generating an offer for me and apologize for being slow in providing a reply. David Chapman  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 6 MAY 86 03:41:04 EDT Date: Tue, 6 May 86 03:40:38 EDT From: Alan Bawden Subject: ITS mania To: BUG-INQUIR@AI.AI.MIT.EDU cc: BUG-COMSAT@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].35088.860506.ALAN> Someone should install the INQUIR system on ML and MD. I note that a recent update I made to my entry changed the machines-known-on field to read: "ALAN@AI @MC @MX @MD". This indicates some kind of bogosity somewhere given that ML has been up for a couple weeks, and it doesn't appear here, but MD only came up today and yet here it is already! (The machines-known-on field is some kind of a joke anyway, given that there doesn't seem to be a way to change it, right?) For these other ITS machines we are sending distribution tapes to, we have to arrange for them to have some kind of an INQUIR database that they can modify. I guess that means they will need to run a local COMSAT, since I don't think any of them have a network connection. Can a COMSAT be built that only knows about the local host? Can someone do so, and write up some instructions on how to install it that we can send to these guys? Can someone build and empty INQUIR database and write up similar instructions for INQUIR? Please?  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 5 MAY 86 15:11:23 EDT Received: from MX.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 5 MAY 86 15:11:40 EDT Received: from XX.LCS.MIT.EDU by MX.LCS.MIT.EDU 5 May 86 15:09:23 EDT Date: Mon, 5 May 1986 15:08 EDT Message-ID: From: Rob Austein To: "David A. Moon" Cc: BUG-MAIL@MX.LCS.MIT.EDU, sra@XX.LCS.MIT.EDU In-reply-to: Msg of 3 May 1986 01:51-EDT from "David A. Moon" Date: Saturday, 3 May 1986 01:51-EDT From: "David A. Moon" To: BUG-MAIL@MX.LCS.MIT.EDU I think comsat job.07 has a hosts3.bin that is more than a day old mapped in. Certainly I can tell with Peek that it does not have the current one mapped in. whoops. i missed that one when i added RENMWO handling to dqdev. thanks.  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 3 MAY 86 17:07:59 EDT Date: Sat, 3 May 86 17:08:14 EDT From: David Chapman Subject: [COMSAT: forwarded] To: BUG-COMSAT@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].34362.860503.ZVONA> OK, how come :HOST can find LL and COMSAT can't? Date: Sat, 3 May 86 17:06:21 EDT From: Communications Satellite To: ZVONA at AI.AI.MIT.EDU cc: MAIL-MAINTAINERS at AI.AI.MIT.EDU Error in input request file. Parsing error: Bad SITE spec - "@LL.ARPA" Line stopped at is: RCPT:(sorceror @LL.ARPA) Message not sent and not queued;text of bad file follows: -------- FROM-PROGRAM:BABYL FROM-XUNAME:ZVONA FROM-UNAME:ZVONA HEADER-FORCE:RFC733 AUTHOR:ZVONA RCPT:(sorceror @LL.ARPA) SUBJECT: [COMSAT: forwarded] TEXT;-1 DOMAINS SUCK! Let's try again... Date: Sat, 3 May 86 17:04:03 EDT From: Communications Satellite To: ZVONA at AI.AI.MIT.EDU AUTHOR:ZVONA RCPT:(ariel @ATHENA.MIT.EDU) RCPT:(cindyb @ATHENA (R-OPTION CC)) RCPT:(rdo @EDDIE (R-OPTION CC)) RCPT:(sorceror @LL (R-OPTION CC)) RCPT:(zvona @AI (R-OPTION CC)) SUBJECT: various stuff USER-HEADER:In-reply-to: Msg of Fri 2 May 86 22:03:02 EDT from I'm cc'ing replies to your message to Rohit, Rodger, and Karl... hope you don't mind. From: Marty i detest administrivia as well. don't know who is going to do it; i don't think anybody likes it. Yeah. I'm upset 'cuz I did most of it this term. In retrospect, I think that Shawn repeatedly asked me to do things that she wanted done and I didn't care about, and I kept on doing it without complaining enough. We could get by with a lot less of it. i do think community outreach or whatever you want to call it is important, where else are the core group members going to come from if not the community? hilda and rohit very recently, karl last fall, and all the rest of us last spring would not have become members if not for advertising ourselves. Well, wasn't Hilda brought in by Rodger and Jennifer? Their tribe probably accounts for more than half of our membership. I think Karl came into the group because he was pointed at us by Leigh-Anne. Rohit's the only one that came because of postering. Though I like him a lot, and am glad we've got him. Have we had any totally spontaneous rituals that bombed? i don't remember; we've had so few spontaneous rituals... what about the one shawn took over last month because jennifer was sick? how did it go? i'm remembering the spring equinox ritual last spring when curt joined, (and you?, was that your first?), the crystal ball blessing last fall, the chakra meditation shawn did, the discordian ritual -- all of them went at least passably. There have been a couple that were just flat, no-ops. No one knew what to do and nothing happened. The spontaneous rituals we've had that have worked have also been ones where it was ``just us'' there, and I think that's very important. The reason I don't care much about advertising at this point is that I think that we have the makings of a viable coven. You've heard this flame before. Rohit feels the same way strongly, so I think next fall we will simply invite over to Shawn's house the people we want to have and do something. The group that was at that Beltaine ritual was just about right. We felt like family. The ritual that Shawn took over because Jennifer was sick was the one that no-one except the two of us and Karl showed up for. Last year's Spring equinox was great. It was my second or third. You remember, you and I planned it as we walked to and from the President's Court for earth? There was a great feeling of closeness. we seem more like a family in those situations, rather than a set of performers and an audience. sarah heskett stopped coming because she didn't like feeling like she was performing. i like getting all theatrical, but like it better when we are spontaneously theatrical rather than all the memorizing lines. I think that both types of rituals are important. The family rituals are the basis of coven structure, and are the way that the lunar meetings should go. They are the magic. The Sabbats should be elaborately theatrical and public. They are the religion, and they are the ones that bring in new people. We've had at least one very successful theatrical Sabbat, Samhain last year. One argument I've heard against closing the group in is that there won't be enough activity to keep the fringe people interested. But most of them only come once in a while anyway; I think that eight times a year is enough. We could up it a bit if necessary. You know, we've alientated a lot of people in a lot of different ways. Ray, Larry, Sarah, Lisa, Curt, ... It's too bad, but probably inevitable. Those of us who are left probably can work together if we try. I think that Beltaine worked partly because everyone just decided it would, and that they would get into it. I don't understand why that happened. But you know how usually not enough people bring enough cakes and wine? Everyone brought food. Why? Everyone brought a musical instrument or equivalent. The jam at the beginning was great. Why did that happen spontaneously? We should do that, plus chanting, for hours. There's no reason we can't. The wonderful ritual we had at your house one time, which was in fact planned in advance, was great because the last time we got together, we resolved that we would make the next ritual a good one, and again it was just us there, and it worked: we chanted a LONG time and all felt high. at xerox? howze that? I'm being funded by CSLI and/or Xerox to hang around ISL and cast my aura of brilliance over the place. I'll probably be part time there and part time at SRI-AI. Hey, by the way, I've got a bunch of stuff that should go in the Book of Scraps, I mean Shadows. Better leave it with someone when you go this summer. I'd also like to get my copy of Margot Adler back from you sometime.  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 3 MAY 86 01:52:24 EDT Received: from MX.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 3 MAY 86 01:52:35 EDT Date: Sat, 3 May 86 01:51:01 EDT From: "David A. Moon" To: BUG-MAIL@MX.LCS.MIT.EDU Message-ID: <[MX.LCS.MIT.EDU].235.860503.MOON> I think comsat job.07 has a hosts3.bin that is more than a day old mapped in. Certainly I can tell with Peek that it does not have the current one mapped in.  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 2 MAY 86 16:42:42 EDT Date: Fri, 2 May 86 16:42:40 EDT From: Alan Bawden Subject: [COMSAT: forwarded] To: DCP@SCRC-STONY-BROOK.ARPA cc: BUG-COMSAT@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].34071.860502.ALAN> This gets better and better, does COMSAT have something against poor DCP? Lets try again with a different spelling for STONY-BROOK. Since this lossage started, a second message has accumulated in DCP;DCP MAIL on AI. Date: Fri, 2 May 86 02:14:00 EDT From: Communications Satellite To: ALAN at AI.AI.MIT.EDU cc: MAIL-MAINTAINERS at AI.AI.MIT.EDU Error in input request file. Parsing error: Bad SITE spec - "@SCRC" Line stopped at is: RCPT:(DCP @SCRC) Message not sent and not queued;text of bad file follows: -------- FROM-PROGRAM:BABYL FROM-XUNAME:ALAN FROM-UNAME:ALAN HEADER-FORCE:RFC733 AUTHOR:ALAN RCPT:(DCP @SCRC) TEXT;-1 The really -interesting- thing about this message is that I retreived it from AI:DCP;DCP MAIL, where it was misdelivered due to some COMSAT lossage. Date: Fri, 2 May 86 01:27:25 EDT From: Alan Bawden Subject: These PARENTHESES have UNBALANCED my mail reader! To: INFO-EXPLORER@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].33811.860502.ALAN> Hey! Get a load of the amazo mail header field new from Symbolics! Date: Wed, 30 Apr 86 23:42 PDT From: DDYER at SCRC-RIVERSIDE.ARPA To: fun at WHITE Re: Good news/bad news -> Character-Type-Mappings: (1 0 (NIL 0) (NIL :ITALIC NIL) "CPTFONTI") Resent-To: rumors%oz@MIT-MC.ARPA Resent-From: tk@SCRC-STONY-BROOK.ARPA 1[rumor unrelated to relality:] 0I heard some film was smuggled out of Kiev which shows conclusively that everything is under control there. Unfortunately, when developed, the film proved to be completely fogged.  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 2 MAY 86 16:03:41 EDT Date: Fri, 2 May 86 16:03:10 EDT From: Alan Bawden Subject: Lossage on AI To: RDZ@AI.AI.MIT.EDU cc: BUG-COMSAT@MC.LCS.MIT.EDU, AILIST-REQUEST@AI.AI.MIT.EDU, BUG-MLDEV@AI.AI.MIT.EDU In-reply-to: Msg of Fri 2 May 86 14:02:45 EDT from Ramin Zabih Message-ID: <[AI.AI.MIT.EDU].34050.860502.ALAN> Date: Fri, 2 May 86 14:02:45 EDT From: Ramin Zabih To: ALAN at MC Re: Lossage on AI I've gotten a few DEVICE FULL errors on AI recently. Is something broken? What was broken was that someone moved the MIT redistribution of AIList from MC to AI, but they left the archives on MC and instructed COMSAT to update the archives through MLDEV. (That is, they put the filename "MC:COMMON;AILIST ARCHIV" in a mailing list on AI.) Unfortunately MLDEV has had a bug (for years) where IOC errors, such as directory full errors, cause the device server to hang forever, even after the user (COMSAT in this case) has closed its channel. After this happens a few time, the system fills up with dead ML: device servers and nobody can use any more job devices. Since COMSAT tries repeatedly to deliver the message, once this lossage starts it can only end when the maximum number of device servers have been used up. I removed the offending message from COMSAT's queue, so the AIList archives on ITS won't contain that most recent digest. Mail hackers should be aware that this problem still exists, and refrain from creating any more mailing lists directed at foreign filesystem. It would be nice if MLDEV didn't have this problem.  Date: Fri, 2 May 86 13:00:46 EDT From: Rob Austein Subject: Here's the scoop, folks To: BUG-COMSAT@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].902111.860502.SRA> 1) The version of DQDEV on MC and MX is definitely bogus. The error handling loses due to bogus BOJ interrupt handling. Result of all this is that null answers get handed back (randomly), and since the NETRTS code uses the same buffer every time it does resolver queries, COMSAT gets handed back whatever was in that buffer, usually the last name it succesfully resolved. 2) I put some more paranoid code in COMSAT and the RESOLV library. I also changed the DQDEV code that (I think) is causing the problem. Alan, if you have the time and the stomach, you might check what I did to see if it is reasonable. I'm pretty sure it still isn't right from the results I get running in experimental mode. This is the DQDEV currently up on AI. 3) As an experiment I tried removing all the "@" signs from the header people list, ie, (FOO @BAR) became (FOO BAR). It certainly changed things (see AI: SRA; PRETTY WEIRD) but didn't fix them. This suggest anything? 4) I'll be back sunday. If anybody wants to play while I'm gone, feel free. Building a COMSAT should be routine. Building a DQDEV is not, there are some locations that have to be patched in order for it to run on all (like, SPACY1 doesn't exist on all machines, IOC handling is totally bogus, that sort of thing). Are we having fun yet?  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 2 MAY 86 05:56:04 EDT Date: Fri, 2 May 86 05:56:07 EDT From: "Pandora B. Berman" Subject: bogus lengths To: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].33890.860502.CENT> MC comsat is producing supposedly oversize badreqs again. thing is, the stats file records different sizes than the files are. i tried to remail one and it died again, giving a different, shorter spurious size than before.  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 2 MAY 86 03:56:42 EDT Date: Fri, 2 May 86 03:56:38 EDT From: "Pandora B. Berman" Subject: open mouth, insert foot To: HEADER-PEOPLE@AI.AI.MIT.EDU cc: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].33875.860502.CENT> Moving this list to AI shook loose a number of bugs, probably within the timing of the ITS address resolver rather than inside COMSAT. This sad situation is being worked on. Until it is corrected, HEADER-PEOPLE is moved back to MC, which being a KL runs faster than AI (a KS).  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 2 MAY 86 02:55:45 EDT Date: Fri, 2 May 86 02:55:45 EDT From: "Pandora B. Berman" Subject: we're not alone To: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].33854.860502.CENT> RAND-UNIX has a identity crisis: Date: Fri, 2 May 86 01:05:43 EDT From: Mail Delivery Subsystem Subject: Returned mail: Host unknown To: ----- Transcript of session follows ----- 550 ... Host unknown [note that 10.3.0.7 is RAND-UNIX's Arpa address.] ----- Unsent message follows ----- Date: Fri, 2 May 86 01:05:43 EDT From: "Pandora B. Berman" Subject: more resolver lossage To: BUG-MAIL@AI.AI.MIT.EDU, greep@rand-unix.ARPA another garbled address. i'm pretty sure this said RAND-UNIX, not WASHINGTON, when i sent it. however (see COMSAT log) it got parsed as WASHINGTON's local-net address. ---------- Date: Fri, 2 May 86 00:06:06 EDT From: Communications Satellite Subject: Msg of Thursday, 1 May 1986 23:41-EDT To: CENT@AI.AI.MIT.EDU FAILED: Greep at WASHINGTON.ARPA; Recipient name apparently rejected. Last reply was: {550 No such local mailbox as "Greep", recipient rejected} Failed message follows: ------- Date: Thu, 1 May 86 23:41:32 EDT From: "Pandora B. Berman" Subject: foot in mouth To: OBERST%EDUCOM.MAILNET@MULTICS.MIT.EDU, FURUTA@WASHINGTON.ARPA, Feinler@SRI-KL.ARPA, ekrell@LOCUS.UCLA.EDU, E-SHARP@UTAH-20.ARPA, 8348016%WWU@CSNET-RELAY.ARPA, bruce@GODOT.THINK.COM, NSF-CS@USC-ISI.ARPA, estrin@USC-ECL.ARPA, seki%SMURF.DEC@DECWRL.DEC.COM, Greep@WASHINGTON.ARPA, BURNUM%VANDVMS1.BITNET@WISCVM.WISC.EDU, Foxea%vtvax3.bitnet@WISCVM.WISC.EDU, S-HEADER%CARLETON.BITNET@WISCVM.WISC.EDU, erik%odin.re.nta.uninett@NTA-VAX.ARPA cc: BUG-MAIL@AI.AI.MIT.EDU Date: Thu, 1 May 86 03:50:27 EDT From: "Pandora B. Berman" Subject: list moving To: HEADER-PEOPLE@AI.AI.MIT.EDU The HEADER-PEOPLE mailing list has moved (back) to MIT-AI, also known now as AI.AI.MIT.EDU. Recent mail to the list lives in the file KSC;HEADER MINS on AI, while older archives are in VAFB;HEADER MINS09 through MINS14, also on AI. These files are trivially accessible over the Arpanet via FTP; we regret that this is not of much help to those list members not on the Arpanet. Please remember to address your add/remove/change requests to HEADER-PEOPLE-REQUEST@AI, not to the main list. This move, by the way, is indeed to be taken as a sign that COMSAT, the ITS mailer daemon, is fixed. It no longer has to keep the host tables in its address space, which leaves all that room to be taken up by other data, like longer messages. A lot of mail, especially to lists like this which live on ITSs, has been sidetracked over the past few months while the local hackers were fixing COMSAT. We expect to start sending out this backlog during the next week; the process will take several days, in order to avoid overloading COMSAT or overworking us. An ArpaNet-BBOARDS msg explaining this retransmission will be broadcast sometime in the next few days. even though you're on HEADER-PEOPLE, you didn't get the above message. Sending it uncovered a rash of bugs, which we think are nesting somewhere in the ITS address resolver rather than in COMSAT itself. so HEADER-PEOPLE is moving back to MC for a while longer. ITS mutual forwarding is in effect, so your mail to HEADER-PEOPLE at either AI or MC should go out relatively error-free.  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 2 MAY 86 02:05:42 EDT Date: Fri, 2 May 86 02:05:41 EDT From: Alan Bawden Subject: Parsing of hostnames using dice! To: BUG-COMSAT@MC.LCS.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].33827.860502.ALAN> Pardon me for including this whole script, but I can't figure out an easy way to make it smaller. There are at least two interesting things to notice about this session: HIC and DCP. Read on. 012725 InReq: 1 > 1; SPECS:{J:BABYL}{ALAN}{CLAIMS-TO-BE:ALAN}{TL=595.} ID=<[AI.AI.MIT.EDU].33811.860502.ALAN> EXP->INFO-EXPLORER@1200400006::=((@FILE [GREGOR;EXPLOR TEXT])@1200400006::=(ZVONA@1200400006,TK@1200400006::=(TK@40700001440),TIM@1200400006::=(TIM@40700001440),terman@40700004120,TATAR@1200400006::=(tatar.pa@1200400040),TAFT@1200400006::=(TAFT@40700001440),SOLEY@1200400006::=(SOLEY@40700001440),SRA@1200400006::=(sra@40700002420),Sidney@40700011406,Saenz@40700004120,RZ@1200400006::=(RZ@40700015316),RWG@1200400006::=(rwg@30002424620),romkey@2202400101,rob@40700004120,RDZ@1200400006,PGS@1200400006,Parker@40700011406,PAE@1200400006::=(s.pae@40700005542),MT@1200400006::=(MT@2225200002),Moon@30002424620,MMCM@1200400006::=(MMCM@30002424620),MLY-SAVE@1200400006::=((FILE [MLY;MLY MAIL])@1200400006),me@40700011406,LWA@1200400006::=(lwa@2202400102),KWH@1200400006,KLOTZ@1200400006::=(KLOTZ@40700001440),JTW@1200400006::=(jtw@40700012035),joseph@30002424620,JNC@1200400006::=(JNC@40700002420),jma@40700004120,JINX@40700011406,jfc@40700011406,JCMA@1200400006::=(jcma@40700013065),HIC@1200400006::=(HIC@1200600054),HGA@1200400006::=(hga@40700016310),Henry-News@40700011406,HENRIK@1200400006::=(HENRIK@40700001440),GUMBY@1200400006::=(GUMBY@40700001440),GSB@1200400006::=(GSB@40700001440),GREGOR@1200400006::=(GREGOR@40700001440),GLR@1200400006::=(GLR@40700011406),GAVAN@1200400006::=(AI.Duffy@1200200076),Foner@40700011406,fleck@40700011406,EHL@1200400006::=(EHL@40700001440),ED@1200400006::=(ED@40700001440),DPH@1200400006,DLA@1200400006::=(DLA@30002424620),deKleer@1200400040,DCP@1200400006,DANNY@1200400006::=(danny@1201000006),DANIEL@1200400006,CWH@1200400006::=(CWH@40700015316),CSTACY@1200400006,CJL@1200400006::=(CJL@40700013065),CENT@1200400006,CBF@1200400006::=(CBF@40700001440),buckley@40700011406,brooks@40700011406,brd@40700011406,BERLIN@1200400006::=(BERLIN@40700002420),BEE@1200400006::=(BEE@40700001440),BATALI@1200400006::=(BATALI@40700011406),ALAN@1200400006,AKR@1200400006,Agre-OZ@40700011406,Aab@40700011406)) 013000 Local->AI.AI.MIT.EDU 013000 TO->AKR 013001 TO->ALAN 013001 TO->CENT 013001 TO->CSTACY 013005 TO->DANIEL 013006 TO->DCP This is bogus. DCP's INQUIR entry clearly indicates his mail is to be sent to SCRC. 013006 TO->DPH 013008 TO->KWH 013009 TO->[MLY;MLY MAIL] 013023 TO->PGS 013023 TO->RDZ 013024 TO->ZVONA 013026 ICP->R20.UTEXAS.EDU (TCP-SMTP) 013034 TO->AI.Duffy 013056 ICP->XEROX.COM (TCP-SMTP) 013103 XTO->deKleer 013105 XTO->tatar.pa 013106 TEXT-> 013124 ICP->MC.LCS.MIT.EDU (CHAOS-MAIL) 013125 TO->HIC...NSMBYE timed out Ignoring the fact that I haven't the slightest idea what "...NSMBYE timed out" means, I note that this is the first of -two- occasions on which COMSAT is going to connect to MC to deliver this message. If you check out the expansion of HIC's address above, you will see that COMSAT has decided that he is HIC@1200600054 (TCP address) while everybody else at MC has been assigned the address @40700001440 (Chaos address). 013126 ICP->GODOT.THINK.COM (TCP-SMTP) 013128 TO->danny 013131 ICP->BORAX.LCS.MIT.EDU (TCP-SMTP) 013135 TO->romkey 013142 ICP->COMET.LCS.MIT.EDU (TCP-SMTP) 013145 TO->lwa 013157 ICP->MEDIA-LAB.MIT.EDU (TCP-SMTP) 013208 TO->MT 013242 ICP->SCRC-STONY-BROOK.ARPA (TCP-SMTP) 013245 XTO->DLA 013248 XTO->joseph 013249 XTO->MMCM 013250 XTO->Moon 013251 XTO->rwg 013251 TEXT-> 013256 ICP->MC.LCS.MIT.EDU (CHAOS-MAIL) Here we are connecting to MC again. At some level COMSAT is unaware that they are the same machine. 013303 XTO->BEE 013304 XTO->CBF 013305 XTO->ED 013306 XTO->EHL 013307 XTO->GREGOR 013307 XTO->GSB 013308 XTO->GUMBY 013308 XTO->HENRIK 013309 XTO->KLOTZ 013310 XTO->SOLEY 013310 XTO->TAFT 013311 XTO->TIM 013311 XTO->TK 013311 TEXT-> 013313 ICP->XX.LCS.MIT.EDU (CHAOS-MAIL) 013315 XTO->BERLIN 013317 XTO->JNC 013318 XTO->sra 013319 TEXT-> 013322 ICP->VAX.LCS.MIT.EDU (CHAOS-MAIL) 013325 XTO->jma 013326 XTO->rob 013326 XTO->Saenz 013327 XTO->terman 013327 TEXT-> 013334 ICP->DEEP-THOUGHT.MIT.EDU (CHAOS-MAIL) 013336 TO->s.pae 013343 ICP->OZ.AI.MIT.EDU (CHAOS-MAIL) 013345 XTO->Aab 013349 XTO->Agre-OZ 013349 XTO->BATALI 013350 XTO->brd 013351 XTO->brooks 013352 XTO->buckley 013353 XTO->fleck 013354 XTO->Foner 013356 XTO->GLR 013356 XTO->Henry-News 013357 XTO->jfc 013358 XTO->JINX 013359 XTO->me 013400 XTO->Parker 013402 XTO->Sidney 013402 TEXT-> 013404 ICP->SPEECH.MIT.EDU (CHAOS-MAIL) 013406 TO->jtw 013410 ICP->REAGAN.AI.MIT.EDU (CHAOS-MAIL) 013411 XTO->CJL 013412 XTO->jcma 013412 TEXT-> 013413 ICP->ZERMATT.LCS.MIT.EDU (CHAOS-MAIL) 013415 XTO->CWH 013418 XTO->RZ 013418 TEXT-> 013420 ICP->CCC.MIT.EDU (CHAOS-MAIL) 013423 TO->hga  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 2 MAY 86 01:46:11 EDT Received: from lll-tis-b.ARPA by AI.AI.MIT.EDU 2 May 86 01:46:04 EDT Return-Path: Received: by lll-tis-b.ARPA id AA21854; Thu, 1 May 86 22:44:18 pdt Date: Thu, 1 May 86 22:44:18 pdt From: Erik E. Fair Message-Id: <8605020544.AA21854@lll-tis-b.ARPA> To: BUG-MAIL@AI.AI.MIT.EDU, CENT@AI.AI.MIT.EDU Subject: Re: comsat fixed? Thanks for the info; I had assumed that when next MC died of hardware failure that the entire thing would go away entirely (i.e. no replacement hardware at all) and I was wondering about all those mailing lists, who, according to the list of lists, live on MC. Erik E. Fair styx!fair fair@lll-tis-b.arpa  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 2 MAY 86 01:34:53 EDT Date: Fri, 2 May 86 01:34:25 EDT From: "Pandora B. Berman" Subject: comsat fixed? To: BUG-MAIL@AI.AI.MIT.EDU, fair@LLL-TIS-B.ARPA Message-ID: <[AI.AI.MIT.EDU].33812.860502.CENT> Date: Thu, 1 May 86 18:39:20 pdt From: Erik E. Fair To: CENT@AI.AI.MIT.EDU Subject: Re: list moving Newsgroups: local.header-people Your message mentions that COMSAT has been fixed. Does this mean that 1. it will process return-paths correctly? 2. it will cease and desist from sending back those blasted delivery progress messages? (i.e. Haven't gotten through to the following hosts; will keep trying for 2 more days) I run the USENET gateway at ucbvax, and a lot of cruft comes my way because the sender is listed as being `usenet@ucbvax.berkeley.edu' despite the fact that the return-path points (thru header hackery) at the list-request address. Erik E. Fair styx!fair fair@lll-tis-b.arpa P.S. What of the rest of the lists on MC? Are they all moving? "Fixed" is a relative term. in this case it mostly meant that COMSAT no longer must keep the host tables in its address space, which leaves lots of space free for msgs longer than 2-3 ITS blocks (~10K-15K chars). For what it's worth (you may already realize this), COMSAT does not produce the silly delivery progress msgs, it merely sends them along when some twenex or whatever out there sends them here addressed for the msg author. I don't know about the return-paths. maybe the COMSAT hackers can provide you with more info on these. in fact, moving HEADER-PEOPLE to AI stirred up a mess of bugs, we think in the address resolver rather than in COMSAT itself. it appears (that is, my relatively uneducated estimation of the situation is) that the code that has been behaving nicely on our KL doesn't go fast enough on a KS to refrain from losing, so the list has been moved back to MC until these problems can be tracked down. as to other MC lists: sometime in the next few months, MC is going to undergo a hardware change. the KL10A will switch names with the KS10 currently under the alias of MIT-MX. some of the lists now on MC will move to AI, but many (probably most large ones) will move to the new MC, which is slated for employment as a mail-forwarding nexus.  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 2 MAY 86 01:06:07 EDT Date: Fri, 2 May 86 01:05:43 EDT From: "Pandora B. Berman" Subject: more resolver lossage To: BUG-MAIL@AI.AI.MIT.EDU, greep@RAND-UNIX.ARPA Message-ID: <[AI.AI.MIT.EDU].33808.860502.CENT> another garbled address. i'm pretty sure this said RAND-UNIX, not WASHINGTON, when i sent it. however (see COMSAT log) it got parsed as WASHINGTON's local-net address. ---------- Date: Fri, 2 May 86 00:06:06 EDT From: Communications Satellite Subject: Msg of Thursday, 1 May 1986 23:41-EDT To: CENT@AI.AI.MIT.EDU FAILED: Greep at WASHINGTON.ARPA; Recipient name apparently rejected. Last reply was: {550 No such local mailbox as "Greep", recipient rejected} Failed message follows: ------- Date: Thu, 1 May 86 23:41:32 EDT From: "Pandora B. Berman" Subject: foot in mouth To: OBERST%EDUCOM.MAILNET@MULTICS.MIT.EDU, FURUTA@WASHINGTON.ARPA, Feinler@SRI-KL.ARPA, ekrell@LOCUS.UCLA.EDU, E-SHARP@UTAH-20.ARPA, 8348016%WWU@CSNET-RELAY.ARPA, bruce@GODOT.THINK.COM, NSF-CS@USC-ISI.ARPA, estrin@USC-ECL.ARPA, seki%SMURF.DEC@DECWRL.DEC.COM, Greep@WASHINGTON.ARPA, BURNUM%VANDVMS1.BITNET@WISCVM.WISC.EDU, Foxea%vtvax3.bitnet@WISCVM.WISC.EDU, S-HEADER%CARLETON.BITNET@WISCVM.WISC.EDU, erik%odin.re.nta.uninett@NTA-VAX.ARPA cc: BUG-MAIL@AI.AI.MIT.EDU Date: Thu, 1 May 86 03:50:27 EDT From: "Pandora B. Berman" Subject: list moving To: HEADER-PEOPLE@AI.AI.MIT.EDU The HEADER-PEOPLE mailing list has moved (back) to MIT-AI, also known now as AI.AI.MIT.EDU. Recent mail to the list lives in the file KSC;HEADER MINS on AI, while older archives are in VAFB;HEADER MINS09 through MINS14, also on AI. These files are trivially accessible over the Arpanet via FTP; we regret that this is not of much help to those list members not on the Arpanet. Please remember to address your add/remove/change requests to HEADER-PEOPLE-REQUEST@AI, not to the main list. This move, by the way, is indeed to be taken as a sign that COMSAT, the ITS mailer daemon, is fixed. It no longer has to keep the host tables in its address space, which leaves all that room to be taken up by other data, like longer messages. A lot of mail, especially to lists like this which live on ITSs, has been sidetracked over the past few months while the local hackers were fixing COMSAT. We expect to start sending out this backlog during the next week; the process will take several days, in order to avoid overloading COMSAT or overworking us. An ArpaNet-BBOARDS msg explaining this retransmission will be broadcast sometime in the next few days. even though you're on HEADER-PEOPLE, you didn't get the above message. Sending it uncovered a rash of bugs, which we think are nesting somewhere in the ITS address resolver rather than in COMSAT itself. so HEADER-PEOPLE is moving back to MC for a while longer. ITS mutual forwarding is in effect, so your mail to HEADER-PEOPLE at either AI or MC should go out relatively error-free.  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 1 MAY 86 23:47:22 EDT Date: Thu, 1 May 86 23:41:32 EDT From: "Pandora B. Berman" Subject: foot in mouth To: OBERST%EDUCOM.MAILNET@MULTICS.MIT.EDU, FURUTA@WASHINGTON.ARPA, Feinler@SRI-KL.ARPA, ekrell@LOCUS.UCLA.EDU, E-SHARP@UTAH-20.ARPA, 8348016%WWU@CSNET-RELAY.ARPA, bruce@GODOT.THINK.COM, NSF-CS@USC-ISI.ARPA, estrin@USC-ECL.ARPA, seki%SMURF.DEC@DECWRL.DEC.COM, Greep@WASHINGTON.ARPA, BURNUM%VANDVMS1.BITNET@WISCVM.WISC.EDU, Foxea%vtvax3.bitnet@WISCVM.WISC.EDU, S-HEADER%CARLETON.BITNET@WISCVM.WISC.EDU, erik%odin.re.nta.uninett@NTA-VAX.ARPA cc: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].33778.860501.CENT> Date: Thu, 1 May 86 03:50:27 EDT From: "Pandora B. Berman" Subject: list moving To: HEADER-PEOPLE@AI.AI.MIT.EDU The HEADER-PEOPLE mailing list has moved (back) to MIT-AI, also known now as AI.AI.MIT.EDU. Recent mail to the list lives in the file KSC;HEADER MINS on AI, while older archives are in VAFB;HEADER MINS09 through MINS14, also on AI. These files are trivially accessible over the Arpanet via FTP; we regret that this is not of much help to those list members not on the Arpanet. Please remember to address your add/remove/change requests to HEADER-PEOPLE-REQUEST@AI, not to the main list. This move, by the way, is indeed to be taken as a sign that COMSAT, the ITS mailer daemon, is fixed. It no longer has to keep the host tables in its address space, which leaves all that room to be taken up by other data, like longer messages. A lot of mail, especially to lists like this which live on ITSs, has been sidetracked over the past few months while the local hackers were fixing COMSAT. We expect to start sending out this backlog during the next week; the process will take several days, in order to avoid overloading COMSAT or overworking us. An ArpaNet-BBOARDS msg explaining this retransmission will be broadcast sometime in the next few days. even though you're on HEADER-PEOPLE, you didn't get the above message. Sending it uncovered a rash of bugs, which we think are nesting somewhere in the ITS address resolver rather than in COMSAT itself. so HEADER-PEOPLE is moving back to MC for a while longer. ITS mutual forwarding is in effect, so your mail to HEADER-PEOPLE at either AI or MC should go out relatively error-free.  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 1 MAY 86 23:05:58 EDT Date: Thu, 1 May 86 23:05:56 EDT From: "Pandora B. Berman" Subject: Msg of Tuesday, 29 April 1986 18:38-EDT To: MAP@AI.AI.MIT.EDU, PAO@DEEP-THOUGHT.MIT.EDU cc: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].33772.860501.CENT> Date: Tue, 29 Apr 86 18:38:38 EDT From: Communications Satellite Subject: Msg of Tuesday, 29 April 1986 18:38-EDT To: PAO@DEEP-THOUGHT.MIT.EDU Resent-To: postmaster@MIT-AI.ARPA Resent-From: PAO@EECS.MIT.EDU Resent-Date: Thu, 1 May 86 14:36 EDT ============ A copy of your message is being returned, because: =========== "R-OPTION" at AI.AI.MIT.EDU is an unknown recipient. This name came from the expansion of MAP-LISPM-MAIL ============ Failed message follows: ============ Date: Tue, 29 Apr 86 18:32 EDT From: Patrick A. O'Donnell Subject: Compromised passwords To: psr@OZ.AI.MIT.EDU, drm@MIT-XX.ARPA cc: info-lispm@OZ.AI.MIT.EDU [original msg to INFO-LISPM omitted] MAP misparenthesized in creating some of his myriad personal mailing lists. i think i have fixed all of them.  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 1 MAY 86 06:07:33 EDT Date: Thu, 1 May 86 06:07:27 EDT From: "Pandora B. Berman" Subject: more barfage To: BUG-mail@MC.LCS.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].33422.860501.CENT> this is ridiculous. ---------- Date: Thu, 1 May 86 05:29:10 EDT From: Communications Satellite Subject: Msg of Thursday, 1 May 1986 05:28-EDT To: CENT@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].33407.860501> ============ A copy of your message is being returned, because: ============ "ITS_BUGS%QZCOM.MAILNET@MULTICS" at AI.AI.MIT.EDU is an unknown recipient. This name came from the expansion of (BUG ITS) "MOON-JUNK@SYMBOLICS" at AI.AI.MIT.EDU is an unknown recipient. This name came from the expansion of (BUG ITS) ============ Failed message follows: ============ Date: Thu, 1 May 86 05:28:04 EDT From: "Pandora B. Berman" Subject: imp lossage To: BUG-ITS@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].33406.860501.CENT> AI crashed around 3 or so. complained about IMP lossage of some sort. dumped to CRASH;IMPOS LOSS.  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 1 MAY 86 05:12:50 EDT Date: Thu, 1 May 86 05:12:39 EDT From: "Pandora B. Berman" Subject: header-people loses pretty big To: BUG-mail@MC.LCS.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].33402.860501.CENT> i just moved header-people to AI. it produced the following problems: Date: Thu, 1 May 86 03:55:33 EDT From: Communications Satellite Subject: Msg of Thursday, 1 May 1986 03:50-EDT To: CENT@AI.AI.MIT.EDU ============ A copy of your message is being returned, because: =========== "R-OPTION" at AI.AI.MIT.EDU is an unknown recipient. This name came from the expansion of MAP-HEADER-PEOPLE-MAIL, from (@FILE [KSC;HEADER PEOPLE]), from HEADER-PEOPLE [MAP is a twit; i fixed this and about 4 other personal lists of his.] ------ 12 errors trying to parse the file DSK:KSC;HEADER PEOPLE --L5 EVAL error: Bad SITE spec - "@CSNET-RELAY" In list: (8348016%WWU @CSNET-RELAY) --L21 EVAL error: Bad SITE spec - "@WISCVM" In list: (BURNUM%VANDVMS1.BITNET @WISCVM) --L40 EVAL error: Bad SITE spec - "@UTAH-20" In list: (E-SHARP @UTAH-20) --L41 EVAL error: Bad SITE spec - "@UCLA-LOCUS" In list: (ekrell @UCLA-LOCUS) --L46 EVAL error: Bad SITE spec - "@USC-ECL" In list: (estrin @USC-ECL) --L48 EVAL error: Bad SITE spec - "@SRI-KL" In list: (Feinler @SRI-KL) --L51 EVAL error: Bad SITE spec - "@WISCVM" In list: (Foxea%vtvax3.bitnet @WISCVM) --L53 EVAL error: Bad SITE spec - "@Washington" In list: (FURUTA @Washington) --L55 EVAL error: Bad SITE spec - "@RAND-UNIX" In list: (Greep @RAND-UNIX) --L153 EVAL error: Bad SITE spec - "@USC-ISI" In list: (NSF-CS @USC-ISI) --L154 EVAL error: Bad SITE spec - "@MULTICS" In list: (OBERST%EDUCOM.MAILNET @MULTICS) --L181 EVAL error: Bad SITE spec - "@DECWRL.DEC.COM" In list: (seki%SMURF.DEC @DECWRL.DEC.COM) [msg omitted] these complaints are batshit. these hosts exist. for most of the above complaints, the msg went through to other addresses on h-p at the same host, with the same address syntax (abbreviations and whatnot) without trouble. Date: Thu, 1 May 86 04:25:38 EDT From: Communications Satellite Subject: Msg of Thursday, 1 May 1986 03:50-EDT To: CENT@AI.AI.MIT.EDU Queued: mcvax!ace!henk at SEISMO.CSS.GOV, RICK at SEISMO.CSS.GOV, eric at UCBVAX.BERKELEY.EDU, jkf at UCBVAX.BERKELEY.EDU, mtxinu!ea!uokvax!emks at UCBVAX.BERKELEY.EDU, nbires!mccallum at UCBVAX.BERKELEY.EDU, netinfo%ucbjade at UCBVAX.BERKELEY.EDU, ulysses!smb at UCBVAX.BERKELEY.EDU, Header-People at CISL-SERVICE-MULTICS.ARPA, SCHOW%FSU.MFENET at LLL-MFE.ARPA, ucl-header-people at CS.UCL.AC.UK, ericb%eclipse at UCBVAX.BERKELEY.EDU, header-people at USC-CSE.USC.EDU [those who were queued but went through soon removed from above list.] FAILED: S-HEADER at BBN-LABS-B.ARPA; Recipient name apparently rejected. Last reply was: {550 (USER) Unknown user name in "S-HEADER@BBN-LABS-B.ARPA"} FAILED: bruce at WASHINGTON.ARPA; Recipient name apparently rejected. Last reply was: {550 No such local mailbox as "bruce", recipient rejected} FAILED: erik at CSNET-RELAY.ARPA; Recipient name apparently rejected. Last reply was: {550 (USER) Unknown user name in "erik@CSNET-RELAY.ARPA"} indeed, none of these addresses exist at these hosts. for each of these, the personal address should be at another host. comsat, or maybe DQ, seems to be hanging onto the host name a fraction too long -- in each of these cases, the previous host in the text of the list is attached to the personal address. e.g., two lines excerpted from the Bs: ---------- (BOB @WASHINGTON) ; B. Albrightson. asked. (bruce @THINK.COM) ; B. Nemnich, asked 26sep85 ---------- Failed message follows: ------- Date: Thu, 1 May 86 03:50:27 EDT From: "Pandora B. Berman" Subject: list moving To: HEADER-PEOPLE@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].33378.860501.CENT> The HEADER-PEOPLE mailing list has moved (back) to MIT-AI, also known now as AI.AI.MIT.EDU. Recent mail to the list lives in the file KSC;HEADER MINS on AI, while older archives are in VAFB;HEADER MINS09 through MINS14, also on AI. These files are trivially accessible over the Arpanet via FTP; we regret that this is not of much help to those list members not on the Arpanet. Please remember to address your add/remove/change requests to HEADER-PEOPLE-REQUEST@AI, not to the main list. This move, by the way, is indeed to be taken as a sign that COMSAT, the ITS mailer daemon, is fixed. It no longer has to keep the host tables in its address space, which leaves all that room to be taken up by other data, like longer messages. A lot of mail, especially to lists like this which live on ITSs, has been sidetracked over the past few months while the local hackers were fixing COMSAT. We expect to start sending out this backlog during the next week; the process will take several days, in order to avoid overloading COMSAT or overworking us. An ArpaNet-BBOARDS msg explaining this retransmission will be broadcast sometime in the next few days. ^_ i hope i don't have to take the above back...  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 30 APR 86 23:07:07 EDT Date: Wed, 30 Apr 86 23:06:56 EDT From: "Pandora B. Berman" Subject: Note: Gobbling LSR1 database To: BUG-COMSAT@MC.LCS.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].33265.860430.CENT> Date: Wed, 30 Apr 86 04:05:55 EDT From: "Christopher C. Stacy" Subject: Note: Gobbling LSR1 database To: BUG-COMSAT@AI.AI.MIT.EDU I think the code which determines if COMSAT should gobble the databases may have a bug. In the STATS files it looks like it does it too often. it has seemed to me like it gobbles them too frequently. i notice that on MC (perhaps this is true generally of COMSAT IV) it now only swallows LSR1 every small N, rather than LSR1 and NAMES >.  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 30 APR 86 21:16:14 EDT Date: Wed, 30 Apr 86 21:15:18 EDT From: Alan Bawden Subject: Fixed, I think... To: BUG-COMSAT@MC.LCS.MIT.EDU, SRA@AI.AI.MIT.EDU In-reply-to: Msg of Wed 30 Apr 86 19:13:29 EDT from Rob Austein Message-ID: <[AI.AI.MIT.EDU].33230.860430.ALAN> Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 30 APR 86 19:14:36 EDT Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 30 APR 86 19:13:44 EDT Date: Wed, 30 Apr 86 19:13:29 EDT From: Rob Austein Subject: Fixed, I think... To: BUG-COMSAT@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].33204.860430.SRA> MC, AI, and MX are all now running COMSAT IV.516. DQDEV should be a little less erratic now. I have no idea how many of the weird symptoms reported will be fixed by this. Obviously a trashed stack can cause almost anything.... Except this message went to Bug-Random-Program because of the Bug- host mix up.  Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU 30 Apr 86 13:44:03 EDT Date: Wed, 30 Apr 1986 13:40 EDT Message-ID: From: Rob Austein To: bug-comsat@MC.LCS.MIT.EDU Subject: strange behavior Much of the strange behavior is caused by a bug I found late yesterday (stack is getting messed up under a certain set of circumstances). I haven't installed the version with this fixed because the fix revealed another bug that I haven't tracked down yet. Should be done by tonight.  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 30 APR 86 04:06:13 EDT Date: Wed, 30 Apr 86 04:05:55 EDT From: "Christopher C. Stacy" Subject: Note: Gobbling LSR1 database To: BUG-COMSAT@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].32887.860430.CSTACY> I think the code which determines if COMSAT should gobble the databases may have a bug. In the STATS files it looks like it does it too often.  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 30 APR 86 03:13:35 EDT Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 30 APR 86 03:13:16 EDT Received: from MOSCOW-CENTRE.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 30 APR 86 03:13:28 EDT Date: Tue, 22 Oct 85 09:54:27 EDT From: "Christopher C. Stacy" Subject: COMSAT bug To: CSTACY@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].688488.851022.CSTACY> Resent-To: BUG-COMSAT@MIT-AI.ARPA Resent-From: CStacy@MIT-AI.ARPA Resent-Date: Wed, 30 Apr 86 03:13 EDT Resent-Message-ID: <860430031311.1.CSTACY@MOSCOW-CENTRE.AI.MIT.EDU> When unqueuing to an Internet host, if init lost R=550, we don't seem to note a permanent error.  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 30 APR 86 02:35:40 EDT Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 30 APR 86 02:35:21 EDT Received: from MOSCOW-CENTRE.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 30 APR 86 02:35:34 EDT Date: Thu, 13 Feb 86 07:43:44 EST From: "Christopher C. Stacy" Subject: Request results To: CSTACY@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].817047.860213.CSTACY> Resent-To: BUG-COMSAT@MIT-AI.ARPA Resent-From: CStacy@MIT-AI.ARPA Resent-Date: Wed, 30 Apr 86 02:35 EDT Resent-Message-ID: <860430023516.6.CSTACY@MOSCOW-CENTRE.AI.MIT.EDU> Message deleted: Date: 11 Apr 1984 09:23:40-MST From: donegan@rice Received: by rice.ARPA (AA16018); Wed, 11 Apr 84 10:01:41 CST Date: Wed, 11 Apr 84 10:01:41 CST From: Mike Donegan Message-Id: <8404111601.AA16018@rice.ARPA> To: info-ada@mit-mc.ARPA Subject: Re: Larry Carroll Thanks to Larry, we now know how to fill up all the transmission lines of the entire nation. Watch the ping-ponging cc. Help, my mailbox runneth over. mkd Date: 02/13/86 07:37:11 From: CSTACY at MC.LCS.MIT.EDU Sender: CSTACY' at MC.LCS.MIT.EDU To: CSTACY at MC.LCS.MIT.EDU Re: Request results Message deleted: Date: 11 April 1984 14:21-EST From: Rosemary B. Hegg Subject: Saxe Seminar To: (*MSG *MIT) @ MIT-MC SEMINAR DATE: Friday, April 13th, 1984 TIME: Refreshments 3.15 pm Lecture 3.30 pm PLACE: NE43-512A Retiming Synchronous Circuit for Multiphase Clocking James B. Saxe Carnegie-Mellon University ABSTRACT Retiming is a method of circuit optimization in which the placement of registers in the circuit is changed in such a way that the logical behavior of the circuit is preserved. Retiming can increase the rate at which the circuit may safely be clocked. In this talk, I will discuss the problem of feasible clock period recognition for multiphase implementation: Given an initial circuit designed under an idealized "one-phase" clocking model, is it possible by retiming to produce an implementation that can run with a specified clock period under a specified k -phase clocking discipline? I will consider three classes of multiphase clocking models: those in which registers are modeled as master-slave D flip-flops , those in which registers are modeled as ordinary D flip-flops , and those in which registers are modeled as flow-through latches. The principal results are as follows: 1. In the master-slave D flip-flop model, the problem of feasible clock period recognition for k -phase implementation is NP-complete for k > 1, although it is solvable in polynomial time for k = 1. 2. In the ordinary D flip-flop model, the problem is meaningless for k = 1, solvable in polynomial time for k = 2, and NP-complete for k > 2. 3. In the flow-through latch model, the problem is meaningless for k <= 2 and is solvable in polynomial time for k > 2. HOST: Professor Ramesh S. Patil  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 29 APR 86 23:53:11 EDT Date: Tue, 29 Apr 86 23:52:48 EDT From: "Christopher C. Stacy" Subject: It's all so -confoosing- here in the future To: Moon@SCRC-STONY-BROOK.ARPA cc: BUG-COMSAT@MC.LCS.MIT.EDU, ALAN@MX.LCS.MIT.EDU In-reply-to: Msg of Tue 29 Apr 86 20:59 EDT from David A. Moon Message-ID: <[AI.AI.MIT.EDU].32795.860429.CSTACY> Quite possibly some of the relaying features have been somehow broken since when they were last used (ie., before AI was on the ARPAnet.) Those stats don't look like COMSAT is working correctly.  Received: from SAPSUCKER.SCRC.Symbolics.COM by MC.LCS.MIT.EDU 29 Apr 86 21:02:52 EDT Received: from EUPHRATES.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 13011; Tue 29-Apr-86 20:59:00 EDT Date: Tue, 29 Apr 86 20:59 EDT From: David A. Moon Subject: It's all so -confoosing- here in the future To: Alan Bawden cc: BUG-COMSAT@MC.LCS.MIT.EDU In-Reply-To: <[MX.LCS.MIT.EDU].199.860429.ALAN> Message-ID: <860429205938.5.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Tue, 29 Apr 86 17:42:57 EDT From: Alan Bawden I find the following to be extremely strange. What does "...net conns gone." signify? Why does it look like this mail was tring to go to Alan@SCRC? 140027 InReq: 1 > 1; SPECS:{J:DRAGON}{PFTHMG-DRAGON}{TL=212.} ID=<[MX.LCS.MIT.EDU].195.860429.PFTHMG-DRAGON> EXP->MAGIC-DRAGON-KEEPER@1200400054::=(MOON@1200400054::=(MOON@30002424620),CSTACY@1200400054::=(CSTACY@40700003130),ALAN@1200400054,CENT@1200400054::=(CENT@40700003130)),ALAN@1200400054::=(ALAN@40700003130) 140035 ICP->SCRC-STONY-BROOK.ARPA (CHAOS-MAIL via AI.AI.MIT.EDU) 140036 TO->MOON...net conns gone. 140040 TO->ALAN...net conns gone....net conns gone. 140040 TO->ALAN...net conns gone....net conns gone. 140040 TO->ALAN...net conns gone. It looks like MX doesn't know it's on the internet yet, so it sends all mail to non-Chaosnet hosts by sending it to AI and letting AI figure it out. Thus MOON and ALAN would actually be delivered to the same host as far as Comsat is concerned. I don't know who stole the net conns and why CSTACY and CENT turned into ALAN, though.  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 29 APR 86 18:27:08 EDT Received: from SAPSUCKER.SCRC.Symbolics.COM by AI.AI.MIT.EDU 29 Apr 86 18:26:06 EDT Received: from EUPHRATES.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 12234; Tue 29-Apr-86 12:08:01 EDT Date: Tue, 29 Apr 86 12:08 EDT From: David A. Moon Subject: comsat size limit To: Pandora B. Berman cc: GUMBY@MIT-AI.ARPA, BUG-MAIL@MIT-AI.ARPA In-Reply-To: <[AI.AI.MIT.EDU].31800.860428.CENT> Message-ID: <860429120827.0.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Mon, 28 Apr 86 01:24:41 EDT From: "Pandora B. Berman" i saw it barf at a 9block+900 (approx) msg sat. morning, but there were still nearly 400 blocks of queued msgs. presumably with LISTS MSGS back to a reasonable level, it can swallow items somewhat larger. i think the limit used to be in the 12-15 block region, but moon or KLH are likely to know better.. As far as I know the size of LISTS MSGS has no effect on address space utilization inside Comsat. The size of LIST MASTER and LIST QUEUE might.  Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 29 APR 86 17:44:15 EDT Date: Tue, 29 Apr 86 17:42:57 EDT From: Alan Bawden Subject: It's all so -confoosing- here in the future To: BUG-COMSAT@MC.LCS.MIT.EDU Message-ID: <[MX.LCS.MIT.EDU].199.860429.ALAN> I find the following to be extremely strange. What does "...net conns gone." signify? Why does it look like this mail was tring to go to Alan@SCRC? 140027 InReq: 1 > 1; SPECS:{J:DRAGON}{PFTHMG-DRAGON}{TL=212.} ID=<[MX.LCS.MIT.EDU].195.860429.PFTHMG-DRAGON> EXP->MAGIC-DRAGON-KEEPER@1200400054::=(MOON@1200400054::=(MOON@30002424620),CSTACY@1200400054::=(CSTACY@40700003130),ALAN@1200400054,CENT@1200400054::=(CENT@40700003130)),ALAN@1200400054::=(ALAN@40700003130) 140035 ICP->SCRC-STONY-BROOK.ARPA (CHAOS-MAIL via AI.AI.MIT.EDU) 140036 TO->MOON...net conns gone. 140040 TO->ALAN...net conns gone....net conns gone. 140040 TO->ALAN...net conns gone....net conns gone. 140040 TO->ALAN...net conns gone. 140041 CMSG ID=<[MX.LCS.MIT.EDU].196.860429> EXP->PFTHMG-DRAGON@1200400054::={IGNORED} 140042 CMSG EXP->DEAD-MAIL-RECEIPTS@1200400054::=((FILE [NUL:])@1200400054) 140043 Local->MX.LCS.MIT.EDU 140044 TO->[NUL:] 140044 Queued: <[MX.LCS.MIT.EDU].195.860429.PFTHMG-DRAGON> for AI.AI.MIT.EDU 141544 Note: Gobbling LSR1 database, freespace: -14,,34 141545 Unqueueing to host AI.AI.MIT.EDU 141545 ICP->AI.AI.MIT.EDU (CHAOS-MAIL) 141546 QID=<[MX.LCS.MIT.EDU].195.860429.PFTHMG-DRAGON> 141546 XTO->ALAN 141547 XTO->CENT 141547 XTO->CSTACY 141547 TEXT-> 141548 CMSG ID=<[MX.LCS.MIT.EDU].197.860429> EXP->PFTHMG-DRAGON@1200400054::={IGNORED} 141549 CMSG EXP->DEAD-MAIL-RECEIPTS@1200400054::=((FILE [NUL:])@1200400054) 141551 Local->MX.LCS.MIT.EDU 141551 TO->[NUL:] 141551 All qmsgs gone for AI.AI.MIT.EDU  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 29 APR 86 09:45:55 EDT Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU 29 Apr 86 09:30:19 EDT Date: Tue, 29 Apr 1986 09:27 EDT Message-ID: From: Rob Austein To: "Christopher C. Stacy" Cc: BUG-INQUIR@AI.AI.MIT.EDU, BUG-MAIL@AI.AI.MIT.EDU Subject: Ahem In-reply-to: Msg of 29 Apr 1986 05:25-EDT from "Christopher C. Stacy" Date: Tuesday, 29 April 1986 05:25-EDT From: "Christopher C. Stacy" To: SRA@AI.AI.MIT.EDU cc: BUG-INQUIR@AI.AI.MIT.EDU, BUG-MAIL@AI.AI.MIT.EDU Re: Ahem Maybe I am not thinking today, but I don't see what is wrong with that input spec? In retrospect, probably nothing. I was extrapolating on too little data. The first few times AI's COMSAT IV went west in this weird fashion the messages were all INQUIR-UPDATE-LOSSAGE messages; I assumed this meant there was something funny about those messages. Since then some other messages that cause the same thing have come in, so it's back to the drawing board. Sorry for noise.  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 29 APR 86 05:41:06 EDT Date: Tue, 29 Apr 86 05:25:51 EDT From: "Christopher C. Stacy" Subject: Ahem To: SRA@AI.AI.MIT.EDU cc: BUG-INQUIR@AI.AI.MIT.EDU, BUG-MAIL@AI.AI.MIT.EDU In-reply-to: Msg of Sun 27 Apr 86 03:18:01 EDT from Rob Austein Message-ID: <[AI.AI.MIT.EDU].32455.860429.CSTACY> Maybe I am not thinking today, but I don't see what is wrong with that input spec?  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 28 APR 86 17:18:41 EDT Date: Mon, 28 Apr 86 17:16:02 EDT From: Rob Austein Subject: MX vs TSTGW To: KS-ITS@AI.AI.MIT.EDU, BUG-MAIL@AI.AI.MIT.EDU, sollins@XX.LCS.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].32149.860428.SRA> I stole TSTGW's Arpanet address and gave it to MX. This should fix the mailer weirdness. I'm -not- going to (officially) tell the NIC; people outside MIT shouldn't know or care about the change. Since I don't feel particularly masochistic, the change won't go into effect until snarfed by the 4am XX batch job.  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 28 APR 86 10:56:17 EDT Date: Mon, 28 Apr 86 10:55:56 EDT From: Rob Austein Subject: AI COMSAT To: BUG-MAIL@AI.AI.MIT.EDU, GUMBY@AI.AI.MIT.EDU, CENT@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].31990.860428.SRA> If AI's COMSAT crashes again it will come back as COMSAT III. No need to destroy mail service while tracking this down.  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 28 APR 86 10:50:54 EDT Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU 28 Apr 86 10:50:33 EDT Date: Mon, 28 Apr 1986 10:49 EDT Message-ID: From: Rob Austein To: David Vinayak Wallace Cc: BUG-MAIL@AI.AI.MIT.EDU, CENT@AI.AI.MIT.EDU Subject: comsat size limit In-reply-to: Msg of 28 Apr 1986 06:27-EDT from David Vinayak Wallace Remember, folks, that the entire host table has vanished from COMSAT's address space, and the code itself is actually smaller by some trivial amount. Other things being equal, add 75 blocks or so to the old size limit. In other words, it is highly unlikely that -any- BADREQ files caused from now on are a space problem, barring things like OZ going west for a week (knock on veneer).  Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU 28 Apr 86 10:44:08 EDT Date: Mon, 28 Apr 1986 10:42 EDT Message-ID: From: Rob Austein To: Alan Bawden Cc: BUG-COMSAT@MC.LCS.MIT.EDU Subject: [ALAN%TSTGW.LCS.MIT.EDU: TSTGW] In-reply-to: Msg of 28 Apr 1986 03:13-EDT from Alan Bawden BUGHST problem: yeah, that was one of my brain bubbles. I changed it to HN$AI in the sources and forgot to patch it back for the nonce. Fixed. TSTGW and MX->MX via Chaosnet: yes, that is the host table, but is also the DQDEV vs. COMSAT Chaos vs. Arpa address preference. I think I'm just going to change the COMSAT initialization code to always put the local machine's Arpanet address into OWNHS2 (what the hell, the cell's already there and the code already does the right thing...).  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 28 APR 86 10:33:17 EDT Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU 28 Apr 86 10:24:00 EDT Date: Mon, 28 Apr 1986 10:22 EDT Message-ID: From: Rob Austein To: "Pandora B. Berman" Cc: BUG-MAIL@AI.AI.MIT.EDU Subject: badreqs In-reply-to: Msg of 28 Apr 1986 01:33-EDT from "Pandora B. Berman" What is happening is that certain messages cause COMSAT crash. The STATS file claims these crashes are the result of attempting to execute a zero as an opcode. Why these seemingly unrelated messages reproducibly cause this is a good question (and why it only happens on AI is a better one). Of course the STATS file is by definition not 1.00 reliable when the program is in the process of crashing, so there may be some other problem.  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 28 APR 86 06:28:00 EDT Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 28 APR 86 06:27:43 EDT Date: Mon, 28 Apr 86 06:27:48 EDT From: David Vinayak Wallace Subject: comsat size limit To: CENT@AI.AI.MIT.EDU cc: BUG-MAIL@AI.AI.MIT.EDU In-reply-to: Msg of Mon 28 Apr 86 01:24:41 EDT from Pandora B. Berman Message-ID: <[MC.LCS.MIT.EDU].897166.860428.GUMBY> Well I mailed a bunch of 49-block (no flames please) messages last night. The first one went easily (not even a belch), so I sent three more. All appear to have arrived safely at the other end! Of course I wouldn't make a general habit of it...  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 28 APR 86 03:13:30 EDT Date: Mon, 28 Apr 86 03:13:15 EDT From: Alan Bawden Subject: [ALAN%TSTGW.LCS.MIT.EDU: TSTGW] To: BUG-COMSAT@MC.LCS.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].31914.860428.ALAN> Hey! I sent this message to Bug-COMSAT while on MX, and both MX and AI behaved as if AI was the Bug- host! Of course there is no Bug-COMSAT on AI, so it was converted to Bug-Random-Program. If COMSAT IV thinks AI is the Bug- host, this is a mistake that should be undone until someone moves all the Bug- mailing lists to AI. (BTW, COMSAT maintainers, I just made the Chaosnet MAIL server somewhere between 100 and 1000 times faster! You can actually see the improved response time by watching the STATS file while COMSAT delivers to another ITS.) Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 27 APR 86 23:44:05 EDT Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 27 APR 86 23:43:29 EDT Received: from MX.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 27 APR 86 23:43:10 EDT Received: from MX.LCS.MIT.EDU by MX.LCS.MIT.EDU via Chaosnet; 27 APR 86 23:42:05 EDT Date: Sun, 27 Apr 86 23:42:02 EDT From: Alan Bawden Subject: TSTGW To: BUG-COMSAT@MX.LCS.MIT.EDU Message-ID: <[TSTGW.LCS.MIT.EDU].176.860427.ALAN> You probably know about this one already but... Here on MX I addressed a message to "cent", letting the host name default because I know that Penny's INQUIR entry would get it to AI. Out of randomness I took a peek at the stats file to watch my message get delivered: 232559 InReq: 1 > 1; SPECS:{J:BABYL}{ALAN}{CLAIMS-TO-BE:ALAN}{TL=182.} ID=<[TSTGW.LCS.MIT.EDU].174.860427.ALAN> EXP->cent@40700003131 232603 ICP->MX.LCS.MIT.EDU (CHAOS-MAIL) 232605 TO->cent 232609 InReq: 1 > 1; SPECS:{NET-MAIL-FROM: MX.LCS.MIT.EDU}{TL=461.}{HDR-FROM:ALAN%TSTGW.LCS.MIT.EDU@AI.AI.MIT.EDU} ID=<[TSTGW.LCS.MIT.EDU].175.860427> EXP->CENT@1200400054::=(CENT@40700003130) 232613 ICP->AI.AI.MIT.EDU (CHAOS-MAIL) 232614 TO->CENT I suppose when MX gets its new arpa address properly entered in HOSTS3, the confusion about TSTGW will go away. Perhaps this will also eliminate the useless hop from MX back to itself?  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 28 APR 86 01:33:44 EDT Date: Mon, 28 Apr 86 01:33:30 EDT From: "Pandora B. Berman" Subject: badreqs To: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].31827.860428.CENT> AI COMSAT appears to die whenever it hits mail it decides to turn into a badreq. that's 4 or 5 times now in rather rapid succession. it shouldn't be quite so fragile.  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 28 APR 86 01:30:13 EDT Date: Mon, 28 Apr 86 01:29:34 EDT From: "Pandora B. Berman" Subject: Apology - multiple bboard posting To: SINGH@SU-SIERRA.ARPA cc: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].31813.860428.CENT> Date: Sat 26 Apr 86 10:12:13-PST From: Harinder Singh Subject: Apology - multiple bboard posting To: bboard@XX.LCS.MIT.EDU I was told by someone that my posting for summer housing appeared ten times on the four machines that he uses. He also subsequently told me that it *may* be due to a bug at the MIT end of things. The other possibility is that people re-mailed it for me to help me get campus-wide coverage (I rather doubt this). My apologies in any case - I sent only *one* message to only *one* bboard address if my memory serves me right (which it does not always as I age) at the address `bboard@xx.lcs.mit.edu', as I'm doing with this one. I hope to God that *this* message does not get multiply-posted! i don't think it did. some of what happened was the following: BBOARD@XX forwards to BBOARD@MC. there the msg is broadcast as BBOARD items and system msgs on various MIT machines, as specified by the BBOARD@MC mailing list. MC's COMSAT, the ITS mailer daemon, crashed in the middle of delivering your msg to this list. so when it came up again, it immediately went to work on your msg again. this second try succeeded; however, the first try had partially succeeded, but there was no way of flushing the bboard msgs and system msgs that partial delivery had created (no easy way, at least; someone could have laboriously wandered through all the hosts involved and individually deleted the extra copy of your msg). that explains a single duplication almost everywhere (comsat crashed pretty near the end of running your msg through the BBOARD list). the further duplication may be due to various individual systems here sharing their BBOARD msgs with various others. for further investigation we'd have to know the exact systems involved. also, by now the log files might be gone... however, not to worry in the future. a new version of COMSAT was installed recently (later on friday, in fact) which is significantly more robust -- basically, COMSAT is now -much- less likely to run out of address space, which it was doing continually before.  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 28 APR 86 01:25:07 EDT Date: Mon, 28 Apr 86 01:24:41 EDT From: "Pandora B. Berman" Subject: comsat size limit cc: GUMBY@AI.AI.MIT.EDU, BUG-MAIL@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].31800.860428.CENT> Date: Sun, 27 Apr 1986 16:39 EDT From: Rob Austein To: David Vinayak Wallace Cc: bug-mail@AI.AI.MIT.EDU Subject: comsat, dqdev, etc. Date: Sunday, 27 April 1986 14:43-EDT From: David Vinayak Wallace To: SRA@AI.AI.MIT.EDU What's COMSAT's size limit these days and how does one use the DQDEV? Size limit is pretty large. Dunno exactly but haven't seen it barf anything yet (not for that reason, anyway). i saw it barf at a 9block+900 (approx) msg sat. morning, but there were still nearly 400 blocks of queued msgs. presumably with LISTS MSGS back to a reasonable level, it can swallow items somewhat larger. i think the limit used to be in the 12-15 block region, but moon or KLH are likely to know better.  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 27 APR 86 16:41:02 EDT Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU 27 Apr 86 16:40:02 EDT Date: Sun, 27 Apr 1986 16:39 EDT Message-ID: From: Rob Austein To: David Vinayak Wallace Cc: bug-mail@AI.AI.MIT.EDU Subject: comsat, dqdev, etc. In-reply-to: Msg of 27 Apr 1986 14:43-EDT from David Vinayak Wallace Date: Sunday, 27 April 1986 14:43-EDT From: David Vinayak Wallace To: SRA@AI.AI.MIT.EDU What's COMSAT's size limit these days and how does one use the DQDEV? Size limit is pretty large. Dunno exactly but haven't seen it barf anything yet (not for that reason, anyway). DQDEV as currently implemented is a crock. If you are feeling masochistic, see AI: SRA; RESOLV >. DQDEV is still pretty minimal and probably doesn't do the right thing except for the cases used by COMSAT, and is pretty horribly slow. I'll probably end up canibalizing the current code in a new implementation. This affects COMSAT less than you'd expect, the major changes to COMSAT were removing all the optimizations that only work with mapped-in host tables. I have a little cleaning up to do before I release the lock on the COMSAT sources, but COMSAT IV.0 is basicly done. I have some other things I want to do before tackling IV.1.... --Rob  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 27 APR 86 03:17:50 EDT Date: Sun, 27 Apr 86 03:18:01 EDT From: Rob Austein Subject: Ahem To: BUG-INQUIR@AI.AI.MIT.EDU, BUG-MAIL@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].31506.860427.SRA> What's a nice subject line doing in the middle of a recipient list like this? (Besides generating CRASH;BURNUP files, that is....) FROM-JOB:INQUPD AUTHOR:INQUPD RCPT:(UPDATE-INQUIR-LOSSAGE (R-OPTION CC)) SUBJECT: Problem updating ROMKEY's INQUIR entry RCPT:(ROMKEY) TEXT;-1 Hello, I am the INQUIR update system daemon for the ITS machines. Some trouble was encountered in processing the latest changes to your INQUIR entry here. One or more of the fields in your entry was too long, and has been truncated. I suggest that you check your INQUIR entry on MIT-MC using the WHOIS command. You may want to run INQUIR again to make all your information fit. Yours Truly, INQUPD  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 26 APR 86 17:58:51 EST Date: Sat, 26 Apr 86 17:59:02 EST From: Rob Austein To: BUG-MAIL@AI.AI.MIT.EDU, CENT@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].31434.860426.SRA> COMSAT IV now orbiting AI.  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 26 APR 86 16:32:41 EST Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU 26 Apr 86 12:42:11 EST Date: Sat, 26 Apr 1986 12:41 EST Message-ID: From: Rob Austein To: "Pandora B. Berman" Cc: BUG-MAIL@AI.AI.MIT.EDU Subject: stable orbit In-reply-to: Msg of 26 Apr 1986 03:22-EST from "Pandora B. Berman" Date: Saturday, 26 April 1986 03:22-EST From: "Pandora B. Berman" Date: Fri, 25 Apr 86 16:37:36 EST From: Rob Austein COMSAT IV has achived stable orbit somewhere near MC. do we get it on AI someday? please? I tried launching it on AI last night, it wedged trying to translate its own address. I was too burned out to investigate (although I've got a couple of guesses). Sometime in the next few days. AI isn't in quite as bad shape with III as MC was, so it should be able to survive that long.  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 26 APR 86 03:22:03 EST Date: Sat, 26 Apr 86 03:22:08 EST From: "Pandora B. Berman" Subject: stable orbit To: SRA@AI.AI.MIT.EDU cc: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].31217.860426.CENT> Date: Fri, 25 Apr 86 16:37:36 EST From: Rob Austein To: BUG-MAIL@MC.LCS.MIT.EDU, ks-its@AI.AI.MIT.EDU COMSAT IV has achived stable orbit somewhere near MC. do we get it on AI someday? please?  Date: Fri, 25 Apr 86 16:37:36 EST From: Rob Austein To: BUG-MAIL@MC.LCS.MIT.EDU, ks-its@AI.AI.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].895287.860425.SRA> COMSAT IV has achived stable orbit somewhere near MC.  Date: Fri, 25 Apr 86 13:25:50 EST From: Rob Austein To: BUG-MAIL@MC.LCS.MIT.EDU cc: sollins@XX.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].894572.860425.SRA> I put up COMSAT IV on MC. We'll see how long it lasts...  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 25 APR 86 07:09:10 EST Date: Fri, 25 Apr 86 06:38:44 EST From: "Pandora B. Berman" Subject: .mail1 again To: GUMBY@AI.AI.MIT.EDU cc: BUG-COMSAT@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].30784.860425.CENT> Date: Thu, 24 Apr 86 03:53:31 EST From: David Vinayak Wallace Subject: .mail1 again To: BUG-COMSAT@MC.LCS.MIT.EDU because .mail. was 98.5% full I moved some BADREQ and OSTAT files to .MAIL1; fine for the ostats files. but due to the peculiar status of BADREQ files these days, they should have been moved to .mail2; instead. i did this.  Date: Thu, 24 Apr 86 03:53:31 EST From: David Vinayak Wallace Subject: .mail1 again To: BUG-COMSAT@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].893428.860424.GUMBY> because .mail. was 98.5% full I moved some BADREQ and OSTAT files to .MAIL1;  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 22 APR 86 01:56:17 EST Date: Tue, 22 Apr 86 01:57:11 EST From: "Pandora B. Berman" Subject: dirs To: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].29730.860422.CENT> Date: Mon, 21 Apr 86 00:28:58 EST From: Alan Bawden Date: Fri, 18 Apr 86 16:27:00 EST From: David Vinayak Wallace Date: Fri, 18 Apr 86 03:20:56 EST From: Pandora B. Berman COMMON is damn full of random large-list archives. Ah, but random is indeed the word. We don't need to have AILIST archives on MC, expecially now there's the OZ device. But there will always be a certain number of orphan mailing lists on any given machine, some of them quite legitimate and some of them tolerated out of our general good nature. (Remember, we are trying not to be knee-jerk fascist pig dogs. At least usually.) When Penny starts shuffling mailing lists around in preparation for the MC/MX swap, more will be created because they used to live on user's directories on MC that won't exist elsewhere. Her life will be easier if there is a catch-all directory for moving archives and @FILEs. How about MLISTS or LISTS or MAILST? Date: Fri, 18 Apr 1986 16:35 EST From: Rob Austein To: David Vinayak Wallace Subject: more directories Date: Friday, 18 April 1986 16:27-EST From: David Vinayak Wallace Date: Fri, 18 Apr 86 03:20:56 EST From: Pandora B. Berman KSC is pretty full too. Create HOUSTN; No, create VAFB; (or VANAFB; or whatever). You got something against non-equatorial orbits? MX:COMAIL; and AI:VAFB; now exist.  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 21 APR 86 22:48:55 EST Date: Mon, 21 Apr 86 22:34:25 EST From: "Christopher C. Stacy" To: BUG-COMSAT@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].29600.860421.CSTACY> I changed around the COMSAT on MX so that it relays mail to the Internet via AI, rather than thinking that it *is* AI. I re-commented the NETRTS variables which control this.  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 21 APR 86 21:52:32 EST Received: from MX.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 21 APR 86 21:53:18 EST Date: Mon, 21 Apr 86 21:51:44 EST From: "Christopher C. Stacy" To: BUG-COMSAT%MX.LCS.MIT.EDU@AI.AI.MIT.EDU cc: CSTACY%MX.LCS.MIT.EDU@AI.AI.MIT.EDU Message-ID: <[MX.LCS.MIT.EDU].89.860421.CSTACY> testing 1,2,3  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 21 APR 86 21:05:31 EST Date: Mon, 21 Apr 86 21:06:20 EST From: "Christopher C. Stacy" To: BUG-COMSAT@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].29543.860421.CSTACY> Where did the older versions of COMSAT disappear to? It looks to me like they have been deleted. I refer to them sometimes.  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 21 APR 86 00:28:21 EST Date: Mon, 21 Apr 86 00:28:58 EST From: Alan Bawden Subject: more directories To: GUMBY@MC.LCS.MIT.EDU cc: BUG-MAIL@AI.AI.MIT.EDU, CENT@AI.AI.MIT.EDU In-reply-to: Msg of Fri 18 Apr 86 16:27:00 EST from David Vinayak Wallace Message-ID: <[AI.AI.MIT.EDU].29170.860421.ALAN> Date: Fri, 18 Apr 86 16:27:00 EST From: David Vinayak Wallace Date: Fri, 18 Apr 86 03:20:56 EST From: Pandora B. Berman COMMON is damn full of random large-list archives. Ah, but random is indeed the word. We don't need to have AILIST archives on MC, expecially now there's the OZ device. But there will always be a certain number of orphan mailing lists on any given machine, some of them quite legitimate and some of them tolerated out of our general good nature. (Remember, we are trying not to be knee-jerk fascist pig dogs. At least usually.) When Penny starts shuffling mailing lists around in preparation for the MC/MX swap, more will be created because they used to live on user's directories on MC that won't exist elsewhere. Her life will be easier if there is a catch-all directory for moving archives and @FILEs. How about MLISTS or LISTS or MAILST?  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 18 APR 86 16:38:45 EST Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU 18 Apr 86 16:38:59 EST Date: Fri, 18 Apr 1986 16:35 EST Message-ID: From: Rob Austein To: David Vinayak Wallace Cc: ALAN@AI.AI.MIT.EDU, BUG-MAIL@AI.AI.MIT.EDU, CENT@AI.AI.MIT.EDU, sra@XX.LCS.MIT.EDU Subject: more directories In-reply-to: Msg of 18 Apr 1986 16:27-EST from David Vinayak Wallace Date: Friday, 18 April 1986 16:27-EST From: David Vinayak Wallace Date: Fri, 18 Apr 86 03:20:56 EST From: Pandora B. Berman KSC is pretty full too. Create HOUSTN; No, create VAFB; (or VANAFB; or whatever). You got something against non-equatorial orbits?  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 18 APR 86 16:27:09 EST Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 18 APR 86 16:27:26 EST Date: Fri, 18 Apr 86 16:27:00 EST From: David Vinayak Wallace Subject: more directories To: CENT@AI.AI.MIT.EDU cc: ALAN@AI.AI.MIT.EDU, BUG-MAIL@AI.AI.MIT.EDU In-reply-to: Msg of Fri 18 Apr 86 03:20:56 EST from Pandora B. Berman Message-ID: <[MC.LCS.MIT.EDU].888523.860418.GUMBY> Date: Fri, 18 Apr 86 03:20:56 EST From: Pandora B. Berman COMMON is damn full of random large-list archives. Ah, but random is indeed the word. We don't need to have AILIST archives on MC, expecially now there's the OZ device. KSC is pretty full too. Create HOUSTN;  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 18 APR 86 03:20:40 EST Date: Fri, 18 Apr 86 03:20:56 EST From: "Pandora B. Berman" Subject: more directories To: BUG-MAIL@AI.AI.MIT.EDU cc: ALAN@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].28311.860418.CENT> COMMON is damn full of random large-list archives. KSC is pretty full too. there has been some offline discussion of creating auxiliaries to these to provide more room. any suggestions for names? COMARC or COMAIL? how would you abbreviate Vandenberg -- VANAFB? VDBAFB?  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 18 APR 86 03:17:38 EST Date: Fri, 18 Apr 86 03:17:54 EST From: "Pandora B. Berman" Subject: names compile delay To: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].28308.860418.CENT> i wrote out a copy of AI:NAMES > at 014457 this morning. COMSAT was in the middle of trying to dequeue mail; it had started on a msg at 014445 which kept it busy until 014542. however, it did not then immediately turn to compiling the new NAMES >. it waited until 014711, after it had delivered 2 more queued msgs to the same host (timing out on the second), delivered 2 new pieces of mail, and tried but failed to dequeue to 4 other hosts. this is less than optimal. starting to compile this file within 3 minutes after it was written is admittedly better than waiting a couple hours. i can perhaps understand waiting until COMSAT loses on dequeuing to the host it's currently dequeuing to. but shouldn't COMSAT's priorities be set so that this compilation has higher priority at least than new incoming mail and trying other hosts? seems to me compiling NAMES > used to come ahead of -any- other activity....  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 15 APR 86 05:04:37 EST Date: Tue, 15 Apr 86 05:07:19 EST From: Alan Bawden Subject: unknown -what-? To: BUG-COMSAT@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].27222.860415.ALAN> Date: Tue, 15 Apr 86 04:42:57 EST From: Communications Satellite ============ A copy of your message is being returned, because: ============ "SILVER.EMORY" at AI.AI.MIT.EDU is an unknown recipient. This name came from the expansion of (@FILE [ALAN;CUBE PEOPLE]), from CUBE-LOVERS "UCI-CUBE-LOVERS" at AI.AI.MIT.EDU is an unknown recipient. This name came from the expansion of (@FILE [ALAN;CUBE PEOPLE]), from CUBE-LOVERS ============ Failed message follows: ============ What this error message is -trying- to tell me is that I misspelled a HOST in my @FILE. This is not my idea of a clear error message.  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 15 APR 86 03:20:04 EST Date: Tue, 15 Apr 86 03:22:41 EST From: "Pandora B. Berman" Subject: comsat space restriction To: MRC@AI.AI.MIT.EDU cc: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].27188.860415.CENT> Date: Sat, 12 Apr 86 18:08:12 EST From: Mark Crispin To: BUG-COMSAT@MC.LCS.MIT.EDU What is this bullshit about a 12 Kbyte message being too large for COMSAT to handle? If you must have a limit 50 Kbytes is more appropriate. it's like this: comsat has to jam itself, its queued msgs and log files, various attendant bits and pieces, the whole host tables, -and- the msg being worked on and any called-for address lists, into one pdp10 address space. with things in the state they are -- that is, the host tables growing like unto exponentially and COMSAT having been haired up over the past few years for various reasons, including preparing it to deal with the world of domains -- there isn't much room left for the mail. about 2-3 blocks (depending on phase of the moon) is available for mail+fully expanded address list. we expect this to be fixed soon -- SRA has been hacking on it for a month off and on -- at which point you will be able to transmit your up-to-12 or 15 block msgs again.  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 13 APR 86 00:30:35 EST Date: Sun, 13 Apr 86 00:32:05 EST From: "Christopher C. Stacy" Subject: message size limit To: MRC@MC.LCS.MIT.EDU cc: BUG-COMSAT@MC.LCS.MIT.EDU In-reply-to: Msg of Sat 12 Apr 86 18:08:12 EST from Mark Crispin Message-ID: <[AI.AI.MIT.EDU].26563.860413.CSTACY> Yeah, it's being worked on.  Date: Sat, 12 Apr 86 18:08:12 EST From: Mark Crispin To: BUG-COMSAT@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].882585.860412.MRC> What is this bullshit about a 12 Kbyte message being too large for COMSAT to handle? If you must have a limit 50 Kbytes is more appropriate.  Date: Sun, 6 Apr 86 02:18:44 EST From: "Christopher C. Stacy" To: BUG-MAIL@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].875415.860406.CSTACY> We should make AI be the BUG host, rather than MC.  Date: Wed, 2 Apr 86 23:21:34 EST From: David Vinayak Wallace Subject: ^C in subject To: BUG-MAIL@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].871857.860402.GUMBY> :MAIL FOO S> Some garbage^C sends the message. What a screw.  Date: Mon, 31 Mar 86 07:06:22 EST From: Alan Bawden Subject: Sic Transit... To: BUG-COMSAT@MC.LCS.MIT.EDU, BUG-INQUIR@MC.LCS.MIT.EDU cc: ALAN@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].866653.860331.ALAN> I presuming that the maintainers of COMSAT and INQUIR are making certain that the contents of various directories will not be lost if MC were to suddenly give up the ghost. (I seem to remember that SRA had already indicated he had dome something to this effect for COMSAT, and it looks like CStacy moved INQUIR too.) I have not tried to get a COMSAT working on MX yet. I'm going to let somebody else have that honor. Until there is a running COMSAT, I'm not going to have MX run Puff either. And of course, the INQUIR database isn't being maintained there either. So let me know when it happens, OK? (No rush.)  Received: from ALLEGHENY.SCRC.Symbolics.COM by MC.LCS.MIT.EDU 26 Mar 86 18:23:43 EST Received: from EUPHRATES.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 8582; Mon 24-Mar-86 17:24:45-EST Date: Mon, 24 Mar 86 17:24 EST From: David A. Moon Subject: test results and religion To: Christopher C. Stacy , SRA@xx.lcs.mit.edu cc: BUG-MAIL@MC.LCS.MIT.EDU In-Reply-To: <[MC.LCS.MIT.EDU].859095.860322.CSTACY> Message-ID: <860324172451.9.MOON@EUPHRATES.SCRC.Symbolics.COM> What Chris says sounds pretty persuasive. I would add that since Comsat already knows how to try multiple protocols, using a backup protocol if it times out trying to use the preferred protocol, the only bad effects of adding CHAOS SMTP support and preferring it to CHAOS MAIL will be a timing issue: if a host is down, it will take two timeout periods to discover that fact; if a host only supports CHAOS MAIL, it will take a timeout period to discover that it doesn't support CHAOS SMTP. I believe (but can't test right now) that among mail-serving hosts on the MIT Chaosnet, only Unix does not support CHAOS SMTP, and everybody is used to mail to Unix not working very well anyway.  Date: Sat, 22 Mar 86 02:17:31 EST From: "Christopher C. Stacy" Subject: test results and religion To: BUG-MAIL@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].859095.860322.CSTACY> Test 1, conducted one year ago, shows that COMSAT gives foreign SMTP servers a return path. Return-Path: Received: from MIT-MC by SU-SIERRA.ARPA with TCP; Fri 3 May 85 21:33:33-PDT Date: Sat, 4 May 85 00:33:46 EST From: Christopher C. Stacy To: CSTACY@SU-SIERRA Message-ID: <[MIT-MC].484794.850504.CSTACY> Test 2, conducted a year ago, shows that COMSAT adds itself to the return path when relaying messages. Return-Path: <@MIT-MC:CSTACY@MIT-AI> Received: from MIT-MC by SU-SIERRA.ARPA with TCP; Fri 3 May 85 22:43:55-PDT Received: from MIT-AI by MIT-MC via Chaosnet; 4 MAY 85 01:43:52 EDT Date: Sat, 4 May 85 01:48:51 EST From: Christopher C. Stacy To: CSTACY@MIT-AI cc: CSTACY@SU-SIERRA Message-ID: <[MIT-AI].412.850504.CSTACY> Test 3, conducted today. Message was actually originated at SIERRA, but with a return path which sends errors back to SIERRA, then XX, and finally to AI. That is, <@SIERRA,@XX.LCS.MIT.EDU:CSTACY@AI.AI.MIT.EDU>. Message is received by MC, and delivered to one valid recipient. Received: from SIERRA by MC.LCS.MIT.EDU 22 Mar 86 01:27:58 EST Date: 22 Mar 86 4:26:28-PST From: Spacy To: CStacy@MC, Losinglist Re: test from SIERRA with rtp = <@SIERRA,@XX:CSTACY@AI> Since there is an invalid recipient, COMSAT also sends an error receipt down the reversed return path. The receipt's return path is null. It hops around and finally gets to AI, and then since really I get my mail on MC, is relayed here. Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 22 MAR 86 01:31:59 EST Received: from SU-SIERRA.ARPA by AI.AI.MIT.EDU.ARPA; 22 Mar 86 01:32:24 EST Received: from MC.LCS.MIT.EDU by SU-SIERRA.ARPA with TCP; Fri 21 Mar 86 22:30:09-PST Date: Sat, 22 Mar 86 01:30:10 EST From: Communications Satellite Subject: Msg of Saturday, 22 March 1986 01:30-EST To: "@SIERRA,@XX.LCS.MIT.EDU:CSTACY@AI.AI.MIT.EDU"@SU-SIERRA.ARPA Message-ID: <[MC.LCS.MIT.EDU].859049.860322> ============ A copy of your message is being returned, because: ============ "LOSINGLIST" at MC.LCS.MIT.EDU is an unknown recipient. ============ Failed message follows: ============ Gee, it looks like COMSAT understands return paths to me! It is true that COMSAT does not look inside the envelope of messages and try to parse the headers there. Instead, it uses SMTP to pass the returns paths around in the envelope like it's supposed to. The problems happen when a "good" Internet host trusts a "bad" Internet host to relay some mail for it across the Chaosnet to some target host. The bad host has to throw away the error receipt routing information because CHAOS MAIL does not support it. Then, when the target host gets an error delivering the mail, it doesn't know where to send the error receipt it generates. If the target host is a COMSAT, it gives up, opens up the envelope, and parses the From line. It sends the error receipt there. (This last feature is a holdover from pre-Internet days.) Your solution is that a COMSAT should add another field (Return Path) at transmission time so that another COMSAT can possibly open up the envelope and parse that instead of "From". My solution is for COMSAT to use only SMTP over the Chaosnet, thereby not losing the return-path information in the first place, and never have to breach the envelope. Neither religion not domains are required to win: just assume SMTP is the "official" protocol for Chaosnet, turn the feature on for the 20Xs and ITSs, udpate the current host tables maintained on the PDP-10s and LispMs to reflect this fact, and you are in business. The choice is between implementing a more powerful kludge, or simply activating the clean solution which conforms to mailer standards of the 1980s. Chris  Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU 21 Mar 86 18:34:39 EST Date: Fri, 21 Mar 1986 17:55 EST Message-ID: From: Rob Austein To: "Christopher C. Stacy" Cc: BUG-MAIL@MC.LCS.MIT.EDU Subject: "received" line foulup and Return-paths. In-reply-to: Msg of 20 Mar 1986 01:35-EST from "Christopher C. Stacy" Chris, I agree that the real sollution is to punt CHAOS/MAIL in favor of CHAOS/SMTP. It may be a while before we can do so, however, since there are all these existing implementations of CHAOS/MAIL out there. Yes, GZ did implement a CHAOS/SMTP listener, which has been installed on XX and OZ since July at least. I expect the right thing to do in the long run is to define what class CH WKS RRs look like and talk SMTP iff the resolver can find a {CH,WKS,"SMTP"} record for the site in question. The rest of the issue is religious. You don't like mailers that mung the text portion of messages, I don't like mailers that destroy useful information when there is a way to preserve it. I sympathize with your view, but note that the headers have to be machine parsable in any case (since it is the headers that will be used by the reply command in the luser's mail composer). Try re-reading what I said and remember that I never said COMSAT can't handle return paths, I said it doesn't handle "RETURN-PATH:" headers (not the same thing). I think you will find that we are mostly in agreement, modulo religion. --Rob  Date: Thu, 20 Mar 86 01:35:52 EST From: "Christopher C. Stacy" Subject: "received" line foulup and Return-paths. To: SRA@XX.LCS.MIT.EDU cc: BUG-MAIL@MC.LCS.MIT.EDU In-reply-to: Msg of Wed 19 Mar 1986 14:10 EST from Rob Austein Message-ID: <[MC.LCS.MIT.EDU].856876.860320.CSTACY> I completely understand the issues and what features need to be implemented for return-path hacking, and I implemented them a long time ago. I wouldn't take your criticisms so personally if you had your facts straight about what COMSAT does and does not do. (Actually I don't feel as though I am really taking anything very personally, but I am trying to correct your understanding of some things.) ------ I don't know or care if unix sendmail or the lispm mailer or the vms mailer can do this, the four 20x machines seem a big enough user community to be worth doing things right. ------ In my opinion, the right thing would be to flush the CHAOS MAIL protocol from 20X, and have it use SMTP over the Chaosnet instead of implementing kludges involving parsing the contents of a message. I was under the impression that GZ wrote the code to do this years ago. ------ If COMSAT relays a message that already has a RETURN-PATH: header, it leaves it alone, rather than adding its own address at the head of the list. ------ I believe that this statement is false, and that COMSAT does handle this. However, COMSAT is using CHAOS MAIL to send, the information is necessarily discarded at transmission time. ------ If COMSAT relays a message that doesn't have a RETURN-PATH:, it should add one if it can figure out how, like by using the argument to the MAIL FROM: negotiation. This is particularly important in the special case of a null return path (ie, MAIL FROM:<>), indicating that no error messages should be sent. ------ I also think that this feature is implemented. ------ There is one last case, which is a COMSAT error message (like "your mail is undeliverable"). It is particularly**2 important that COMSAT specify a RETURN-PATH:<> to keep anybody from trying to send error ------ I distinctly remember implementing this feature. I believe that all of your woes are coming from a deficient mail protocol, not because COMSAT doesn't understand return paths. Also, there is always the possability that there are bugs in the code, but I am pretty sure it works at least most of the time. I will do some testing over the next few days to make sure that things still seem to work, and report back on any problems I find. I am a real believer in seperation of envelope and contents, and am somewhat grossed out by the notion of parsing header fields intended for humans, and the handing to humans of header fields intended for machines. Again, I say we should do away with CHAOS MAIL! I don't know of any system for which the code is not available, although in at least two cases (ITS and 20X) the mail systems are not configured to use it. I think that would solve all of the problems you are talking about. Chris  Received: from SCRC-STONY-BROOK.ARPA by MC.LCS.MIT.EDU 20 Mar 86 00:40:05 EST Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 442922; Thu 20-Mar-86 00:36:55-EST Date: Thu, 20 Mar 86 00:36 EST From: David A. Moon Subject: "received" line foulup and Return-paths. To: Rob Austein cc: Christopher C. Stacy , BUG-MAIL@MC.LCS.MIT.EDU In-Reply-To: Message-ID: <860320003617.6.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Wed, 19 Mar 1986 14:10 EST From: Rob Austein ....Chaosnet does not use SMTP (I wish it did, different subject). Since chaosnet does not use SMTP it would be nice if there was some way to preserve the information from the MAIL FROM negotiation in the SMTP dialog. I implemented SMTP on Chaosnet several years ago. Of course Comsat has no way of knowing which hosts run servers for it and which don't. You can probably guess what the contact name is without much trouble!  Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU 19 Mar 86 19:49:16 EST Date: Wed, 19 Mar 1986 14:10 EST Message-ID: From: Rob Austein To: "Christopher C. Stacy" Cc: BUG-MAIL@MC.LCS.MIT.EDU Subject: "received" line foulup and Return-paths. In-reply-to: Msg of 19 Mar 1986 12:51-EST from "Christopher C. Stacy" So much for using shorthand instead of repeating the whole song and dance. I'm going to spell it all out again, hopefully without being too offensive, and hopefully for the last time. Chris, the problem I am talking about is one you have completely ignored. Considered as a program for delivering mail to MC users and complaining if the address is bogus, what you have done is fine. But COMSAT is not doing the right thing when it is used as a relay. Chaosnet does not use SMTP (I wish it did, different subject). Since chaosnet does not use SMTP it would be nice if there was some way to preserve the information from the MAIL FROM negotiation in the SMTP dialog. There is such a thing. It is called the RETURN-PATH: header. And yes, MMAILR does parse this if it has no better source of information. I don't know or care if unix sendmail or the lispm mailer or the vms mailer can do this, the four 20x machines seem a big enough user community to be worth doing things right. If COMSAT relays a message that already has a RETURN-PATH: header, it leaves it alone, rather than adding its own address at the head of the list. This produces such amusing items as a message arriving on XX via the Chaosnet with a return path of . Which can get interesting if MC and XX have different versions of the host tables, as sometimes happens temporarily. If COMSAT relays a message that doesn't have a RETURN-PATH:, it should add one if it can figure out how, like by using the argument to the MAIL FROM: negotiation. This is particularly important in the special case of a null return path (ie, MAIL FROM:<>), indicating that no error messages should be sent. There is one last case, which is a COMSAT error message (like "your mail is undeliverable"). It is particularly**2 important that COMSAT specify a RETURN-PATH:<> to keep anybody from trying to send error messages about the error messages. Good taste forbids recounting the whole sordid affair, but on more than one occasion I have logged in to find XX and MC in a tight loop sending a particularly pathological bug message at each other, because COMSAT wasn't using this mechanism. I have not investigated within the last month or so, but the last time I checked, COMSAT was completely ignoring (ie, not editing and not adding) the RETURN-PATH: header. Maybe you fixed this since then. I don't have time to investigate it at the moment. So, no, Chris, you implemented a feature (and a useful one, no argument there), but it wasn't the one I was talking about. Don't take it so personally, I wasn't thowing rocks or asking you to do anything. Anybody who thinks RETURN-PATH = FROM is either naive (curable) or is a hopeless loser who should be invited to go play on Memorial Drive during rush hour. And even MM is cabable of suppressing typeout of uninteresting headers like RETURN-PATH for you so that you don't have to read it. --Rob  Date: Wed, 19 Mar 86 12:51:09 EST From: "Christopher C. Stacy" Subject: "received" line foulup and Return-paths. To: SRA@XX.LCS.MIT.EDU cc: BUG-MAIL@MC.LCS.MIT.EDU, KLH@MC.LCS.MIT.EDU, CSTACY@MC.LCS.MIT.EDU In-reply-to: Msg of Wed 19 Mar 1986 11:07 EST from Rob Austein Message-ID: <[MC.LCS.MIT.EDU].855987.860319.CSTACY> Your suggestion seems confused to me. Adding return-path lines to a textual message header will not affect the delivery of the message; all that it will do is create more shit in user mailboxes, and confuse them into thinking RETURN-PATH = FROM. Once a message is delivered to a mailbox, the Return path, like the Received lines, are simply historical information, possibly useful for debugging, but not to be used for anything again. What you want is for COMSAT to notice incoming return-paths from an SMTP "MAIL FROM" command, and use that as the place to send error replies. I already taught it to do this. Example: NET-MAIL-FROM-HOST:0032000000111 RETURN-PATH:<@SRI-NIC.ARPA,@XX.LCS.MIT.EDU:CSTACY@MC.LCS.MIT.EDU> RCPT:(CSTACY MC) RCPT:(LOSING-ADDRESS MC) TEXT;-1 Date: 12:36pm Wednesday, 19 March 1986 From: Christopher C Stacy Subject: sent to an invalid address Here's the STATS log. Note that the message was returned to the address specified in the return-path, rather than the FROM field. (Also, COMSAT added 208.0.0.73 to the front of the path because that's the host it got the return path from originally.) 123720 InReq: 1 > 1; SPECS:{NET-MAIL-FROM: 208.0.0.73}{RTP:<@SRI-NIC.ARPA,@XX.LCS.MIT.EDU:CSTACY@MC.LCS.MIT.EDU>}{TL=137.}{HDR-FROM:CSTACY@SRI-NIC.ARPA} ID=<[MC.LCS.MIT.EDU].855976.860319> EXP->LOSING-ADDRESS@1200600054::={IGNORED},CSTACY@1200600054 123720 CMSG ID=<[MC.LCS.MIT.EDU].855977.860319> EXP-><@SRI-NIC.ARPA,@XX.LCS.MIT.EDU:CSTACY@MC.LCS.MIT.EDU>@32000000111 123720 ICP->208.0.0.73 (TCP-SMTP=Timeout) 123735 Queued: <[MC.LCS.MIT.EDU].855977.860319> for 208.0.0.73 123737 Local->MC.LCS.MIT.EDU 123737 TO->CSTACY If error receipts appear to be going to the wrong place, then they probably came from a machine which did not give COMSAT a return path to work with. I wish you would stop flaming about how I didn't ever implement this feature, when you can see it working in the above example. (If course, it's possible there is some subtle bug which makes it not work sometimes, and of course you are welcome to fix it.) Chris  Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU 19 Mar 86 11:02:43 EST Date: Wed, 19 Mar 1986 11:07 EST Message-ID: From: Rob Austein To: Ken Harrenstien Cc: bug-mail@MC.LCS.MIT.EDU Subject: "received" line foulup In-reply-to: Msg of 19 Mar 1986 07:13-EST from Ken Harrenstien Date: Wednesday, 19 March 1986 07:13-EST From: Ken Harrenstien Note that the indiscriminate addition of "Received" lines to *MSg recipients has caused things like :MSGS to stop working, because it expects the first line to be in a special format that it knows how to interpret. Yeah. My inclination is to arbitrarily decide that :MSGS and friends are confused and need fixing. But then, I was one of the people screaming the loudest for RECEIVED: headers until Chris implemented them. In fact, I intend to add more of this cruft, specificly RETURN-PATH: headers for all messages (including Chaosnet), because I am tired of watching COMSAT blithly ignore another host's request to -please- not receive failure notifications on a particular message (like a failure notification). I know, *MSGs aren't really mail messages, but it seems silly to heavily special case them when a little smarts on the part of :MSGS would work equally well. I don't really feel strongly about this, so if somebody else wants to do the work s/he is welcome to do it some other way. After I'm done with all this DQDEV hacking, of course.  Date: Wed, 19 Mar 86 07:13:54 EST From: Ken Harrenstien Subject: "received" line foulup To: BUG-MAIL@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].855757.860319.KLH> Note that the indiscriminate addition of "Received" lines to *MSg recipients has caused things like :MSGS to stop working, because it expects the first line to be in a special format that it knows how to interpret.  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 18 MAR 86 02:35:45 EST Date: Tue, 18 Mar 86 02:35:33 EST From: Alan Bawden Subject: Hey! COMSAT is messed up. Fix it? To: BUG-COMSAT@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].19579.860318.ALAN> Just now AI came up not knowing the time because it had been power cycled. As is normal these days, the demon TARAKA NETIME noticed this deficiency and asked around the net to see what time it was. AP6 said it was 3/18/86 1:17:36, which seemed reasonable, so NETIME set it to be that. Seconds pass. It is now 1:18:16. All of a sudden Somebody grabs the system console and prints: Hey! The time is messed up. Fix it! (:PDSET?) Yr mst obdt svt, COMSAT III Well after looking around at the system I couldn't figure out what COMSAT was talking about. The time was perfectly reasonable, and had been for almost a minute. The system had not been previously brought up thinking it was 1987 or anything like that. The message from COMSAT was cute, but it didn't tell me what "messed up" was exactly. I was finally forced to conclude that COMSAT was the one that was messed up, and I had been sent on a wild goose chase.  Date: Mon, 17 Mar 86 00:01:08 EST From: Puff the Magic Dragon Subject: Happy Birthday! To: KSC@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].852699.860317.DRAGON> Happy birthday to you, Happy birthday to you, Happy birthday dear Kennedy, Happy birthday to you.  Date: Thu, 13 Mar 86 20:24:22 EST From: "Devon S. McCullough" Subject: gosh, MC's in trouble now... To: HENRIK@MC.LCS.MIT.EDU, BUG-COMSAT@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].850071.860313.DEVON> Date: Thu, 13 Mar 86 19:22:05 EST From: Communications Satellite To: DEVON at MC.LCS.MIT.EDU Re: Msg of Thursday, 13 March 1986 15:36-EST FAILED: HENRIK at MC.LCS.MIT.EDU; I gave up on sending this after 201 "temporary" errors. Failed message follows: ------- Date: Thu, 13 Mar 86 15:36:19 EST From: "Devon S. McCullough" Subject: my modem ... To: HENRIK@MC.LCS.MIT.EDU cc: LIZZIT@MC.LCS.MIT.EDU, MASON@MC.LCS.MIT.EDU In-reply-to: Msg of Thu 13 Mar 86 13:58:00 EST from "Lawrence A. DeLuca, Jr." Message-ID: <[MC.LCS.MIT.EDU].849747.860313.DEVON> Your modem has been at ZetaSoft in the AmTwine building. I would love to take it instead of cash for what you owe, since a lisp machine with no net access is not too useful. -Devon  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 11 MAR 86 00:43:13 EST Date: Tue, 11 Mar 86 00:42:30 EST From: "Pandora B. Berman" Subject: MC mail problems To: wales@LOCUS.UCLA.EDU cc: HEADER-PEOPLE-REQUEST@AI.AI.MIT.EDU, BUG-MAIL@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].18504.860311.CENT> Date: Thu, 6 Mar 86 19:35:17 PST From: Rich Wales To: HEADER-PEOPLE-REQUEST@MC.LCS.MIT.EDU Subject: More MC mail problems? Hi. I sent the following message to HEADER-PEOPLE last week, but I never saw it come back to me via the list. Did you have another mail problem at MC? If so, can you resubmit the message using the copy below? Or should I simply send it again myself? Please note that this is NOT the same message that I asked a similar question about a few weeks ago. I did resend that one, and as far as I can tell, it did go out on the retry. rich, you're running into the same problem you had before; i thought i explained it then, but maybe i didn't. the Header-People list is having no particular insidious problems (unless someone isn't telling me something). your msg isn't going through because COMSAT is in a crippled state, and has been for a few months. basically, COMSAT has to fit itself, its file of queued-for-retransmission msgs, the host tables, and some other assorted necessary junk, as well as the piece of mail being worked on and the address list that mail is going to, into one (count them one) PDP10 address space. the host tables, for those as are still using them these days, are enormous, and COMSAT has had to grow a lot of hair in preparation for moving to the domain-resolution world; these combine to leave only 2-3 ITS blocks for the msg and its (expanded) address list. the exact size varies according to how much state COMSAT has built up. since Header-People is a large list, msgs larger than small can be untransmittable in COMSAT's current state. mail that COMSAT can't transmit has been accumulating on an auxiliary directory; that's where your current-problem msg is now. i doubt it would do me much good to extract it and try to re-send it, as COMSAT will still have the same address space limitations -- possibly your msg is just on the edge of sendable, and resending just when COMSAT happens to start up fresh would work, but that chance is pretty slim. the solution is to sit tight. a local hacker, having finished several other tasks he had to deal with first, is now hacking furiously on making COMSAT deal with domains instead of host tables. he expects to have this done in the next couple weeks. when this change is installed, COMSAT will (as in days of yore) again be able to transmit mail up to 12-15 blocks. when that happens, i expect to spend several days requeuing all these msgs which COMSAT has had to drop for lack of space.  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 5 MAR 86 23:38:18 EST Date: Wed, 5 Mar 86 23:41:40 EST From: "Pandora B. Berman" Subject: launching COMSAT To: ZVONA@AI.AI.MIT.EDU cc: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].17761.860305.CENT> Date: Wed, 5 Mar 86 12:21:40 EST From: David Chapman To: BUG-MAIL@AI.AI.MIT.EDU what do I do to launch a dead comsat, other than running :mail? well, you could $J a reasonably-named job, load COMSAT LAUNCH into it, and start it off with the appropriate DDT incantation to correctly disown it... but just sending mail or qsend (from DDT, doesn't work from inside emacs, etc.) is a hell of a lot easier.  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 5 MAR 86 14:51:14 EST Date: Wed, 5 Mar 86 14:54:34 EST From: Alan Bawden To: BUG-COMSAT@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].17668.860305.ALAN> The most recent COMSAT crash on AI is one I haven't seen before (not that I know all that much about COMSAT remember, but it isn't one of the usual address space lossages...) It dumped itself into CRASH;BURNUP of course, this is just a note to tell you that the real corpse is still disowned on AI with the names ALAN III.  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 5 MAR 86 12:18:23 EST Date: Wed, 5 Mar 86 12:21:40 EST From: David Chapman To: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].17646.860305.ZVONA> what do I do to launch a dead comsat, other than running :mail?  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 4 MAR 86 17:49:41 EST Date: Tue, 4 Mar 86 17:52:54 EST From: Alan Bawden Subject: ...IOC error? To: BUG-COMSAT@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].17524.860304.ALAN> Read in a recent STATS file on AI and do M-X List Matching Lines$QID=  Date: Sun, 2 Mar 86 18:34:05 EST From: Rob Austein Subject: COMSAT To: BUG-MAIL@MC.LCS.MIT.EDU, ks-its@AI.AI.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].835955.860302.SRA> I am claiming write locks on all network related files used by COMSAT. These include (but are not restricted to): CSTACY;RESOLV, CSTACY;DQDEV, KSC;OUT, SYSENG;NETWRK, SYSNET;NETRTS and of course COMSAT itself.  Date: Fri, 28 Feb 86 20:07:15 EST From: Jonathan A Rees Subject: [COMSAT: Msg of Friday, 28 February 1986 20:00-EST] To: BUG-MAIL@MC.LCS.MIT.EDU, postmaster@BBNA.ARPA Message-ID: <[MC.LCS.MIT.EDU].834520.860228.JAR> I sent a message to ALLEN@BBNG, and got this back from BBNG: Date: Fri 28 Feb 86 19:19:31-EST From: The Mailer Daemon To: JAR at MC.LCS.MIT.EDU Re: PS:[--QUEUED-MAIL--].NEW-132632006636-MAISER-J0.1 No such host as "BBNG.ARPA", file renamed to PS:[--BAD-QUEUED-MAIL--]..45 So I tried sending something to ALLEN@G.BBN.COM instead, and got the following from COMSAT: Date: Fri, 28 Feb 86 20:00:18 EST From: Communications Satellite To: JAR at MC.LCS.MIT.EDU Re: Msg of Friday, 28 February 1986 20:00-EST Message-ID: <[MC.LCS.MIT.EDU].834512.860228> Queued: allen at BBNG.ARPA I expect to get a complaint back from G.BBN.COM very soon, with the same complaint as above, because MC has turned my G.BBN.COM back into BBNG. (If I turn out to be wrong I'll apologize.) How can I get mail to Don Allen? Jonathan  Date: Thu, 27 Feb 86 14:39:32 EST From: David Vinayak Wallace Subject: resolvers and tables and mail, oh my To: Moon@SCRC-STONY-BROOK.ARPA cc: BUG-MAIL@MC.LCS.MIT.EDU, sollins@XX.LCS.MIT.EDU, SRA@XX.LCS.MIT.EDU, ks-its@AI.AI.MIT.EDU In-reply-to: Msg of Wed 26 Feb 86 22:19 EST from David A. Moon Message-ID: <[MC.LCS.MIT.EDU].832771.860227.GUMBY> Date: Wed, 26 Feb 86 22:19 EST From: David A. Moon The problem with doing it this way (using a device) is that you have to pay device startup overhead every time you invoke the device. That might be a couple of seconds. What about JOBREU? Or we could have a call like CHAOSO which gives you a pair of channels to a jobdev.  Received: from ALLEGHENY.SCRC.Symbolics.COM by MC.LCS.MIT.EDU 26 Feb 86 22:23:45 EST Received: from EUPHRATES.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 1142; Wed 26-Feb-86 22:23:11-EST Date: Wed, 26 Feb 86 22:19 EST From: David A. Moon Subject: resolvers and tables and mail, oh my To: Rob Austein cc: ks-its@AI.AI.MIT.EDU, bug-mail@MC.LCS.MIT.EDU, sollins@XX.LCS.MIT.EDU In-Reply-To: Message-ID: <860226221958.7.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Wed, 26 Feb 1986 13:28 EST From: Rob Austein There are several distinct problems that need to be solved. In decreasing order of priority: 1) COMSAT needs its address space back, so the moby HOSTS3 table has to get out of COMSAT's address space. 2) COMSAT needs to be able to do name<->address stuff for domains. 3) COMSAT needs to be taught to do sophisticated things with all this new mail related stuff that is part of the domain spec. It also has to preserve the string-format host name until actually sending the message, as opposed to the current practice of immediately converting to a HOSTS3 address. New timeouts have to be installed (since some formerly trivial operations can now take minutes), some amount of parallelism has to take place with the resolver (ie, COMSAT should go do something else while resolver is grinding away), scads of other things that I haven't thought of yet. Considerations: Task (1) needs to be done ASAP**2, if not sooner. Task (2) needs to be done ASAP but COMSAT will at least be a functional mailer again while this is under development. Task (3) will take a while, nobody has really done much of this anywhere yet and the ideas themselves are still being debugged. Separating out task 3 seems like a good idea to me. Proposed sollution: Step one is to take CSTACY's NETWRK clone routines I'm not sure what you mean by this but my best guess is "CSTACY" was a typo for "COMSAT" here. and adapt them for whatever high-speed comunication channel COMSAT is going to use to talk to its resolver (note that I do not say -the- resolver; if necessary I am willing to put up with having COMSAT have its own private resolver and cache until we can work out and code the details of a high bandwidth method of sharing the cache with the DQ: device or whatever incarnation the non-COMSAT resolver takes). Current top of the list of things to try is a core link, if that doesn't work out there are other things we can try. For a core link to work we need some way of making sure there is something on the other end of the core link; ideas here are normal USR: frobbing, a special system call to set up a core link and boot the other end of it if not already present, or maybe the old DM .DEMON stuff. In any case, once there is some communiction channel, COMSAT uses it instead of mapping in HOSTS3. As a first step, the thing on the other end will not be a resolver at all, just a job that grovels through HOSTS3 and returns an appropriate answer. This should be a two hour hack, modulo the core link (or whatever) code. CStacy already wrote a version of the DQ device that uses HOSTS3 instead of resolving and commented-out code in Comsat that talks to that version of the DQ device. The first thing to try is probably to turn this on and see what has to be done to make it work. I looked at it a little a month or two ago and didn't see any gross travesties, but I couldn't spend the time to turn it on and watch what happened to make sure it was working reliably. The problem with doing it this way (using a device) is that you have to pay device startup overhead every time you invoke the device. That might be a couple of seconds. A small cache of host name/address pairs inside Comsat might alleviate that for the time being (we're talking here just about the quickest way to get Comsat back on its feet). Probably a job inferior to Comsat communicating through shared memory, like the way XMAILR works (or used to work when I knew about it), would be the best way to give Comsat a resolver that is always in existence and doesn't have to wait for locks held by some user. This probably implies that this resolver doesn't use the same cache as the resolver that users use, or else the locking is done carefully so that things don't get hung up. Once it's an inferior job you don't gain anything by using a core link. The small cache of host name/address pairs might still be worthwhile, since it's so easy to do. If the DQ-device code is not totally bankrupt, and I have no judgement about that one way or the other, it's probably quite easy to make it work both as a JOB device handler and as an inferior job taking requests from its superior Comsat. Second step will be to replace the fake resolver with a real resolver. Part of the reason for doing the fake resolver is to have an easy way of backing out of losing resolver code; just punt the resolver and put the fake resolver back up (something a non-hacker can do, so that you aren't dependent on me being present 24 hours per day to get the mail through). In fact, the cannonical resolver boot file should just be a link to the resolver of the week (or day or minute...). Agreed. At this point COMSAT will be doing the same things it used to do with host tables but be doing them with domains. Experimental evidence from XX (who's MMAILR is currently at this stage) shows that this isn't that all horrible. It could be a lot better, but it works and the mail does get through. Once we get this far we'll be happy for a while.  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 26 FEB 86 22:07:56 EST Date: Wed, 26 Feb 86 22:10:37 EST From: "Pandora B. Berman" Subject: not all comsats are created equal? To: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].16581.860226.CENT> what gets me is that both AI and MC use COMSAT.... ---------- Date: Sun, 23 Feb 86 10:46:49 EST From: Keith Petersen Subject: Bad message headers To: CENT@AI.AI.MIT.EDU Your mailer is not using legal headers. I can't use Babyl to forward or reply. Message included below, so you can see how it's munged. --Keith --forwarded message-- BABYL OPTIONS: Version:5 Append:1 ^_ 1, bad-header, recent,, *** EOOH *** MSG: PWORD UP Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 19 FEB 86 01:31:15 EST DISTRIB: *MC, *AI, *OZ EXPIRES: 03/22/86 01:32:45 CENT@AI.AI.MIT.EDU 02/19/86 01:32:45 Re: PWORD on AI MIT-AI is now running PWORD. This means that users who connect to MIT-AI from non-local sites must have accounts with passwords in order to log in. Having an ITS inquir entry is -not- the same as having an account with a password; if you connect to MIT-AI from a site that is not considered local, you will not be allowed to log in without a password. The password database from MIT-MC has not been copied over to MIT-AI, so having a password on MIT-MC does not give you one on MIT-AI. The password database from the old MIT-AI (the KA-10) has not been resurrected, so having a password on the previous incarnation of MIT-AI does not automatically give you one now. Any AI Lab member or other official MIT-AI user who does not have a password should contact USER-ACCOUNTS@AI to rectify this situation. Others who would like accounts should connect to MIT-AI and run the :ACOUNT program. ^_  Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU 26 Feb 86 14:12:03 EST Date: Wed, 26 Feb 1986 13:28 EST Message-ID: From: Rob Austein To: ks-its@AI.AI.MIT.EDU, bug-mail@MC.LCS.MIT.EDU, sollins@XX.LCS.MIT.EDU cc: sra@XX.LCS.MIT.EDU Subject: resolvers and tables and mail, oh my [Forgive the wide distribution and length, I want to make sure nobody comes up to me later and flames about being left out.] As some of you know, I now have the twenex domain code basicly done, or at least in a state where I can leave it alone for a few months. So now I can start working on COMSAT. Premise: There are several distinct problems that need to be solved. In decreasing order of priority: 1) COMSAT needs its address space back, so the moby HOSTS3 table has to get out of COMSAT's address space. 2) COMSAT needs to be able to do name<->address stuff for domains. 3) COMSAT needs to be taught to do sophisticated things with all this new mail related stuff that is part of the domain spec. It also has to preserve the string-format host name until actually sending the message, as opposed to the current practice of immediately converting to a HOSTS3 address. New timeouts have to be installed (since some formerly trivial operations can now take minutes), some amount of parallelism has to take place with the resolver (ie, COMSAT should go do something else while resolver is grinding away), scads of other things that I haven't thought of yet. Considerations: Task (1) needs to be done ASAP**2, if not sooner. Task (2) needs to be done ASAP but COMSAT will at least be a functional mailer again while this is under development. Task (3) will take a while, nobody has really done much of this anywhere yet and the ideas themselves are still being debugged. Proposed sollution: Step one is to take CSTACY's NETWRK clone routines and adapt them for whatever high-speed comunication channel COMSAT is going to use to talk to its resolver (note that I do not say -the- resolver; if necessary I am willing to put up with having COMSAT have its own private resolver and cache until we can work out and code the details of a high bandwidth method of sharing the cache with the DQ: device or whatever incarnation the non-COMSAT resolver takes). Current top of the list of things to try is a core link, if that doesn't work out there are other things we can try. For a core link to work we need some way of making sure there is something on the other end of the core link; ideas here are normal USR: frobbing, a special system call to set up a core link and boot the other end of it if not already present, or maybe the old DM .DEMON stuff. In any case, once there is some communiction channel, COMSAT uses it instead of mapping in HOSTS3. As a first step, the thing on the other end will not be a resolver at all, just a job that grovels through HOSTS3 and returns an appropriate answer. This should be a two hour hack, modulo the core link (or whatever) code. Second step will be to replace the fake resolver with a real resolver. Part of the reason for doing the fake resolver is to have an easy way of backing out of losing resolver code; just punt the resolver and put the fake resolver back up (something a non-hacker can do, so that you aren't dependent on me being present 24 hours per day to get the mail through). In fact, the cannonical resolver boot file should just be a link to the resolver of the week (or day or minute...). At this point COMSAT will be doing the same things it used to do with host tables but be doing them with domains. Experimental evidence from XX (who's MMAILR is currently at this stage) shows that this isn't that all horrible. It could be a lot better, but it works and the mail does get through. Third step will be ad lib'd when I get that far. Comments?  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 26 FEB 86 11:24:28 EST Received: from BBNJ.ARPA by AI.AI.MIT.EDU.ARPA; 26 Feb 86 11:26:55 EST To: "Pandora B. Berman" cc: liz@brillig.umd.EDU, BUG-MAIL@ai.ai.mit.EDU, JA@ai.ai.mit.EDU, LWA@ai.ai.mit.EDU, allen@BBNJ.ARPA, postamster@bbng.ARPA Subject: Re: mis-forwarded mail In-reply-to: Your message of Wed, 26 Feb 86 06:55:42 EST. <[AI.AI.MIT.EDU].16410.860226.CENT> Date: 26 Feb 86 11:13:16 EST (Wed) From: allen@BBNJ.ARPA Indeed acourt@bbnv was an invalid address on the butterfly-lispers list and has now been removed. /don allen  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 26 FEB 86 06:53:59 EST Date: Wed, 26 Feb 86 06:55:42 EST From: "Pandora B. Berman" Subject: mis-forwarded mail To: liz@BRILLIG.UMD.EDU cc: BUG-MAIL@AI.AI.MIT.EDU, JA@AI.AI.MIT.EDU, LWA@AI.AI.MIT.EDU, allen@BBNJ.ARPA, postamster@BBNG.ARPA Message-ID: <[AI.AI.MIT.EDU].16410.860226.CENT> To: postmaster@mc.lcs.mit.edu Cc: allen@bbnj.ARPA, ja@mc.lcs.mit.edu Subject: mis-forwarded mail Date: Mon, 24 Feb 86 14:09:57 -0500 From: Liz Allen It looks like there are a few problems here... 1. The scheme mailing list appears to have a problem (as all mailing lists do) yes. COMSAT, the ITS mailer, is currently in a limping stage. it must fit itself, its queued-mail file, a couple other necessary items, and the host tables into a PDP-10 address space, along with the msg text and address-list expansion, in order to run. what with the explosion of the host tables over the past few years, and the increased size of COMSAT as it works toward domain hacking, the space left for msg and address has shrunk to the point that COMSAT simplly cannot swallow anything over about 3 ITS blocks (exact size depends on how much state it's already carrying around and how much the address list expands). SCHEME@MC is a big list, so mail to it sometimes pushes COMSAT over the limit, and sometimes is just too big to pass. someone is starting to work on hooking up the domain-hacking software, which is mostly written, to COMSAT now (perhaps even as we speak), which will obviate the need for the host-table in COMSAT's address space and thus (we expect) allow COMSAT to transmit more sensibly sized msgs, like the up-to-12-or-15 block msgs it used to be able to handle. 3. Mail to allen at any random mit site goes to me. Number three occurs because I have an account on oz, liz@oz, my last name is Allen, and, I guess, even though there are other Allen's at MIT, I must have been the first (as liz@mit-ai). I have a feeling that mail to allen@mit.edu should go to someone like Jon Allen since, as has already occured once before, someone sending mail to allen@mit.edu is much more likely to be thinking of Jon Allen rather than me. Can that be fixed? sorry, no. no ITS user has the UNAME ALLEN, and there is no equivalence in the address-list files to forward mail for this name to some individual address. so COMSAT, being cautious, sends mail for ALLEN to -all- users in the ITS inquir (user) database with that name -- you, Jon Allen, and an LCS staff member -- the theory being that COMSAT doesn't know who it's for but one of you is a good guess. ------- Forwarded Message Date: Mon 24 Feb 86 12:32:26-EST From: The Mailer Daemon To: allen@mc.lcs.mit.EDU Subject: Message of 24-Feb-86 12:31:37 Message failed for the following: ACOURT@VAX.BBN.COM.#Internet: 550 ------------ To: scheme@mit-mc.ARPA cc: allen@BBNJ.ARPA Subject: Butterfly Lisp Date: 24 Feb 86 09:50:24 EST (Mon) From: allen@BBNJ.ARPA [msg text omitted] ------- End of Forwarded Message 2. The mail responding to the problem went to allen@mc.lcs.mit.edu instead of to the sender, allen@bbnj (though that isn't very helpful either). Number two appears to be a real bug. yes, but not our bug. Postmaster@BBNG, please note the excerpts below from COMSAT@MC's log file on 24 feb: ---------- 122151 OldReq: 1; SPECS:{NET-MAIL-FROM: BBNJ.ARPA}{RTP:allen@BBNJ.ARPA}{TL=588.}{HDR-FROM:allen@BBNJ.ARPA} ID=<[MC.LCS.MIT.EDU].828743.860224> EXP->SCHEME@1200600054::=((@FILE [JAR;SCHEME LIST])@1200600054::= [mailing-list expansion omitted; it does not include ACOURT@BBN-VAX, the address complained about, directly]) ... 123431 ICP->BBNG.ARPA (TCP-SMTP) 123438 XTO->ABOULANGER 123439 XTO->BRoberts 123441 XTO->Butterfly-Lispers 123441 TEXT-> ... ---------- 125143 InReq: 47 > 1; SPECS:{NET-MAIL-FROM: BBNG.ARPA}{RTP:Mailer@G.BBN.COM}{TL=974.}{HDR-FROM:Mailer@BBNG.ARPA} ID=<[MC.LCS.MIT.EDU].828791.860224> EXP->ALLEN@1200600054::=(LWA@1200600054::=(lwa@2202400102),LIZ@1200600054::=(liz.umcp-cs@1200000140),JA@1200600054::=(nlg.ja@40700012035)) 125145 ICP->LOUIE.UDEL.EDU (TCP-SMTP) 125151 TO->liz.umcp-cs 125155 ICP->COMET.LCS.MIT.EDU (TCP-SMTP) 125158 TO->lwa 125201 ICP->SPEECH.MIT.EDU (CHAOS-MAIL) 125203 TO->nlg.ja ---------- my guess is that some host at BBN is chewing over the headers, and either ACOURT@BBN-VAX is an invalid address on the Butterfly-Lispers@BBNG list, or BBN-VAX is behaving badly. please look into this. thank you.  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 23 FEB 86 22:15:52 EST Date: Sun, 23 Feb 86 22:02:09 EST From: "Pandora B. Berman" Subject: This application clearly has NOTHING... To: RDZ@AI.AI.MIT.EDU, USER-ACCOUNTS@AI.AI.MIT.EDU cc: BUG-MAIL@AI.AI.MIT.EDU, BUG-PWORD@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].15880.860223.CENT> Date: Sat, 22 Feb 86 19:04:34 EST From: Ramin Zabih Subject: This application clearly has NOTHING to do with Jeff Broughton To: BUG-MAIL@MC.LCS.MIT.EDU, BUG-PWORD@MC.LCS.MIT.EDU Date: Sat, 22 Feb 86 17:08:25 EST From: Jeffrey M. Broughton Sender: JS at AI.AI.MIT.EDU To: ACCOUNTS-NOTIFICATION at AI.AI.MIT.EDU Re: Application from TTY 16 Date: 22 FEB 1986 1708-EST From: "Jeff Siegal " To: USER-ACCOUNTS at MIT-AI Name: Jeff Siegal From net site DEEP-THOUGHT.MIT.EDU Purpose: I use ITS from time to time to try and learn MIDAS Address: x2737 MIT 38-394 Affiliation: MIT EECS Dept ---------- you are confused. MAIL has to put -some- UNAME in the author field. what PWORD hands it is the real-name of the applicant. sometimes this translates into a UNAME that COMSAT recognizes, which causes the UNAME's owner's real-name to be included in the mail header. i don't know why PWORD doesn't hand COMSAT the applicant's desired UNAME -- perhaps there are screw cases that can come up. in any case, there is no confusion if you look at all closely. the applicant's real-name is inside the brackets of the From: header, showing that it is the real return addres -- what's before the brackets is cosmetic, like "From: The tty of Geoff Goodfellow ". The applicant's desired UNAME is given as the Sender: header.  Date: Sat, 22 Feb 86 19:04:34 EST From: Ramin Zabih Subject: This application clearly has NOTHING to do with Jeff Broughton To: BUG-MAIL@MC.LCS.MIT.EDU, BUG-PWORD@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].827323.860222.RDZ> Date: Sat, 22 Feb 86 17:08:25 EST From: Jeffrey M. Broughton Sender: JS at AI.AI.MIT.EDU To: ACCOUNTS-NOTIFICATION at AI.AI.MIT.EDU Re: Application from TTY 16 Date: 22 FEB 1986 1708-EST From: "Jeff Siegal " To: USER-ACCOUNTS at MIT-AI Name: Jeff Siegal From net site DEEP-THOUGHT.MIT.EDU Purpose: I use ITS from time to time to try and learn MIDAS Address: x2737 MIT 38-394 Affiliation: MIT EECS Dept  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 21 FEB 86 17:45:50 EST Date: Fri, 21 Feb 86 17:47:51 EST From: Daniel Huttenlocher To: BUG-COMSAT@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].15395.860221.DPH> Parsing the names file does not get an error when the same mailing list is defined twice as was evidenced by two BUG-3600's today.  Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU 18 Feb 86 00:34:19 EST Date: Tue, 18 Feb 1986 00:33 EST Message-ID: From: Rob Austein To: postmaster@ATHENA.MIT.EDU cc: bug-mail@MC.LCS.MIT.EDU Subject: [CSTACY: incorrect entry in host table ?] Will you people PLEASE make up your minds? Last week you asked me to put Athena's Chaosnet address into the host tables. So I did (after quietly checking to make sure you did in fact have a MAIL server). Now you have taken away your MAIL server and half of MIT can't talk to you anymore. If you don't want to be in the chaosnet table, say so. I don't care one way or the other, but I have better things to do than wade through the bug reports. Date: Monday, 17 February 1986 21:44-EST From: "Christopher C. Stacy" ATHENA has a Chaosnet address which COMSAT keeps trying to connect to, but this loses because it always gets a "No server for MAIL" rejection.  Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU 18 Feb 86 00:26:44 EST Date: Tue, 18 Feb 1986 00:25 EST Message-ID: From: Rob Austein To: "Christopher C. Stacy" Cc: BUG-MAIL@MC.LCS.MIT.EDU Subject: incorrect entry in host table ? In-reply-to: Msg of 17 Feb 1986 21:44-EST from "Christopher C. Stacy" Date: Monday, 17 February 1986 21:44-EST From: "Christopher C. Stacy" ATHENA has a Chaosnet address which COMSAT keeps trying to connect to, but this loses because it always gets a "No server for MAIL" rejection. They can't make up their minds (or whatever it is they use in lieu thereof). Last week they asked me to put this in the table for them, and last week they had a server (I checked then, it was there, I checked now, and it isn't). Maybe we should just tell people that we don't support mail to scitzophrenic twits.  Date: Mon, 17 Feb 86 21:46:03 EST From: "Christopher C. Stacy" Sender: CSTAC0@MC.LCS.MIT.EDU To: BUG-COMSAT@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].820990.860217.CSTAC0> I have lowered the threshold of connection attempts before COMSAT thinks a host is down; the new number is 250. This should be more reasonable given the large queues nowadays.  Date: Mon, 17 Feb 86 21:44:14 EST From: "Christopher C. Stacy" Sender: CSTAC0@MC.LCS.MIT.EDU Subject: incorrect entry in host table ? To: SRA@MC.LCS.MIT.EDU cc: BUG-MAIL@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].820978.860217.CSTAC0> ATHENA has a Chaosnet address which COMSAT keeps trying to connect to, but this loses because it always gets a "No server for MAIL" rejection.  Date: Mon, 17 Feb 86 05:12:17 EST From: "Christopher C. Stacy" To: BUG-MAIL@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].820411.860217.CSTACY> It is a bug that huge amounts of INFO-VAX mail is relayed through MC to hosts such as SCRC-STONY-BROOK and DSPG. The sender should know that SCRC has its own Internet address, and DSPG should have a local redistribution.  Date: Mon, 17 Feb 86 05:05:06 EST From: "Christopher C. Stacy" To: BUG-MAIL@MC.LCS.MIT.EDU cc: ALAN@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].820408.860217.CSTACY> The messages from the broken database have now all been delivered or returned to the sender with an indication that the destination host was down. I am not sure what was wrong with the database - something was fucked up in the MSGS file itself as far as I can tell, and this caused some messages to Multics to be lost.  Date: Sat, 15 Feb 86 05:02:43 EST From: "Christopher C. Stacy" To: BUG-COMSAT@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].819270.860215.CSTACY> I guess I'll look at the old MSGS file soon to see what the problem was. As a wild guess without looking, I wonder if it could be a REMIND frobbie that somehow got in there a long time ago and has never tried to run before. That's the only kind of message I can imagine offhand that would cause the program to crash while everything else continued to run BTW, the oldest message I found in MSGS the other day was from APRIL 1984!  Date: Sat, 15 Feb 86 04:46:21 EST From: "Christopher C. Stacy" To: BUG-MAIL@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].819263.860215.CSTACY> I moved the SAVE XXX files into SPACY1; so that COMSAT would not run out of directory space.  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 15 FEB 86 02:20:23 EST Date: Sat, 15 Feb 86 02:20:14 EST From: "Pandora B. Berman" Subject: foot slightly in mouth cc: BUG-MAIL@AI.AI.MIT.EDU, vtisr1!irlistrq@SEISMO.CSS.GOV Message-ID: <[AI.AI.MIT.EDU].14059.860215.CENT> Date: Sat, 15 Feb 86 01:09:27 EST From: "Pandora B. Berman" Subject: mail file size To: vtisr1!irlistrq@SEISMO.CSS.GOV cc: BUG-MAIL@AI.AI.MIT.EDU .... first, consider the size of your digests. are they -really- 20Kbytes, or are you just trusting COMSAT's count? i have heard that these days COMSAT sometimes does not give accurate sizes in these error msgs. that done, if your digests tend to be over something like 17Kbytes (i've forgotten the specific number), they couldn't have made it through COMSAT when COMSAT was healthy. the beastie just wasn't built to eat anything that large. if, however, they tend to be somewhat under that size, but larger than 2-3Kbytes, you are being bitten by COMSAT's space crunch. currently, COMSAT is not completely hooked up with the domain way of thinking, so it must stuff the enormity of the host tables as well as various other odds and ends into core to run. this doesn't leave much space for the actual msgs and their address lists that COMSAT is trying to process and transmit; as a result, anything over 2-3Kbytes (exactly how long depends on how much state COMSAT is currently hanging on to) just cannot be transmitted. all such msgs are stowed in an auxiliary directory for checking over/ignoring by the COMSAT maintainers. this unreasonable state of affairs is being worked on, or more accurately, will be soon, when the hacker who is going to fix this finishes his present higher-priority task. we hope COMSAT will be back up to snuff in a couple weeks. when that happens, all the msgs flushed by COMSAT for supposed excess length will be requeued and unleashed on the world again. until then, we all suffer this style of slings and arrows. sorry. sorry, i can't keep these numbers straight. the problem is as described above. however, i should have specified sizes in KWORDS, not KBYTES (CStacy says 1 ITS block = 1Kwords = roughly 5Kbytes, and he should know). in its heyday, COMSAT could swallow msgs up to roughly 15 ITS blocks. right now it can't handle anything over 2-3 blocks. so maybe your digests are really 20kbytes, but COMSAT still can't transmit them right now.  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 15 FEB 86 01:09:36 EST Date: Sat, 15 Feb 86 01:09:27 EST From: "Pandora B. Berman" Subject: mail file size To: vtisr1!irlistrq@SEISMO.CSS.GOV cc: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].14052.860215.CENT> Date: Thu, 13 Feb 86 13:18:09 EST From: vtisr1!irlistrq@seismo.CSS.GOV To: cent@mit-mc.arpa Subject: mail file size Perhaps you can help? I distribute IRList Digest to jcma@mit-mc.arpa Foner-Magazines@mit-mc.arpa DeJong%mit-oz@mit-mc.arpa and have recently been getting back messages like the one at the end of this one. SInce Digests often get large, and since I have no access to do FTP, is there some way that mit-mc can be made to accept messages of up to say 20k? Many thanks for your assistance! - Ed Fox (UUCP:seismo!vtisr1!fox; CSNET:fox@vt; BITNET:foxea@vtvax3) ---------- >From uucp Tue Feb 11 02:40 EST 1986 >From Mon Feb 10 09:54:14 1986 Received: by seismo.CSS.GOV; Mon, 10 Feb 86 09:54:14 EST Date: Mon, 10 Feb 86 09:24:16 EST From: Communications Satellite To: "vtisr1!irlistrq@seismo.CSS.GOV" Cc: MC.LCS.MIT.EDU!MAIL-MAINTAINERS Message-Id: <[MC.LCS.MIT.EDU].813443.860210> Status: R Error in input request file. Request too large. Message not sent and not queued; 20 Kbytes is far too large for me. Please use the FTP program to transfer huge files around the network. first, consider the size of your digests. are they -really- 20Kbytes, or are you just trusting COMSAT's count? i have heard that these days COMSAT sometimes does not give accurate sizes in these error msgs. that done, if your digests tend to be over something like 17Kbytes (i've forgotten the specific number), they couldn't have made it through COMSAT when COMSAT was healthy. the beastie just wasn't built to eat anything that large. if, however, they tend to be somewhat under that size, but larger than 2-3Kbytes, you are being bitten by COMSAT's space crunch. currently, COMSAT is not completely hooked up with the domain way of thinking, so it must stuff the enormity of the host tables as well as various other odds and ends into core to run. this doesn't leave much space for the actual msgs and their address lists that COMSAT is trying to process and transmit; as a result, anything over 2-3Kbytes (exactly how long depends on how much state COMSAT is currently hanging on to) just cannot be transmitted. all such msgs are stowed in an auxiliary directory for checking over/ignoring by the COMSAT maintainers. this unreasonable state of affairs is being worked on, or more accurately, will be soon, when the hacker who is going to fix this finishes his present higher-priority task. we hope COMSAT will be back up to snuff in a couple weeks. when that happens, all the msgs flushed by COMSAT for supposed excess length will be requeued and unleashed on the world again. until then, we all suffer this style of slings and arrows. sorry.  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 14 FEB 86 20:36:12 EST Date: Fri, 14 Feb 86 20:36:02 EST From: "Pandora B. Berman" Subject: lost msg To: wales@LOCUS.UCLA.EDU cc: HEADER-PEOPLE-REQUEST@AI.AI.MIT.EDU, BUG-MAIL@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].14028.860214.CENT> Date: Wed, 12 Feb 86 17:56:59 PST From: Rich Wales To: Header-People-Request@MC.LCS.MIT.EDU Subject: Re: Non-domain nicknames in mail Two weeks ago, I sent a message to the HEADER-PEOPLE list regarding the continued use of "non-domain" host nicknames in mail. I never saw this message come back to me through the list. Did my message make it out over HEADER-PEOPLE? If not, please let me know so I can send it again.... it apparently didn't make it out, but not for your lack of trying. COMSAT is undergoing a sad period of trial: basically, the size of everything COMSAT has to fit into core at once currently precludes its transmitting combinations of msgs&address lists larger than a few K words. Header-People is a pretty damn big list, so the combination of it and your msg have been just enough to tip COMSAT over the edge. your msg is now sitting in an auxiliary directory, waiting for COMSAT to have domains wired in. this is supposed to happen within a couple weeks (we hope); the hacker who's going to do it is now working on something with higher priority but thinks he's close to done. when domains are wired into COMSAT, it should revert to the previous state of being able to transmit msgs up to 15K (more or less) words, at which point all the msgs which have been flushed due to this problem will be re-queued and sent on their ways (probably causing much confusion). it might be worth your just trying to resend the msg now. COMSAT had its queued msg files gc'd of a lot of previously overlooked stuff earlier this week, and today suffered a catastrophe which forced us to rename these files and start with new empty ones; these circumstances mean that COMSAT has that much less to keep in core, so slightly larger msgs might make it through now.  Date: Fri, 14 Feb 86 17:42:46 EST From: Alan Bawden Subject: Big fire extinguished. Autopsy remains to be done. To: BUG-COMSAT@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].818842.860214.ALAN> Remember those PDL overflows I complained about earlier? Well there was this message (number 818354.860214) that was causing COMSAT to barf every time it tried to deliver it. In general it would cause COMSAT to dribble several pages of random garbage from its internal databases into the STATS file before it croaked. I tried to kill it, but that also cause COMSAT to go down in flames. The problem has not been solved. Instead the damaged mailer database files have been renamed to .MAIL.;SAVE * and a new set of files has been created using MFINIT$G. Someone will have to grovel over the SAVE files to extract the valid messages and find out what this killer msg looks like. (Its not going to be me.) Hopefully you haven't all forgotten about the 484 BADREQ files we have accumulated on .MAIL2 (some of them only on backup tape now) since December.  Date: Fri, 14 Feb 86 13:07:53 EST From: Alan Bawden To: BUG-COMSAT@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].818499.860214.ALAN> COMSAT on MC is dying today with PDL overflows. I pdumped a corpse into CRASH;COMSAT %PIPDL. The only additional information I can think of that you might need is that MC has been getting a lot of parity errors, although I don't see how that could be relevant.  Date: Wed, 12 Feb 86 10:10:31 EST From: Alan Bawden Subject: AI comsat losing? To: GZ@MC.LCS.MIT.EDU cc: BUG-COMSAT@MC.LCS.MIT.EDU, BUG-TCP@MC.LCS.MIT.EDU, CSTACY@MC.LCS.MIT.EDU, JTW@MC.LCS.MIT.EDU In-reply-to: Msg of Tue 11 Feb 86 20:38:58 EST from Gail Zacharias Message-ID: <[MC.LCS.MIT.EDU].815989.860212.ALAN> Date: Tue, 11 Feb 86 20:38:58 EST From: Gail Zacharias Date: Tue, 11 Feb 86 19:34:24 EST From: Alan Bawden Statistics from AI's and MC's most recent STATS files reveals that MC times out on 59% of its attempts to make TCP contact, it is refused 6% of the time and it succeeds 34% of the time. AI times out 85% of the time, is refused 14% of the time, and succeeds 2% of the time.... Umm, when AI came up on the net, I put it on the list of mail gateways for OZ. It's right after XX but before MC (I figure MC handles a lot of our mail anyway). XX was down for a while yesterday, so AI was getting OZ's mail for a few hours. Since OZ always tries to deliver mail semi-directly using the Chaos TCP server first, the mail only goes to the mail gateways when the Chaos/TCP connection fails. I.e. almost all mail from OZ which ends up queued on the gateway would be for hosts which are down at the time. Well, thats a good theory! Here is another theory to explain my AI is -refused- more often than MC: Some servers might be getting upset because AI is missing from their host table or otherwise blacklisted because of being down for several years. 2% is still awfully low. Perhaps some more detailed statistics are in order that actually take into account what set of hosts it is that AI and MC are trying to reach. Note, BTW, that LISTS MSGS on AI is only 25 block long, compared with 164 blocks on MC, so the consistency of the queue is probably completely different.  Date: Wed, 12 Feb 86 00:54:56 EST From: "Christopher C. Stacy" Subject: hmmmm To: BUG-COMSAT@MC.LCS.MIT.EDU cc: CENT@MC.LCS.MIT.EDU, sra@XX.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].815829.860212.CSTACY> There were a bunch of messages in MASTER but not QML, dated from many months ago. Since I requeued them, the size of LISTS MSGS has decreased from 700 blocks to 224 blocks as they have been delivered. Either someone manually fucked up the LISTS QUEUE file at some point in the past or there is a bug where messages can fall off the queue. I bet that if there is a bug, it is related to certain classes of failures where the message should be marked as flushable but instead is just unlinked.  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 12 FEB 86 00:49:08 EST Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 12 FEB 86 00:48:44 EST Date: Wed, 12 Feb 86 00:48:44 EST From: "Christopher C. Stacy" Subject: blast from the past! To: SRA@XX.LCS.MIT.EDU cc: BUG-MAIL@AI.AI.MIT.EDU, CENT@AI.AI.MIT.EDU In-reply-to: Msg of Wed 12 Feb 1986 00:21 EST from Rob Austein Message-ID: <[MC.LCS.MIT.EDU].815823.860212.CSTACY> Somehow, some amount of mail became unqueued but was still in the system. I suspected this the other day when I noticed some odd proportions of certain parts of COMSAT's database. So, I requeued them and now they are finally coming out of the woodwork. This could have happenned by someone deleting the LIST QUEUE file at some point, or possibly by some obscure bug.  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 12 FEB 86 00:20:04 EST Received: from XX.LCS.MIT.EDU by AI.AI.MIT.EDU.ARPA; 12 Feb 86 00:19:47 EST Date: Wed, 12 Feb 1986 00:21 EST Message-ID: From: Rob Austein To: "Pandora B. Berman" Cc: BUG-MAIL@AI.AI.MIT.EDU Subject: blast from the past! In-reply-to: Msg of 11 Feb 1986 23:54-EST from "Pandora B. Berman" Either things are emerging from dark corners of MC's queue, or somebody dumped a bunch of old MAIL > files onto MC. That one, having been sent to *MIT, should be somewhere in XX:MAIL-THROUGH-APR-85.TXT if in fact it was ever sent. Want me to pull it back online and check?  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 11 FEB 86 23:54:41 EST Date: Tue, 11 Feb 86 23:54:30 EST From: "Pandora B. Berman" Subject: blast from the past! To: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].13542.860211.CENT> Received: from OZ.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 11 FEB 86 23:51:31 EST Received: from MC.LCS.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 10 Feb 86 23:24-EST Date: 11 April 1984 14:21-EST From: Rosemary B. Hegg Subject: Saxe Seminar To: (*MSG *MIT) @ MIT-MC SEMINAR DATE: Friday, April 13th, 1984 yow! i wonder where this had been hiding.  Date: Tue, 11 Feb 86 22:36:25 EST From: "Keith F. Lynch" Subject: Why did MC receive this last August but I only got it today? To: BUG-MAIL@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].815686.860211.KFL> Received: from RUTGERS.ARPA by MIT-MC.ARPA 12 Aug 85 18:29:54 EDT Return-Path: Received: from BRL-TGR.ARPA by RUTGERS.ARPA with TCP; 9 Aug 85 00:33:40 EDT Date: Thu, 8 Aug 85 21:53:56 EDT From: Brint Cooper ReSent-Date: 12 Aug 85 17:27:33 EDT ReSent-From: *Hobbit* ReSent-To: Security: ; ...  Date: Tue, 11 Feb 86 20:38:58 EST From: Gail Zacharias Subject: AI comsat losing? To: ALAN@MC.LCS.MIT.EDU cc: BUG-COMSAT@MC.LCS.MIT.EDU, BUG-TCP@MC.LCS.MIT.EDU, CSTACY@MC.LCS.MIT.EDU, JTW@MC.LCS.MIT.EDU In-reply-to: Msg of Tue 11 Feb 86 19:34:24 EST from Alan Bawden Message-ID: <[MC.LCS.MIT.EDU].815612.860211.GZ> Date: Tue, 11 Feb 86 19:34:24 EST From: Alan Bawden Statistics from AI's and MC's most recent STATS files reveals that MC times out on 59% of its attempts to make TCP contact, it is refused 6% of the time and it succeeds 34% of the time. AI times out 85% of the time, is refused 14% of the time, and succeeds 2% of the time. I have no explanation for this phenomena. Umm, when AI came up on the net, I put it on the list of mail gateways for OZ. It's right after XX but before MC (I figure MC handles a lot of our mail anyway). XX was down for a while yesterday, so AI was getting OZ's mail for a few hours. Since OZ always tries to deliver mail semi-directly using the Chaos TCP server first, the mail only goes to the mail gateways when the Chaos/TCP connection fails. I.e. almost all mail from OZ which ends up queued on the gateway would be for hosts which are down at the time.  Date: Tue, 11 Feb 86 19:34:24 EST From: Alan Bawden Subject: AI comsat losing? To: CSTACY@MC.LCS.MIT.EDU cc: BUG-COMSAT@MC.LCS.MIT.EDU, BUG-TCP@MC.LCS.MIT.EDU, JTW@MC.LCS.MIT.EDU In-reply-to: Msg of Tue 11 Feb 86 18:12:24 EST from Christopher C. Stacy Message-ID: <[MC.LCS.MIT.EDU].815537.860211.ALAN> Date: Tue, 11 Feb 86 18:12:24 EST From: Christopher C. Stacy COMSAT looked like it was working with TCP when I installed it, and I know that at least some of the hosts AI could not reach are almost always down. A number of successful connections are also being made. So, I guess I am not convinced that anything is wrong. Please let me know if something obvious comes up. Statistics from AI's and MC's most recent STATS files reveals that MC times out on 59% of its attempts to make TCP contact, it is refused 6% of the time and it succeeds 34% of the time. AI times out 85% of the time, is refused 14% of the time, and succeeds 2% of the time. I have no explanation for this phenomena.  Date: Tue, 11 Feb 86 18:12:24 EST From: "Christopher C. Stacy" Subject: AI comsat losing? To: ALAN@MC.LCS.MIT.EDU cc: BUG-COMSAT@MC.LCS.MIT.EDU, BUG-TCP@MC.LCS.MIT.EDU, JTW@MC.LCS.MIT.EDU In-reply-to: Msg of Tue 11 Feb 86 10:05:59 EST from Alan Bawden Message-ID: <[MC.LCS.MIT.EDU].815465.860211.CSTACY> COMSAT looked like it was working with TCP when I installed it, and I know that at least some of the hosts AI could not reach are almost always down. A number of successful connections are also being made. So, I guess I am not convinced that anything is wrong. Please let me know if something obvious comes up.  Date: Tue, 11 Feb 86 10:05:59 EST From: Alan Bawden Subject: AI comsat losing? To: JTW@MC.LCS.MIT.EDU cc: CSTACY@MC.LCS.MIT.EDU, BUG-COMSAT@MC.LCS.MIT.EDU, BUG-TCP@MC.LCS.MIT.EDU In-reply-to: Msg of Tue 11 Feb 86 00:43:38 EST from John T. Wroclawski Message-ID: <[MC.LCS.MIT.EDU].814791.860211.ALAN> Date: Tue, 11 Feb 86 00:43:38 EST From: John T. Wroclawski To: CSTACY at AI, alan at MC Re: AI comsat losing? It looks like most (not all) of COMSAT's outgoing attempts to open TCP connections are timing out. Comments? Perhaps COMSAT's timeout for TCP connections is simply too short for a slow machine like AI? Can the hosts that COMSAT times out on be reached through other means? (Like FINGERing them from AI? Can MC's COMSAT reach them?)  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 9 FEB 86 15:31:22 EST Date: Sun, 9 Feb 86 15:14:42 EST From: "Christopher C. Stacy" To: BUG-MAIL@AI.AI.MIT.EDU cc: POSTMASTER@AI.AI.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].13063.860209.CSTACY> COMSAT on AI is now configured to use the ARPAnet, rather than relaying through MC. COMSAT BACKUP is the old version. Let me know if any problems are noticed.  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 2 FEB 86 20:24:41 EST Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 2 FEB 86 20:23:56 EST Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU 2 Feb 86 20:24:31 EST Date: Sun, 2 Feb 1986 20:25 EST Message-ID: From: Rob Austein To: Mark Plotnick Cc: bug-mail%ai@MC.LCS.MIT.EDU, postmaster%vx@MC.LCS.MIT.EDU Subject: losing addresses on info-hosts list In-reply-to: Msg of 1 Feb 1986 21:01-EST from Mark Plotnick Date: Saturday, 1 February 1986 21:01-EST From: Mark Plotnick I suspect the mailer problem is only semi-permanent. From what I can see, if you can open a telnet connection to mit-vax via tcp, you should also be able to open an smtp connection (there's still the problem of replies not being able to get back to the sender, though...). I just tried this from mit-charon, and it worked. Anyway, I no longer have the appropriate access to modify the unix mailer configuration tables here to handle tcp mail correctly, so it's probably best to talk to Jon Seiber (who's the official system maintainer and other member of the "postmaster" alias here) about the state of mit-vax's networking. I just tried the same thing from XX. The connection opened, I got the "4.2BSD" message, then VX broke the connection. This matches my recollection of previous attempts to do this sort of thing. I very much doubt that it is your SMTP server that is losing, it is almost certainly some flakeout in your TCP/IP code. For those on postmaster@VX who didn't get my last message, I would like to remove VX's IP address from the MIT host tables until you get your TCP/IP code fixed. I am getting tired of answering bug reports caused by this lossage.  Date: Sat, 1 Feb 86 23:04:06 EST From: Ken Harrenstien Subject: COMSAT barfing on "message too large" To: ELMO@XX.LCS.MIT.EDU cc: BUG-COMSAT@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].804880.860201.KLH> That is a spazz which only happens at certain times when COMSAT chokes up. The actual size of the message is irrelevant, although it is true that 20K bytes is guaranteed to cause a rejection. I doubt you'll ever have a digest THAT big. Was anyone looking at this?  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 1 FEB 86 21:02:55 EST Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 1 FEB 86 21:02:09 EST Received: from VAX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 1 FEB 86 21:02:48 EST Received: by mit-vax.Mit-chaos.Arpa (4.12/4.8) id AA15179; Sat, 1 Feb 86 21:01:43 est Date: Sat, 1 Feb 86 21:01:43 est From: Mark Plotnick To: bug-mail%ai@mc, sra@xx Subject: Re: losing addresses on info-hosts list I suspect the mailer problem is only semi-permanent. From what I can see, if you can open a telnet connection to mit-vax via tcp, you should also be able to open an smtp connection (there's still the problem of replies not being able to get back to the sender, though...). I just tried this from mit-charon, and it worked. Anyway, I no longer have the appropriate access to modify the unix mailer configuration tables here to handle tcp mail correctly, so it's probably best to talk to Jon Seiber (who's the official system maintainer and other member of the "postmaster" alias here) about the state of mit-vax's networking. Mark  Date: Sat, 1 Feb 86 00:05:07 EST From: Alan Bawden Subject: The curious history of message 802973.860131 To: BUG-COMSAT@MC.LCS.MIT.EDU In-reply-to: Msg of Fri 31 Jan 86 23:25 EST from David A. Moon Message-ID: <[MC.LCS.MIT.EDU].803886.860201.ALAN> Date: Fri, 31 Jan 86 23:25 EST From: David A. Moon My guess is that the list of messages queued to Marie became circular. The only thing stopping Comsat from looping infinitely was, I guess, that new input requests take priority over dequeueing old requests. Dave's choice on tense reminds me that I forgot to mention that this wasn't an isolated incident. There are a bunch of messages to this guy at MARIE doing this same thing in the stats files. Like it seems to always happen when he gets mail. (And he gets a lot since he is on something like Info-Atari-Request.)  Received: from SCRC-STONY-BROOK.ARPA by MC.LCS.MIT.EDU 31 Jan 86 23:26:58 EST Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 406718; Fri 31-Jan-86 23:23:48-EST Date: Fri, 31 Jan 86 23:25 EST From: David A. Moon Subject: The curious history of message 802973.860131 To: Alan Bawden cc: BUG-COMSAT@MC.LCS.MIT.EDU In-Reply-To: <[MC.LCS.MIT.EDU].803777.860131.ALAN> Message-ID: <860131232513.1.MOON@EUPHRATES.SCRC.Symbolics.COM> My guess is that the list of messages queued to Marie became circular. The only thing stopping Comsat from looping infinitely was, I guess, that new input requests take priority over dequeueing old requests.  Date: Fri, 31 Jan 86 21:12:38 EST From: Alan Bawden Subject: The curious history of message 802973.860131 To: BUG-COMSAT@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].803777.860131.ALAN> Below I have included every entry in the STATS files for message 802973.860131. Three things I find curious. First, note that COMSAT gave up trying to send this message in less than two hours after only about 30 tries to deliver it to TETHER at MARIE. Second, COMSAT seems to be batching its attempts to make contact with with MARIE. In fact COMSAT only tried to unqueue message to MARIE about 4 times before giving up, although each time it seems to have knocked multiple times. Third, COMSAT doesn't seem to have given up very cleanly; A few minutes after announcing that it is giving up, COMSAT seem suprised to find the message missing from MASTER. Perhaps my first observation can be explained because COMSAT has blacklisted MARIE in some way? (Does COMSAT have a way to put a host on probation if it seems uncooperative for an extended period, as MARIE has been?) Not knowing anything about how COMSAT works, I'm tempted to identify this behavior with the way COMSAT persecuted poor GSB a few days ago because his directory was full for 30 minutes... 084355 InReq: 1 > 1; SPECS:{NET-MAIL-FROM: SU-SCORE.ARPA}{RTP:@SU-SCORE.ARPA:abrams@mitre.ARPA}{TL=6162.}{HDR-FROM:abrams@MITRE.ARPA} ID=<[MC.LCS.MIT.EDU].802973.860131> EXP->SAT@1200600054,FIGMO@1200600054,EGK@1200600054,ARPEE@1200600054,SAT@1200600054::=(TETHER@40700007500),FIGMO@1200600054::=(LYNN%PANDA@1200000070),EGK@1200600054::=(egk@40700011406),ARPEE@1200600054 084357 Local->MC.LCS.MIT.EDU 084357 TO->ARPEE(GUEST0;) 084359 ICP->SUMEX-AIM.ARPA (TCP-SMTP) 084406 TO->LYNN%PANDA 084425 ICP->MARIE.MIT.EDU (CHAOS-MAIL) 084426 TO->TETHER 084440 NTMEND ERR=460,{%MAIL-E-NOMSG, Message number 107E810A} 084440 ICP->OZ.AI.MIT.EDU (CHAOS-MAIL) 084441 TO->egk 084444 Queued: <[MC.LCS.MIT.EDU].802973.860131> for MARIE.MIT.EDU 085155 QID=<[MC.LCS.MIT.EDU].802973.860131> 085156 TO->TETHER 085207 NTMEND ERR=460,{%MAIL-E-NOMSG, Message number 107E810A} 090709 Unqueueing to host MARIE.MIT.EDU 090710 ICP->MARIE.MIT.EDU (CHAOS-MAIL) 090711 QID=<[MC.LCS.MIT.EDU].802973.860131> 090711 TO->TETHER 090801 NTMEND ERR=460,{%MAIL-E-NOMSG, Message number 107E802A} 102525 Unqueueing to host MARIE.MIT.EDU 102525 ICP->MARIE.MIT.EDU (CHAOS-MAIL) 102526 QID=<[MC.LCS.MIT.EDU].802973.860131> 102526 TO->TETHER 102532 NTMEND ERR=460,{%MAIL-E-NOMSG, Message number 107E802A} 102533 QID=<[MC.LCS.MIT.EDU].802973.860131> 102534 TO->TETHER 102538 NTMEND ERR=460,{%MAIL-E-NOMSG, Message number 107E802A} 102540 QID=<[MC.LCS.MIT.EDU].802973.860131> 102541 TO->TETHER 102545 NTMEND ERR=460,{%MAIL-E-NOMSG, Message number 107E802A} 102546 QID=<[MC.LCS.MIT.EDU].802973.860131> 102547 TO->TETHER 102552 NTMEND ERR=460,{%MAIL-E-NOMSG, Message number 107E802A} 102553 QID=<[MC.LCS.MIT.EDU].802973.860131> 102554 TO->TETHER 102558 NTMEND ERR=460,{%MAIL-E-NOMSG, Message number 107E802A} 102559 QID=<[MC.LCS.MIT.EDU].802973.860131> 102600 TO->TETHER 102604 NTMEND ERR=460,{%MAIL-E-NOMSG, Message number 107E802A} 102606 QID=<[MC.LCS.MIT.EDU].802973.860131> 102607 TO->TETHER 102611 NTMEND ERR=460,{%MAIL-E-NOMSG, Message number 107E802A} 102613 QID=<[MC.LCS.MIT.EDU].802973.860131> 102614 TO->TETHER 102618 NTMEND ERR=460,{%MAIL-E-NOMSG, Message number 107E802A} 102619 QID=<[MC.LCS.MIT.EDU].802973.860131> 102620 TO->TETHER 102624 NTMEND ERR=460,{%MAIL-E-NOMSG, Message number 107E802A} 102734 Unqueueing to host MARIE.MIT.EDU 102734 ICP->MARIE.MIT.EDU (CHAOS-MAIL) 102735 QID=<[MC.LCS.MIT.EDU].802973.860131> 102735 TO->TETHER 102739 NTMEND ERR=460,{%MAIL-E-NOMSG, Message number 107E802A} 102741 QID=<[MC.LCS.MIT.EDU].802973.860131> 102742 TO->TETHER 102746 NTMEND ERR=460,{%MAIL-E-NOMSG, Message number 107E802A} 102748 QID=<[MC.LCS.MIT.EDU].802973.860131> 102749 TO->TETHER 102753 NTMEND ERR=460,{%MAIL-E-NOMSG, Message number 107E802A} 102754 QID=<[MC.LCS.MIT.EDU].802973.860131> 102755 TO->TETHER 102759 NTMEND ERR=460,{%MAIL-E-NOMSG, Message number 107E802A} 102800 QID=<[MC.LCS.MIT.EDU].802973.860131> 102801 TO->TETHER 102806 NTMEND ERR=460,{%MAIL-E-NOMSG, Message number 107E802A} 102807 QID=<[MC.LCS.MIT.EDU].802973.860131> 102808 TO->TETHER 102814 NTMEND ERR=460,{%MAIL-E-NOMSG, Message number 107E802A} 102815 QID=<[MC.LCS.MIT.EDU].802973.860131> 102816 TO->TETHER 102822 NTMEND ERR=460,{%MAIL-E-NOMSG, Message number 107E802A} 102823 QID=<[MC.LCS.MIT.EDU].802973.860131> 102824 TO->TETHER 102828 NTMEND ERR=460,{%MAIL-E-NOMSG, Message number 107E802A} 102830 QID=<[MC.LCS.MIT.EDU].802973.860131> 102830 TO->TETHER 102835 NTMEND ERR=460,{%MAIL-E-NOMSG, Message number 107E802A} 102836 QID=<[MC.LCS.MIT.EDU].802973.860131> 102837 TO->TETHER 102841 NTMEND ERR=460,{%MAIL-E-NOMSG, Message number 107E802A} 102843 QID=<[MC.LCS.MIT.EDU].802973.860131> 102844 TO->TETHER 102848 NTMEND ERR=460,{%MAIL-E-NOMSG, Message number 107E802A} 102849 QID=<[MC.LCS.MIT.EDU].802973.860131> 102850 TO->TETHER 102854 NTMEND ERR=460,{%MAIL-E-NOMSG, Message number 107E802A} 102856 QID=<[MC.LCS.MIT.EDU].802973.860131> 102857 TO->TETHER 102901 NTMEND ERR=460,{%MAIL-E-NOMSG, Message number 107E802A} 102903 QID=<[MC.LCS.MIT.EDU].802973.860131> 102904 TO->TETHER 102908 NTMEND ERR=460,{%MAIL-E-NOMSG, Message number 107E802A} 102909 QID=<[MC.LCS.MIT.EDU].802973.860131> 102910 TO->TETHER 102915 NTMEND ERR=460,{%MAIL-E-NOMSG, Message number 107E802A} 102916 QID=<[MC.LCS.MIT.EDU].802973.860131> 102917 TO->TETHER 102921 NTMEND ERR=460,{%MAIL-E-NOMSG, Message number 107E802A} 102923 QID=<[MC.LCS.MIT.EDU].802973.860131> 102924 TO->TETHER 102928 NTMEND ERR=460,{%MAIL-E-NOMSG, Message number 107E802A} 102929 QID=<[MC.LCS.MIT.EDU].802973.860131> 102930 TO->TETHER 102935 NTMEND ERR=460,{%MAIL-E-NOMSG, Message number 107E802A} 102936 QID=<[MC.LCS.MIT.EDU].802973.860131> 102938 TO->TETHER 102944 NTMEND ERR=460,{%MAIL-E-NOMSG, Message number 107E802A}...Giving up. 102944 CMSG ID=<[MC.LCS.MIT.EDU].803043.860131> EXP->@SU-SCORE.ARPA:abrams@mitre.ARPA@1200600013 102945 ICP->SU-SCORE.ARPA (TCP-SMTP) 102949 TO->@SU-SCORE.ARPA:abrams@mitre.ARPA 103036 Unqueueing to host MARIE.MIT.EDU 103036 Note: Qmsg "<[MC.LCS.MIT.EDU].802973.860131>" not found in MASTER, flushing. 103036 ICP->MARIE.MIT.EDU (CHAOS-MAIL) 103037 QID=<[MC.LCS.MIT.EDU].803024.860131> 103037 TO->TETHER 103040 NTMEND ERR=460,{%MAIL-E-NOMSG, Message number 107E802A}  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 31 JAN 86 15:29:23 EST Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 31 JAN 86 15:28:28 EST Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU 31 Jan 86 15:29:08 EST Date: Fri, 31 Jan 1986 15:29 EST Message-ID: From: Rob Austein To: Mark Plotnick Cc: bug-mail%ai@MC.LCS.MIT.EDU, cent%ai@MC.LCS.MIT.EDU, postmaster%vx@MC.LCS.MIT.EDU Subject: losing addresses on info-hosts list In-reply-to: Msg of 31 Jan 1986 15:00-EST from Mark Plotnick Mark, Is the VX mailer problem a permenant (or semi-permenant) thing? If so, I should comment out VX's IP address in the MIT host tables so that XX (and maybe other dual homed machines) won't try to send mail that way. This will also change the data in the LCS.MIT.EDU domain so that outsiders will know what to do with mail, assuming their mailers are smart enough to do this sort of thing. Right now XX and most of the outside world things VX is dead. I remember going around on this the last time VX was losing on TCP/IP mail, at that point it was a real uphill climb to get anybody to let me fix the host tables to reflect reality, mostly for emotional reasons. If you let me fix them this time I can promise that the change can be undone almost instantly (24->48 hours to propegate through most of MIT and any other part of the known universe that bothers to port our domain information). Modulo hardare lossages, of course, but that's part of any such promise. --Rob  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 31 JAN 86 15:02:06 EST Received: from VAX.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 31 JAN 86 15:01:14 EST Received: by mit-vax.Mit-chaos.Arpa (4.12/4.8) id AA02565; Fri, 31 Jan 86 15:00:55 est Date: Fri, 31 Jan 86 15:00:55 est From: Mark Plotnick To: bug-mail@ai, cent@ai, postmaster@mit-vax Subject: Re: losing addresses on info-hosts list the mailer here can currently only talk to chaosnet hosts (jon, you may want to talk with cliff neuman about adapting mit-eddie's config file to work on mit-vax). since scrc isn't a chaosnet host any more, jek's address was losing. I changed it to go through mc. the "TEN" alias here just forwards to "Tech@OZ", so I believe the problem lies there.  Date: Wed, 29 Jan 86 05:28:52 EST From: Ken Harrenstien Subject: Well, it was a period when I typed the message... To: ALAN@MC.LCS.MIT.EDU cc: BUG-COMSAT@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].800237.860129.KLH> The reason for "," instead of ". " is that no recopying of the message text is necessary; the offending char can be smashed in place. The message text can then be completely sent with a single call, rather than scanning it all line by line to do quoting on the fly.  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 29 JAN 86 00:51:44 EST Date: Wed, 29 Jan 86 00:51:21 EST From: "Pandora B. Berman" Subject: NYU loses, msg flushed To: ENERGY-REQUEST%AI.AI.MIT.EDU@MC.LCS.MIT.EDU, sullivan@NYU.ARPA cc: BUG-MAIL%AI.AI.MIT.EDU@MC.LCS.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].12039.860129.CENT> i had to delete the following msg from MC's queue: ---------- Date: Sun, 26 Jan 86 13:16:03 EST From: Moderator Sender: OAF@MC.LCS.MIT.EDU Subject: Energy Digest V86 #1.1 To: ENERGY-DIEHARDS@MC.LCS.MIT.EDU [msg body omitted] ---------- because it was screwing up NYU's mailer: ---------- Date: Mon, 27 Jan 86 13:35:34 est From: sullivan@nyu.arpa (David J. Sullivan) To: energy-request@mc.lcs.mit.edu Subject: Our mailer is barfing - please cease and desist..... Cc: postmaster@nyu.arpa, postmaster@mc.lcs.mit.edu We have been getting a piece of mail from the energy mailing list with an smtp from address of <<< HELO MC.LCS.MIT.EDU <<< MAIL FROM:@MC.LCS.MIT.EDU> I think it is the nested angle brackets that causes our mailer to go into a loop. Obviously, our mailer should be more robust, but of course a valid address will clean up the problems. I have had to kill ten invocations of our mailer twice, some of which had run over one hour of cpu time. No work can be done when this happens. Please! Fix the letter bomb. David Sullivan New York University ---------- unfortunately, the msg was still in the queue to ISI-VAXA and LANL at the time i killed it, so any ENERGY list members at those sites did not receive the msg. sorry. this is what a typical interaction looked like to COMSAT: ---------- 003147 Unqueueing to host NYU.ARPA 003147 ICP->NYU.ARPA (TCP-SMTP) 003151 QID=<[MC.LCS.MIT.EDU].796527.860126.OAF>...error for @MC.LCS.MIT.EDU>="554 Too many rewrites - assuming infinite loop.", trying <>....init lost, R="554 Too many rewrites - assuming infinite loop." 003156 Note: Gobbling LSR1 database 003157 Note: Gobbling host table 003157 Unqueueing to host ISI-VAXA.ARPA 003157 ICP->ISI-VAXA.ARPA (TCP-SMTP=Timeout) 003213 InReq: 1 > 1; SPECS:{NET-MAIL-FROM: NYU.ARPA}{RTP:MAILER-DAEMON@nyu.arpa}{TL=576.}{HDR-FROM:MAILER-DAEMON@NYU.ARPA} ID=<[MC.LCS.MIT.EDU].800052.860129> EXP->Moderator@3200000072 003213 ICP->NYU.ARPA (TCP-SMTP) 003218 TO->Moderator 003219 NTMBEG PERM ERR={550 ... User unknown} 003219 CMSG ID=<[MC.LCS.MIT.EDU].800053.860129> EXP->MAILER-DAEMON@nyu.arpa@3200000072 003223 ICP->NYU.ARPA (TCP-SMTP) 003227 TO->MAILER-DAEMON@nyu.arpa  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 29 JAN 86 00:17:11 EST Date: Wed, 29 Jan 86 00:16:48 EST From: "Pandora B. Berman" Subject: losing addresses To: postmaster@VAX.LCS.MIT.EDU cc: BUG-MAIL%AI.AI.MIT.EDU@MC.LCS.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].12030.860129.CENT> something is broken with the way VX is handling mail; please look into the following: Date: Tue, 28 Jan 86 21:55:35 EST From: Mail Delivery Subsystem Subject: Returned mail: Host unknown To: "Pandora B. Berman" ----- Transcript of session follows ----- 550 jek@scrc... Host unknown ----- Unsent message follows ----- Received: by mit-vax.Mit-chaos.Arpa (4.12/4.8) with CHAOS id AA12928; Tue, 28 Jan 86 21:57:50 est Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 28 JAN 86 21:55:59 EST Date: Tue, 28 Jan 86 21:55:35 EST From: "Pandora B. Berman" Subject: SYSNET;HSTMIT ? To: Mills@CISL-SERVICE-MULTICS.MIT.EDU Cc: INFO-Hosts@MC.LCS.MIT.EDU Message-Id: <[AI.AI.MIT.EDU].12019.860128.CENT> [INFO-HOSTS msg omitted] SCRC should be a known host. ---------- Date: Tue 28 Jan 86 22:02:28-EST From: The Mailer Daemon To: CENT%AI.AI.MIT.EDU@MC.LCS.MIT.EDU Subject: Message of 28-Jan-86 22:01:04 Message failed for the following: tech.tech@MULTICS.MIT.EDU.Internet: 550 Some directory in path specified does not exist. ------------ Received: from VAX.LCS.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 28 Jan 86 22:01-EST Received: by mit-vax.Mit-chaos.Arpa (4.12/4.8) with CHAOS id AA12928; Tue, 28 Jan 86 21:57:50 est Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 28 JAN 86 21:55:59 EST Date: Tue, 28 Jan 86 21:55:35 EST From: "Pandora B. Berman" Subject: SYSNET;HSTMIT ? To: Mills@CISL-SERVICE-MULTICS.MIT.EDU Cc: INFO-Hosts@MC.LCS.MIT.EDU Message-Id: <[AI.AI.MIT.EDU].12019.860128.CENT> [INFO-HOSTS msg again omitted] probably the Multics address is actually Tech.Tech -- capitalization tends to be relevant in Multics addresses. could VX's mailer be lower-casing this address?  Date: Mon, 27 Jan 86 08:30:32 EST From: Alan Bawden Subject: MC:.MAIL.;BADREQ files To: JPG@MC.LCS.MIT.EDU, CENT@AI.AI.MIT.EDU cc: BUG-MAIL@MC.LCS.MIT.EDU In-reply-to: Msg of Mon 27 Jan 86 07:11:03 EST from Pandora B. Berman Message-ID: <[MC.LCS.MIT.EDU].797253.860127.ALAN> JPG correctly points out that the people who sent all of those BADREQ files generally received a note from COMSAT explaining that their mail had not gone through. In some sense the files are expendable and we are doing them a favor, rather than fulfilling an obligation, if we deliver it now. Date: Mon, 27 Jan 86 07:11:03 EST From: Pandora B. Berman ... most of those badreqs are files that comsat would usually have no trouble with, but right now it can't send them on, and it can't even return them... Penny correctly points out that those people did not always get their mail back, many of them got a note complaining that their mail was larger than 15K characters and so could not be delivered. Since in general their mail was not even close to that long, you could probably forgive them if they were confused and had no idea what COMSAT was talking about. JPG wins additional points because he is the one who has actually been shuffling the files off of .MAIL. regularly and keeping us from drowning completely. I'm generally in favor of the rule that the people who do the actual work to clean up the mess have more of a right to make decisions about how the job gets done. Alan points out that those files are sequentially numbered and sitting out there on incremental dump tapes, so it shouldn't be hard to get them back if we decide we -really- feel like it. Finally, Alan apologizes for misleading Penny into thinking that no reasonable person could possibly be just deleting those files, and so therefore we should chop the fingers off of whoever did it. Turns out that JPG was in fact using his brain, things aren't a disaster, and I am inclined to encourage him to continue the practice even if it isn't exactly what I would have done myself.  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 27 JAN 86 07:11:35 EST Date: Mon, 27 Jan 86 07:11:03 EST From: "Pandora B. Berman" Subject: MC:.MAIL.;BADREQ files To: JPG%AI.AI.MIT.EDU@MC.LCS.MIT.EDU cc: BUG-MAIL%AI.AI.MIT.EDU@MC.LCS.MIT.EDU, ALAN%AI.AI.MIT.EDU@MC.LCS.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].11870.860127.CENT> Date: Mon, 27 Jan 86 01:11:32 EST From: "Jeffrey P. Golden" Subject: MC:.MAIL.;BADREQ files To: CENT@MC.LCS.MIT.EDU cc: BUG-MAIL@MC.LCS.MIT.EDU CENT@MC.LCS.MIT.EDU 01/27/86 00:24:54 Re: "File too large" BADREQs To: JPG at MC.LCS.MIT.EDU CC: (BUG MAIL) at MC.LCS.MIT.EDU do you know what's happening to the BADREQ files? alan set up .MAIL2; to hold them until COMSAT could eat them again. recently, someone else (you, we conjectured) starting moving them there from .MAIL.;. also the oldest ones have been disappearing -- that seems somewhat anti-social. do you know anything about this? Yes, I've been moving the BADREQ files from .MAIL.; less it get too full. And I've been deleting old ones from .MAIL2; when it was getting full. As we all know file directories on MC can only hold so many files. I've always got mail back when a BADREQ file was due to mail I've sent so I had no idea my action was in any way antisocial. But I'll take your word for it and desist. If you wish, I'll sit back and watch COMSAT have to deal with a bloated .MAIL.; directory! i'm sorry, i was afraid that would come out sounding wrong. in general, you are right: mail authors who cause badreqs get back a copy of their undeliverable mail, and the badreq files shouldn't be left to clutter up .mail.;. thank you for keeping moving them. but comsat has been under special constraints for about a month -- basically, with the domain naming stuff not hooked up yet and the current size of comsat and names > and the host tables and all, comsat can't stomach a msg longer than 2-3 blocks. which is pretty damn small. so most of those badreqs are files that comsat would usually have no trouble with, but right now it can't send them on, and it can't even return them, either strictly because the msgs are too big for it or because their from: headers produce unparsable return addresses. so they end up as badreqs and no one responsible for their creation knows what's going on (not everyone has the good fortune to use an ITS for their mail). when they started building up, alan created .mail2;, and he said the intent was to resend the badreqs that were ok except for the current size fiasco after comsat was fixed. of course, that's taken longer than we hoped because cstacy has (with moving to palladian) become for our purposes completely unreliable. but SRA has volunteered to deal with comsat, and he's competent, so we think something useful will happen in the foreseeable future. i thought alan was going to comment on the current situation, but he's not on bug-mail. alan, please help me take my foot out of my mouth.  Date: Mon, 27 Jan 86 01:11:32 EST From: "Jeffrey P. Golden" Subject: MC:.MAIL.;BADREQ files To: CENT@MC.LCS.MIT.EDU cc: BUG-MAIL@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].797011.860127.JPG> CENT@MC.LCS.MIT.EDU 01/27/86 00:24:54 Re: "File too large" BADREQs To: JPG at MC.LCS.MIT.EDU CC: (BUG MAIL) at MC.LCS.MIT.EDU do you know what's happening to the BADREQ files? alan set up .MAIL2; to hold them until COMSAT could eat them again. recently, someone else (you, we conjectured) starting moving them there from .MAIL.;. also the oldest ones have been disappearing -- that seems somewhat anti-social. do you know anything about this? Yes, I've been moving the BADREQ files from .MAIL.; less it get too full. And I've been deleting old ones from .MAIL2; when it was getting full. As we all know file directories on MC can only hold so many files. I've always got mail back when a BADREQ file was due to mail I've sent so I had no idea my action was in any way antisocial. But I'll take your word for it and desist. If you wish, I'll sit back and watch COMSAT have to deal with a bloated .MAIL.; directory!  Date: Mon, 27 Jan 86 01:10:46 EST From: David Vinayak Wallace Subject: NAMED ERR files To: BUG-COMSAT@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].797008.860127.GUMBY> MSG: NAMED ERR CENT@MC.LCS.MIT.EDU 01/26/86 22:15:49 Re: NAMED ERR files Several times during the past week, someone has deleted all the NAMED ERR files on .MAIL.;... COMSAT should set the don't reap bit on the higest version when it makes it, and remove it from the previous version.  Date: Mon, 27 Jan 86 00:24:54 EST From: "Pandora B. Berman" Subject: "File too large" BADREQs To: JPG@MC.LCS.MIT.EDU cc: BUG-MAIL@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].796994.860127.CENT> do you know what's happening to the BADREQ files? alan set up .MAIL2; to hold them until COMSAT could eat them again. recently, someone else (you, we conjectured) starting moving them there from .MAIL.;. also the oldest ones have been disappearing -- that seems somewhat anti-social. do you know anything about this?  Date: Sun, 26 Jan 86 23:10:01 EST From: Gail Zacharias Subject: failed mail notification excessively verbose To: JTW@SPEECH.MIT.EDU cc: BUG-COMSAT@MC.LCS.MIT.EDU In-reply-to: Msg of Sun 26 Jan 86 16:48:19-EST from John Wroclawski Message-ID: <[MC.LCS.MIT.EDU].796953.860126.GZ> With the possible exception of Multics, all the mail systems I've ever seen send back the complete message when they fail to deliver mail. You might be getting confused by non-final error notifications, which generally only include the header (or, in COMSAT's case, only the recipient addresses).  Received: from SCRC-STONY-BROOK.ARPA by MC.LCS.MIT.EDU 26 Jan 86 16:51:47 EST Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 401814; Sun 26-Jan-86 16:50:07-EST Date: Sun, 26 Jan 86 16:50 EST From: David A. Moon Subject: Re: return addresses in mailed messages To: Ian Macky cc: JTW%MIT-SPEECH@MC.LCS.MIT.EDU, bug-comsat@MC.LCS.MIT.EDU In-Reply-To: <12178130724.18.IAN@SRI-NIC.ARPA> Message-ID: <860126165043.6.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Sat 25 Jan 86 13:10:02-PST From: Ian Macky the bogus header was made by COMSAT, when SENDER requested HEADER-FORCE:NET... i took out the header-force, since i'm not as picky about format as i used to be. comsat people: hf:net makes from: fields like "foo at bar" which no longer makes it, instead of "foo@bar" Comsat's just doing what you tell it to. Try HEADER-FORCE:RFC733 if you want it to format according to a more recent standard.  Received: from SPEECH.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 26 JAN 86 16:49:09 EST Date: Sun 26 Jan 86 16:48:19-EST From: John Wroclawski Subject: Re: failed mail notification excessively verbose To: Moon@SCRC-STONY-BROOK.ARPA cc: bug-comsat@MC.LCS.MIT.EDU In-Reply-To: Message from "David A. Moon " of Sun 26 Jan 86 16:21:59-EST From: David A. Moon Subject: failed mail notification excessively verbose Well, how are you going to retransmit the message to the correct address if you haven't got the whole message in your hands? If this is religious, I'm the Pope. ------ By plucking it out of the file where all my mail gets cc'd to when I send it. But yes, Alan pointed this usefulness out, and I guess it makes sense for those of us who do not have an RP06 full of old outgoing mail. I wonder what those people do when they get messages bounced back from TOPS20 or that PDP11 operating system that everyone is using. -------  Received: from SCRC-STONY-BROOK.ARPA by MC.LCS.MIT.EDU 26 Jan 86 16:17:54 EST Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 401786; Sun 26-Jan-86 16:16:15-EST Date: Sun, 26 Jan 86 16:16 EST From: David A. Moon Subject: failed mail notification excessively verbose To: John Wroclawski cc: bug-comsat@MC.LCS.MIT.EDU In-Reply-To: The message of 25 Jan 86 03:00-EST from John Wroclawski Message-ID: <860126161653.0.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Sat 25 Jan 86 03:00:28-EST From: John Wroclawski Is there some religious reason why COMSAT has to return the *entire* message to you when it fails to deliver it? Perhaps just the header, or the header and the first few lines, would do. I just sent this guy a small book in the mail and got the whole 14K character thing bounced back in my face because his address was bogus. ------- Well, how are you going to retransmit the message to the correct address if you haven't got the whole message in your hands? If this is religious, I'm the Pope.  Received: from SRI-NIC.ARPA by MC.LCS.MIT.EDU 25 Jan 86 16:11:00 EST Date: Sat 25 Jan 86 13:10:02-PST From: Ian Macky Subject: Re: return addresses in mailed messages To: JTW%MIT-SPEECH@MC.LCS.MIT.EDU cc: bug-comsat@MC.LCS.MIT.EDU In-Reply-To: Message from "John Wroclawski " of Sat 25 Jan 86 12:56:25-PST Message-ID: <12178130724.18.IAN@SRI-NIC.ARPA> the bogus header was made by COMSAT, when SENDER requested HEADER-FORCE:NET... i took out the header-force, since i'm not as picky about format as i used to be. comsat people: hf:net makes from: fields like "foo at bar" which no longer makes it, instead of "foo@bar" -------  Received: from SPEECH.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 25 JAN 86 03:01:16 EST Date: Sat 25 Jan 86 03:00:28-EST From: John Wroclawski Subject: failed mail notification excessively verbose To: bug-comsat@MC.LCS.MIT.EDU Is there some religious reason why COMSAT has to return the *entire* message to you when it fails to deliver it? Perhaps just the header, or the header and the first few lines, would do. I just sent this guy a small book in the mail and got the whole 14K character thing bounced back in my face because his address was bogus. -------  Date: Sat, 25 Jan 86 00:06:29 EST From: Alan Bawden Subject: Well, it was a period when I typed the message... To: BUG-COMSAT@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].795561.860125.ALAN> Date: Fri, 24 Jan 86 23:59:47 EST From: Alan Bawden Subject: . To: ALAN@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].795557.860124.ALAN> , The previous line contains a single period. I think I liked it better when COMSAT would turn a line consisting of a single period into a period followed by a space. That way you run a much smaller the risk of damaging the intent of the message. Is this feature really still necessary? I thought the braindamage that made this necessary was changed.  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 24 JAN 86 21:40:50 EST Date: Fri, 24 Jan 86 21:39:35 EST From: "Pandora B. Berman" Subject: aniticipation To: KROWITZ@MARIE.MIT.EDU cc: BUG-MAIL%AI.AI.MIT.EDU@MC.LCS.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].11742.860124.CENT> sorry, your infinite msg -is- still in the queue. our queue-flushing software has to be modified to understand the new domain-style names. this should happen real soon...  Received: from MARIE.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 24 JAN 86 12:11:47 EST Date: 24 Jan 86 12:14:58 EST From: KROWITZ@MIT-MARIE To: bug-mail@mc HELP!!! I'm being burried alive by the mailer! In the past two days I have received over 100 copies of the message below. All of the copies have the same recevied date both for XX gettting the message from SUMEX and for MC getting the message from XX. This leads me to believe that it is MC who is duplicating the message. The info-mac mailing list has been dead for months, and now that it has returned it has sent me the same message about once every 5 to 10 minutes! -- Dave Krowitz -------------------------------------------------------------- From: MARIE::CHAOSMAIL 23-JAN-1986 17:17 To: KROWITZ Subj: From: INFO-MAC-REQUEST@SUMEX-AIM.ARPA Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU 22 Jan 86 21:35:57 EST Received: from SUMEX-AIM.ARPA by XX.LCS.MIT.EDU with TCP; Wed 22 Jan 86 21:34:08-EST Date: 22 Jan 86 1657-PST From: Moderator Richard M. Alderson Reply-to: INFO-MAC@SUMEX-AIM.ARPA Subject: INFO-MAC Digest V4 #5 To: INFO-MAC@SUMEX-AIM.ARPA INFO-MAC Digest Wednesday, 22 Jan 1986 Volume 4 : Issue 5 Today's Topics: The list is back in action MacWorld Expo ---------------------------------------------------------------------- Date: Sun 19 Jan 86 23:31:37-PST From: Richard M. Alderson Subject: The list is back in action The Info-Mac Digests are back. I apologize to all those who have suffered the long drought so patiently. I won't bore the entire readership with the long list of reasons that I took so long to get back into the swing of this. Now that I am back, I will clear out a very large backlog, and then step aside. My special thanks go to those across the country who offered their help. It would have been difficult to set up forwardings and such because I have no privileges here on the SUMEX machine--my status is that of a guest, with an account only because I am moderating the digest. In any case, we are back. There will be a large number of large digests coming in the next days. A lot of software has come in, along with quite a few questions. The newsy items will, I'm afraid, have lost a little of their punch, but that will change very quickly. Rich Alderson (soon-to-be-ex-)Moderator P. S. This note was supposed to come out Sunday, but SUMEX had hardware problems that made them take it down. ------------------------------ Date: Tue 21 Jan 86 19:48:09-PST From: Richard M. Alderson Subject: MacWorld Expo Too crowded, too commercial. [Opinion of the writer.] One thing did stand out in my mind: Everyone seems to agree that the SCSI port on the Mac Plus means that prices for Mac hard disks from ALL manufac- turers have to drop. The Mac Plus looks like a nice machine, but it's evolutionary, not revolu- tionary. It DOES fix up some flaws in the original design, but it's NOT the open-architecture machine many were hoping for. Ah, well, such is progress. There are also upgrade kits, and those who bought their machines in the last two or three months (I don't have the fencepost dates available to me) can receive a rebate for the upgrades. I'm still looking for someone to do something about my two-year-old 128K single-drive wonderbox. Rich Alderson "Although these may be the opinions of lots of people I know, I'm the one who expressed them here. And there's nothing less official than that!" ------------------------------ End of INFO-MAC Digest **********************  Date: Wed, 22 Jan 86 13:06:56 EST From: Alan Bawden Subject: COMSAT persecuting GSB, film at 11 To: BUG-COMSAT@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].792094.860122.ALAN> I don't care if it got 1,000,000 "temporary errors", COMSAT has no business bouncing this back to me after only trying for 30 minutes! Did it really try 201 times in 30 minutes? Surely COMSAT has something better to do than to perpetually pound on GSB's directory. Perhaps COMSAT has forgotten how to count and only -thinks- it tried 201 times. Date: Wed, 22 Jan 86 11:59:54 EST From: Communications Satellite To: ALAN at MC.LCS.MIT.EDU Re: Msg of Wednesday, 22 January 1986 11:31-EST FAILED: GSB at MC.LCS.MIT.EDU; I gave up on sending this after 201 "temporary" errors. Failed message follows: ------- Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 22 JAN 86 11:30:03 EST Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 22 JAN 86 11:28:52 EST Date: Wed, 22 Jan 86 11:28:57 EST From: Alan Bawden Subject: Enter the rumor mill To: JNC@XX.LCS.MIT.EDU cc: KS-ITS@MC.LCS.MIT.EDU, sollins@XX.LCS.MIT.EDU, SRA@XX.LCS.MIT.EDU, JTW@SPEECH.MIT.EDU In-reply-to: Msg of Tue 21 Jan 86 23:02:02-EST from J. Noel Chiappa Message-ID: <[MC.LCS.MIT.EDU].791949.860122.ALAN>  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 17 JAN 86 02:15:47 EST Date: Fri, 17 Jan 86 02:16:00 EST From: "Pandora B. Berman" Subject: Quest for Prof. Paul Penfield To: PHILLIPS%src.csnet@CSNET-RELAY.ARPA cc: POSTMASTER%AI.AI.MIT.EDU@MC.LCS.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].11138.860117.CENT> Date: Wed, 15 Jan 86 13:24 ??? From: "D. HOWARD PHILLIPS, MANUFACTURING SCIENCES RESEARCH" To: postmaster@mit-mc.ARPA Subject: Quest for Prof. Paul Penfield Could you advise the correct e-mail address for Prof. Penfield? His former address does not seem to work any more. Thanks, Howard Phillips his address is LSI.PP%MIT-SPEECH@MIT-MC.ARPA.  Date: Thu, 16 Jan 86 18:56:50 EST From: Rob Austein Subject: "Alright then, I shall avenge your near moral wounding..." To: BUG-COMSAT@MC.LCS.MIT.EDU, ALAN@MC.LCS.MIT.EDU, BERLIN@MC.LCS.MIT.EDU cc: SRA@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].786041.860116.SRA> I twiddled the host table some and managed to GC about 8 disk blocks, which seems to be enough to keep COMSAT running (although not well). COMSAT will probably continue to fall over whenever it recompiles NAMES, but at least it should be able to reboot now.  Date: Thu, 16 Jan 86 17:21:19 EST From: Rob Austein Subject: COMSAT is on its last legs To: BUG-COMSAT@MC.LCS.MIT.EDU, ALAN@MC.LCS.MIT.EDU, MLY@MC.LCS.MIT.EDU, BERLIN@MC.LCS.MIT.EDU cc: SRA@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].785800.860116.SRA> I just managed to launch a COMSAT after several losing tries. It had been down since around 8am. Postmortem reveals that (1) MLY compiled a new HOSTS3 > last night, and (2) BERLIN edited NAMES > at around 8am (to *delete* something, fer gossakes). Apparently the new HOSTS3 (which is one name larger) pushed COMSAT over the edge so that it no longer has enough address space to compile NAMES > into LIST EQV. Of course, by the time I noticed this and fixed it there was enough mail piled up that COMSAT couldn't compile LIST QUEUE either, so this had to be gc'd by hand (groan). I am going to see what I can do with the host table, but I don't expect to be able to gc that all much space. This means that unless somebody does something drastic COMSAT will not even be able to boot in another few months. Begining of the end, folks.  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 15 JAN 86 02:00:37 EST Date: Wed, 15 Jan 86 02:00:12 EST From: "Pandora B. Berman" Subject: ARMS-D trouble To: LIN@XX.LCS.MIT.EDU cc: POSTMASTER%AI.AI.MIT.EDU@MC.LCS.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].10947.860115.CENT> Date: Tue, 14 Jan 1986 23:26 EST From: LIN@XX.LCS.MIT.EDU To: "Pandora B. Berman" Cc: arms-d-request@XX.LCS.MIT.EDU, POSTMASTER@MC.LCS.MIT.EDU Date: Tuesday, 14 January 1986 22:26-EST From: Pandora B. Berman To: arms-d-request cc: POSTMASTER at MC.LCS.MIT.EDU your new distribution list has been causing COMSAT to crash when it tries to send you msg-queued info -- please look into this. Hmmm. I've never gotten msg-queued info before from COMSAT. Any idea what's going on? when COMSAT expands the list, it appears to have no problems (doesn't run into unknown hosts or local users). however, during delivery, it has this: ---------- 210423 ICP->C.CS.CMU.EDU (TCP-SMTP) 210426 XTO->VAF 210427 XTO->HASTINGS 210429 TEXT-> 210429 NTMBEG PERM ERR={550 No such local mailbox as "HASTINGS", recipient rejected} 210429 ICP->USC-ISIB.ARPA (TCP-SMTP) 210432 TO->ISI-ARMS-D 210444 ICP->JPL-VLSI.ARPA (TCP-SMTP) 210449 TO->august 210459 ICP->CSNET-RELAY.ARPA (TCP-SMTP) 210506 XTO->arms-d.umass-coins 210517 XTO->armslist%lsu 210522 XTO->uci-arms-d.uci 210526 XTO->kjs%tufts.arpa ...PERM ERR={550 (BHST) Unknown host/domain name in "kjs%tufts.arpa@CSNET-RELAY.ARPA"} 210532 XTO->Cerys%TI-CSL 210537 XTO->das%oregon-state.csnet 210539 XTO->dietz%slb-doll.csnet 210544 XTO->chapman_sys%uta.csnet 210548 XTO->FOLLMER%HP-LABS.csnet 210551 XTO->linnig%ti-eg.csnet 210556 XTO->RLG2.YKTVMT%ibm-sj.csnet 210559 TEXT-> ---------- and also this sort of thing: ---------- 210251 ICP->LOCUS.UCLA.EDU (TCP-SMTP=Timeout) 210306 ICP->XEROX.ARPA (TCP-SMTP) 210309 TO->ArmsDiscussion^.pa 210322 ICP->UCBVAX.BERKELEY.EDU (TCP-SMTP=Timeout) ---------- normally, a user who sends mail which encounters such errors and delays gets a notification from COMSAT that the mail was rejected or delayed. recently, these warnings have not been reaching many list-maintainers, because of confusion over domains and other addressing issues (instead, COMSAT has tried to deliver the warning, been told by the foreign host that no such address exists or similar lossage, and dropped the warning into the bit bucket). when COMSAT tried to send the notification to you, this happened: ---------- 211923 CMSG ID=<[MC.LCS.MIT.EDU].784174.860114> EXP->ARMS-D-Request%MIT-MC.ARPA@XX.LCS.MIT.EDU@1200000054 211923 ICP->XX.LCS.MIT.EDU (CHAOS-MAIL ---------- and then it died. there are a couple possibilities. one is that COMSAT filled its working space (which is pretty small these days) just as it tried to send you the warning, and died; but in such cases COMSAT has been asserting that it's dying due to lack of space, and with your mail it was crashing silently instead. another is that the From: header you supplied, ARMS-D-REQUEST%MC@XX@MC, was unparsable. COMSAT does not check From headers until it finds that it has to send a notification or return the msg, so i think this is more likely. you should change the header to avoid this bouncing between XX and MC.  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 14 JAN 86 02:44:57 EST Date: Tue, 14 Jan 86 02:44:26 EST From: "Pandora B. Berman" Subject: "Mail too large" To: TMPLee@DOCKMASTER.ARPA cc: POSTMASTER%AI.AI.MIT.EDU@MC.LCS.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].10839.860114.CENT> Date: Fri, 10 Jan 86 00:45 EST From: TMPLee@DOCKMASTER.ARPA To: COMSAT@MIT-MC.ARPA, MAIL-MAINTAINERS@MIT-MC.ARPA, POSTMASTER@MIT-MC.ARPA In-Reply-To: Message of 8 Jan 86 11:57 EST from "Communications Satellite" Date: 8 January 1986 11:57 est From: Communications Satellite Error in input request file. Request too large. Message not sent and not queued; 15 Kbytes is far too large for me. Please use the FTP program to transfer huge files around the network. a) out of over 200 addressees, yours is the only one to reject the message. unfortunately, COMSAT (our mailer) has been experiencing some constipation due to the effort to change over to the use of domains. during this period, it is unable to transmit mail larger than a few Kbytes, and it sometimes misstates the size of something it couldn't swallow. we hope that this phase will soon be over. however, if your msg really was over 15 Kbytes, then COMSAT could never have transmitted it in any case.  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 10 JAN 86 23:28:04 EST Date: Fri, 10 Jan 86 22:18:35 EST From: "Pandora B. Berman" Subject: woefully misdirected mail To: postmaster@UCBVAX.BERKELEY.EDU, postmaster@OZ.AI.MIT.EDU cc: POSTMASTER%AI.AI.MIT.EDU@MC.LCS.MIT.EDU, Schiffman@SRI-KL.ARPA Message-ID: <[AI.AI.MIT.EDU].10510.860110.CENT> postmasters: ALLAN is not on the INFO-NETS list (which lives on MIT-OZ, which tends to access the Arpanet through MIT-MC), nor is SCHIFFMAN, nor any other likely incarnation of his name. unless mr. schiffman sent some mail to INFO-NETS which engendered errors, there is no good reason he should receive this error response. my (mostly uneducated) guess is that UKMA or CBOSGD is confused, or somewhere in between them bits are being dropped or rearranged, garbling the return addresses and depicting MC as the author's host when in fact it was just a conduit, so that someone on the list with first name Allan is being confused with ALLAN@MC. INFO-NETS is a large and active list; please look into this problem quickly so that allan@mc can get some relief from the onslaught. thanks. ---------- Date: Wed 8 Jan 86 19:42:18-PST From: Allan M. Schiffman Subject: [ukma!MAILER-DAEMON@ucbvax.berkeley.edu (Mail Delivery Subsystem): Returned mail: User unknown] To: postmaster%MIT-MC@SRI-KL I am getting all kinds of mailer error messages from MC. I have an account there (uname: ALLAN) that seems to be getting misdirected mail. -Allan --------------- Remailed-on: Jan 8 1986 13:14:21 Return-Path: <@MC.LCS.MIT.EDU:cbosgd!ukma!MAILER-DAEMON@ucbvax.berkeley.edu> Received: from MC.LCS.MIT.EDU by SRI-KL.ARPA with TCP; Tue 7 Jan 86 20:52:57-PST Received: from ucbvax.berkeley.edu by MC.LCS.MIT.EDU 7 Jan 86 23:35:43 EST Received: by ucbvax.berkeley.edu (5.39/1.7) id AA04171; Tue, 7 Jan 86 20:35:44 PST Received: by ukma.UUCP (4.12/4.7) id AB23706; Tue, 7 Jan 86 16:48:26 est Date: Tue, 7 Jan 86 16:48:26 est From: ukma!MAILER-DAEMON@ucbvax.berkeley.edu (Mail Delivery Subsystem) Subject: Returned mail: User unknown Message-Id: <8601072148.AB23706@ukma.UUCP> To: cbosgd!MC.LCS.MIT.EDU!Allan at ucbvax.berkeley.edu (Mail Delivery Subsystem) To: 'info-nets'@ucbvax.berkeley.edu ----- Transcript of session follows ----- 554 cbosgd!ucbvax!MC.LCS.MIT.EDU!Allan 'info-nets'... Usage: /etc/sendmail [flags] addr... 550 'info-nets'... User unknown ----- No message was collected -----  Date: Thu, 9 Jan 86 11:34:55 EST From: "Christopher C. Stacy" To: BUG-MAIL@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].778285.860109.CSTACY> To clarify my previous note, the DQ device (using HOSTS3) is NOT currently hooked up to COMSAT.  Date: Thu, 9 Jan 86 10:50:14 EST From: "Christopher C. Stacy" To: BUG-MAIL@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].778229.860109.CSTACY> I have not finished hooking up domains to COMSAT yet; I am still working on it. I will be gone this weekend, but will be able to do some more hacking next week. Meanwhile, I have taught DQ: about the HOSTS3 database, so that we can run with the domain stuff in place without relying on the resolver and foreign servers for the nonce. DQ:HOTS3;CH;PTR;1440.CH-ADDR.MIT.EDU works ....  Received: from SRI-KL.ARPA by MC.LCS.MIT.EDU 6 Jan 86 15:34:49 EST Date: Mon, 6 Jan 1986 11:26 PST From: David Chapman To: bug-mail at mc, bug-mail at oz Subject: someone isn't putting in % signs I got mail today that claimed to be from FLECK@OZ.AI.MIT.EDU. That doesn't make it from the outside world.  Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 6 Jan 86 04:47:57 EST Received: from bostonu by csnet-relay.csnet id ac02199; 6 Jan 86 4:39 EST Received: from BUCS20 (bucs20.ARPA) by bu-cs.ARPA (4.12/4.7) id AA14297; Sun, 5 Jan 86 17:08:56 est Date: Sun, 5 Jan 1986 17:09 EST Message-Id: <[BUCS20].JSOL. 5-Jan-86 17:09:02> From: Jon Solomon To: Alan Bawden Cc: BUG-ITS@mit-mc.arpa, BUG-MAIL@mit-mc.arpa, BUG-RANDOM-PROGRAM@mit-mc.arpa, KS-ITS@mit-mc.arpa Subject: [JSOL: TELECOM] Consider this a warning. Phase-Of-The-Moon: LQ+2D.21H.36M.2S. In-Reply-To: Msg of 5 Jan 1986 15:26-EST from Alan Bawden Okay, now I know the intended audience for my message. One fact that I forgot to mention in the other message was that this JUST started happening about a week ago. Whoever is hacking COMSAT, please take note. Thanks, --JSol  Date: Sun, 5 Jan 86 15:26:51 EST From: Alan Bawden Subject: [JSOL: TELECOM] Consider this a warning. To: BUG-MAIL@MC.LCS.MIT.EDU, BUG-ITS@MC.LCS.MIT.EDU, BUG-RANDOM-PROGRAM@MC.LCS.MIT.EDU, KS-ITS@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].773515.860105.ALAN> MSG: *MSG 4866 Date: 01/05/86 13:22:00 From: JSOL at XX.LCS.MIT.EDU To: *BBOARD at XX.LCS.MIT.EDU Re: TELECOM Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU 5 Jan 86 13:21:49 EST Date: Sun 5 Jan 86 13:24:23-EST From: Jon Solomon Subject: TELECOM To: BBOARD@MC.LCS.MIT.EDU Message-ID: <12172857686.19.JSOL@XX.LCS.MIT.EDU> Due to the installation of a new mail system, I can no longer ship off TELECOM to MC. Since there are quite a large number of MC users on TELECOM, and considering the fact that this restriction might affect other digests, I am sending this message to your bulletin board rather than individually to MC users. I -believe- what he is refering to is the fact that digests tend to be large enough that they exceed COMSAT's pitifully small size limitation. I note that CSTACY claimed the lock for hacking COMSAT two weeks ago, hacked on it for an evening, and hasn't logged in since then. There are now about 130 BADREQ files on .MAIL2, many of them 2 weeks old. (I'm going to have to create .MAIL3 soon...) Warning: If the day ever comes that I feel that it is Up-To-Me- To-Do-Something about COMSAT (because of address space problems, lack of proper domain support, or whatever) I will simply advise everybody that ITS no longer supports mail for users or mail forwarding for the network and I will shut it off. I feel this day -rapidly- approaching. I don't see any competent programmers making the kind of necessary effort it is going to take to straighten out this mess. I am forwarding this message to a large audience in the hopes that somebody will get inspired, but I realize this is grasping at straws.  Date: Mon, 30 Dec 85 16:18:36 EST From: Herb Lin Subject: [ota: Name problem.] To: BUG-MAIL@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].769005.851230.LIN> hi. can someone help with a peculiar mailer problem arms-d seems to be having? tnx. Date: Mon, 30 Dec 85 11:19:48 PST From: Ted Anderson To: lin at mit-mc.arpa cc: jmb at s1-b.arpa, ota at s1-b.arpa, jmiller at apg-1.arpa Re: Name problem. I found the following message in a Dec 20 issue of the space digest. It is clearly from Jeff Miller. However, it claims to be from Jeffrey M Broughton. As far as I know Broughton doesn't even read ARMS-D, but the attribution is far from clear and it is moderately important to get it right. My guess as to the problem is that MIT-MC thinks that jeff is an alias for Jeff Broughton and for some reason the from field of the message is being reinterpreted at MC. This might also explain the double set of nested angle brackets. Please look into this problem. Thanks, Ted Anderson Date: Fri, 20 Dec 85 10:38:27 EST From: "Jeffrey M. Broughton" @MC.LCS.MIT.EDU> Subject: Dezinformatsiya I apologize- our organization is heavily involved in the generating of quarterly reports, so I could not put as much as I would like to have in this message. Disinformation is not a synonym for misinformation or propaganda. It is not a legitimate member of the English lexicon. Why? The term "dezinformatsiya" was coined by the Soviets. Many terms used in the . . . . Redoubt". An elaborate story was concocted to lead to the discovery of the crate, whose contents were believed and caused great damage to the German government. Highly recommend the book by Ladislav Bittmann I quoted in earlier message. I believe Ballentine has it in paperback. It is rare that the West gets to hear from a defector who was an architect of a given field of intelligence. Also, "Inside the KGB" by Aleksei Myagkov.  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 29 DEC 85 20:40:53 EST Date: Sun, 29 Dec 85 20:39:13 EST From: "Pandora B. Berman" To: LIN@MC.LCS.MIT.EDU cc: BUG-MAIL@MC.LCS.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].9505.851229.CENT> Date: Fri, 27 Dec 85 10:32:24 EST From: Herb Lin To: BUG-MAIL@MC.LCS.MIT.EDU hi. can someone tell me how big a file the MC mailer will send? I tried 10K and it barfed, but I thought I have tried 10K before. (with success) tnx. COMSAT used to be able to swallow msgs up to somewhere in the region of 15 blocks. however, in those days COMSAT was smaller and didn't have to deal with excessive address and net protocol bullshit. when COMSAT runs, it has to fit itself, the bin of NAMES >, LISTS MSGS, the host tables or something like them, and a copy of each @FILE list that has been used since COMSAT came up, into an address space, as well as the msg it is trying to send. the bigger all the rest of these things are, the shorter the max msg it can transmit. nowadays, COMSAT is all haired up to deal with SMTP and domains and like that, and the host tables are huge, so COMSAT barfs on things longer than a few blocks. i -think- things are supposed to get better when the domain stuff starts working; chris said he's working on that now.  Date: Sun, 29 Dec 85 20:10:13 EST From: Alan Bawden Subject: Rulers To: DCP@SCRC-STONY-BROOK.ARPA cc: BUG-COMSAT@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].768272.851229.ALAN> Here are all minimal solutions up to 12 spaces (13 marks). Dan's program is responsible for the results so marked. (I hope the format of this table is obvious.) 1 1 ((1)) 2 3 ((1 2)) 3 6 ((1 3 2)) 4 11 ((1 3 5 2) (2 5 1 3)) 5 17 ((1 3 6 2 5) (1 3 6 5 2) (1 7 3 2 4) (1 7 4 2 3)) 6 25 ((1 3 6 8 5 2) (1 6 4 9 3 2) (1 10 5 3 4 2) (2 1 7 6 5 4) (2 5 6 8 1 3)) 7 34 ((1 3 5 6 7 10 2)) 8 44 ((1 4 7 13 2 8 6 3)) 9 55 ((1 5 4 13 3 8 7 12 2)) 10 72 ((1 3 9 15 5 14 7 10 6 2) (1 8 10 5 7 21 4 2 11 3)) 10 73 () ; Hoey 11 85 ((2 4 18 5 11 3 12 13 7 1 9)) ; Hoey 12 106 ((2 3 20 12 6 16 11 15 4 9 1 7)) ; Hoey Here is all of the mail I have from Dan: (In more-or-less chronological order) [ Sorry, COMSAT is too broken to mail 3 blocks of text. Take a look at the file MC:ALAN;RULER MAIL for the text I had to delete from the end of this message. Bug-COMSAT: Please note that the error message I got from COMSAT incorrectly accused me of trying to mail 15 Kbytes! ]  Date: Sun, 29 Dec 85 17:28:40 EST From: Alan Bawden Subject: mail queued in BADREQ files To: BUG-COMSAT@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].768186.851229.ALAN> This afternoon I moved some more BADREQ files to .MAIL2, there are about 75 of them there now. There have been 6 more created on .MAIL. since then. Somebody should figure out some way to help all of that mail on its way...  Date: Sat, 28 Dec 85 19:00:04 EST From: Alan Bawden To: BUG-COMSAT@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].767453.851228.ALAN> I found .MAIL. completely full of BADREQ files, so I created a .MAIL2 directory and moved them there. COMSAT still seems unable to do a damn thing without crashing (which means you won't even see this message until you fix the problem). I am seriously considering moving my mail someplace other than an ITS.  Date: Fri, 27 Dec 85 10:32:24 EST From: Herb Lin To: BUG-MAIL@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].767164.851227.LIN> hi. can someone tell me how big a file the MC mailer will send? I tried 10K and it barfed, but I thought I have tried 10K before. (with success) tnx.  Date: Fri, 27 Dec 85 00:22:29 EST From: "Leo P. Harten" To: BUG-MAIL@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].766909.851227.LPH> I deleted a number of backed up or un-needed (as in names > when named errnnn was ok) off .MAIL.; when it got full and refused to process further. Is it a good idea to move the BADREQ files to another directory so that space will remain available on .mail.; for short mail files? I tend to login in the overnight times, and could easily check .mail.; to see if space is available during the time I'm around. If someone will advise me on the practicality of the idea, the mailer could probably run the small jobs ok and then a knowledgable person could re-queue the larger files off some temp dir when they come in...  Date: Tue, 24 Dec 85 19:40:12 EST From: "George J. Carrette" To: BUG-COMSAT@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].765865.851224.GJC> How come LISTS MSGS is getting so big lately, e.g. 389 blocks? Why is the mailer killing itself over this so much lately? Is there anything that can be done about it?  Date: Mon, 23 Dec 85 22:17:55 EST From: "Keith F. Lynch" Subject: Host JI To: BUG-MAIL@MC.LCS.MIT.EDU cc: KFL@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].765237.851223.KFL> Why does replying to McGeer@JI not work? Is JI short for JIMI.AI.MIT.EDU as FINGER thinks? ...Keoth  Date: Mon, 23 Dec 85 02:14:37 EST From: "Christopher C. Stacy" To: BUG-MAIL@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].764396.851223.CSTACY> COMSAT 548 (installed on MC) has the feature that if it crashes out of address space before processing a single input request, the current input request is renamed. This should keep it from crashing over and over and over again on the same first job. To keep it from crashing in general, I have begun hooking up the DOMAIN: device to it, but this will take longer than today. I'll be in and out this week to work on it, which is as much time as I can spare.  Date: Sun, 22 Dec 85 15:22:54 EST From: "Christopher C. Stacy" To: BUG-COMSAT@MC.LCS.MIT.EDU cc: POOR-MC@MC.LCS.MIT.EDU In-reply-to: Msg of Sat 21 Dec 85 18:12:59 EST from Gail Zacharias Message-ID: <[MC.LCS.MIT.EDU].763994.851222.CSTACY> Okay folks, here I am hooking up domains to COMSAT today. The SYSNET directory is now locked.  Date: Sat, 21 Dec 85 18:12:59 EST From: Gail Zacharias To: BUG-COMSAT@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].763387.851221.GZ> I had to rename a few more mailin files to badreq cause they were choking comsat. I hope somebody goes thru these once in a while and generates rejection notices or something for them, cause comsat doesn't.  Date: Sat, 21 Dec 85 17:10:51 EST From: Charles Frankston Subject: Bad Comsat food from yesterday. To: BUG-MAIL@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].763261.851221.CBF> As per more standard practive, I moved that failing InReq file from yesterday to .MAIL.;BADREQ >.  Date: Fri, 20 Dec 85 20:03:20 EST From: Charles Frankston Subject: COMSAT dieing To: BUG-MAIL@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].762845.851220.CBF> In CBF;MAILIN 1 you will find an InReq file that was causing COMSAT die repeatedly. I :MOVE'd it to my directory in order to unwedge COMSAT. It appears to be running out of address space. Does this mean that NAMES > has gotten much too big again, or there really something terrible about this InReq file? I wonder if COMSAT will run long enough for anyone to see this message?  Date: Fri, 20 Dec 85 06:04:13 EST From: Alan Bawden To: BUG-COMSAT@MC.LCS.MIT.EDU cc: CENT@MC.LCS.MIT.EDU, JPG@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].762020.851220.ALAN> The fact that these days COMSAT cannot handle a mail file that is more than about 4 blocks long is a complete and total shaft! The fact that this causes it to drop dead, leaving the file as MAILIN 1 so that it will just choke on it again when it gets restarted sucks! This means that some poor human (me, JPG, Penny, etc.) have to babysit the sucker just to nurse it through a normal day.  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 20 DEC 85 05:57:01 EST Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 20 DEC 85 05:54:49 EST Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 20 DEC 85 04:54:12 EST Received: from SINATRA.AI.MIT.EDU by MIT-OZ via Chaosnet; 20 Dec 85 04:51-EST Date: Fri, 20 Dec 85 04:51 EST From: David M. J. Saslav Subject: extraneous lists To: Pandora B. Berman cc: BUG-MAIL%AI.AI.MIT.EDU@MC.LCS.MIT.EDU In-Reply-To: <[AI.AI.MIT.EDU].9055.851219.CENT> Message-ID: <851220045154.1.SAZ@SINATRA.AI.MIT.EDU> You are quite right on all counts. I'm sorry. It won't happen again. David  Date: Thu, 19 Dec 85 16:55:06 EST From: Gail Zacharias To: BUG-COMSAT@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].761232.851219.GZ> Comsat couldn't get past the mailin file without crashing so I renamed it to badreq 3.  Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 19 DEC 85 03:19:46 EST Date: Thu, 19 Dec 85 03:17:33 EST From: "Pandora B. Berman" Subject: extraneous lists To: SAZ%AI.AI.MIT.EDU@MC.LCS.MIT.EDU cc: BUG-MAIL%AI.AI.MIT.EDU@MC.LCS.MIT.EDU Message-ID: <[AI.AI.MIT.EDU].9055.851219.CENT> i noticed that someone had been diddling a lot with MC:NAMES > around midnight, and investigated. first, if you're going to create mailing lists, please save the file the minimum number of times required to insure that your editing is saved -- saving the file extra times in the middle just overworks COMSAT more. second, don't make cute aliases for yourself just to cloud the issue of how many people really receive mail through a list -- NAMES > is rather close to its maximum size, above which it -won't- compile, causing COMSAT to die, guaranteeing that you will not receive mail from the outside world. not to mention the grief this situation would cause everyone else at the lab. i have removed your extraneous aliases; please do not reinstall them. third, while as a member of the lab you have the right to create nearly any mailing list in reason, i think that creating lists simply to cause every alphabet letter to have lists is a pretty thin reason. if you really want to twiddle with mailing lists, do it on OZ.  Date: Wed, 18 Dec 85 18:41:23 EST From: "Jeffrey P. Golden" Subject: COMSAT chokes To: BUG-MAIL@MC.LCS.MIT.EDU Message-ID: <[MC.LCS.MIT.EDU].759938.851218.JPG> The mailer was choking just now on a MAILIN 1 file. I renamed it to .MAIL.;BADMLN 1 and it appears to be working again.  Received: from SCRC-STONY-BROOK.ARPA by MIT-MC.ARPA 16 Dec 85 18:28:00 EST Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 375452; Mon 16-Dec-85 16:47:19-EST Date: Mon, 16 Dec 85 16:42 EST From: David A. Moon Subject: [COMSAT@MIT-MC.ARPA: Msg of Sunday, 15 December 1985 03:39-EST] To: David Vinayak Wallace cc: bug-comsat@MIT-MC.ARPA In-Reply-To: <851215042301.8.GUMBY@JIMI.AI.MIT.EDU> Message-ID: <851216164247.5.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Sun, 15 Dec 85 04:23 EST From: David Vinayak Wallace Maybe comsat should treat this as if the host were down? Although I agree with the sentiment that sendmail is a loser, I think COMSAT should be smart enough to deal with this. Date: Sun, 15 Dec 85 03:42:29 EST From: Communications Satellite Subject: Msg of Sunday, 15 December 1985 03:39-EST To: GUMBY@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].754546.851215> FAILED: INFO-GNU-PREP at MIT-PREP.ARPA; Funny reply from foreign host after sending message. Last reply was: {-Sendmail is losing big.} ... The protocol says that a minus sign in the reply means that the error is fatal and should not be retried and a percent sign means that the error is temporary and should be retried. Regardless of how big a lose sendmail is, I think it's better to make Prep's mail server follow the protocol than to put a special case into Comsat.  Received: from MIT-JIMI by MIT-MC.ARPA via Chaosnet; 15 DEC 85 04:25:10 EST Date: Sun, 15 Dec 85 04:23 EST From: David Vinayak Wallace Subject: [COMSAT@MIT-MC.ARPA: Msg of Sunday, 15 December 1985 03:39-EST] To: bug-comsat@MIT-MC.ARPA Message-ID: <851215042301.8.GUMBY@JIMI.AI.MIT.EDU> Maybe comsat should treat this as if the host were down? Although I agree with the sentiment that sendmail is a loser, I think COMSAT should be smart enough to deal with this. Date: Sun, 15 Dec 85 03:42:29 EST From: Communications Satellite Subject: Msg of Sunday, 15 December 1985 03:39-EST To: GUMBY@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].754546.851215> FAILED: INFO-GNU-PREP at MIT-PREP.ARPA; Funny reply from foreign host after sending message. Last reply was: {-Sendmail is losing big.} ...  Date: Fri, 13 Dec 85 20:12:22 EST From: "George J. Carrette" To: BUG-COMSAT@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].753357.851213.GJC> Is there a way to get COMSAT to tell you what the sequence of commands was when it tried to send a message to a host?  Date: Thu, 12 Dec 85 20:58:06 EST From: "Edward H. Lay" Subject: forwarded mail To: CENT@MIT-AI.ARPA cc: BUG-MAIL@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].751516.851212.EHL> Date: Wed, 11 Dec 85 22:02:11 EST From: Pandora B. Berman To: EHL at MIT-MC.ARPA Re: forwarded mail Date: Tue, 10 Dec 85 17:04:05 EST From: "Edward H. Lay" Subject: forwarding... this must be for you To: CENT@MIT-AI.ARPA Date: Tue, 10 Dec 85 00:29:27 EST From: Pandora B. Berman ==> To: bug-boxer at MIT-OZ cc: EHL%MIT-AI.ARPA at MIT-MC.ARPA Re: forwarding... this must be for you Date: Mon, 9 Dec 85 20:48 PST From: Edward Lay Subject: some random turds ==> To: bug-boxer@MC.ARPA I'm sort of curious as where this ended up so that it had to be forwarded. there is no BUG-BOXER@MC. however, COMSAT is equipped to believe that any mail with an address beginning BUG- may be important, so all such mail with unknown addresses (e.g. BUG-BOXER) is sent to a catch-all list of people willing to redirect it or otherwise deal with it. i am on that list. Something is broken here because there IS a bug-boxer@MC (I just checked in .mail.;names >). In fact, bug-boxer@OZ is supposed to FORWARD to MC.  Received: from MIT-AI.ARPA by MIT-MC.ARPA via Chaosnet; 11 DEC 85 23:24:19 EST Date: Wed, 11 Dec 85 23:22:06 EST From: "Pandora B. Berman" Subject: mail flood To: postel@USC-ISIB.ARPA, cak@PURDUE.EDU, sloan@UW-TANGA.ARPA cc: POSTMASTER%MIT-AI.ARPA@MIT-MC.ARPA, HEADER-PEOPLE-REQUEST%MIT-AI.ARPA@MIT-MC.ARPA, postmaster@SEISMO.CSS.GOV Message-ID: <[MIT-AI.ARPA].8493.851211.CENT> Date: 10 Dec 1985 15:08-PST From: Kenneth Sloan Subject: mail flood To: postmaster@washington.arpa, postmaster@mit-mc.arpa, postmaster@seismo.css.gov Postmaster- The message below (header only shown) has been appearing at uw-tanga.arpa every half-hour or so. If you can stem the tide, please do so. -Ken Sloan ---------- Date: 10 Dec 1985 17:41:23 PST From: POSTEL@USC-ISIB.ARPA Subject: re help! To: ken@CIT-HAMLET.ARPA, header-people-request@MIT-MC.ARPA cc: postel@USC-ISIB.ARPA Yes. I am receiving multiple copies of this message from Teus Hagen. --jon. ---------- To: header-people-request@mit-mc.arpa Subject: Make it stop! National-Indulgence-Of-The-Day: Lager Date: 10 Dec 85 20:14:08 EST (Tue) From: "Christopher A. Kent" Please ... I've gotten at least 10 copies of this message. chris ------- Forwarded Message Return-path: @MIT-MC.ARPA:mcvax!ace!teus@seismo.CSS.GOV Received: from arthur.Purdue.EDU (purdue-arthur) by merlin.Purdue.EDU; Tue, 10 Dec 85 17:48:23 EST Received: from MIT-MC.ARPA by arthur.Purdue.EDU; Tue, 10 Dec 85 17:47:36 EST Received: from seismo.CSS.GOV by MIT-MC.ARPA 10 Dec 85 17:27:20 EST Return-Path: Received: from mcvax.UUCP by seismo.CSS.GOV with UUCP; Tue, 10 Dec 85 17:03:11 EST Received: by mcvax.UUCP; Tue, 10 Dec 85 21:46:48 +0100 (MET) Received: by mcvax.UUCP; Tue, 10 Dec 85 21:45:42 +0100 (MET) Received: by ace (4.40/1.10) with UUCP id AA02208; Tue, 10 Dec 85 21:40:14+0100 (MET) Received: by sunrel1 (4.40/1.10) id AA16148; Tue, 10 Dec 85 11:18:00+0100 (MET) Message-Id: <8512101018.AA16148@sunrel1> To: Tommy_Ericson__QZ%QZCOM.MAILNET@mit-multics.arpa, Header_People_mailing_lists%QZCOM.MAILNET@mit-multics.arpa, MHS_implementation_mailing_list%QZCOM.MAILNET@mit-multics.arpa Cc: MIT-MULTICS.ARPA!Header_People_mailing_lists@qzcom.mailnet, MIT-MULTICS.ARPA!MHS_implementation_mailing_list@qzcom.mailnet, header-people , mhs_implementation@rsch.wisc.edu Subject: Re: Need for new field in RFC and MHS standards Date: 10 Dec 85 11:17:48 N (Tue) From: Teus Hagen [msg text omitted] sorry about that, gang. apparently Teus's msg was redundantly sent many times before it reached MC. not too much we can do about it. i hope the onslaught has finished. if not, i can poke around some, but you're more likely to get effective assistance nearer the source -- e.g. from postmaster@seismo and whoever's in charge of the vaxes that the msg passed through before it got there.  Received: from MIT-XX.ARPA by MIT-MC.ARPA 11 Dec 85 14:38:57 EST Date: Wed 11 Dec 85 12:58:50-EST From: "J. Noel Chiappa" Subject: MIT-AI To: bug-mail@MIT-MC.ARPA cc: JNC@MIT-XX.ARPA Message-ID: <12166299437.10.JNC@MIT-XX.ARPA> I'm not sure this is the right place, but: Mail sent to MIT-AI from XX loses, since XX thinks that AI is on the INternet (since it's in HSTNIC) and doesn't try CHAOS mail. Lose, lose. -------  Date: Wed, 11 Dec 85 01:00:53 EST From: Alan Bawden To: BUG-COMSAT@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].749279.851211.ALAN> COMSAT crashed every time it came up for about two hours because of the file I renamed to BADREQ 4. This new policy of keeping the MAILIN file around forever really does seem to be a loser. Perhaps it should rename that file if COMSAT has been up for less than 15 minutes when it crashes? Hello?!  Received: from MIT-AI.ARPA by MIT-MC.ARPA via Chaosnet; 10 DEC 85 00:27:26 EST Date: Tue, 10 Dec 85 00:26:19 EST From: "Pandora B. Berman" Subject: Why this failed To: KFL%MIT-AI.ARPA@MIT-MC.ARPA cc: BUG-MAIL%MIT-AI.ARPA@MIT-MC.ARPA Message-ID: <[MIT-AI.ARPA].8341.851210.CENT> Date: Mon, 9 Dec 85 20:32:36 EST From: "Keith F. Lynch" Subject: Why did this fail? To: BUG-MAIL@MIT-MC.ARPA Date: Mon, 9 Dec 85 20:30:59 EST From: Communications Satellite ============ A copy of your message is being returned, because: ======= "SWA@TALCOTT.MIT.EDU" at MIT-MC.ARPA is an unknown recipient. ============ Failed message follows: ============ Date: Mon, 9 Dec 85 20:30:59 EST From: "Keith F. Lynch" To: "SWA@TALCOTT.MIT.EDU"@MIT-MC.ARPA Welcome back to the net! ...Keith there is no host TALCOTT.MIT.EDU. perhaps you meant TALCOTT.HARVARD.EDU. you must have typed in the full host name yourself, because the hosts table has know that TALCOTT is a harvard machine for several weeks.  Date: Mon, 9 Dec 85 20:32:36 EST From: "Keith F. Lynch" Subject: Why did this fail? To: BUG-MAIL@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].747743.851209.KFL> Date: Mon, 9 Dec 85 20:30:59 EST From: Communications Satellite ============ A copy of your message is being returned, because: ============ "SWA@TALCOTT.MIT.EDU" at MIT-MC.ARPA is an unknown recipient. ============ Failed message follows: ============ Date: Mon, 9 Dec 85 20:30:59 EST From: "Keith F. Lynch" To: "SWA@TALCOTT.MIT.EDU"@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].747731.851209.KFL> Welcome back to the net! ...Keith  Date: Sat, 7 Dec 85 19:02:36 EST From: Alan Bawden Subject: .msgs.; bloated To: BUG-COMSAT@MIT-MC.ARPA, CENT@MIT-AI.ARPA cc: BUG-ITS@MIT-MC.ARPA In-reply-to: Msg of Sat 7 Dec 85 06:10:23 EST from Pandora B. Berman Message-ID: <[MIT-MC.ARPA].745744.851207.ALAN> Date: Sat, 7 Dec 85 06:10:23 EST From: Pandora B. Berman for reasons unknown, AI can't figure out how to purge obsolete msgs from .MSGS.;. it wouldn't do it when the files weren't backed up, but i expected that. however, now the files are regularly backed up, the _LAST_ EXPIRE file looks well formed, but they -still- don't disappear on cue. MC, on the other hand, seems to have no problem in this regard. any ideas why? A Typical message from MC:.MSGS.;*MSG > begins: DISTRIB: *BBOARD EXPIRES: 12/14/85 12:38:14 Received: from BORAX by MIT-MC.ARPA 7 Dec 85 12:38:13 EST A typical message from AI:.MSGS.;*MSG > begins: Received: from MIT-MC.ARPA by MIT-AI.ARPA via Chaosnet; 7 DEC 85 12:37:44 EST DISTRIB: *BBOARD EXPIRES: 12/14/85 12:38:14 Received: from BORAX by MIT-MC.ARPA 7 Dec 85 12:38:13 EST I suspect the recieved line at the front fakes GMSGS out when it tries to find the expiration date. This could be fixed by changing COMSAT to not do this, or by fixing GMSGS to be smarter. Somebody else is going to fix this one. (I don't think it can be all -that- hard guys!)  Received: from MIT-AI.ARPA by MIT-MC.ARPA via Chaosnet; 25 NOV 85 00:18:27 EST Received: from MIT-MC.ARPA by MIT-AI.ARPA via Chaosnet; 25 NOV 85 00:16:10 EST Received: from Xerox.ARPA by MIT-MC.ARPA 25 Nov 85 00:18:04 EST Received: from Cabernet.ms by ArpaGateway.ms ; 24 NOV 85 21:14:34 PST Date: 24 Nov 85 21:14:18 PST (Sunday) From: JLarson.pa@Xerox.ARPA Subject: Re: Please remove Wolf.pa@Xerox.arpa... To: "Pandora B. Berman" cc: JLarson.pa@Xerox.ARPA, POSTMASTER%MIT-AI.ARPA@MIT-MC.ARPA, gloger.es@Xerox.ARPA, phil-sci-request@MIT-OZ.ARPA Message-ID: <851124-211434-2249@Xerox> Wolf.PA is not on XeroxPhil-Sci^.pa@Xerox and the headers below indicate no forwarding site other then MIT-OZ or MIT-MC. So, either an MIT-OZ or MIT-MC mail address is being forwarded to Wolf.pa or somebody else removed the entry already. Thanks for your help. John ---------------------------------------------------------------- Return-Path: <@MIT-MC.ARPA:MERRY.pa@XEROX.ARPA> Redistributed: XeroxPhil-Sci^.pa Received: from MIT-MC.ARPA by Xerox.ARPA ; 22 NOV 85 16:17:35 PST Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 22 NOV 85 17:45:11 EST Received: from MIT-MC.ARPA by MIT-OZ via Chaosnet; 22 Nov 85 17:42-EST Received: from Xerox.ARPA by MIT-MC.ARPA 22 Nov 85 16:54:34 EST Received: from Semillon.ms by ArpaGateway.ms ; 22 NOV 85 11:34:25 PST Date: Fri, 22 Nov 85 11:34:11 PST From: MERRY.pa@Xerox.ARPA Subject: Re: Classic Quotes (Positivism Assesses Progress in Meaning) In-Reply-To: <[MIT-MC.ARPA].727439.851121.JCMA> To: "John C. Mallery" cc: MINSKY@MIT-MC.ARPA, PHIL-SCI@MIT-MC.ARPA Message-ID: <851122-113425-2280@Xerox> ----------------------------------------------------------------  Received: from MIT-AI.ARPA by MIT-MC.ARPA via Chaosnet; 25 NOV 85 00:07:25 EST Date: Mon, 25 Nov 85 00:05:09 EST From: "Pandora B. Berman" Subject: Please remove Wolf.pa@Xerox.arpa... To: JLarson.pa@XEROX.ARPA cc: POSTMASTER%MIT-AI.ARPA@MIT-MC.ARPA, gloger.es@XEROX.ARPA, phil-sci-request@MIT-OZ Message-ID: <[MIT-AI.ARPA].7321.851125.CENT> Date: 23 Nov 85 15:20:07 PST (Saturday) From: JLarson.pa@Xerox.ARPA Subject: Please remove Wolf.pa@Xerox.arpa... To: Postmaster@MIT-MC.ARPA .. from the PHIL-SCI list. (I've sent several messages to PHIL-SCI-REQUEST@MIT-MC.ARPA to no avail.) John ---------------------------------------------------------------- Date: 22 Nov 85 23:20:35 PST From: Mailer.PA To: DeadMessage.MS Subject: Undeliverable mail notification Unable to deliver msg to the following recipients: "Wolf.PA" => invalid recipient. Successfully delivered to some recipients. The message will be sent to: @MIT-MC.ARPA:MERRY.pa@XEROX.ARPA. The header of the message was: -------------------- [original msg to Phil-Sci omitted] the Phil-Sci list is actually kept on MIT-OZ; MIT-MC does a lot of forwarding for it becaause OZ is only on our local Chaosnet. the -request list on MC does forward correctly to the one on OZ, and the list maintainer is around (he was logged in today), so i don't know why he hasn't at least responded to you. i would have fixed this myself except that Wolf.pa@xerox isn't now on the list. a couple possibilities: someone else on the Postmaster list here fixed this for you already, or Wolf gets forwarded to from some other name/site, or he somehow gets it through the list XeroxPhil-Sci^.pa@Xerox. Gloger.es@Xerox is cited in the notes as the maintainer of that sublist; maybe s/he can help?  Received: from MIT-XX.ARPA by MIT-MC.ARPA 20 Nov 85 03:49:34 EST Date: Wed, 20 Nov 1985 03:46 EST Message-ID: From: Rob Austein To: Bug-Comsat@MIT-MC.ARPA cc: sra@MIT-XX.ARPA Subject: RFC 821/822 Return-Path: hacking It would be nice if COMSAT munged the Return-Path: header properly when relaying messages (it may be doing it for TCP/SMTP but I know it isn't for CHAOS/MAIL). Not exactly a bug, since this is an optional portion of the spec, but I could tell some stories about really bizzare problems that get triggered by this lack. Eg, XX receives a message that has been relayed around the Internet a few hops and thus has a Return-Path. This message comes in via the Chaosnet, so XX is receiving a message via the Chaosnet that claims to be from an Internet-only host! It figures it out, but some host a couple more hops down the line can't figure out how the message got from point A to point C without ever touching point B, gives up, and dies. Whee. I guess this goes on the wish list.  Received: from MIT-AI.ARPA by MIT-MC.ARPA via Chaosnet; 19 NOV 85 18:56:44 EST Received: from MIT-MC.ARPA by MIT-AI.ARPA via Chaosnet; 19 NOV 85 18:54:29 EST Date: Tue, 19 Nov 85 18:56:37 EST From: "Christopher C. Stacy" Subject: ostats files To: CENT@MIT-AI.ARPA cc: BUG-MAIL@MIT-AI.ARPA In-reply-to: Msg of Tue 19 Nov 85 04:47:03 EST from Pandora B. Berman Message-ID: <[MIT-MC.ARPA].724515.851119.CSTACY> Date: Tue, 19 Nov 85 04:47:03 EST From: Pandora B. Berman To: BUG-MAIL%MIT-AI.ARPA at MIT-MC.ARPA Re: ostats files hey chris, now that they've been dumped to tape, do we really need to keep all the AI OSTATS files around? No, I flushed a bunch of them. Now that it's a real machine we can treat it like we do MC -- keep two or three of them around, etc...  Date: Tue, 19 Nov 85 18:55:45 EST From: "Christopher C. Stacy" Subject: ai queue fukt To: CENT@MIT-MC.ARPA cc: BUG-MAIL@MIT-MC.ARPA In-reply-to: Msg of Tue 19 Nov 85 08:09:30 EST from Pandora B. Berman Message-ID: <[MIT-MC.ARPA].724514.851119.CSTACY> It doesn't seem so clear to me that the queue on AI is broken. You got back a response that there were no messages, and saw that the files were very small -- that all makes sense. The files have some overhead (at least a few hundred words each) associated with them. Since there was nothing in the queue (and nothing in MSGS) I rebuilt the files, just in case something was really wrong. But it looked more or less reasonable to me. Was there some other behaviour that you observed?  Received: from MIT-AI.ARPA by MIT-MC.ARPA via Chaosnet; 19 NOV 85 08:11:45 EST Date: Tue, 19 Nov 85 08:09:30 EST From: "Pandora B. Berman" Subject: ai queue fukt To: BUG-MAIL%MIT-AI.ARPA@MIT-MC.ARPA Message-ID: <[MIT-AI.ARPA].6869.851119.CENT> when i tried to list the AI queued msgs, i received the following: ---------- CENT@MIT-AI.ARPA (Sent by CENT'@MIT-AI.ARPA) 11/19/85 08:06:19 Re: Request results ---------- clearly the queue is fukt internally. it's only 2 blocks long so there isn't likely to be much there, but since AI is now getting backed up (and thus having users move in) this should get fixed ASAP.  Received: from MIT-AI.ARPA by MIT-MC.ARPA via Chaosnet; 19 NOV 85 04:49:22 EST Date: Tue, 19 Nov 85 04:47:03 EST From: "Pandora B. Berman" Subject: ostats files To: BUG-MAIL%MIT-AI.ARPA@MIT-MC.ARPA Message-ID: <[MIT-AI.ARPA].6846.851119.CENT> hey chris, now that they've been dumped to tape, do we really need to keep all the AI OSTATS files around?  Date: Mon, 18 Nov 85 12:38:01 EST From: "Christopher C. Stacy" Subject: Mail to CMU To: KFL@MIT-MC.ARPA cc: BUG-MAIL@MIT-MC.ARPA In-reply-to: Msg of Sat 16 Nov 85 14:21:46 EST from Keith F. Lynch Message-ID: <[MIT-MC.ARPA].722351.851118.CSTACY> MC does not know about "CMU.EDU". I can't find out anything about them via Domains either, because there server is not returning any useful information.  Date: Sun, 17 Nov 85 16:01:21 EST From: Alan Bawden To: BUG-COMSAT@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].721461.851117.ALAN> COMSAT crashed multiple times this afternoon trying to mail the file I eventually renamed to .MAIL.;BADREQ LOOPS. I thought that COMSAT flushed the file it was working on when a crash happened so that it wouldn't happen again? (I remember that penny negotiated an exception for the case where it was a crash due to the frequent out-of-address-space bug, but that wasn't what was causing the crash today as far as I can tell.)  Date: Sat, 16 Nov 85 14:21:46 EST From: "Keith F. Lynch" Subject: Mail to CMU To: BUG-MAIL@MIT-MC.ARPA cc: KFL@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].720659.851116.KFL> Date: Sat, 16 Nov 85 14:19:44 EST From: Communications Satellite ============ A copy of your message is being returned, because: ============ "DT04%TF.CC@CMU.EDU" at MIT-MC.ARPA is an unknown recipient. "DT04@TF.CC.CMU.ARPA" at MIT-MC.ARPA is an unknown recipient. "DT04%TF.CC@CMU.ARPA" at MIT-MC.ARPA is an unknown recipient. "DT04@CMU.ARPA" at MIT-MC.ARPA is an unknown recipient. ============ Failed message follows: ============ Date: Sat, 16 Nov 85 14:19:43 EST From: "Keith F. Lynch" Subject: Lets see if one of these addresses works. To: "DT04%TF.CC@CMU.EDU"@MIT-MC.ARPA, "DT04@TF.CC.CMU.ARPA"@MIT-MC.ARPA, "DT04%TF.CC@CMU.ARPA"@MIT-MC.ARPA, "DT04@CMU.ARPA"@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].720657.851116.KFL> Date: Sat, 16 Nov 85 12:40:43 EST From: Communications Satellite ============ A copy of your message is being returned, because: ============ "DT04@TF.CC.CMU.EDU" at MIT-MC.ARPA is an unknown recipient. ============ Failed message follows: ============ ...  Received: from SCRC-STONY-BROOK.ARPA by MIT-MC.ARPA 14 Nov 85 10:00:39 EST Received: from PEACE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 354726; Thu 14-Nov-85 09:57:39-EST Date: Thu, 14 Nov 85 09:58 EST From: Charles Hornig Subject: wrong address To: Pandora B. Berman cc: BUG-LISPM%OZ.AI.MIT.EDU@MIT-MC.ARPA, BUG-MAIL@MIT-MC.ARPA In-Reply-To: <[MIT-MC.ARPA].717132.851113.CENT> Message-ID: <851114095824.5.HORNIG@PEACE.SCRC.Symbolics.COM> Date: Wed, 13 Nov 85 21:41:46 EST From: "Pandora B. Berman" Date: Wed, 13 Nov 85 09:35 EST From: Charles Hornig Subject: 6.1 NFILE & IP-TCP 29.0 To: Chris Lindblad , /----> BUG-LISPM%OZ.AI.MIT.EDU@MIT-MC.ARPA | See this address? there is no such animal. mail to BUG-LISPM%OZ.AI.MIT.EDU@MIT-MC.ARPA goes to BUG-RANDOM-PROGRAM@MC. i don't know where you are getting this address, but it is incorrect; ITS and Twenex do not run domain stuff (yet -- i know CSTACY is working on it for ITS). OZ.AI.MIT.EDU may be a -logical- equivalent for OZ, but it not an official name. please get your software fixed so i won't get bombarded with your incorrectly-addressed mail.. It was in the header of the mail from CJL. I just got tired of editing the reply headers by hand. Since we can't talk to OZ, I had to route it somewhere. Can you suggest an internet mail gateway that will understant it?  Date: Wed, 13 Nov 85 21:41:46 EST From: "Pandora B. Berman" Subject: wrong address To: Hornig@SCRC-STONY-BROOK.ARPA cc: BUG-LISPM%OZ.AI.MIT.EDU@MIT-MC.ARPA, BUG-MAIL@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].717132.851113.CENT> Date: Wed, 13 Nov 85 09:35 EST From: Charles Hornig Subject: 6.1 NFILE & IP-TCP 29.0 To: Chris Lindblad , /----> BUG-LISPM%OZ.AI.MIT.EDU@MIT-MC.ARPA | See this address? there is no such animal. mail to BUG-LISPM%OZ.AI.MIT.EDU@MIT-MC.ARPA goes to BUG-RANDOM-PROGRAM@MC. i don't know where you are getting this address, but it is incorrect; ITS and Twenex do not run domain stuff (yet -- i know CSTACY is working on it for ITS). OZ.AI.MIT.EDU may be a -logical- equivalent for OZ, but it not an official name. please get your software fixed so i won't get bombarded with your incorrectly-addressed mail.  Date: Fri, 8 Nov 85 22:45:12 EST From: "Christopher C. Stacy" Subject: loops with TARDIS To: CENT@MIT-MC.ARPA cc: BUG-MAIL@MIT-MC.ARPA, ddl@HARVARD.HARVARD.EDU, swa@TARDIS.HARVARD.EDU In-reply-to: Msg of Fri 8 Nov 85 03:09:49 EST from Pandora B. Berman Message-ID: <[MIT-MC.ARPA].712250.851108.CSTACY> The host TARDIS.HARVARD.EDU does not appear know its own name. TARDIS is looping with itself; MC is only acting as a third party to hold onto the error messages. I can't see how the loop got initialized, but the current scenario is that TARDIS connects to MC and asks us to relay a message to "MAILER-DAEMON@TARDIS.HARVARD.EDU". We connect to TARDIS and hand it back the message, which is accepted. (Note: the return path given MC is the same as the recipient name.) Later, TARDIS decides that the message can't be delivered because there is no such host as "TARDIS.HARVARD.EDU". So, since the message came to TARDIS via MC, TARDIS composes an error receipt, and sends it off. The return path is <@MIT-MC.ARPA:MAILER-DAEMON@TARDIS.HARVARD.EDU>, so the receipt is sent from TARDIS to TARDIS via MC. Note that TARDIS's SMTP server claims that it is running on the host "TARDIS.ARPA", not "TARDIS.HARVARD.EDU". To completely test my analysis, I just now tried to send a message to MAILER-DAEMON@TARDIS.HARVARD.EDU, but it was rejected because they are out of disk space. Hmmmm, I wonder where it went! This is the nth time since Domains were introduced that I have seen Unix mailer systems lose in exactly this way. I don't think that the recent hardware installation over there has anything to do with this; it's a software (probably configuration) problem at the TARDIS end. There isn't much we can do about this on our end. Chris  Date: Fri, 8 Nov 85 03:09:49 EST From: "Pandora B. Berman" Subject: loops with TARDIS To: BUG-MAIL@MIT-MC.ARPA cc: ddl@HARVARD.HARVARD.EDU, swa@TARDIS.HARVARD.EDU Message-ID: <[MIT-MC.ARPA].710792.851108.CENT> there was a lot of mail looping between here and TARDIS.HARVARD. a lot of the msgs got so large that COMSAT barfed at them and renamed them to BADREQ files. someone deleted most of these, but BADREQ TARDIS is a prime example, if much smaller than the others. looks to me like someone misunderstood a low-level RFC or something, and the msgs started bouncing between COMSAT on MC and TARDIS's MAILER-DAEMON, without either recognizing itself as the party being addressed by the mail being returned from the other. i talked to DDL tonight, and he wondered if his recent installation (today?) of a net interface with a new address for their machine might have something to do with the problem. i assured him that COMSAT gets new host tables quickly, once the NIC distributes them. chris, could you get back to him and straighten this out? they were sort of worried when this went on for several hours, especially when comsat started issuing its "file much too big, you should use FTP" notices about these msgs, which (like BADREQ TARDIS) were all headers, user-unknown msgs, and s, but to the length of 10 and 12 blocks.  Date: Wed, 6 Nov 85 03:22:10 EST From: "Christopher C. Stacy" Subject: "file too big" To: CENT@MIT-MC.ARPA cc: BUG-MAIL@MIT-MC.ARPA In-reply-to: Msg of Mon 4 Nov 85 07:25:12 EST from Pandora B. Berman Message-ID: <[MIT-MC.ARPA].707324.851106.CSTACY> What happenned here was that COMSAT ran out of space and could not handle a message which was a little over 2 blocks long. Rather than dying, it rejected the message. When you resubmitted it to a new COMSAT, there was enough room. The error message you got had the wrong numbers in it; I have fixed this. Another issue is that it seems ridiculous for COMSAT to reject perfectly reasonably sized messages which it doesn't have room for. I am in the process of teaching COMSAT how to restart itself under certain conditions. Meanwhile, when it gets a message which is of a reasonable size but for which there isn't enough room left, COMSAT will croak. Then when a human relaunches it, it will be able to try with a clean slate (and will either die infinitely or succeed.) BTW, Puff The Magic Dragon on MC now tries to restart COMSAT once every hour, just in case it died.  Date: Wed, 6 Nov 85 00:32:22 EST From: "Christopher C. Stacy" Subject: "file too big" To: CENT@MIT-MC.ARPA cc: BUG-MAIL@MIT-MC.ARPA In-reply-to: Msg of Mon 4 Nov 85 07:25:12 EST from Pandora B. Berman Message-ID: <[MIT-MC.ARPA].707111.851106.CSTACY> Hmm, that's pretty weird looking. I'll have a look.  Date: Tue, 5 Nov 85 23:38:10 EST From: Charles Frankston Subject: multi-line subject To: MLY@MIT-MC.ARPA cc: BUG-COMSAT@MIT-MC.ARPA, BUG-RMAIL@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].707034.851105.CBF> No. Its not supposed to work.  Date: Tue, 5 Nov 85 12:35:38 EST From: Richard Mlynarik Subject: multi-line subject To: BUG-COMSAT@MIT-MC.ARPA, BUG-RMAIL@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].706056.851105.MLY> I typed in a multi-line subject to an rmail reply, starting the second line with a bunch of spaces. Is this supposed to work? Date: Tue, 5 Nov 85 12:22:36 EST From: Communications Satellite To: MLY@MIT-MC.ARPA cc: MAIL-MAINTAINERS@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].706033.851105> Error in input request file. Parsing error: Attribute too long. Line stopped at is: ^--I'm a cretin Message not sent and not queued;text of bad file follows: -------- FROM-PROGRAM:RMAIL FROM-XUNAME:MLY FROM-UNAME:MLY AUTHOR:MLY RCPT:(CENT@MIT-MC.ARPA) SUBJECT:z:syebf.bin.88 (f00032 #33 24-sep-85 0000 1) ^--I'm a cretin TEXT;-1 Oh foo. I'm sorry for the fuckup.  Date: Mon, 4 Nov 85 07:25:12 EST From: "Pandora B. Berman" Subject: "file too big" To: BUG-MAIL@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].703983.851104.CENT> Date: Mon, 4 Nov 85 07:14:14 EST From: Communications Satellite To: CENT@MIT-MC.ARPA cc: MAIL-MAINTAINERS@MIT-MC.ARPA Error in input request file. Request too large. Message not sent and not queued; 13 Kbytes is far too large for me. Please use the FTP program to transfer huge files around the network. the piece of mail in question was 2blocks+613words large. whether this adds up to 13Kbytes i don't know, but i doubt it. so i gunned down comsat, renamed the badreq file to MAIL >, and started it again. worked fine. i'm not sure what the solution is, chris, but it would be nice if the error msg corresponded to reality.  Date: Mon, 4 Nov 85 03:53:41 EST From: "Pandora B. Berman" Subject: lost mail to H-MA1 To: ED@MIT-MC.ARPA cc: BUG-MAIL@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].703928.851104.CENT> i flushed the oldest couple of your msgs thence because they weren't getting through. a perusal of the stats file shows that -all- msgs to H-MA1 get reactions like this: 145614 Unqueueing to host H-MA1.ARPA 145615 ICP->H-MA1.ARPA (TCP-SMTP) 145625 QID=<[MIT-MC.ARPA].681894.851016.ED> 145627 TO->nitzberg ...NTMBEG Timeout  Date: Fri, 1 Nov 85 16:25:10 EST From: "Christopher C. Stacy" Subject: mail too big? To: CENT@MIT-MC.ARPA cc: BUG-MAIL@MIT-MC.ARPA In-reply-to: Msg of Fri 1 Nov 85 04:54:38 EST from Pandora B. Berman Message-ID: <[MIT-MC.ARPA].701663.851101.CSTACY> Date: Fri, 1 Nov 85 04:54:38 EST From: Pandora B. Berman To: BUG-MAIL at MIT-MC.ARPA Re: mail too big? chris, i think your latest hacking on comsat to deal with too-big mail needs some tuning. tonight, 4 BADREQ files accumulated on .MAIL.;. curious as to their faults, i looked at them, and they looked perfectly normal. indeed, 2 were over 11 blocks, possibly pushing the size limit, but one was only 5 1/2, and one was only 2! yet comsat had claimed they were too large; see excerpts from stats file: If an input file is 2 blocks or under, COMSAT just tries to gobble it. If it's bigger than that, COMSAT looks to see how much free space it has. If there is not enough room to read in the file, it rejects it. The amount of free space that COMSAT has at any moment is variable, and it could be that there was no more room left for even a tiny file like 2 blocks to fit. (But I bet not much would get done before a crash if that were the case.) The code looks correct to me, although those numbers are just a a little bit hard to believe. I'll put something in to print out more info in the stats file so we can make sure the feature is really working. (...Maybe there should be a GC for the EQV LSE. Maybe I should make @FILEs more clever someday...)  Date: Fri, 1 Nov 85 15:50:16 EST From: "Christopher C. Stacy" Subject: MC's COMSAT (not) delivering BOGUS messages To: fair@UCBARPA.BERKELEY.EDU cc: INFO-TERMS-REQUEST@MIT-MC.ARPA, POSTMASTER@MIT-MC.ARPA, BUG-MAIL@MIT-MC.ARPA In-reply-to: Msg of Fri 1 Nov 85 08:52:42 PST from fair at ucbarpa.berkeley.edu (Erik E. Fair) Message-ID: <[MIT-MC.ARPA].701595.851101.CSTACY> ------- Date: Fri, 1 Nov 85 08:52:42 PST From: fair at ucbarpa.berkeley.edu (Erik E. Fair) To: comsat at mit-mc.arpa, postmaster at mit-mc.arpa cc: info-terms-request at mit-mc.arpa Re: MC's COMSAT delivering BOGUS messages 1) I should never have gotten this message in the first place. Errors are supposed to go to the address given in MAIL FROM: NOT to the sender. ------- COMSAT does mail its error receipts to the address in the return path. For example: 175355 OldReq: 1; SPECS:{NET-MAIL-FROM: UCBVAX.BERKELEY.EDU} {RTP:usenet@ucb-vax.berkeley.edu} ID=<[MIT-MC.ARPA].700308.851031> EXP->INFO-TERMS@1200600054 175419 CMSG ID=<[MIT-MC.ARPA].700309.851031> EXP->usenet@ucb-vax.berkeley.edu@1200400116 175419 ICP->UCBVAX.BERKELEY.EDU (TCP-SMTP) 175425 TO->usenet@ucb-vax.berkeley.edu So, according to our log, it was your host that failed to give COMSAT the return path you apparently asked for. (I also just now tested this manually and it worked for me.) ------- 2) COMSAT should use a proper MAIL FROM: command in SMTP when it sends; the blank between the `From ' and the date in the first line indicates that COMSAT did NOT supply an address in MAIL FROM: ------- All SMTP servers are required to support null return paths. (See RFC821, section 3.6, around page 14). As recommended by the RFC, COMSAT uses this feature when sending error receipts so that if something goes wrong with a message about something going wrong, the mess will probably terminate more quickly. 3) I'd appreciate it if MCLURE@MIT-MC was removed from info-terms You should send mail to INFO-TERMS-REQUEST for these kinds of changes. I have updated the list for them this time however. Cheers, Chris  Date: Fri, 1 Nov 85 04:54:38 EST From: "Pandora B. Berman" Subject: mail too big? To: BUG-MAIL@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].700989.851101.CENT> chris, i think your latest hacking on comsat to deal with too-big mail needs some tuning. tonight, 4 BADREQ files accumulated on .MAIL.;. curious as to their faults, i looked at them, and they looked perfectly normal. indeed, 2 were over 11 blocks, possibly pushing the size limit, but one was only 5 1/2, and one was only 2! yet comsat had claimed they were too large; see excerpts from stats file: ---------- 173535 InReq: 62 > 1; 173535 Note: Inreq file too big! Length=2+70 SPECS:{NET-MAIL-FROM: MIT-EECS}{TL=5054.} 173535 Note: Error during parse of input request. 173535 Input-request error, msg sent: ID=<[MIT-MC.ARPA].700300.851031> EXP->MAIL-MAINTAINERS@1200600054::=((FILE [.MAIL.;FAILED STUFF])@1200600054),NET-ORIGIN@1200600054::=((FILE [.MAIL.;FAILED NETORG])@1200600054,MAIL-MAINTAINERS@1200600054) 173537 Local->MIT-MC.ARPA 173537 TO->[.MAIL.;FAILED NETORG] 173538 TO->[.MAIL.;FAILED STUFF] 173538 Note: Renaming bad input file to BADREQ 1 ---------- 214522 OldReq: 1; 214522 Note: Inreq file too big! Length=11+100 SPECS:{NET-MAIL-FROM: MIT-CIPG}{TL=5057.}{HDR-FROM:uucp@MIT-CIPG} 214522 Note: Error during parse of input request. 214522 Input-request error, msg sent: ID=<[MIT-MC.ARPA].700493.851031> EXP->MAIL-MAINTAINERS@1200600054::=((FILE [.MAIL.;FAILED STUFF])@1200600054),uucp@40700016260 214524 Local->MIT-MC.ARPA 214524 TO->[.MAIL.;FAILED STUFF] 214525 ICP->MIT-CIPG (CHAOS-MAIL) 214526 TO->uucp 214532 Note: Renaming bad input file to BADREQ 2 ---------- 004621 OldReq: 1; 004621 Note: Inreq file too big! Length=11+440 SPECS:{J:MAIL}{KFL} 004621 Parsing aborted: "Semicolon arg truncated by EOF." 004621 Note: Error during parse of input request. 004621 Input-request error, msg sent: ID=<[MIT-MC.ARPA].700825.851101> EXP->MAIL-MAINTAINERS@1200600054::=((FILE [.MAIL.;FAILED STUFF])@1200600054),KFL@1200600054 004623 Local->MIT-MC.ARPA 004623 TO->KFL(GUEST2;) 004623 TO->[.MAIL.;FAILED STUFF] 004623 Note: Renaming bad input file to BADREQ 3 ---------- 035040 InReq: 1 > 1; 035040 Note: Inreq file too big! Length=5+735 SPECS:{NET-MAIL-FROM: BRL-TGR.ARPA}{RTP:unix-wizards-request@BRL-TGR.ARPA}{TL=4825.}{HDR-FROM:Info-Unix-Request@BRL.ARPA} 035041 Note: Error during parse of input request. 035041 Input-request error, msg sent: ID=<[MIT-MC.ARPA].700966.851101> EXP->MAIL-MAINTAINERS@1200600054::=((FILE [.MAIL.;FAILED STUFF])@1200600054),unix-wizards-request@BRL-TGR.ARPA@30001212404 035043 Local->MIT-MC.ARPA 035043 TO->[.MAIL.;FAILED STUFF] 035044 ICP->BRL-TGR.ARPA (TCP-SMTP) 035047 TO->unix-wizards-request@BRL-TGR.ARPA 035055 Note: Renaming bad input file to BADREQ 4 ---------- when i renamed these files to MAIL >, all of them went through without any problems. please look into this.  Received: from MIT-CROSBY by MIT-MC.ARPA via Chaosnet; 31 OCT 85 09:27:23 EST Date: Thu, 31 Oct 85 09:27 EST From: Christopher C. Stacy To: Glenn S. Burke cc: BUG-MAIL@MIT-MC.ARPA In-Reply-To: <[MIT-MC.ARPA].644854.850913.GSB> Message-ID: <851031092723.5.CSTACY@CROSBY.AI.MIT.EDU> Date: Fri, 13 Sep 85 18:15:35 EDT From: Glenn S. Burke is "@host1:mailbox@host2" supposed to work in mail addresses? (to fields and the like) Yes, although I don't think there is any easy way for a user on ITS to hand COMSAT that kind of address. COMSAT does use those kinds of addresses (which are called "forward paths") when it does error reporting via "return paths". If a foreign host connects to ITS and says RCPT TO:<@FOO:BAR@BAZ> it works.  Received: from MIT-CROSBY by MIT-MC.ARPA via Chaosnet; 31 OCT 85 08:57:45 EST Date: Thu, 31 Oct 85 08:57 EST From: Christopher C. Stacy Subject: "at mit-mc.arpa" To: David Vinayak Wallace cc: BUG-SENDER@MIT-MC.ARPA, BUG-COMSAT@MIT-MC.ARPA In-Reply-To: <[MIT-MC.ARPA].699330.851031.GUMBY> Message-ID: <851031085745.3.CSTACY@CROSBY.AI.MIT.EDU> I poked through the sender code and couldn't figger out what was causing it; the best I could guess was that (R-MODE-SEND 0) causes COMSAT to do it, hence this going to BUG-COMSAT too. No, COMSAT doesn't say "at" anymore. I just tested it send mode to make sure.  Date: Thu, 31 Oct 85 01:15:52 EST From: David Vinayak Wallace Subject: "at mit-mc.arpa" To: BUG-SENDER@MIT-MC.ARPA, BUG-COMSAT@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].699330.851031.GUMBY> (Maybe this was just reported a day or so ago?) I tried to reply to someone at a remote host who had logged out, so I used "M"(ail instead). This generated a from field of "Gumby at mit-mc.arpa" which is bogus. I poked through the sender code and couldn't figger out what was causing it; the best I could guess was that (R-MODE-SEND 0) causes COMSAT to do it, hence this going to BUG-COMSAT too.