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

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

[Kyle Meyer]

In Emacs 24.4 [0], the command used in nntp.el for detecting NNTP
capabilities changed from CAPABILITIES to HELP to work around an issue
with a particular news server not recognizing the CAPABILITIES command
(bug#12763).

This probably works most the time because, according the RFC 3977 [1],
it is "customary for [HELP] to list the valid commands and give a brief
definition of what they do".  However, that same section says HELP
shouldn't be used as a replacement for CAPABILITIES.

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?


[0] b9989bfa7e59b423df76b184e657b66017f72ff9
    lisp/gnus/nntp.el (nntp-open-connection): Fix nntp connection
    problems with the Typhoon server
    2012-12-28
[1] https://tools.ietf.org/html/rfc3977#section-7.2
[2] https://public-inbox.org/

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

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

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

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

I had to add more support for this stuff in open-network-stream, but
nothing too horrid.

So this should be fixed in Emacs 28.1 now, and nntp.el sends CAPABILITES
to all servers, except Typhoon ones.

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

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

[Kyle Meyer]

Lars Ingebrigtsen writes:

> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
>> I'll give that a whirl and see how it goes...
>
> I had to add more support for this stuff in open-network-stream, but
> nothing too horrid.
>
> So this should be fixed in Emacs 28.1 now, and nntp.el sends CAPABILITES
> to all servers, except Typhoon ones.

Great.  Thank you!