The LIST OVERVIEW.FMT command MUST return these 7 following
case-insensitive strings:
Subject:
From:
Date:
Message-ID:
References:
:bytes
:lines
However, RFC 3977 also states in Section 8.4.2 that "for compatibility
with existing implementations, the last two lines MAY instead be:
Bytes:
Lines:
even though they refer to metadata, not headers."
Are you aware of news readers that send LIST OVERVIEW.FMT and would
break if they encountered ":bytes" or ":lines"? I'm wondering whether
it is safe nowadays to advertise the expected strings.
Also, are there useful other header fields that news readers are already >searching for in their (X)OVER requests and then would benefit from them
if present in the overview? The idea would then be to suggest to news
admins adding such fields in their overview data.
Like Newsgroups to know whether the article is crossposted? (Some news >servers already provide the Xref header field, but one cannot take for
sure that an article is crossposted with that mere field.)
Also, are there useful other header fields that news readers are already
searching for in their (X)OVER requests and then would benefit from them
if present in the overview? The idea would then be to suggest to news
admins adding such fields in their overview data.
Like Newsgroups to know whether the article is crossposted? (Some news
servers already provide the Xref header field, but one cannot take for
sure that an article is crossposted with that mere field.)
Newsgroups would make my life easier, certainly. I also have kill file entries based on Path.
Hi Adam,
Also, are there useful other header fields that news readers are already >>>searching for in their (X)OVER requests and then would benefit from them >>>if present in the overview? The idea would then be to suggest to news >>>admins adding such fields in their overview data.
Like Newsgroups to know whether the article is crossposted? (Some news >>>servers already provide the Xref header field, but one cannot take for >>>sure that an article is crossposted with that mere field.)
Newsgroups would make my life easier, certainly. I also have kill file >>entries based on Path.
I see that you're using trn. The question would then be: were the
Newsgroups and Path header fields be present in (X)OVER responses, would
trn use them directly? (without sending (X)HDR or HEAD commands to
retrieve these header fields)
It is the whole point of having them in the overview database. Yet, I
don't know whether current versions of news clients would directly grab
them from there. (It may be an interesting feature to implement in news >clients if they aren't already doing that.)
It is the whole point of having them in the overview database. Yet, I
don't know whether current versions of news clients would directly grab
them from there. (It may be an interesting feature to implement in news clients if they aren't already doing that.)
[...]
Also, are there useful other header fields that news readers are already searching for in their (X)OVER requests and then would benefit from them
if present in the overview? The idea would then be to suggest to news
admins adding such fields in their overview data.
Like Newsgroups to know whether the article is crossposted? (Some news servers already provide the Xref header field, but one cannot take for
sure that an article is crossposted with that mere field.)
[...]
The LIST OVERVIEW.FMT command MUST return these 7 following
case-insensitive strings:
Subject:
From:
Date:
Message-ID:
References:
:bytes
:lines
Julien ÉLIE wrote:
[...]
The LIST OVERVIEW.FMT command MUST return these 7 following
case-insensitive strings:
Subject:
From:
Date:
Message-ID:
References:
:bytes
:lines
RFC 3977 says in Section 8.4.2:
| This command MAY generate different results if it is used more than
| once in a session.
A newsreader needs to know when to refresh the information in this case.
Or is it intended to be repeated before every OVER command?
RFC 3977 says in Section 8.4.2:
|
| This command MAY generate different results if it is used more than
| once in a session.
Also, are there useful other header fields that news readers are already
searching for in their (X)OVER requests and then would benefit from them
if present in the overview? The idea would then be to suggest to news
admins adding such fields in their overview data.
Like Newsgroups to know whether the article is crossposted? (Some news
servers already provide the Xref header field, but one cannot take for
sure that an article is crossposted with that mere field.)
Newsgroups would be nice to have for scoring.
Currently the OVER command must be disabled for this to work in flnews. Quoted from man page:
|
| o nntp_no_over (Integer) Disable usage of overview (OVER command) for
| NNTP protocol
|
| Setting this to a nonzero value disables usage of overview and makes
| the whole newsgroup list usable for scoring rules.
| [...]
I see that you're using trn. The question would then be: were thePerhaps Wayne Davidson is still reading news.software.readers on
Newsgroups and Path header fields be present in (X)OVER responses, would
trn use them directly? (without sending (X)HDR or HEAD commands to
retrieve these header fields)
occassion. Eli the Bearded had contributed some trn patches a few years
ago; maybe he could glance at the code.
Well, yes, since which headers are being downloaded is configurable at
the server level, it would be ideal if the newsreader could determine
which additional headers beyond the standard headers had been
downloaded.
I'm not quite sure if the overview code in rt-ov.h properly deals with
extra content in overview. My experience suggests yes, but it could have
been masked by fast XHDR action.
Michael Bäuerle wrote:
[...]
Currently the OVER command must be disabled for this to work in flnews. Quoted from man page:
|
| o nntp_no_over (Integer) Disable usage of overview (OVER command) for
| NNTP protocol
|
| Setting this to a nonzero value disables usage of overview and makes
| the whole newsgroup list usable for scoring rules.
| [...]
Why not automatically disable OVER if there exists a scoring rule using
the Newsgroups header field? (and keep using OVER otherwise)
In case you wish to test a possible use of the Newsgroups field if
present in overview data, I've added it in my news server (news.trigofacile.com):
LIST OVERVIEW.FMT
215 Order of fields in overview database
Subject:
From:
Date:
Message-ID:
References:
:bytes
:lines
Xref:full
Newsgroups:full
Path:full
.
GROUP news.software.nntp
211 10940 1 15264 news.software.nntp
OVER 15262
224 Overview information for 15262 follows
15262 Re: Advertising metadata and other fields in overview Michael =?ISO-8859-1?Q?B=E4uerle?= <michael.baeuerle@stz-e.de> Mon, 1 Aug 2022 12:55:15 +0200 (CEST) <AABi57ETSaEAAAJK.A3.flnews@WStation5.stz-e.de> <tc6fmu$2q025$1@news.trigofacile.com> 1585 21 Xref: news.trigofacile.com
news.software.nntp:15262 Newsgroups: news.software.nntp,news.software.readers Path: news.trigofacile.com!weretis.net!feeder8.news.weretis.net!lilly.ping.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
.
I've also added Path, as Urs has a special handling of it in tin.
And switched to the "preferred" naming of ":bytes" and ":lines" (feel
free to test that everything is still OK with these names).
Michael Bäuerle <michael.baeuerle@stz-e.de> wrote:
[...]
My plan is to simply skip the first 7 fields of the response.
Different order or meaning is not allowed by RFC 3977. And this
newsoverview(5) from Geoff Collyer (some time in 1992) did specify an order (but did't mention LIST OVERVIEW.FMT as that was invented AFAIK ~1 year later).
RFC 2980 (from 10.2000) didn't specify an order.
RFC 3977 (from 10.2006) does specify an order.
IIRC I've seen non RFC 3977 compliant setups in the wild (reversed order, missing mandatory fields, duplicate fields, ...).
I've also added Path, as Urs has a special handling of it in tin.
My plan is to simply skip the first 7 fields of the response.
Different order or meaning is not allowed by RFC 3977. And this
[...]
In case you wish to test a possible use of the Newsgroups field if
present in overview data, I've added it in my news server (news.trigofacile.com):
LIST OVERVIEW.FMT
215 Order of fields in overview database
Subject:
From:
Date:
Message-ID:
References:
:bytes
:lines
Xref:full
Newsgroups:full
Path:full
.
[...]
Connect to news.trigofacile.com:nntps][Established encrypted connection using TLSv1.3 protocol with cipher suite TLS_AES_256_GCM_SHA384]
] CAPABILITIES[<=] 101 Capability list:
] LIST OVERVIEW.FMT[<=] 215 Order of fields in overview database
I have implemented support for LIST OVERVIEW.FMT in the snapshot flnews 1.2.0pre1.
[Compression]
[Newsgroups header field available from overview]
Urs noted that some server implementations are broken.The mandatory fields are now checked for presence and order.
The Newsgroups header field, if present, is copied from the overview.
Scoring rules of type "group" are applied to all groups in this case.
Hi all,
The LIST OVERVIEW.FMT command MUST return these 7 following
case-insensitive strings:
Subject:
From:
Date:
Message-ID:
References:
:bytes
:lines
However, RFC 3977 also states in Section 8.4.2 that "for compatibility
with existing implementations, the last two lines MAY instead be:
Bytes:
Lines:
even though they refer to metadata, not headers."
Are you aware of news readers that send LIST OVERVIEW.FMT and would
break if they encountered ":bytes" or ":lines"? I'm wondering whether
it is safe nowadays to advertise the expected strings.
Also, are there useful other header fields that news readers are already searching for in their (X)OVER requests and then would benefit from them
if present in the overview? The idea would then be to suggest to news
admins adding such fields in their overview data.
Like Newsgroups to know whether the article is crossposted? (Some news servers already provide the Xref header field, but one cannot take for
sure that an article is crossposted with that mere field.)
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 498 |
Nodes: | 16 (2 / 14) |
Uptime: | 03:23:11 |
Calls: | 9,821 |
Calls today: | 9 |
Files: | 13,757 |
Messages: | 6,190,389 |