Message Area
Casually read the BBS message area using an easy to use interface. Messages are categorized exactly like they are on the BBS. You may post new messages or reply to existing messages! You are not logged in. Login here for full access privileges. |
Previous Message | Next Message | Back to Support Echo For JAMNNTPD NNTP S... <-- <--- | Return to Home Page |
|
||||||
From | To | Subject | Date/Time | |||
mark lewis | Rick Christian | JamNNTPd that WORKS |
November 5, 2016 6:06 AM * |
|||
04 Nov 16 22:33, you wrote to me: ml>> BTW: i responded to your issue #6 at the ftnapps repo... i read over ml>> the RFC and i don't think that your simple fix will work... mainly ml>> because JAMNNTPd is not a mode switching NNTP server... RC> Few NNTP servers are, other than INN, BUT they need to respond to the RC> command as if they were. no sir, they do not... read the RFC... not just parts of it... the whole thing... that's an elephant, not a pillar, a rope, a tree branch, a hand fan, a wall, or a solid pipe... RC> They just need to fake out the readers which insist on this before RC> doing anything. no... those clients are not implemented correctly... they should not attempt "MODE READER" unless the server shows "MODE-READER" capability... this because the server literally has to switch modes and disallow certain other commands when in "MODE READER" mode... "IHAVE" is one that i remember needing to be specifically disallowed but jamnntpd doesn't support that anyway althought its message would have to be changed when in "MODE READER" mode IF it is even implemented... ml>> your news clients would know this if they used the CAPABILITIES ml>> request as noted RC> Ummm.. Just FYI .... JamNNTPD does NOT RESPOND to this! of course not! it is not a mode switching server RC> ~$ telnet news.wpusa.dynip.com 119 RC> Trying 40.136.244.87... RC> Connected to news.wpusa.dynip.com. RC> Escape character is '^]'. RC> 200 Welcome to JamNNTPd/OS2 1.21.b9/wpusa (posting may or may not be RC> allowed, try your luck) CAPABILITIES 500 Unknown command CAPABILITIES 500 RC> Unknown command that right there is enough to tell the client that "MODE READER" is not supported and it should just use traditional methods of getting the articles... even "HELP" would be enough to tell that the "CAPABILITIES" command is not available... RC> Based on https://tools.ietf.org/html/rfc3977 ml>> in the RFC... anyway, just thought i'd let you know that i did ml>> consider the request and was going to add it to my code base for RC> Per the RFC and several sources... for reference: RC> https://tools.ietf.org/html/rfc3977 i already read that and referenced it in my response on SF... you should also read the whole RFC and not just pick out parts that suit some purpose... other parts may be required as well before even getting to that point... unfortunately we also see that problem with FTSC standards... folks not reading everything or taking shortcuts instead of following the entire path... that elephant thing again... RC> An NNTP server when it gets MODE READER, should respond: RC> 200 some text RC> So RC> 200 Welcome to JamNNTPd/OS2 1.21.b9/wpusa (posting may or may not be RC> allowed, try your luck) RC> Seems to be a good way to "*fake*" out PAN and KNode which issue this RC> command before doing anything else like LIST to get a list of the RC> groups. screw /faking out/ anything... "fix yer shit!" as we used to say... PAN has not implemented "MODE READER" properly from what i've seen and read in the RFC... PAN should check if "MODE READER" is even available *before* attempting to use it... if it isn't available it should not even attempt to use that mode and PAN should fall back to the standard methods... this goes with KNode or whatever the other one was you tried to use... plus, the above welcome message has already been sent on connection... IF "MODE READER" is implemented, the response should be something other than the welcome text again... perhaps 200 Reader mode engaged. or 200 MODE READER enabled. posting or not is something else and allowed on a per area as well as a per user basis... users can be prohibited from posting in areas where other users are allowed to post on the same server... it doesn't need to be restated... it might even be fun to do it with some snark :laugh: ml>> testing but not without further study of the RFC and consulting with ml>> others in this echo that have a better understanding than i... RC> *I* will know soon enough... more power to you but just remember, this is a hobby and abuse doesn't win friends or result in problems being fixed with any speed )\/(ark Always Mount a Scratch Monkey Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong... ... I'm too sexy for this conference... --- * Origin: (1:3634/12.73) |
||||||
|
Previous Message | Next Message | Back to Support Echo For JAMNNTPD NNTP S... <-- <--- | Return to Home Page |
Execution Time: 0.0955 seconds If you experience any problems with this website or need help, contact the webmaster. VADV-PHP Copyright © 2002-2024 Steve Winn, Aspect Technologies. All Rights Reserved. Virtual Advanced Copyright © 1995-1997 Roland De Graaf. |