>  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