| |
N1URO > SYSOP 28.08.20 01:21l 65 Lines 2794 Bytes #999 (0) @ WW
BID : 52008_N1URO
Read: GUEST
Subj: Re: JNOS BID changing
Path: IW8PGT<IZ3LSV<I3XTY<I0OJJ<GB7CIP<PE1RRR<KM8V<GB7YEW<VE2PKT<N1URO
Sent: 200827/1516Z @:N1URO.#CCT.CT.USA.NOAM #:52008 [Unionville] $:52008_N1URO
From: N1URO@N1URO.#CCT.CT.USA.NOAM
To : SYSOP@WW
Sergej et al;
> Can some JNOS experts explain how not to do BID changing
> or why JNOS developers not fix it for many years?
>
> We have that problem on packet BBS network few times every year
> with someone new (and old too!) JNOS'ers.
The biggest issue with ANY nos BBS is that they're not a true bbs. xNOS
systems are 100% SMTP based and rely on rewriting mail. Mail comes into
xNOS in a standard internet SMTP type header. Ex:
From i0ojj@i0ojj.ampr.org Wed Aug 26 21:48:21 2020
Received: from ir0rm-7.ampr.org by i0ojj.ampr.org (JNOS2.0m.4) with SMTP
id AA128061 ; Wed, 26 Aug 2020 21:48:21 +0200
From there it's queued and then rewritten into a mail spool file for the
particular "area" it may be viewed in or if the sysop desires they may
relay mail to their own mailbox OR to one that is not shared with any
other BBS.
The biggest issue that's plagued JNOS2 is when mail is forwarded without
a BID or is rewritten without a BID. Xnos actually sees a bid as a user
sending SMTP mail during the rewrite. Ex:
References: <128056@i0ojj.ampr.org>
Not that this is flawed by anymeans for an IP based system however when the
mail is not properly read by the sending system OR it somehow gets grunged
during the rewrite process and gets stripped then NO BID exists.
According to the latest PBBS specifications written by W0RLI and adapted by
TAPR... when a BID does not exist treat it as locally written mail and assign
it your own BID. This is what JNOS2 has been doing - it's been following the
proper specifications. This is why PBBS specs need to be revised and also
modernized. It's been ions since they've been visited and no one at all
seems to be willing to touch them. Times have changed a bit, newer softwares
have been introduced so the specs really do need to be revisited and
programmers to respect them.
> Also another "regular fun" from LU-guys (Agrentina)... No words to say, sorry.
That one you can't blame JNOS2 for but I'll comment below. :)
Gus;
> However the JNOS/JNOS2 is very complex per se and it's
> outside the range of many people, a true Swiss Army knife:)
The problem in this scenario is parallel to the "regular fun" comment above;
When you try to do too much in one program things are apt to fail
whether it's bugs, ram issues, being overly complex for sysops to configure,
whatever. This is what's made programs like RLIBBS, FBB, etc to be so solid -
they pick one function and they specialize in it. Once the bugs are 100%
worked out and are rock solid then maybe create external modules that can
plug-in to the main app or be run separately, and halted individually in the
event a bug is found so it doesn't cause any harm.
Just my 2 cents worth.
73
---
SendBBS v1.1 by N1URO for LinFBB
Read previous mail | Read next mail
| |
