NOS problems/solutions

[Murray_RJ@cc.curtin.edu.au]

   I've experienced a couple of problems with NOS over the last couple of
weeks, but our site administrators saw fit to shut our VAXes down over
the holiday season (i.e. for two weeks), so I haven't been able to report
them before. I'm using GRINOS v1.7j, but I think most of these comments
would apply to any version.

1. The MFJ-1278 TNC requires two commands to take it out of KISS
   mode: "param ax0 255" and "param ax0 254" (according to the manual).
   Unfortunately, NOS won't let you send command 254! I had written code to
   implement "return2" as command 254, but it's just occurred to me that
   "param ax0 255 254" might work just as well. Since the TNC isn't mine,
   I can't test this now, but I'll get the owner to check it. Has anyone
   else encountered this problem?

2. (This was discovered while testing the first one). If you do send the
   return command to a TNC (i.e. command 255), but don't exit NOS, memory
   problems occur. NOS usually crashes completely within a couple of
   commands. This doesn't occur on my 486 machine (which isn't connected
   to a TNC, so it may not be a valid test), but it happens every time on
   my 286 which is used on packet. I guess that this isn't exactly something
   you're going to want to do every day, but the fact that it does crash
   is a little disturbing. As far as I can see, command 255 is treated the
   same as any other KISS command, so it's hard to see why it should cause
   problems; it's possible that something coming from the (now non-KISS) TNC
   is causing it, but I'm still looking.

3. The sysop of my local AA4RE bbs figured out how to call up my NOS
   mailbox and forward mail and bulletins into it -- the dreaded initial CR
   requirement for NOS notwithstanding. Currently it's working fine, but if
   my system has any mail which should be sent to the BBS (which you'd expect
   should be sent after the BBS has finished sending and replies with the F>
   prompt), NOS won't send it unless the current time is within the limits
   set in forward.bbs. This means that reverse forwarding (at least I think
   that's what the term is) won't occur unless the BBS was still connected
   and forwarding mail when the time window set in forward.bbs starts --
   otherwise, NOS would have already initiated a connection and sent outgoing
   mail.

   Changing the following line in forward.c fixes the problem, but only to
   the extent that this reverse forwarding can occur at any time.

      In routine fwdinit(), change line 487:

      /* get the name of this forwarding record */
    findident(m->line,1,host);
    if(stricmp(m->name,host) == 0) {
        if((m->state != MBX_REVFWD) && !timeok(m->line))  /* Change to this */
            break;
      /* eat the connect command line */
        fgets(m->line,MBXLINE,m->tfile);
        return 0;

Line 487 was:
        if(!timeok(m->line))

   There may be a better way to do this, but I'm not sure exactly what the
   norm is for BBSes. We could, for example, have an extra field in
   forward.bbs which specified the times during which reverse forwarding
   can occur, but this is probably a case of overkill!

4. When NOS connects and forwards mail to a BBS, then responds with an F>
   prompt after all mail has been sent, the BBS may not have been configured
   properly and may respond with "Invalid command" or somesuch. Agreed, this
   is not a NOS problem; but the fact that NOS then tries to re-send the mail
   it has already sent (even though marked as "deleted") should probably be
   fixed. I've looked into this one and it's not as easy to fix as I thought;
   is this something we may have to live with?

5. If a mailbox user attempts to enter a message to an address with a '\' or
   '/' in it, SMTP goes into infinite recursion, presumably because NOS tries
   to create a file with '\' in the filename, which indicates a subdirectory
   (which probably doesn't exist). The problem can be fixed by putting lines
   like
        */* junk
   and
        *\* junk
   in \spool\rewrite, but perhaps it would be better to include a check for
   invalid filename characters in message addressees. (The user on my system
   at the time entered "s pc/tcpip" when he presumably meant "w pc/tcpip". I
   had a hell of a time stopping the recursion -- finally turning the SMTP
   server off gave me enough breathing space to kill the offending messages).

6. This isn't so much a problem as an enhancement. After mail in and out
   of the BBS world from NOS was up and running (or at least up and limping),
   one minor annoyance was the inability to send mail to the BBS system
   without manually logging on and sending it from the BBS (the TCP/IP
   network here in Perth currently comprises two or three stations, and
   we don't have a gateway). I eventually found that routing within NOS
   was determined by the .WRK file associated with each message, but when
   NOS forwards outgoing mail to a BBS it uses the address in the message
   itself (there's no .WRK file any more). I wrote a quick and dirty
   program to massage the .WRK file, so that if I sent a message to
   vk6qqq@vk6www from my 486 machine using View (presumably other mailers
   would act the same), the .WRK file would be changed to send it to
   outmail@vk6zjm ("vk6zjm" being my packet NOS machine), and a line in
   forward.bbs would send messages in outmail.txt to the BBS when the next
   forwarding session occurred.

   There are problems with this approach. The first is that it's not a
   good idea to do it on the packet NOS machine unless NOS is not running
   at the time, since the message will probably be sent before you can
   change the destination. You could accomplish the same thing with
   a few entries in the rewrite file, but it means you can't send bulletins
   this way (for example, if I set up rewrite so that it sends a message
   addressed to tcpip@oc, anything coming in from the BBS addressed to
   tcpip@oc will be sent back to it. This annoys sysops and erases the
   bulletins, which makes them very hard to read).

   The idea does work fine if you're preparing messages offline. If you have
   a second machine connected to the packet NOS machine, you can just add a
   couple of lines to the rewrite file and do it all from the mailbox. In
   the long run, of course, it would be best to incorporate the re-routing
   into the mailer program.

   One possible use for the whole thing is to implement a gateway from
   a TCP/IP network to the BBS world. After all, the machine which actually
   does the forwarding doesn't have to be one's own -- it could be anywhere
   on a network.

   The question is, then, is whether I've missed anything. It's a bit hard
   to believe that nobody's encountered the problem before, but I couldn't
   find any reference to it. If the re-routing program looks useful I'll
   wash its face a bit and upload it; on the other hand, if you can do the
   same thing with a few lines in rewrite or alias, I'll go quietly.

   That's probably enough questions for now. Any comments?

 .....Ron

                                 ***
 Ron Murray
 Internet: Murray_RJ@cc.curtin.edu.au
     Are we having fun yet?    -- Garfield