[nos-bbs] Questions related to JNOS 1.11f
Barry Siegfried
k2mf at k2mf.ampr.org
Thu Mar 29 01:44:08 EDT 2007
["Miroslav Skoric (YT7MPB)" <skoric at ptt.yu> wrote]:
> Barry Siegfried wrote:
>
> > > - How to switch off that nasty 'beep' in JNOS after any line of
> > > "New mail for ...".
> >
> > net> smtp quiet on
>
> Thank you Barry.
>
> > Probably not because this was done intentionally and by design. If
> > memory serves me correctly, the 'areas' file was intended to define
> > which email mailfiles are to be considered "public" (i.e. may be read
> > by everyone). I don't think you'd want every mailbox user's mailfile
> > to be considered public.
>
> Of course not. But when a JNOS mailbox is going to be filled with
> bulletins having all possible values within the 'To:' field, the
> question is if a sysop should read all messages in his/her system and
> determine if there is a new 'To:' field message that might be interested
> for his/her users - and to enable users to read it, the 'areas' file
> should be changed manually again and again. Seems to me as a not so
> rational solution for a busy sysop. I mean, just imagine a new bulletin
> has been forwarded to the JNOS mailbox. And that new bull has completely
> new 'To:' field. If I understood your explanation properly, that would
> mean the bulletin can't be read by everyone on the JNOS mailbox - as
> long as the sysop adds the new value to the 'areas' file. Is that
> correct?
Yes, I believe so. I have never personally been very much into the
bulletin functionality of the NOS mailbox but this is how I recall
that it works.
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.
And that says nothing of how you would program the 'rewrite' file
to do the same thing as well. Presumably, there is some sort of
incoming SMTP email control using a 'rewrite' file, which if done
correctly, would have to have the mailbox's public area names
specified in it to make sure they are authorized for delivery.
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.
["(Skip) K8RRA" <k8rra at ameritech.net> wrote]:
> You might find it useful to compile with only the minimal stuff
> you will use and without tracing after your feet are wet.
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.
The reason for this is that it is said that a picture is worth a
thousand words and there is no case that I can think of where this
isn't more evident! Packet header tracing is singly the most useful
tool that anyone can use in order to learn how all this stuff works.
If it taught me how TCP/IP and network layering works (supplemented
with some good reading material) then it can teach anyone.
73, de Barry, K2MF >>
o
<|> Barry Siegfried
+---------/-\---------------------------+
| Internet | bgs at mfnos.net |
| HomePage | http://www.mfnos.net/~bgs |
+----------+----------------------------+
| Amprnet | k2mf at k2mf.ampr.org |
| PBBS | k2mf at k2ge.#cnj.nj.usa.noam |
+----------+----------------------------+
More information about the nos-bbs
mailing list