| |
N1URO > SYSOP 17.09.20 11:32l 80 Lines 3646 Bytes #999 (0) @ WW
BID : 41360_N1URO
Read: GUEST
Subj: Re: UT1HZM > JNOS BID changing
Path: IZ3LSV<ED1ZAC<EA5URD
Sent: 200914/2110Z @:EA5URD.EAMU.ESP.EU #:20367 XFBB7.04h Bid:41360_N1URO
R:200914/2109Z @:EA2RCF.EAVI.ESP.EU #:2095 [Vitoria] $:41360_N1URO
R:200914/2109Z 25626@LU9DCE.TOR.BA.ARG.SOAM LinBPQ6.0.20
R:200914/2108Z @:LU4ECL.LP.BA.AR.SOAM #:52512 [52513] FBB7.01.35 alpha $:41360_N1URO
R:200914/2103Z 32498@N3HYM.MD.USA.NOAM BPQ6.0.19
R:200914/2107Z 59624@OK2PEN.SP.BRA.SOAM [Sao Jose dos Campos] $:41360_N1URO
R:200914/2103Z @:N1URO.#CCT.CT.USA.NOAM #:52924 [Unionville] $:41360_N1URO
R:200914/2055z @:N1URO.#JNOS.CT.USA.NOAM [Unionville] #:41365 $:41360_N1URO
R:200828/2332z @:N2NOV.#RICH.NY.USA.NOAM #:51620 $:52071_N1URO
R:200828/2330z @:AA6HF.#SCA.CA.USA.NOAM [Palm Springs] #:20952 $:52071_N1URO
R:200828/2328Z @:N1URO.#CCT.CT.USA.NOAM #:52071 [Unionville] $:52071_N1URO
>From n1uro%n1uro.#cct.ct.usa.noam@n2nov.ampr.org Fri Aug 28 19:32:00 2020
Received: from n2nov.ampr.org by n2nov.ampr.org (JNOS2.0.6.URO) with SMTP
id AA151620 ; Fri, 28 Aug 2020 19:32:00 EDT
Message-Id: <52071_N1URO@AA6HF.bbs>
>From: n1uro@n1uro.#cct.ct.usa.noam
X-JNOS-User-Port: Circuit (BBGATE:AA6HF-4 AA6HF-4) -> Sending message
From: N1URO@N1URO.#CCT.CT.USA.NOAM
To : SYSOP@WW
Sergej et al;
> Brian, thanks for attempt to explain.
> Never used JNOS here, so you say when doing FWD JNOS to JNOS,
> they don't do it in classic FBB-type compressed protocol?
Keep in mind, even in the US where I'm at, compressed forwarding via RF
has yet to be decided with government if it's a form of encryption (and
thusly illegal) or not, however Maiko (who maintains JNOS2) has incorporated
some of the levels of FBB compressed forwarding. This does not prevent the
SMTP engine from controlling the mail once received. Mail is still rewritten
under the SMTP engine twice:
- to convert the incoming mail to SMTP format
- to rewrite it to proper mailbox spool and other bbs forward spool files.
> With SID's like '[BPQ-6.0.20.24-B1FIHJM$]' etc? Its new for me, hi.
Actually it does, and it's usually during proposal of mail the remote BBS
fails to send the BID... and when this occurs the local BBS, by PBBS
specification, inserts it's own BID.
> What can cause situation where NOS not put original BID's in FWD proposition?
> And can developers finally fix it?!
This seems to be something specific to one sysop at this particular time.
The sad thing is that it makes those who receive mail from them look as
if they're doing bid changing deliberately when it's by spec design this
happens. I've supplied code to the JNOS2 project that for the most part
has helped prevent a lot of this from occurring.
> For example, on some versions of classic BBS system (FBB etc) it could be
> happen too, when BBS forward is not set right on both sides, so initial side
> not drop session if compressed protocol for some reason not available,
> but tried to do "fake FWD" in "plain text" mode w/o original BIDs.
I refer you to my above comment where forwarding sessions where compression is
used may not be legal to do. The fact that the text is altered in a non-readable
format may be considered encrypted. Of course, RF forwarding is so far and
few these days (just look at R: Lines and you can see the landline paths
things take) it probably doesn't matter.
> Maybe it worth make some checking, to stop that 'plain mode fwd' and
> use only full/compressed mode with original BIDs...
And maybe in those countries where compression is illegal we can do away
with amateur licenses too since they'll be pointless :)
FidoNet is a much better structured mail flow system, and I'm going back
to that. It's better governed by those who use it and there's no issues
with mail as on the amateur PBBS network.
---
SendBBS v1.1 by N1URO for LinFBB
Read previous mail | Read next mail
| |
