Gamgee wrote to poindexter FORTRAN <=-
Not sure how that's any easier than logging in with Syncterm and just getting the QWK packet the normal way, and then repeating for the .REP. Seems harder, actually.
Mindsurfer wrote to poindexter FORTRAN <=-
ah, ok. so thats less critical then if you just use insecure ftp
locally. So in your case it is a sysops solution only.
You can FTP to the BBS and download a magic name "BBS.QWK" to download your new messages, and upload BBS.REP to upload your packet (change BBS > pF> to the name your BBS gives to QWK packets).
Not sure how that's any easier than logging in with Syncterm and just getting the QWK packet the normal way, and then repeating for the .REP. Seems harder, actually.
I'll play devil's advocate here - running insecure protocols on a BBS aren't that big of a deal as long as you're not sharing passwords. I still allow telnet.
Dumas Walker wrote to Gamgee <=-
Re: Re: NNTP(S) via Thunderbi
By: Gamgee to poindexter FORTRAN on Wed Nov 05 2025 08:10:45
You can FTP to the BBS and download a magic name "BBS.QWK" to download your new messages, and upload BBS.REP to upload your packet (change BBS to the name your BBS gives to QWK packets).
Not sure how that's any easier than logging in with Syncterm and just getting the QWK packet the normal way, and then repeating for the .REP. Seems harder, actually.
OT from the original post but this is actually pretty easy with a shell scrit and ncftp. I log onto my BBS to get the QWK packet, but almost always upload the REP using a script. Once it is set up, it is easy
and a lot faster.
Not sure how that's any easier than logging in with Syncterm and just getting the QWK packet the normal way, and then repeating for the .REP. Seems harder, actually.
Console prompt:
$ ./getpkt
$ ./mm
$ ./putpkt
Mind you, these were scripts I wrote, one of which is one line, and the other is maybe 5 lines. No where near as difficult or time consuming.
OT from the original post but this is actually pretty easy with a shell scrit and ncftp. I log onto my BBS to get the QWK packet, but almost always upload the REP using a script. Once it is set up, it is easy
and a lot faster.
Yeah, after reading yours and a couple other responses, I can see this
being a good thing, didn't know that could be done.
Mind sharing a look at the script? (assuming Linux). Thanks.
Yeah, after reading yours and a couple other responses, I can see this
being a good thing, didn't know that could be done.
Mind sharing a look at the script? (assuming Linux). Thanks.
Sure. It changes to the "DOS drive" that Multimail/SLMR would have
I am now seeing the value of this method...
Would you mind sharing the scripts? (don't need the MultiMail one).
NOTE that the lines that start with a '+' are line wrapped!
Sure. It changes to the "DOS drive" that Multimail/SLMR would have
Um... you may want to change your password now?
NOTE that the lines that start with a '+' are line wrapped!
..and completely disregard the password, too! :D
Regards, Nick
Yes, understood. The "put" direction makes good sense to me. I have a question about the "get" side though - What causes the BBS to know to
pack up all the new messages into a QWK packet though? Does just the
act of requesting <BBSID>.qwk cause that to happen?
I was thinking I'd
have to somehow "tell" the BBS to create the new QWK packet, and *then*
grab it with wget/ftp.
Yes, understood. The "put" direction makes good sense to me. I have a question about the "get" side though - What causes the BBS to know to
pack up all the new messages into a QWK packet though? Does just the
act of requesting <BBSID>.qwk cause that to happen? I was thinking I'd
have to somehow "tell" the BBS to create the new QWK packet, and *then*
grab it with wget/ftp.
Appreciate you taking the time to send/explain this! Thanks.
No, it happens on demand. The *.qwk file that appears in the FTP
directory listing is just a virtual file. A "get" (RETR) of the file actually signals the sbbs event thread to create the packet, on demand,
so there is a bit of delay before the file transfer actually starts
(which is fine).
Accession wrote to Gamgee <=-
Yes, understood. The "put" direction makes good sense to me. I have a question about the "get" side though - What causes the BBS to know to
pack up all the new messages into a QWK packet though? Does just the
act of requesting <BBSID>.qwk cause that to happen? I was thinking I'd
have to somehow "tell" the BBS to create the new QWK packet, and *then*
grab it with wget/ftp.
I think either when you connect or when there is a new message(s), Synchronet creates the QWK packet and puts it in that location automatically. I'm not sure on exactly how it works, but it's there
every time I grab it, and it's an updated packet each time.
Rob would have to explain that better, but I'll just call it 'magic'.
:)
Digital Man wrote to Gamgee <=-
Re: Re: NNTP(S) via Thunderbi
By: Gamgee to Accession on Fri Nov 07 2025 09:15 pm
Yes, understood. The "put" direction makes good sense to me. I have a question about the "get" side though - What causes the BBS to know to
pack up all the new messages into a QWK packet though? Does just the
act of requesting <BBSID>.qwk cause that to happen?
Yes, correct.
I was thinking I'd
have to somehow "tell" the BBS to create the new QWK packet, and *then*
grab it with wget/ftp.
No, it happens on demand. The *.qwk file that appears in the FTP
directory listing is just a virtual file. A "get" (RETR) of the file actually signals the sbbs event thread to create the packet, on demand,
so there is a bit of delay before the file transfer actually starts
(which is fine).
On Fri, 07 Nov 2025 11:31:18 -0500, you wrote:
NOTE that the lines that start with a '+' are line wrapped!
..and completely disregard the password, too! :D
NOTE that the lines that start with a '+' are line wrapped!
..and completely disregard the password, too! :D
Regards, Nick
too bad he didnt post the system pass, i could have fixed some stuff.
See, Gamgee? Magic! :)
Regards, Nick
Regards, Nick
too bad he didnt post the system pass, i could have fixed some stuff.
Just because *you* don't like it doesn't make it broken.
Not sure how that's any easier than logging in with Syncterm
and just getting the QWK packet the normal way, and then
repeating for the .REP. Seems harder, actually.
It's pretty handy here, I don't know if a lot of sysops open FTP on
their firewalls though.
Sure. It changes to the "DOS drive" that Multimail/SLMR would
have accessed the QWK packets in, tests for whether or not the
packet name got written out in all CAPS or all lower case, and
acts accordingly.
NOTE that the lines that start with a '+' are line wrapped!
#!/bin/bash
cd /opt/DRIVE_E/KERM231
test -e /opt/DRIVE_E/KERM231/CAPCITY2.REP
if (( $? == 0 )) ;
then
ncftpput -u "Dumas Walker" -p 448fmr -DD -E -d stdout
+ capitolcityonline.net / /opt/DRIVE_E/KERM231/CAPCITY2.REP
fi
test -e /opt/DRIVE_E/KERM231/capcity2.rep
if (( $? == 0 )) ;
then
ncftpput -u "Dumas Walker" -p 448fmr -DD -E -d stdout
+ capitolcityonline.net / /opt/DRIVE_E/KERM231/capcity2.rep
fi
cd ~
#
##END
Regards, Nick
too bad he didnt post the system pass, i could have fixed some stuff.
Just because *you* don't like it doesn't make it broken.
yeah ooookay. i just dont like broken things.
As I said, just because you don't like it doesn't make it broken.
As you are the only one whose ever complained, I would suggest the
problem is elsewhere -- and very much not mine.
OTOH, I originally had Synchronet set up so that all the message
areas were grouped by network -- which is how you like it -- and
users (plural) did complain because they couldn't find the "echoes
When a user isn't either pissed at the network admins, or banned by
then, which networks you want/need to avoid isn't an issue.
OTOH, I originally had Synchronet set up so that all the message areas were grouped by network -- which is how you like it -- and users
(plural) did complain because they couldn't find the "echoes about (subject)" that they were used to participating in on the predecessor
BBS.
predecessor BBS.
can message areas not be grouped in more than one way? i don't
recall. perhaps in a(n unpleasant) way where two areas listed in two
groups use the same files?
can message areas not be grouped in more than one way? i don't recall. perhaps in a(n unpleasant) way where two areas listed in two groups use the same files?
can message areas not be grouped in more than one way? i don't recall. perhaps in a(n unpleasant) way where two areas listed in two groups use t > > same files?
They actually can be, by having a sub-board with the same internal code in m > than one message group. This means you can't use the "internal code prefix"
feature, but it is doable. Some oddity with message scan config / pointers might occur also, I don't recall.
| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 59 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 20:57:01 |
| Calls: | 810 |
| Calls today: | 1 |
| Files: | 1,287 |
| D/L today: |
11 files (21,026K bytes) |
| Messages: | 194,568 |