> What's up there? Can anybody explain this? /Eric > >24 May 1987 23:49:34 From DPANCAMO@SFAUSTIN: LIST LONG >24 May 1987 23:49:55 Sent file "FRECP11 LISTS D" to DPANCAMO@SFAUSTIN >24 May 1987 23:49:56 Sent information mail to DPANCAMO@SFAUSTIN >24 May 1987 23:50:08 RSCS message: FROM UIUCVMD: LINK SFAUSTIN IS NOT DEFINED Eric, consider yourself lucky that the node with the downlevel RSCS tables was not your own. The same S.F.Austin user sent some commands to our LISTSERV as well. LISTSERV obediently sent back the log of the command job via MAILER (Crosswell variety), which sent the mail in BSMTP format (as requested by the SFAUSTIN entry in XMAILER NAMES since April). Unfortunately, RSCS didn't know about SFAUSTIN yet, so it sent MAILER a nasty interactive message and transferred the file back to MAILER, which saw it as just another bit of BSMTP mail to be delivered, tried to send an interactive message to the originator (at node RICE.BITNET, which RSCS also didn't buy :-)) and forwarded the file (with another Received: line) to RSCS for delivery. As you can guess, RSCS still didn't like the node name SFAUSTIN. MAILER and RSCS played this little game of ping pong until the spool filled up (which was due to another problem, but was not helped by the 100K-line MAILER console and who-knows-how-long RSCS console). Several observations suggest themselves: 1. We should not have let our RSCS table updating person go on vacation without appointing someone else to perform that duty. Mea culpa! 2. This problem could have been triggered at any time since the April XMAILER NAMES update established SFAUSTIN as expecting BSMTP. 3. When the new MG version defaults new nodes to expecting BSMTP, this can happen at any time a new node is added to XMAILER NAMES before the corresponding RSCS table update is out. 4. If the new MG version is accompanied by a recommendation that the *DEFAULT* entry in OUTGOING be changed to use BSMTP, it can happen at any time a new node connects to the network before all other nodes know about it. Worse, it can happen whenever *any* user tries to send mail to *any* unknown node (assuming that is allowed by the MTPLATE/PROFILE). 5. The Crosswell Mailer needs to be able to detect that it is trying to forward BSMTP mail it has already handled, at least when the mail has bounced off of the local RSCS. This case should be handled the same way that bounces of non-BSMTP mail should be handled (and will be in 1.24, right?). Ideally, loops of any length should be detected, but that may not be practical. 6. Maybe RSCS should not accept files from nodes to which it would not be able to respond? (Pardon me while I don my flameproof clothes.) --Mark