[nos-bbs] Questions related to JNOS 1.11f

[Miroslav Skoric (YT7MPB)]

Barry Siegfried wrote:

> 
> 
> How would you propose that the code be programmed to know that a
> new "To: " field contains a userid that the sysop would want to
> qualify as being a new public area?  If I were running a NOS mailbox
> with public areas, there are nearly an infinite number of possible
> "To: " fields I can think of that I would NOT want to be added
> automatically to the 'areas' file if a bulletin happened to show
> up for them.
> 

Hi Barry et al,

Well, what I suggested is just from the experience I have with FBB. I
mean, there's no reason not to accept any incoming (forwarded) bulletin
- regardless its "To: " field is brand new or already used. If it
happens to be a bulletin with, say, an inappropriate content or
something like that /what a sysop may dislike/, later such a "To: "
field could be put in a kind of a 'reject' file. Mathematically
speaking, the percentage of rejected "To: " fields is far less than the
accepted bulls. And that is why I see as wasting time for a sysop, to
check every new "To: " field to see if it should be added to the list or
not. Btw, I always see as the much bigger problem when some hams use
'accepted' mailbox groups i.e. "To: " fields, for posting things that
shouldn't be there :-) Btw, personal (private) areas I always consider
as non-public ones and when a sender post something using a 'SP' command
the result should always be as non-public.

> It is clear from the original code that the programmer (presumably
> WG7J) was quite certain in his mind that the sysop must take the
> time to be responsible for defining what public areas he wants to
> have in his mailbox.
> 
Ok, I am not against that policy, but that is why the locally-generated
messages should get on 'hold' prior the sysop's review, whenever
possible. And not only that: Even *some* bulls in transit could end up
on 'hold' queue, depending on the "From:" field or like. I also recall a
subroutine of FBB server which offered an automatic search trough the
texts of bulletins in order to catch for specific words. That might be
another security measure to ensure the proper mailbox content.

> 
> The suggestion to compile as small a NOS as possible is always a
> good one, however, may I suggest that no NOS ever be compiled
> without the packet header tracing tool included.  I feel it is
> so important in the programs I support for both myself and others
> that I have removed it as a compile-time option in my own CONFIG.H
> files.
> 

Well, I agree with the suggestion to compile as small a NOS as possible
but, as a beginner in JNOS, what I miss is a basic manual explaining
what must be #define(d) for a specific NOS usage and what may be left as
#undef(ined). For example, I only wanted to have an AX.25 mailbox for
the local VHF users and a capability to forward the content with the
other home computer running FBB. I did not plan to run any pop3 or smtp
Internet-like services and so I excluded the smtp server in one of the
first iterations. Later it appeared that without defined smtp server
nothing worked - related to the mailbox.

Now somebody may ask: If you wanted just plain AX.25 mailbox, why didn't
you chose DosFBB or MSYS or something? Well, they either won't run on a
80286, or not support network card, or not Y2K compliant, or ...

Regards,

Misko