bug#41960: nntp.el: Switch back to CAPABILITIES command?

[Lars Ingebrigtsen]

Kyle Meyer <kyle@kyleam.com> writes:

> A specific case where using HELP instead of CAPABILITIES causes an issue
> is with public-inbox's [2] NNTP service, such as the one hosted at
> <news.public-inbox.org>.  public-inbox doesn't include a list of
> commands in its HELP output.  That is, it's not following the
> convention, but it is still following the specification.  Because
> nntp-open-connection tries to detect capabilities with HELP, it doesn't
> catch the properly advertised STARTTLS capability and fails to upgrade
> to a TLS connection.
>
> I'm guessing that the server from bug#12763 didn't recognize
> CAPABILITIES because it was based on RFC 977.  However, given RFC 3977
> supersedes 977 and is from 2006, does it make sense at this point to
> assume CAPABILITIES is supported?

Yeah, nntp.el should really use CAPABILITIES here, but working around
buggy NNTP software (i.e., Typhoon) would also be nice...  because NNTP
servers don't exactly get updated a lot these days.

Hm...  I think I see a way to do both here: `open-network-stream' today
only takes a string as a capability command, so we can't send different
commands based on the server software.  But we could easily extend that
function to allow taking a function, and use the greeting as the input
parameter, and then do HELP for Typhoon and CAPABILITIES for everything
else.

I'll give that a whirl and see how it goes...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no