Proposal for new status fields for newsgroups
Julien ÉLIE
In case you have any comments or special need on status fields
returned by LIST ACTIVE, do not hesitate to speak up.
Expectations from news readers, how they can be used, implementation
on news servers, etc.
New status fields
The LIST ACTIVE command is defined in Section 7.6.3 of [RFC3977].
The fourth field of each line of this list indicates the current
status of the newsgroup whose name is specified in the first field.
Three status are defined in [RFC3977]:
"y" Posting is permitted.
"n" Posting is not permitted.
"m" Postings will be forwarded to the newsgroup moderator.
This document defines five other status which can also be used:
"l" Only local posting is permitted.
"lm" Only local posting is permitted and will be forwarded to the
newsgroup moderator.
"j" Posting is permitted but no articles are locally filed.
"x" Postings and articles from peers are not permitted.
"=other.group" Articles are filed under the newsgroup named
"other.group".
The server SHOULD use these values when these meanings are required
and MUST NOT use them with any other meaning.
A newsgroup with status "l" is a newsgroup with status "y" wherein
articles from peers are not accepted. Similarly, a newsgroup with
status "lm" is a newsgroup with status "m" wherein articles from peers
are not accepted.
The difference between a newsgroup with status "y" and a newsgroup
with status "j" is that articles are filed into the corresponding
newsgroup for the former, and not filed at all for the latter. If an
article is locally posted to a newsgroup with status "j" or is
received from a peer, and in case it is not crossposted to some other
valid groups, it will not be filed into a newsgroup on the news
server. Yet, this article will still be propagated to other peers,
if appropriate. Otherwise, in case this article is crossposted to
some other valid groups, it will be filed only into the valid
newsgroups it is crossposted to.
NOTE: Instead of not filing at all an article posted to a
newsgroup with status "j", a news server MAY file it under a
catch-all group. When a news server uses a catch-all group to
file the articles posted to newsgroups with status "j", this
catch-all group SHOULD be named "junk". (The first letter of the
"junk" newsgroup explains why this status has been called "j".)
Consequently, when a news server carries the "junk" newsgroup and
uses it for the purpose of the "j" status, the "junk" newsgroup
contains all the postings which cannot file under a newsgroup
name, whatever the status of the "junk" newsgroup is. (However,
an article posted explicitly to "junk" is treated according to the
status of the "junk" newsgroup.)
This newsgroup may be available to news readers and is often used
by a news server as a way to locally store an article with the
view to transmitting it to its peers (which may carry some of the
newsgroups the article was posted to). Besides, instead of
rejecting an article which contains an invalid Newsgroups header
or which is posted to newsgroups it does not carry, a news server
may accept such an article and file it under this catch-all "junk"
newsgroup.
Depending on the configuration of the news server, mentioning a
newsgroup with status "j" is different than simply not listing the
group, since articles arriving in unknown newsgroups may be
rejected.
The difference between a newsgroup with status "n" and a newsgroup
with status "x" is that articles from peers are accepted for the
former, and rejected for the latter. A newsgroup with status "x" is
considered as closed: no new articles will arrive in such a group.
On the contrary, articles from peers will arrive in a newsgroup with
status "n". Local postings are not allowed in a newsgroup with one
of these two status.
When the status field begins with an equal sign ("=" or %x3D), the
name of an existing newsgroup on the news server MUST immediately
follow the sign. If the status field of "foo.bar" is "=other.group",
it means that "foo.bar" is an alias for "other.group". These two
newsgroups are distinct; they do not share their articles or their
article numbers. Local postings to "foo.bar" are not allowed, but
articles from peers are accepted for "foo.bar" and filed into
"other.group", whatever the status of "other.group" is. The contents
of their Newsgroups headers MUST NOT be altered.
Alias groups are typically used during a transition between two
newsgroups.
An alias MUST NOT point to another alias group. The newsgroup an
alias points to SHOULD exist on the news server. If an alias is
listed in the active list, the newsgroup it points to is not also
listed in the active list when a wildmat is given to the LIST ACTIVE
command, and the name of the newsgroup the alias points to does not
match this wildmat.
The following table summarizes what usually happens to an article
posted to only the newsgroup "foo.bar", depending on its status field
on the news server:
+--------------+-----------+------------+------------+--------------+
| Status field | Accepted | Accepted | Moderation | Destination |
| of "foo.bar" | if local | from | needed? | if accepted? |
| | posting? | peers? | | |
+--------------+-----------+------------+------------+--------------+
| y | Yes | Yes | No | foo.bar |
| n | No | Yes | No | foo.bar |
| m | Yes | Yes | Yes | foo.bar |
| l | Yes | No | No | foo.bar |
| lm | Yes | No | Yes | foo.bar |
| j | Yes | Yes | No | junk (if |
| | | | | filed) |
| x | No | No | No | |
| =other.group | No | Yes | No | other.group |
+--------------+-----------+------------+------------+--------------+
NOTE: If a server files newsgroups with status "j" into "junk", a
newsgroup with status "j" and a newsgroup with status "=junk" are
different. For instance, a local posting to only the former will
be accepted and filed into "junk" whereas a local posting to only
the latter will not be accepted.
The following table summarizes what usually happens to an article
crossposted to the newsgroup "foo.bar" and a valid newsgroup
"misc.test" (whose status field is "y") known by the news server,
depending on the status field of "foo.bar" on the news server:
+--------------+-----------+------------+------------+--------------+
| Status field | Accepted | Accepted | Moderation | Destination |
| of "foo.bar" | if local | from | needed? | if accepted? |
| | posting? | peers? | | |
+--------------+-----------+------------+------------+--------------+
| y | Yes | Yes | No | foo.bar, |
| | | | | misc.test |
| n | No | Yes | No | foo.bar, |
| | | | | misc.test |
| m | Yes | Yes | Yes | foo.bar, |
| | | | | misc.test |
| l | Yes | No | No | foo.bar, |
| | | | | misc.test |
| lm | Yes | No | Yes | foo.bar, |
| | | | | misc.test |
| j | Yes | Yes | No | misc.test |
| x | No | Yes | No | misc.test |
| =other.group | No | Yes | No | other.group, |
| | | | | misc.test |
+--------------+-----------+------------+------------+--------------+
NOTE: The status of a newsgroup only indicates how articles
arriving to that newsgroup are normally processed; news servers
MAY provide clients with special privileges to allow or disallow
some rights in these newsgroups. This specification defines
neither these rights nor whether or not articles posted to these
groups should be propagated to other peers.
If the news server may accept articles from the client during the
session (possibly after successful authentication), it SHOULD NOT
return a status like "n" or "x" which suggests that articles are
not accepted in the corresponding newsgroup.
Example
Example of an article posted to an alias group by a peer:
[C] LIST ACTIVE
[S] 215 List of newsgroups follows
[S] foo.bar 21 12 y
[S] misc.test 3002322 3000234 =foo.bar
[S] .
[C] IHAVE <for.mi...@example.com>
[S] 335 Send it; end with <CR-LF>.<CR-LF>
[C] Path: demo!.POSTED.somewhere!not-for-mail
[C] From: "Demo User" <nob...@example.com>
[C] Newsgroups: misc.test
[C] Subject: I am just a test article
[C] Date: 18 Oct 2009 04:48:12 +0200
[C] Organization: An example, Paris, FR.
[C] Message-ID: <for.mi...@example.com>
[C]
[C] This is just a test article.
[C] .
[S] 235 Article transferred OK
[C] LIST ACTIVE
[S] 215 List of newsgroups follows
[S] foo.bar 22 12 y
[S] misc.test 3002322 3000234 =foo.bar
[S] .
[C] HDR Xref <for.mi...@example.com>
[S] 225 Header information follows
[S] 0 news.server.com foo.bar:22
[S] .
[C] HDR Newsgroups <for.mi...@example.com>
[S] 225 Header information follows
[S] 0 misc.test
[S] .
The Newsgroups header of this article is kept untouched. This
article is filed under "foo.bar" even though it has originally been
posted, and still propagates to other peers, to the newsgroup
"misc.test".
ABNF syntax
newsgroup-status =/ %x6c / %x6c.6d / ; case-sensitive "l" and "lm"
%x6A / %x78 / ; case-sensitive "j" and "x"
newsgroup-alias
newsgroup-alias = "=" newsgroup-name
--
Julien ï¿œLIE
ￜ On ne va jamais si loin que lorsque l'on ne sait pas oￜ l'on va. ￜ
D. Stussy
news:hesbr3$m1n$1...@news.trigofacile.com...
> In case you have any comments or special need on status fields
> returned by LIST ACTIVE, do not hesitate to speak up.
> Expectations from news readers, how they can be used, implementation
> on news servers, etc.
>
>
> New status fields
>
> The LIST ACTIVE command is defined in Section 7.6.3 of [RFC3977].
> The fourth field of each line of this list indicates the current
> status of the newsgroup whose name is specified in the first field.
> Three status are defined in [RFC3977]:
>
> "y" Posting is permitted.
>
> "n" Posting is not permitted.
>
> "m" Postings will be forwarded to the newsgroup moderator.
>
> This document defines five other status which can also be used:
>
> "l" Only local posting is permitted.
I don't like this. The local-permitting system should have a "y" and other
servers an "n".
(see also below)
> "lm" Only local posting is permitted and will be forwarded to the
> newsgroup moderator.
I don't like this either. I think it should just be "m". We don't need to
specially mark "local groups" with an "L".
(see also below)
> "j" Posting is permitted but no articles are locally filed.
Isolated posting is PROHIBITED: The group "does not exist" as far as the
local server is concerned. Cross-posting (with a carried group) may occur
but no article is locally filed to the "j"-marked group. The group is
listed in the active file (INN) only for the purpose of passing the group
through to other peers. That's why my recent patch screens OUT "j" groups
from the "LIST ACTIVE" output (as well as "=" groups). That's why I skip
creating an empty traditional overview fileset for them. They don't
locally exist.
> "x" Postings and articles from peers are not permitted.
Note: Postings to the "junk", "to", and "control" hierarchy pseudogroups
still occur when those groups are marked with an "x".
My patch presents "x" groups in the "LIST ACTIVE" output only when the
highmark is not zero (i.e. something, sometime, was posted to the group).
Otherwise, they are NOT included and therefore not presented to the client.
Again, empty overview files are not created for them (at initialization).
> "=other.group" Articles are filed under the newsgroup named
> "other.group".
>
> The server SHOULD use these values when these meanings are required
> and MUST NOT use them with any other meaning.
>
> A newsgroup with status "l" is a newsgroup with status "y" wherein
> articles from peers are not accepted. Similarly, a newsgroup with
> status "lm" is a newsgroup with status "m" wherein articles from peers
> are not accepted.
If you disagree with my comments regarding "L" (I use the capital because
in some fonts, the lower case "l" and "1", the digit, look identical), I
then also suggest that it appear as a SUFFIX: "yl" and "ml". That way,
older reader programs that expect or look at only the first character will
still function properly, especially for "ml" where a message to a moderator
is needed.
For INN: Doesn't the screening of groups ("patterns") in
"{pathetc}/incoming.conf" and a choice of patterns fed from peers generally
take care of the same function as "L"?
> The difference between a newsgroup with status "y" and a newsgroup
> with status "j" is that articles are filed into the corresponding
> newsgroup for the former, and not filed at all for the latter. If an
...not filed LOCALLY for the latter. (Peers may file them if they're
not "j"-flagged elsewhere)
> article is locally posted to a newsgroup with status "j" or is
> received from a peer, and in case it is not crossposted to some other
> valid groups, it will not be filed into a newsgroup on the news
> server. Yet, this article will still be propagated to other peers,
> if appropriate. Otherwise, in case this article is crossposted to
> some other valid groups, it will be filed only into the valid
> newsgroups it is crossposted to.
An article locally posted only to "j"-marked groups will NOT be propagated
to other peers. Articles from peers to "j"-marked groups may be passed on
to other peers.
> NOTE: Instead of not filing at all an article posted to a
> newsgroup with status "j", a news server MAY file it under a
> catch-all group. When a news server uses a catch-all group to
> file the articles posted to newsgroups with status "j", this
> catch-all group SHOULD be named "junk". (The first letter of the
> "junk" newsgroup explains why this status has been called "j".)
..., this catch-all group has historically been named "junk".
I don't think that we should fix the name of the junk group in an RFC. All
that we need require is that its name not clash with any currently defined
newsgroup. We may say in the RFC that historically, the name of such a
group is "junk", but we need not enforce this. "trash", "garbage",
"pass-through", or "unfiled" are equally representative names unlikely to
be used for a real group name.
> Consequently, when a news server carries the "junk" newsgroup and
> uses it for the purpose of the "j" status, the "junk" newsgroup
> contains all the postings which cannot file under a newsgroup
...contains all postings not filed under another newsgroup, ...
> name, whatever the status of the "junk" newsgroup is. (However,
> an article posted explicitly to "junk" is treated according to the
> status of the "junk" newsgroup.)
I do agree with the above "however", but we could also say that postings
explicitly to "junk" should not be permitted. Granted, I mark my junk
group with an "x" flag so the result is the same, but that's because I have
locally chosen such. Should posting explicitly to the "junk" newsgroup
ever be permitted?
> This newsgroup may be available to news readers and is often used
> by a news server as a way to locally store an article with the
> view to transmitting it to its peers (which may carry some of the
> newsgroups the article was posted to). Besides, instead of
> rejecting an article which contains an invalid Newsgroups header
> or which is posted to newsgroups it does not carry, a news server
> may accept such an article and file it under this catch-all "junk"
> newsgroup.
>
> Depending on the configuration of the news server, mentioning a
> newsgroup with status "j" is different than simply not listing the
> group, since articles arriving in unknown newsgroups may be
> rejected.
>
> The difference between a newsgroup with status "n" and a newsgroup
> with status "x" is that articles from peers are accepted for the
> former, and rejected for the latter. A newsgroup with status "x" is
> considered as closed: no new articles will arrive in such a group.
> On the contrary, articles from peers will arrive in a newsgroup with
> status "n". Local postings are not allowed in a newsgroup with one
> of these two status.
Note: Pseudogroups "control"/"control.*", "junk", and "to", even when
marked with "x", may have articles filed that meet their special criteria.
As we have mentioned the "junk" group above, it is important to repeat that
its status of "x" will still permit unfiled articles to be filed to it.
Marking "junk" with an "x" will only block articles explicitly posted to
it, not unfiled articles filed to it.
> When the status field begins with an equal sign ("=" or %x3D), the
> name of an existing newsgroup on the news server MUST immediately
> follow the sign. If the status field of "foo.bar" is "=other.group",
> it means that "foo.bar" is an alias for "other.group". These two
> newsgroups are distinct; they do not share their articles or their
> article numbers. Local postings to "foo.bar" are not allowed, but
> articles from peers are accepted for "foo.bar" and filed into
> "other.group", whatever the status of "other.group" is. The contents
> of their Newsgroups headers MUST NOT be altered.
...or %x3D...: I would delete that. We don't encode hexidecmal values in
a "LIST ACTIVE" output.
"whatever the status of 'other.group' is.": "regardless of the status of
'other.group'." looks better.
> Alias groups are typically used during a transition between two
> newsgroups.
..., including but not limited to a renaming of a group, or a correction
of a misspelled group name. (cf. "alt.*" hierarchy).
> An alias MUST NOT point to another alias group. The newsgroup an
> alias points to SHOULD exist on the news server. If an alias is
> listed in the active list, the newsgroup it points to is not also
> listed in the active list when a wildmat is given to the LIST ACTIVE
> command, and the name of the newsgroup the alias points to does not
> match this wildmat.
The newsgroup an alias points to MUST exist on the news server.
If it doesn't exist, how's the redirected article going to be filed? It
won't be; an error results.
My patch will not list the aliases (those with a "=" flag) for "LIST
ACTIVE", so I don't have to check to see if the canonical (target) group
exists.
> The following table summarizes what usually happens to an article
> posted to only the newsgroup "foo.bar", depending on its status field
> on the news server:
>
> +--------------+-----------+------------+------------+--------------+
> | Status field | Accepted | Accepted | Moderation | Destination |
> | of "foo.bar" | if local | from | needed? | if accepted? |
> | | posting? | peers? | | |
> +--------------+-----------+------------+------------+--------------+
> | y | Yes | Yes | No | foo.bar |
> | n | No | Yes | No | foo.bar |
> | m | Yes | Yes | Yes | foo.bar |
> | l | Yes | No | No | foo.bar |
yl
> | lm | Yes | No | Yes | foo.bar |
ml
> | j | Yes | Yes | No | junk (if |
NO!
> | | | | | filed) |
> | x | No | No | No | |
> | =other.group | No | Yes | No | other.group |
> +--------------+-----------+------------+------------+--------------+
>
> NOTE: If a server files newsgroups with status "j" into "junk", a
> newsgroup with status "j" and a newsgroup with status "=junk" are
> different. For instance, a local posting to only the former will
> be accepted and filed into "junk" whereas a local posting to only
> the latter will not be accepted.
The latter form may cause cross-posted articles from peers with the "junk"
group, while the former will not.
... unless authentication makes no difference to the group's posting
status.
Suggested change from above: "l" -> "yl", and "lm" -> "ml".
Julien ÉLIE
>> "l" Only local posting is permitted.
>
> I don't like this. The local-permitting system should have a "y" and other
> servers an "n".
The reason why I suggest to standardize "l" and "lm" (or "yl" and "ml")
is because I believe we have a hole when we look at the table explaining
how articles are treated with "y", "n", "m", "j", "x", and "=".
I thought it might be useful to have that local status.
It is more homogeneous.
>> "j" Posting is permitted but no articles are locally filed.
>
> Isolated posting is PROHIBITED
How could we standardize that isolated posting is PROHIBITED when all versions
of INN have always ALLOWED that? Even INN 1.0 explicitly allowed that.
(Just checked on <ftp://ftp.isc.org/isc/inn/OLD/>).
case 'j':
/* Do NOT return an error. */
break;
> That's why my recent patch screens OUT "j" groups
> from the "LIST ACTIVE" output (as well as "=" groups). They don't
> locally exist.
They do exist. If you rename a newsgroup ("group.old" with status "=group.new"),
then "group.old" would suddenly disappear, and readers would not be able to
see the messages in this group which in fact still exists.
Same thing for "j" groups.
> If you disagree with my comments regarding "L" (I use the capital because
> in some fonts, the lower case "l" and "1", the digit, look identical), I
> then also suggest that it appear as a SUFFIX: "yl" and "ml".
It is also what I initially thought but having "yl" and "ml" without also
having "nl" does not contribute to the beauty and harmony of the syntax :-)
In fact, "x" is exactly "nl".
"l" would mean "articles from peers not accepted".
But it is unfortunately too late right now to change "x"!
> For INN: Doesn't the screening of groups ("patterns") in
> "{pathetc}/incoming.conf" and a choice of patterns fed from peers generally
> take care of the same function as "L"?
Yes. The only disadvantage is that it adds a bit of overhead here (we check
the patterns one more time).
I do not know whether other news servers have similar facilities. So maybe
they could use "yl" or similar.
>> The difference between a newsgroup with status "y" and a newsgroup
>> with status "j" is that articles are filed into the corresponding
>> newsgroup for the former, and not filed at all for the latter. If an
>
> ...not filed LOCALLY for the latter.
OK, thanks.
> An article locally posted only to "j"-marked groups will NOT be propagated
> to other peers.
Why?
What if the "junk" group is fed? or "j"-marked groups?
>> NOTE: Instead of not filing at all an article posted to a
>> newsgroup with status "j", a news server MAY file it under a
>> catch-all group. When a news server uses a catch-all group to
>> file the articles posted to newsgroups with status "j", this
>> catch-all group SHOULD be named "junk". (The first letter of the
>> "junk" newsgroup explains why this status has been called "j".)
>
> ..., this catch-all group has historically been named "junk".
>
> I don't think that we should fix the name of the junk group in an RFC. All
> that we need require is that its name not clash with any currently defined
> newsgroup. We may say in the RFC that historically, the name of such a
> group is "junk", but we need not enforce this.
Readers might expect that name (?)
What if we put a lowercase "should" here?
USEAGE might want to add more precisions afterwards.
>> Consequently, when a news server carries the "junk" newsgroup and
>> uses it for the purpose of the "j" status, the "junk" newsgroup
>> contains all the postings which cannot file under a newsgroup
>
> ...contains all postings not filed under another newsgroup, ...
Adopted.
>> name, whatever the status of the "junk" newsgroup is. (However,
>> an article posted explicitly to "junk" is treated according to the
>> status of the "junk" newsgroup.)
>
> I do agree with the above "however", but we could also say that postings
> explicitly to "junk" should not be permitted. Granted, I mark my junk
> group with an "x" flag so the result is the same, but that's because I have
> locally chosen such. Should posting explicitly to the "junk" newsgroup
> ever be permitted?
I do not think we should define that right in this memo. As you say, it is
a local decision made by the news administrator. It is up to him to put
the flags he wishes on "junk", "control", etc.
USEAGE might want to add precisions about that.
(A link to the current USEAGE draft is available from
<http://www.eyrie.org/~eagle/usefor/>).
>> The difference between a newsgroup with status "n" and a newsgroup
>> with status "x" is that articles from peers are accepted for the
>> former, and rejected for the latter. A newsgroup with status "x" is
>> considered as closed: no new articles will arrive in such a group.
>> On the contrary, articles from peers will arrive in a newsgroup with
>> status "n". Local postings are not allowed in a newsgroup with one
>> of these two status.
>
> Note: Pseudogroups "control"/"control.*", "junk", and "to", even when
> marked with "x", may have articles filed that meet their special criteria.
> As we have mentioned the "junk" group above, it is important to repeat that
> its status of "x" will still permit unfiled articles to be filed to it.
> Marking "junk" with an "x" will only block articles explicitly posted to
> it, not unfiled articles filed to it.
It has already been written when defining how "junk" works:
Consequently, when a news server carries the "junk" newsgroup and
uses it for the purpose of the "j" status, the "junk" newsgroup
contains all postings not filed under another newsgroup, whatever
the status of the "junk" newsgroup is. (However, an article posted
explicitly to "junk" is treated according to the status of the "junk"
newsgroup.)
Why repeat that paragraph which is 10 lines above?
>> When the status field begins with an equal sign ("=" or %x3D),
>
> ...or %x3D...: I would delete that. We don't encode hexadecmal values in
> a "LIST ACTIVE" output.
In RFC 3977, we have a similar wording:
If any line of the data block begins with the "termination octet"
("." or %x2E),
If you look at the ABNF syntax below, only "=" is allowed.
> "whatever the status of 'other.group' is.": "regardless of the status of
> 'other.group'." looks better.
Adopted.
>> Alias groups are typically used during a transition between two
>> newsgroups.
>
> ..., including but not limited to a renaming of a group, or a correction
> of a misspelled group name. (cf. "alt.*" hierarchy).
OK, added.
>> An alias MUST NOT point to another alias group. The newsgroup an
>> alias points to SHOULD exist on the news server. If an alias is
>> listed in the active list, the newsgroup it points to is not also
>> listed in the active list when a wildmat is given to the LIST ACTIVE
>> command, and the name of the newsgroup the alias points to does not
>> match this wildmat.
>
> The newsgroup an alias points to MUST exist on the news server.
>
> If it doesn't exist, how's the redirected article going to be filed? It
> won't be; an error results.
I don't know. I just believe MUST is too strong. It the alias does
not exist, then we send a reject for the article (if of course the article
was not crossposted to another valid newsgroup).
I also have doubts on "An alias MUST NOT point to another alias group."
Maybe SHOULD NOT would be better.
It is not an error, because the operation is not recursive.
In the same order of idea, "a =b" and "b =a" SHOULD NOT exist. But it
would work.
Thanks again for your corrections. I have already merged them in my
current version of the proposal.
--
Julien �LIE
� Quand tu auras lu ces lignes, le papyrus s'autod�truira. � (Ast�rix)
D. Stussy
> Hi D. Stussy,
>
> >> "l" Only local posting is permitted.
> >
> > I don't like this. The local-permitting system should have a "y" and
other
> > servers an "n".
>
> The reason why I suggest to standardize "l" and "lm" (or "yl" and "ml")
> is because I believe we have a hole when we look at the table explaining
> how articles are treated with "y", "n", "m", "j", "x", and "=".
>
> I thought it might be useful to have that local status.
> It is more homogeneous.
Ok, but I still don't really like it. A group will be local when incoming
is blocked and it is absent (or excluded/poisoned) from outbound feeds.
Those operations seem to have nothing to do with whether a client can post
to it. I see what you're trying to say with the L flag, but posting and
propagation are separate operations in my view.
> >> "j" Posting is permitted but no articles are locally filed.
> >
> > Isolated posting is PROHIBITED
>
> How could we standardize that isolated posting is PROHIBITED when all
versions
> of INN have always ALLOWED that? Even INN 1.0 explicitly allowed that.
> (Just checked on <ftp://ftp.isc.org/isc/inn/OLD/>).
>
> case 'j':
> /* Do NOT return an error. */
> break;
Well, when I tried to post to such, I did get an error. However, the error
could have been from my client as it doesn't see a group so marked in the
LIST ACTIVE output it saves. Excluding "j"-marked groups from the server's
output was sufficient.
If "j" means that the group is a passthrough only and not locally carried,
there isn't a local group to post to, so it logically should be
prohibited -- just as if the group didn't exist at all.
> > That's why my recent patch screens OUT "j" groups
> > from the "LIST ACTIVE" output (as well as "=" groups). They don't
> > locally exist.
>
> They do exist. If you rename a newsgroup ("group.old" with status
"=group.new"),
> then "group.old" would suddenly disappear, and readers would not be able
to
> see the messages in this group which in fact still exists.
>
> Same thing for "j" groups.
Only when the client's reader updates the group's status. My reader
program doesn't do that automatically. It's done only when I tell it to
refresh the group list.
> > If you disagree with my comments regarding "L" (I use the capital
because
> > in some fonts, the lower case "l" and "1", the digit, look identical),
I
> > then also suggest that it appear as a SUFFIX: "yl" and "ml".
>
> It is also what I initially thought but having "yl" and "ml" without also
> having "nl" does not contribute to the beauty and harmony of the syntax
:-)
> In fact, "x" is exactly "nl".
> "l" would mean "articles from peers not accepted".
>
> But it is unfortunately too late right now to change "x"!
See above: Posting vs. propagation.
> > For INN: Doesn't the screening of groups ("patterns") in
> > "{pathetc}/incoming.conf" and a choice of patterns fed from peers
generally
> > take care of the same function as "L"?
>
> Yes. The only disadvantage is that it adds a bit of overhead here (we
check
> the patterns one more time).
> I do not know whether other news servers have similar facilities. So
maybe
> they could use "yl" or similar.
>
> >> The difference between a newsgroup with status "y" and a newsgroup
> >> with status "j" is that articles are filed into the corresponding
> >> newsgroup for the former, and not filed at all for the latter. If
an
> >
> > ...not filed LOCALLY for the latter.
>
> OK, thanks.
>
> > An article locally posted only to "j"-marked groups will NOT be
propagated
> > to other peers.
>
> Why?
> What if the "junk" group is fed? or "j"-marked groups?
The group is a passthrough only. It doesn't "locally exist." Therefore,
it's inappropriate to accept articles posted locally to it (filed
anywhere). It still has to be in the active file to be accepted from peers
so it may be passed on. "j"-groups cannot be read by clients (if they need
to read it, they read "junk").
Read: No
Post: No
Peer: Yes, via the "junk" pseudogroup.
Allowing a server to accept an article posted to groups all of which it
doesn't carry seems to be a perfect tool for a Usenet spammer.
To accept a local posting, the server must visibly carry at least one group
in the Newsgroups header data. "j"-groups are always empty, and therefore
don't [visibly] exist for clients. They exist [in a virtual manner, via
"junk",] only for peers.
> >> NOTE: Instead of not filing at all an article posted to a
> >> newsgroup with status "j", a news server MAY file it under a
> >> catch-all group. When a news server uses a catch-all group to
> >> file the articles posted to newsgroups with status "j", this
> >> catch-all group SHOULD be named "junk". (The first letter of
the
> >> "junk" newsgroup explains why this status has been called "j".)
> >
> > ..., this catch-all group has historically been named "junk".
> >
> > I don't think that we should fix the name of the junk group in an RFC.
All
> > that we need require is that its name not clash with any currently
defined
> > newsgroup. We may say in the RFC that historically, the name of such a
> > group is "junk", but we need not enforce this.
>
> Readers might expect that name (?)
>
> What if we put a lowercase "should" here?
> USEAGE might want to add more precisions afterwards.
I don't see any expectations by reader programs as to any group names.
By saying "historically", I have suggested that it continue to be called
that, but again, not mandated a requirement. As I said, as long as it
doesn't collide with another group, the precise name used doesn't matter
and may even be changed in the future without consequence.
> >> Consequently, when a news server carries the "junk" newsgroup
and
> >> uses it for the purpose of the "j" status, the "junk" newsgroup
> >> contains all the postings which cannot file under a newsgroup
> >
> > ...contains all postings not filed under another newsgroup, ...
>
> Adopted.
>
> >> name, whatever the status of the "junk" newsgroup is. (However,
> >> an article posted explicitly to "junk" is treated according to
the
> >> status of the "junk" newsgroup.)
> >
> > I do agree with the above "however", but we could also say that
postings
> > explicitly to "junk" should not be permitted. Granted, I mark my junk
> > group with an "x" flag so the result is the same, but that's because I
have
> > locally chosen such. Should posting explicitly to the "junk" newsgroup
> > ever be permitted?
>
> I do not think we should define that right in this memo. As you say, it
is
> a local decision made by the news administrator. It is up to him to put
> the flags he wishes on "junk", "control", etc.
I yield on this point. I was simply asking a question.
Because such isn't specific to only the junk group. It applies to all the
pseudogroups INN uses.
> >> When the status field begins with an equal sign ("=" or %x3D),
> >
> > ...or %x3D...: I would delete that. We don't encode hexadecmal values
in
> > a "LIST ACTIVE" output.
>
> In RFC 3977, we have a similar wording:
>
> If any line of the data block begins with the "termination octet"
> ("." or %x2E),
>
> If you look at the ABNF syntax below, only "=" is allowed.
Noted, but as we named the character, we need not give its ASCII/UTF-8
value (in case someone implements with a different character set). Long
live EBCDIC! ;-)
Julien ÉLIE
I have just tried to write you an e-mail but your server
rejected it:
spammers_executed_here
550 5.7.1 Relay host 91.121.30.210 is listed at DNSBL ubl.unsubscore.com
>> "j" Posting is permitted but no articles are locally filed.
>
> Isolated posting is PROHIBITED: The group "does not exist" as far as the
> local server is concerned. Cross-posting (with a carried group) may occur
> but no article is locally filed to the "j"-marked group. The group is
> listed in the active file (INN) only for the purpose of passing the group
> through to other peers.
I have just asked in inn-workers@:
https://lists.isc.org/pipermail/inn-workers/2009-November/017000.html
--
Julien �LIE
� Les femmes pardonnent parfois � celui qui brusque l'occasion,
mais jamais � celui qui la manque. � (Talleyrand)
D. Stussy
> Hi D. Stussy,
>
> I have just tried to write you an e-mail but your server
> rejected it:
> spammers_executed_here
> 550 5.7.1 Relay host 91.121.30.210 is listed at DNSBL ubl.unsubscore.com
See http://www.lashback.com/support/UnsubscribeBlacklistSupport.aspx
(I've submitted a de-listing request on your behalf. It may take 1 hour.)
> >> "j" Posting is permitted but no articles are locally filed.
> >
> > Isolated posting is PROHIBITED: The group "does not exist" as far as
the
> > local server is concerned. Cross-posting (with a carried group) may
occur
> > but no article is locally filed to the "j"-marked group. The group is
> > listed in the active file (INN) only for the purpose of passing the
group
> > through to other peers.
>
> I have just asked in inn-workers@:
> https://lists.isc.org/pipermail/inn-workers/2009-November/017000.html
Noted, reviewed, and you have properly reflected my comments on the matter.
Julien ÉLIE
> See http://www.lashback.com/support/UnsubscribeBlacklistSupport.aspx
> (I've submitted a de-listing request on your behalf. It may take 1 hour.)
Thanks!
>> I have just asked in inn-workers@:
>> https://lists.isc.org/pipermail/inn-workers/2009-November/017000.html
>
> Noted, reviewed, and you have properly reflected my comments on the matter.
That's great, then!
Have a nice week,
--
Julien �LIE
� Those who do not understand Unix are condemned to reinvent it,
poorly. � (Henry Spencer)
Julien ÉLIE
[answering to myself:]
>> The reason why I suggest to standardize "l" and "lm" (or "yl" and "ml")
>> is because I believe we have a hole when we look at the table explaining
>> how articles are treated with "y", "n", "m", "j", "x", and "=".
>>
>> I thought it might be useful to have that local status.
>> It is more homogeneous.
The main problem is the fact that implementations usually read the first char
and we need at least to mention that a local group is moderated.
Maybe "Y" and "M" (upper case) would be better, as the status is
case-sensitive.
> Those operations seem to have nothing to do with whether a client can post
> to it. I see what you're trying to say with the L flag, but posting and
> propagation are separate operations in my view.
RFC 3977:
6.3. Article Posting
Article posting is done in one of two ways: individual article
posting from news-reading clients using POST, and article transfer
from other news servers using IHAVE.
Propagation is also posting.
Note that if the flag "Y" is advertised by A, it is not used so as to
rule the propagation A->B. It is used only for propagation B->A.
B can see (with LIST ACTIVE) that a newsgroups has status "Y". It is
an information A gives. And A rejects articles received from B.
It is the same for other flags: A rejects articles received from B
for "x" groups.
> "j"-groups cannot be read by clients (if they need
> to read it, they read "junk").
>
> Read: No
> Post: No
> Peer: Yes, via the "junk" pseudogroup.
I believe it is the behaviour I will finally document for "j" groups.
>> It has already been written when defining how "junk" works:
>>
>> Consequently, when a news server carries the "junk" newsgroup and
>> uses it for the purpose of the "j" status, the "junk" newsgroup
>> contains all postings not filed under another newsgroup, whatever
>> the status of the "junk" newsgroup is. (However, an article posted
>> explicitly to "junk" is treated according to the status of the "junk"
>> newsgroup.)
>>
>> Why repeat that paragraph which is 10 lines above?
>
> Because such isn't specific to only the junk group. It applies to all
> the pseudogroups INN uses.
We do not document INN's pseudogroups here. "control" or "to" are unknown
in RFC 3977.
>> If any line of the data block begins with the "termination octet"
>> ("." or %x2E),
>>
>
> Noted, but as we named the character, we need not give its ASCII/UTF-8
> value (in case someone implements with a different character set). Long
> live EBCDIC! ;-)
I missed a comment written in RFC 3977:
(that is, the octets
with those codes in US-ASCII [ANSI1986] and thus in UTF-8 [RFC3629])
I should mention it in the introduction of my proposal.
--
Julien �LIE
� Prolonger les adieux ne vaut jamais grand-chose ;
ce n'est pas la pr�sence que l'on prolonge, mais le d�part. � (Bibesco)
D. Stussy
> [answering to myself:]
> >> The reason why I suggest to standardize "l" and "lm" (or "yl" and
"ml")
> >> is because I believe we have a hole when we look at the table
explaining
> >> how articles are treated with "y", "n", "m", "j", "x", and "=".
> >>
> >> I thought it might be useful to have that local status.
> >> It is more homogeneous.
>
> The main problem is the fact that implementations usually read the first
char
> and we need at least to mention that a local group is moderated.
> Maybe "Y" and "M" (upper case) would be better, as the status is
> case-sensitive.
>
> > Those operations seem to have nothing to do with whether a client can
post
> > to it. I see what you're trying to say with the L flag, but posting
and
> > propagation are separate operations in my view.
>
> RFC 3977:
>
> 6.3. Article Posting
>
> Article posting is done in one of two ways: individual article
> posting from news-reading clients using POST, and article transfer
> from other news servers using IHAVE.
>
> Propagation is also posting.
In the sense of "remote posting," OK. However, I think of posting as
initial injection.
> Note that if the flag "Y" is advertised by A, it is not used so as to
> rule the propagation A->B. It is used only for propagation B->A.
> B can see (with LIST ACTIVE) that a newsgroups has status "Y". It is
> an information A gives. And A rejects articles received from B.
>
> It is the same for other flags: A rejects articles received from B
> for "x" groups.
>
> > "j"-groups cannot be read by clients (if they need
> > to read it, they read "junk").
> >
> > Read: No
> > Post: No
> > Peer: Yes, via the "junk" pseudogroup.
>
> I believe it is the behaviour I will finally document for "j" groups.
Note: From the "active(5)" manual page:
"If a newsgroup has the 'j' flag, no articles will be filed in that
newsgroup, and local postings to that group will be rejected...."
> >> It has already been written when defining how "junk" works:
> >>
> >> Consequently, when a news server carries the "junk" newsgroup and
> >> uses it for the purpose of the "j" status, the "junk" newsgroup
> >> contains all postings not filed under another newsgroup, whatever
> >> the status of the "junk" newsgroup is. (However, an article posted
> >> explicitly to "junk" is treated according to the status of the "junk"
> >> newsgroup.)
> >>
> >> Why repeat that paragraph which is 10 lines above?
> >
> > Because such isn't specific to only the junk group. It applies to all
> > the pseudogroups INN uses.
>
> We do not document INN's pseudogroups here. "control" or "to" are
unknown
> in RFC 3977.
True, but as pseudogroups may exist, we should't close this off either.
Julien ÉLIE
> My patch presents "x" groups in the "LIST ACTIVE" output only when the
> highmark is not zero (i.e. something, sometime, was posted to the group).
> Otherwise, they are NOT included and therefore not presented to the client.
> Again, empty overview files are not created for them (at initialization).
[...]
> That's why my recent patch screens OUT "j" groups
> from the "LIST ACTIVE" output (as well as "=" groups).
Please note that it violates a MUST in RFC 3977:
7.6.3. LIST ACTIVE
LIST ACTIVE returns a list of valid newsgroups and associated
information. If no wildmat is specified, the server MUST include
every group that the client is permitted to select with the GROUP
command (Section 6.1.1).
Groups whose status is "j", "x" or "=" can be selected with GROUP. So you
will also have to remove that possibility to users.
Yet, as you already know, I reckon that LIST ACTIVE should output "j", "x"
and "=" groups. We should not conceal information this way to users.
--
Julien �LIE
� Love isn't all smiles and laughs for the moment;
but crying and fighting for what you believe is right
and will last forever. �