Re: [Pan-users] RFC versus sever versus client

[Lacrocivious Acrophosist]

On Thu, 10 Nov 2016 23:12:16 +0100, Per Hedeland wrote:

> Hi,
> 
> Sorry for top-posting, but I'm afraid my normal interleaved-style reply
> wouldn't be really useful here...
> 
> As a bit of background, NNTP hasn't had much interest from the Internet
> standards groups for most of its existence, and thus implementations
> have made the extensions they needed when they needed them. It is great
> that RFC 3977 exists, but the MODE READER command, introduced by the INN
> implementation in 1991 (part of what it needed to achieve its huge
> performance improvement over the earlier "reference implementation"),
> predates the CAPABILITIES command introduced in 3977 by some 15 years.
> 
> And the publication of an RFC obviously doesn't cause support for it to
> magically appear in existing implementations, far less in existing
> installations of those implementations. Thus there likely exists a large
> number of NNTP servers that absolutely require that you use the MODE
> READER command if you want reader service, yet will give you a 500 reply
> if you try CAPABILITIES.
> 
> I think it is reasonable to expect implementors of NNTP servers to have
> some knowledge of this background, and not think that RFC 3977 has
> everything they need - e.g. RFC 2980 is a good read. It is perhaps
> particularly ironic that implementors of a gateway to FidoNet of all
> things lack the historical perspecive.:-) And regarding Duncan's mention
> of what is known as "Postel's principle", a resonable application of
> that is that if you are an NNTP server that only provides reader
> service,
> and a client asks you for reader service, you just say "sure, go ahead"
> - while a client ignoring an error response from the server may not be,
> since it can lead to all kinds of difficult-to-debug problems down the
> line.
> 
> Anyway, enough rambling - I think the answer, maybe not to your actual
> question but to the question of what needs to be fixed, is perfectly
> clear from RFC 3977 - and it is what you could expect from a standard
> created by people that actually *have* the historical perspective. It
> says:
> 
> In section 5.2.2, about the CAPABILITIES command:
> 
>    This command MAY be issued at any time; the server MUST NOT require
>    it to be issued in order to make use of any capability.
> 
> In section 5.3.2, about the MODE READER command:
> 
>    If the server is not mode-switching, then the following apply:
> 
>    o  If it advertises the READER capability, it MUST return a 200 or
>       201 response with the same meaning as for the initial greeting; in
>       this case, the command MUST NOT affect the server state in any
>       way.
> 
> If the implementation of the server in question is done per the letter
> of 3977, it surely advertises the READER capability, and then per the
> above it MUST return a 200 or 201 response to MODE READER, regardless of
> whether the CAPABILITIES command has been issued by the client.
> 
> --Per Hedeland
> 
> On 2016-11-10 13:54, DLSauers wrote:
>> On Thu, 10 Nov 2016 03:27:14 +0000, Duncan wrote:
>> 
>>> A practical and common RFC guideline and general policy is: Interpret
>>> the RFCs strictly in what you send, but be more tolerant in what you
>>> are prepared to receive.
>> 
>> If that is the case, then by that definition, Pan and Knode are the bug
>> sources in insisting on MODE READER before doing anything..while other
>> clients seem to just ignore, tolerate as you put it, and move on..
>> 
>> 
>>> In this case, that would mean that regardless of whether the RFCs
>>> mandate MODE READER or not, particularly given that there are known
>>> servers out there that don't support it, pan should be prepared to
>>> work
>> 
>> What other servers don't support it???? I am curious for reference...
>> 
>> Which also would mean that Pan would not work them since MODE READER is
>> the first thing that comes in, and then BOOM, 500, offline.
>> 
>>> around receiving an error for the command, and continue without it the
>>> best it can.
>> 
>> Well this is sort of what one other client does...it issues MODE
>> READER, gets 500 from this server, then just does LIST anyway...
>>  
>> Based on this:
>> 
>> https://tools.ietf.org/html/rfc3977#section-3.4.2
>>  An implementation MAY, but SHOULD NOT, provide both transit and
>>    reader facilities on the same server but require the client to
>>    select which it wishes to use.  Such an arrangement is called a
>>    "mode-switching" server.
>> 
>> it seems that Pan and Knode which issue this MODE READER get 500,
>> should then respond as another client does and just issue LIST
>> 
>> Since this is not a "transit" sever in that Server to server
>> communications will occur.. then MODE READER is not correct...????
>> 
>>> I /was/ going to suggest that a workaround would be using a firewall
>>> to block the 500 error response and replace it with a synthetic
>>> response
>> 
>> My fix, responds to MODE READER, issues 200, Pan then does LIST, and
>> every one is happy... I've pulled messages from this server.. Not
>> posted with it yet, due to an issue not related to this....
>> 
>> 
>>> Which means the only real solution if you're going to use pan with
>>> that server is finding someone who knows enough C++ and is either
>>> familiar enough with the RFCs or willing to /become/ familiar enough
>>> with them to create and submit a patch...
>> 
>> I have a "hackish" fix to it for now... I working on more "proper" fix
>> to it after working out how this thing works... since its not my code
>> originally.... my original initial fix didn't work because of the way
>> it parses commands...
>> 
>> I have a fix... and working on adding some other things...
>> 
>> Based on the RFC's a client *SHOULD*
>> 
>> Connect to SERVER
>> 
>> CAPABILITIES parse that for commands (optionally switch to Secure mode)
>> based on this, rinse repeat CAPABILITIES after switching to secure
>> mode)
>> MODE READER if above CAPABILITIES parse again LIST
>> 
>> But the clients I checked with, 3, Pan, Knode, and thunderturkey don't
>> issue CAPABILITIES.
>> 
>> Just issue MODE READER and go from there....
>> 
>> So seems that there is a diversion away from the proper route and the
>> quick route ....
>> 
>> Doesn't seem to be a complete definitive answer here as it seems all
>> servers and clients have gotten away from the RFC's....

DLSauers--

Per Hedeland's superb post made me think several times before posting 
this lame offering, but what the hell, I have no ego ;-)

I am not a coder and can only sort-of follow what you are discussing, but 
I am a willing and somewhat experienced Willing Laboratory Lab Animal and 
can do gdb backtraces and such if told what parameters to use.

So what I'm saying is, although I will be less than useless in helping 
you code a fix for this very real problem in any commit-worthy sense of 
the word, I might be able to help if you need sacrificial test critters 
that you have to unscrew the tops of the head of in order to pour in your 
desired instructions.

Just offering ;-)

I care very much about the Pan project and am always eager to see it 
advance in any particulars.

You may get some idea of the level of my Sacrificial Lab Animal 
usefulness from this rather dated example for another project. I suppose 
it could help you decide whether I would be of any use): 

http://pastehtml.com/view/5tx16jw.html

... hey, at least I didn't <shudder> *top post* ;-)

-- 
Lacrocivious Acrophosist

Twice as crazy as I would be, if I was half as crazy as I am.