I am using TIdNNTP and encountered a situation with news.astraweb.com server where it announces in LIST EXTENSIONS that it supports new command HDR and OVER (formal versions of XHDR and XOVER) - see https://www.rfc-editor.org/rfc/rfc3977#section-8.3 and https://www.rfc-editor.org/rfc/rfc2980#section-2.8
The problem is that the server replies with command code 500 (invalid command) when issued OVER command (instead of XOVER). Although this is clearly non-RFC-compliant behavior I'd like to see if there is a possibility to force TIdNNTP to use XOVER instead of OVER, in other words to work in a sort of "legacy" mode. The same thing works perfectly with compliant server like news.aioe.org
Log example from news.astraweb.com (problematic server)
->CAPABILITIES
<-500 What?
->LIST EXTENSIONS
<-202 Extensions supported:
<-HDR
<-OVER
<-.
->GROUP group.name
<-211 100031 1 100031 group.name
->OVER 100031-100031
<-500 What?
Proper log from news.aioe.org (works as expected)
-> CAPABILITIES
<- 101 Capability list:
<- VERSION 2
<- IMPLEMENTATION INN 2.5.2
<- AUTHINFO
<- SASL
<- HDR
<- LIST ACTIVE ACTIVE.TIMES DISTRIB.PATS HEADERS NEWSGROUPS OVERVIEW.FMT
<- OVER
<- POST
<- READER
<- SASL NTLM DIGEST-MD5 CRAM-MD5
<- STARTTLS
<- .
-> STARTTLS
<- 382 Begin TLS negotiation now
-> MODE READER
<- 200 news.aioe.org InterNetNews NNRP server INN 2.5.2 ready (posting ok)
-> CAPABILITIES
<- 101 Capability list:
<- VERSION 2
<- IMPLEMENTATION INN 2.5.2
<- AUTHINFO
<- USER
<- SASL
<-
<- HDR
<- LIST ACTIVE ACTIVE.TIMES DISTRIB.PATS HEADERS NEWSGROUPS OVERVIEW.FMT
<- OVER
<- POST
<- READER
<- SASL NTLM DIGEST-MD5 CRAM-MD5 PLAIN LOGIN
<- .
-> GROUP group.name
<- 211 4540 67027 71566 group.name
-> OVER 67027-71566
<- 224 Overview information for 67027-71566 follows
....
Right now, TIdNNTP automatically selects OVER when server announces it supports OVER and using IdNNTP.XOVER call will issue OVER command. Can this be overridden somehow? Is it worth bothering by doing this sort of legacy support?