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)