NOS Mailbox

["Mike Bilow, mikebw@ids.jvnc.net" <mikebw@IDS.JVNC.NET>]

>I'd like to offer a suggestion on a modification to the NOS mailbox code.
>One of the complaints I hear frequently from local NOS users is that they
>always have to look through messages in the non-personal areas to figure
>out where they left off, since NOS doesn't store last message read data.

I am always amazed at the number of people who are trying to get NOS to
work as a full-featured mailbox.  It really isn't, and most of the
discussions about letting it evolve into one have concluded that it is
not a good idea.

[stuff deleted]

>Since NOS doesn't number messages consecutively, but instead starts at 1
>within each area, we can't just save the last message number read.  We have
>to store that number for each area independently.  Also, we need to modify
>NOS so it doesn't always start renumbering within areas at 1.  It seems to me
>we then have two approaches; we change the numbering scheme within areas as
>described previously or we can change NOS to simply number messages in
>consecutive order as most PBBS systems do now.

Using consecutive numbering like W0RLI or AA4RE is not that easy to do.
For one thing, message numbers are not attached to the messages themselves,
and are not stored in the mail file nor anywhere else.  When a user starts
the mailbox and enters his deafult area, or when he issues the "area"
change command, the selected mail file is loaded and parsed into separate
messages.  At this time, numbers are assigned.  When the mailbox is exited,
these numbers, always intended to be transient, are lost.

>If we go to consecutive numbering, we simply need to modify NOS to save each
>user's last message read number somewhere.  Perhaps a user file.  If we choose
>to allow NOS to continue keeping separate numbers within message areas, we
>then have to track them separately per area.  Perhaps an approach there is
>to write out the area name and last message number to a file whenever the
>area is changed or the mailbox is exited.  By doing it this way, we don't
>have to have any pre-prepared formatted file of area names.

It would be a great deal better to avoid doing anything which invloves
changing the structure of a message file.  Assuming that there is some
unique identifying mark on each message, then this could be stored for
each user, and the consecutive numbering would not be necessary.

There is already a unique message identifier, which is valid as long
as the integrity of the /spool/mqueue/sequence.seq file is respected.
This is the ID number, assigned on reception.  Here is an example of the
header file from a message received at my host:

  From wa1equ@wa1equ.ampr.org Wed Jan 29 23:42:12 1992
  Received: from switch.w1cg-9.ampr.org by n1bee.ampr.org with SMTP
          id AA9898 ; Wed, 29 Jan 92 23:41:54 UTC
  Received: from wa1equ.ampr.org by switch.w1cg-9.ampr.org with SMTP
          id AA16788 ; Wed, 29 Jan 92 18:45:16 EST
  Date: Wed, 29 Jan 92 18:35:10 EDT
  Message-Id: <45792@wa1equ.ampr.org>
  From: wa1equ@wa1equ.ampr.org (Rich Vitello - Read "The NE TCPer"!)

While I could choose to use the identifier <45792@wa1equ.ampr.org>,
this depends on the other guy to do it right.  (Sorry, Rich.)  The
better choice, in my view, would be to pick up the "id AA9898" that
was automatically assigned by my system on reception.  It is unique,
and it is as easy to parse as finding the "From " line, which is how
things are done now.

Note that the ID number is not guaranteed to start with "AA", and is
not really guaranteed to be in any particular form.  The amount of
information that would need to be stored for each user would be
small.  For example, I could have a file, N1BEE.USR, which resides
in /spool/mail.  This file might contain:

n1bee AA9898
arrl AA9867
amsat AA9895

If I get the chance, I will try and code it.  I would not be
heartbroken if someone else got to it first.

-- Mike Bilow, <mikebw@ids.jvnc.net>  (Internet)