Bug#293978: tin does not work with news.mozilla.org (freeze at the beginning)

[Urs Janßen]

I've created an entry
news.mozilla.org .newsrc-mozilla mozilla
tin 1.7.6 release 20040906 ("Baleshare") [UNIX] (c) Copyright 1991-2004 Iain Lea.
secnews.netscape.com Netscape-Collabra/3.52 03615 NNRP ready (posting ok).
Your server does not have Xref: in its XOVER information.

there are several problems with that server, the first one is that the
Netscape-Collabra/3.52 server responbds with a different returncode
to a "list extensions" than e.g. inn does.

[Netscape]
| 215 Extensions supported by server.
| SEARCH
| SETGET
| OVER
| XPATTEXT
| XACTIVE
| LISTMOTD
| LISTSUBSCR
| LISTPNAMES
| .

[inn]
| 202 Supported NNTP extensions.
| AUTHINFO USER
| LISTGROUP
| .

tin expects a 202 responsecode otherwise it assumes that the server
doesn't support extensions. unfortunately tin doesn't expect a
multiline response here if the servers answer is not 202, so it
does not fetch the pending data on the socket and gets out of sync.

LIST EXTENSION isn't specified by an RFC and it looks like that it
will never be officially implemented (CAPABILITIES might be it's
"replacement"). so officiall we can't blame the netscape server, but
usualy INN is regarded as reference implementation so I'd say that
expecting an 202 answer is the right thing and the server is
'buggy'. there is still tins problem with unexpected multiline responses
and getting out of sync...

once you bypassed this problem (either by pathing check_extensions()
to expect 212 or by by not calling check_extensions() at all you
might find more problems like:

nntp command: LISTGROUP netscape.public.beta.feedback.help

: LISTGROUP netscape.public.beta.feedback.help

<<<: 211 Article list follows
LISTGROUP netscape.public.beta.feedback.help: OK
setup_hard_base: LISTGROUP netscape.public.beta.feedback.help
nntp command: OVER 176-179

: OVER 176-179

<<<: 224 data follows
OVER 176-179: OK
read_overview: 0 Bad overview record (6 fields)

and as the server doesn't store the xref header in the overviews you
might see a lot of XHDR XREF calls, but that's just cosmetics.

Tin will try to use XHDR XREF instead (slows down things a bit).
Reading keymap file...
Reading input history file...
Reading mail active file...
Try and save newsrc file again? (Y/n) Y
Then tin freezes.

for me (but this is with the lastest spanshot) it still accepts the 'n'
answer. I didn't had a closer look at the code why it doesn't accept
'Y' here.

urs

[Michael Bienia]

Post by Urs Janßen

Tin will try to use XHDR XREF instead (slows down things a bit).
Reading keymap file...
Reading input history file...
Reading mail active file...
Try and save newsrc file again? (Y/n) Y
Then tin freezes.

for me (but this is with the lastest spanshot) it still accepts the 'n'
answer. I didn't had a closer look at the code why it doesn't accept
'Y' here.

There is a tolower() missing in prompt.c:229:
func = key_to_func(tolower(ch), prompt_keys);

Michael