Readers behaviour with newsgroups status
Julien ÉLIE
When a news reader sends a LIST ACTIVE command, it receives a status flag
for each newsgroup.
For instance "y" if posting is permitted and "n" if it is not permitted.
I wonder whether news readers usually implement something to warn
the user when posting is probably not allowed (so that to prevent
him from writing his message).
If that is the case, can the user bypass the warning?
And when is the LIST ACTIVE sent?
Before any MODE READER command (in transit mode)? Just after MODE READER
(reader mode, on a mode-switching news server)? After authentication?
As a matter of fact, the status flag of a newsgroup may change
when a reader authenticates himself ("n"->"y" after successful AUTHINFO).
Furthermore, it is currently possible that "n" is advertised though
the client can post to a newsgroup...
Should a news server worry about that and try to do its best not
to use "n"? (that is to say advertise "y" on most cases, and "n"/"x"
only if the news server knows for sure that the user will never be able
to post to such "n"/"x" groups)
--
Julien ï¿œLIE
ￜ Les idￜes fausses ne sont pas toujours mauvaises. ￜ (Marcel Aymￜ)
Russ Allbery
> I wonder whether news readers usually implement something to warn
> the user when posting is probably not allowed (so that to prevent
> him from writing his message).
> If that is the case, can the user bypass the warning?
trn did. It would show "moderated" or "no posting" (something like that)
next to the group while you were reading it if it had one of those flags,
and IIRC Pnews had a warning when trying to post to those groups. (It's
been a while since I used it, though.)
I'm pretty sure that you could continue anyway if you wanted to, though.
> And when is the LIST ACTIVE sent?
> Before any MODE READER command (in transit mode)? Just after MODE READER
> (reader mode, on a mode-switching news server)? After authentication?
Pnews would do a LIST ACTIVE and LIST NEWSGROUPS before posting, I think.
I'm not sure when trn did its own, although I'm sure it was after MODE
READER.
--
Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>
Please post questions rather than mailing me directly.
<http://www.eyrie.org/~eagle/faqs/questions.html> explains why.
Bert Hyman
=?ISO-8859-15?Q?Julien_=C9LIE?= <iul...@nom-de-mon-site.com.invalid>
wrote:
> And when is the LIST ACTIVE sent?
> Before any MODE READER command (in transit mode)? Just after MODE
> READER (reader mode, on a mode-switching news server)? After
> authentication?
Since a "list active" on most servers will return a lot of data, most
news clients will only send that command when the user explicitly asks
it to.
--
Bert Hyman St. Paul, MN be...@iphouse.com
D. Stussy
news:87fx8i7...@windlord.stanford.edu...
> Julien �LIE <iul...@nom-de-mon-site.com.invalid> writes:
> > I wonder whether news readers usually implement something to warn
> > the user when posting is probably not allowed (so that to prevent
> > him from writing his message).
> > If that is the case, can the user bypass the warning?
>
> trn did. It would show "moderated" or "no posting" (something like that)
> next to the group while you were reading it if it had one of those flags,
> and IIRC Pnews had a warning when trying to post to those groups. (It's
> been a while since I used it, though.)
Micro$oft's Outlook Express seems to show "moderated" or "blocked" based on
the group's flags on the status bar showing the currently selected group -
on the right side of the bar.
> I'm pretty sure that you could continue anyway if you wanted to, though.
>
> > And when is the LIST ACTIVE sent?
> > Before any MODE READER command (in transit mode)? Just after MODE
READER
> > (reader mode, on a mode-switching news server)? After authentication?
>
> Pnews would do a LIST ACTIVE and LIST NEWSGROUPS before posting, I think.
> I'm not sure when trn did its own, although I'm sure it was after MODE
> READER.
OE has the ability to log NNTP commands, so I leave it to the loggers to
discover.
Julien ÉLIE
>> And when is the LIST ACTIVE sent?
>> Before any MODE READER command (in transit mode)? Just after MODE
>> READER (reader mode, on a mode-switching news server)? After
>> authentication?
>
> Since a "list active" on most servers will return a lot of data, most
> news clients will only send that command when the user explicitly asks
> it to.
Then we can consider this discussion with "LIST ACTIVE a.newsgroup.name",
sent for every newsgroup the user has subscribed.
--
Julien �LIE
� On me tape dessus � tout bout de chant... � (Ast�rix)
Julien ÉLIE
>> I wonder whether news readers usually implement something to warn
>> the user when posting is probably not allowed (so that to prevent
>> him from writing his message).
>
> tin does, so postings (n/x) groups are shown with an "X", moderated groups
> with an "M", aliased ones with an = (and the status bar mentions the
> target), junk and normal groups do not get any specical flag.
Interesting, thanks!
When the group an alias points to does not allow postings ("X"), is it
also properly seen? Because it is useless to write there if
postings are not allowed. It requires to send the relevant LIST ACTIVE
command for it.
>> If that is the case, can the user bypass the warning?
>
> no (but he could start to write a posting in a different group and edit
> the newsgroups header).
A bit of gymnastic, then, for the user.
>> And when is the LIST ACTIVE sent?
>> After authentication?
>
> depends when the server requests auth, if tin is forced to auth
> without seeing 480 on the servers side it is send rigt after
> CAPABILITIES, otherwise auth is send whenever needed, wich might be
> after LIST ACTIVE.
OK.
>> Furthermore, it is currently possible that "n" is advertised though
>> the client can post to a newsgroup...
>> Should a news server worry about that and try to do its best not
>> to use "n"? (that is to say advertise "y" on most cases, and "n"/"x"
>> only if the news server knows for sure that the user will never be able
>> to post to such "n"/"x" groups)
>
> the flag should be correct.
The fact is that we can have the following thing (at least with INN,
see the access: parameter in readers.conf
<http://www.eyrie.org/~eagle/software/inn/docs/readers.conf.html>):
* read access for fr.test and misc.test for all unauthenticated users;
* read access for fr.test and read&post access for misc.test for
user A;
* read&post access for fr.test and misc.test for user B.
Where fr.test is status "n" and misc.test is status "y".
User B has the "L" (local post) access right in readers.conf.
I believe it is correct to send "y" for misc.test even for
unauthenticated users.
But should we send "y" or "n" for fr.test to unauthenticated users?
(considering the fact that if it is "y" just after the authentication
of user B, he will probably not see the change)
Maybe the choice between "y" and "n" should be done the same way
as 200/201 is chosen for the initial greeting?
(I'm writing a draft to try to standardize "x", "j", and alias groups.
My question here was originally more an INN implementation issue but
it appears that the problem is broader after second thought; I will
mention it in the draft.)
--
Julien �LIE
� C'est tout un art que de parvenir � couper un g�teau de telle sorte
que chacun croit en avoir eu la plus grosse part. �
Russ Allbery
> The fact is that we can have the following thing (at least with INN,
> see the access: parameter in readers.conf
> <http://www.eyrie.org/~eagle/software/inn/docs/readers.conf.html>):
> * read access for fr.test and misc.test for all unauthenticated users;
> * read access for fr.test and read&post access for misc.test for
> user A;
> * read&post access for fr.test and misc.test for user B.
> Where fr.test is status "n" and misc.test is status "y".
> User B has the "L" (local post) access right in readers.conf.
The "L" local post access right is an explicit override, letting the user
do something that one normally would not expect to be able to do. In that
sort of a case, I'm not sure it matters *too* much if we make the data
that user sees consistent. It's a bit outside the protocol somewhat by
definition, and is generally only used with users who have special
capabilities anyway.
I think it may be too complex to do the fully correct thing here, since
the logic of whether or not someone might have local post access could get
rather complicated (and in the presence of Perl or Python access hooks,
may be impossible for nnrpd to determine). We'd end up having to show a
flag of "y" for all "n" groups just in case someone has local post rights
in order to be sure of not getting it wrong.
Julien ÉLIE
> The "L" local post access right is an explicit override, letting the user
> do something that one normally would not expect to be able to do. In that
> sort of a case, I'm not sure it matters *too* much if we make the data
> that user sees consistent. It's a bit outside the protocol somewhat by
> definition, and is generally only used with users who have special
> capabilities anyway.
Yep, it bypasses what is specified in the protocol. (A bit like the
possibility a user has to advertise overview fields his server is not
consistent with.)
So we may leave "n" as is.
> I think it may be too complex to do the fully correct thing here, since
> the logic of whether or not someone might have local post access could get
> rather complicated (and in the presence of Perl or Python access hooks,
> may be impossible for nnrpd to determine).
I was just suggesting to do the same thing we currently do for 200/201.
The only difference would be that we look for "L" and not "P".
nnrpd returns 200 even though a Perl or Python hook refuses everything;
nnrpd returns 200 even though there is "post: news.group.not.carried"
or "post: !*". Better advertise more rights (200) than less (201).
> We'd end up having to show a
> flag of "y" for all "n" groups just in case someone has local post rights
> in order to be sure of not getting it wrong.
Yes, and only if using AUTHINFO the user may obtain these rights. That is
to say if he can have the corresponding access block.
For instance, if "L" is given only for connections coming from "localhost",
a normal user will not see "y".
However, as you suggest, it is maybe pointless having these special cases
for an explicit an unusual override made by the news administrator.
And we can advertise "n" for all users, then "y" for the authenticated
user with local post rights. At least for him to get it right.
It is up to the news client to send LIST ACTIVE at the right moment :-)
RFC 3977 only mentions:
The status of a newsgroup only indicates how posts to that newsgroup
are normally processed and is not necessarily customised to the
specific client. For example, if the current client is forbidden
from posting, then this will apply equally to groups with status "y".
Conversely, a client with special privileges (not defined by this
specification) might be able to post to a group with status "n".
We do not know if it is meant to work like 200/201 or reflect the rights
at the current state of the connection.
--
Julien ÉLIE
« C'est tout un art que de parvenir à couper un gâteau de telle sorte
que chacun croit en avoir eu la plus grosse part. »
Russ Allbery
> RFC 3977 only mentions:
> The status of a newsgroup only indicates how posts to that newsgroup
> are normally processed and is not necessarily customised to the
> specific client. For example, if the current client is forbidden
> from posting, then this will apply equally to groups with status "y".
> Conversely, a client with special privileges (not defined by this
> specification) might be able to post to a group with status "n".
> We do not know if it is meant to work like 200/201 or reflect the rights
> at the current state of the connection.
This was intended to permit continuing to advertise "n" even if the user
could actually post because of local posting rights.
Russ Allbery
> it's also useless to setup an aliasgroup where the target is no
> posting. in that case one can simply remove the old group as there will
> be no more (local) posts to it.
It still routes new incoming messages for the alias group from other
servers into the group to which it's aliased, which is permitted even if
the group is marked no local posting.
> the server knows what the falg should be for the given user in the
> current state and should return the correct flag. if user has some read
> access but some write access only after auth it's up to the user/client
> to auth at the beginning. so there is no need to return diffent flags
> for the same group in the same connection.
Ah, yes, that would work too.
>> But should we send "y" or "n" for fr.test to unauthenticated users?
> when it's not clear, send 'y' and let the client handle the "posting not
> allowed" return code upon post later on.
I suppose I don't object to this either, since local posting rights are
rare in any case, but I suspect this will mean we'll mark a lot of groups
'y' that are actually 'n' on a typical server that allows local posting
only to authenticated admins.
> this all wouldn't be an issue if GROUP would return the current flag
> ,-)
Yes. :)
D. Stussy
news:hdm6lp$3n4$1...@news.trigofacile.com...
> >> I wonder whether news readers usually implement something to warn
> >> the user when posting is probably not allowed (so that to prevent
> >> him from writing his message).
> >
> > tin does, so postings (n/x) groups are shown with an "X", moderated
groups
> > with an "M", aliased ones with an = (and the status bar mentions the
> > target), junk and normal groups do not get any specical flag.
>
> Interesting, thanks!
> When the group an alias points to does not allow postings ("X"), is it
> also properly seen? Because it is useless to write there if
> postings are not allowed. It requires to send the relevant LIST ACTIVE
> command for it.
No, nor do I see a reason why it would be checked. The "=" operator is not
recursive. It says to file articles for group1 (LHS) into group 2 (RHS),
not to treat group 1 as if it were group 2. Articles for group1 are
blindly filed into group2, regardless of group 2's status.
> >> Furthermore, it is currently possible that "n" is advertised though
> >> the client can post to a newsgroup...
> >> Should a news server worry about that and try to do its best not
> >> to use "n"? (that is to say advertise "y" on most cases, and "n"/"x"
> >> only if the news server knows for sure that the user will never be
able
> >> to post to such "n"/"x" groups)
> >
> > the flag should be correct.
>
> The fact is that we can have the following thing (at least with INN,
> see the access: parameter in readers.conf
> <http://www.eyrie.org/~eagle/software/inn/docs/readers.conf.html>):
>
> * read access for fr.test and misc.test for all unauthenticated users;
> * read access for fr.test and read&post access for misc.test for
> user A;
> * read&post access for fr.test and misc.test for user B.
>
> Where fr.test is status "n" and misc.test is status "y".
> User B has the "L" (local post) access right in readers.conf.
>
> I believe it is correct to send "y" for misc.test even for
> unauthenticated users.
> But should we send "y" or "n" for fr.test to unauthenticated users?
> (considering the fact that if it is "y" just after the authentication
> of user B, he will probably not see the change)
>
>
> Maybe the choice between "y" and "n" should be done the same way
> as 200/201 is chosen for the initial greeting?
"n" should be used for groups that accept external (i.e. peered) articles
but not local articles. Such uses are for:
1) ONE-WAY gated mailing lists, where NNTP->SMTP is not permitted, and
2) Special purpose (e.g. "nocem") groups where information originates from
a single point (or a few, limited points) but is meant to be distributed to
all. Of course, at the actual distribution points, the group would be
flagged with "y" or "m" instead of "n".
> (I'm writing a draft to try to standardize "x", "j", and alias groups.
> My question here was originally more an INN implementation issue but
> it appears that the problem is broader after second thought; I will
> mention it in the draft.)
Note that "j" and "=junk" are NOT equivalent operations for cross-posted
articles.
Note that "junk", "control"/"control.*", and "to" (when mergetogroups=TRUE)
work properly (under INN 2.5.1) even when marked with "x". Marking them
with "x" does prevent propagation of articles posted explicitly to such
named groups, yet articles can still be filed there if they meet the
special criterion of each special pseudogroup.
Jeffrey M. Vinocur
Julien � LIE <iul...@nom-de-mon-site.com.invalid> wrote:
>
>RFC 3977 only mentions:
>
> The status of a newsgroup only indicates how posts to that newsgroup
> are normally processed and is not necessarily customised to the
> specific client. For example, if the current client is forbidden
> from posting, then this will apply equally to groups with status "y".
> Conversely, a client with special privileges (not defined by this
> specification) might be able to post to a group with status "n".
>
>We do not know if it is meant to work like 200/201 or reflect the rights
>at the current state of the connection.
I think this means the client should treat the flags as advisory
(and therefore that the server can simply send whatever is in the
active file, with or without updating for the client's current
permissions, and certainly not be obligated to mask them against
whatever permissions the user has the potential to acquire).
--
Jeffrey M. Vinocur
je...@litech.org
Julien ÉLIE
>> RFC 3977 only mentions:
>>
>> The status of a newsgroup only indicates how posts to that newsgroup
>> are normally processed and is not necessarily customised to the
>> specific client. For example, if the current client is forbidden
>> from posting, then this will apply equally to groups with status "y".
>> Conversely, a client with special privileges (not defined by this
>> specification) might be able to post to a group with status "n".
>>
>> We do not know if it is meant to work like 200/201 or reflect the rights
>> at the current state of the connection.
>
> I think this means the client should treat the flags as advisory
> (and therefore that the server can simply send whatever is in the
> active file, with or without updating for the client's current
> permissions, and certainly not be obligated to mask them against
> whatever permissions the user has the potential to acquire).
OK, I understand. We can advertise whatever we want.
My interrogation was more "what SHOULD we advertise?"
Maybe USEAGE could tackle that subject...
--
Julien �LIE
� -- C'est une bonne situation �a, scribe ?
-- Oh, c'est une situation assise. � (Ast�rix)
Julien ÉLIE
> | > LIST ACTIVE local.*
> | < local.test.j 0000000000 0000000001 j
> | < local.test.x 0000000000 0000000001 x
> | < local.test.test 0000000000 0000000001 =local.test.n
> | < local.test.n 0000000000 0000000001 n
>
> the groups local.test.n and local.test.x will be markes with X in tin
> an the user is not able to post to it, the group local.test.test will
> be marked with = in tin and the user is able to post to it (but the
> posting will be rejected by the server and the user get's an error).
> IMHO it's out of the scope of a NRA to check if the target is
> moderated or non-posting or whatever.
It depends on what you want to achieve.
The news server will know when it receives the article for local.test.test
whether the target is moderated or non-posting, and will act on consequence.
But as you properly say to the user a group is non-posting, I thought it
would have been the same for an alias group to a non-posting group...
(just to be homogenous in behaviour)
>> Because it is useless to write there if postings are not allowed.
>
> it's also useless to setup an aliasgroup where the target is no
> posting. in that case one can simply remove the old group as there
> will be no more (local) posts to it.
For instance one could want to aggregate different sources into one?
Thus several newsgroups pointing to one. (Maybe with mailing-lists
gatewaying with no bidirectional postings.)
>>> no (but he could start to write a posting in a different group and edit
>>> the newsgroups header).
>> A bit of gymnastic, then, for the user.
>
> as I said, the flag should be correct.
In the case of a read-only news server before authentication, it would
mean that every group has status "n". And "y"/"m" comes after authentication.
I don't know if it's wise. Especially for the active list sent by transit
servers. Everything will be marked as "n".
Wouldn't it disturb news readers? (or programs like actsync...)
I also believe the flag should be correct (to give the right information
at the right moment) but it appears that software expects a special
behaviour -- and particularly readers-oriented, with proper "y"/"m".
No link with the POST capability.
> the server knows what the falg should be for the given user in the
> current state and should return the correct flag. if user has some
> read access but some write access only after auth it's up to the
> user/client to auth at the beginning. so there is no need to return
> diffent flags for the same group in the same connection.
Yes, I agree the news client should acquire the right privileges
before anything else. Status flags would then be correct and adapted
to the situation.
But other software relying on the legacy behaviour will break
(especially on transit servers).
>> But should we send "y" or "n" for fr.test to unauthenticated users?
>
> when it's not clear, send 'y' and let the client handle the "posting
> not allowed" return code upon post later on.
Sure.
> reissung LIST ACTIVE after late auth is no real option as the amount of
> data which has to be reread can be huge (i.e. 50000 groups in active,
> usual active entry is about 50 bytes -> retransmit more than 2MB of data
> just to get some flags right).
I would have thought reissuing LIST ACTIVE for only the newsgroups the
user is subscribed to.
--
Julien �LIE
� -- C'est une bonne situation �a, scribe ?
-- Oh, c'est une situation assise. � (Ast�rix)
Julien ÉLIE
>> When the group an alias points to does not allow postings ("X"), is it
>> also properly seen? Because it is useless to write there if
>> postings are not allowed. It requires to send the relevant LIST ACTIVE
>> command for it.
>
> No, nor do I see a reason why it would be checked. The "=" operator is not
> recursive. It says to file articles for group1 (LHS) into group 2 (RHS),
> not to treat group 1 as if it were group 2. Articles for group1 are
> blindly filed into group2, regardless of group 2's status.
If group 2 does not allow any postings (status "n"), why wouldn't an article
posted to group 1 be rejected?
>> (I'm writing a draft to try to standardize "x", "j", and alias groups.
>> My question here was originally more an INN implementation issue but
>> it appears that the problem is broader after second thought; I will
>> mention it in the draft.)
>
> Note that "j" and "=junk" are NOT equivalent operations for cross-posted
> articles.
Not only for crossposted articles, is it?
If group1 is status "j", group2 is status "=junk" and group3 is status "y":
* a local post to group1 will be accepted (and filed into "junk") whereas
a local post to group2 will not be accepted;
* a crosspost to group1,group3 will be filed only into only group3 whereas
a crosspost to group2,group3 will be rejected if it is a local post
and filed into "junk" and group3 if it comes from a peer.
Do you confirm?
> Note that "junk", "control"/"control.*", and "to" (when mergetogroups=TRUE)
> work properly (under INN 2.5.1) even when marked with "x".
I assume it is because INN does not check the status of these groups. It
just files articles into them when it has to.
It is what is should do, isn't it?
Thanks for your two notes. I cannot unfortunately incorporate them in
the first draft I wrote (draft-elie-nntp-list-additions-00) because I
already submitted it yesterday -- and it is stuck for manual posting
by the IETF secretariat because they do not recognize the format output
by the current version of rfc2xml (the abstract is before the status
of the memo).
But I will certainly add them in the following version of the draft.
--
Julien �LIE
� -- C'est une bonne situation �a, scribe ?
-- Oh, c'est une situation assise. � (Ast�rix)
Julien ÉLIE
> tin does not do the redirection itself, it lets the user post to the
> original group, when the target is flagged no posting the server will
> return an error to the user. as = groups are not much in use (and
> usualy just cause confusion) it's IMHO not worth the extra code to
> follow the alias(es? who much can they be nested?).
So the user will always receive an error (at least with INN) because
it says that the group has been renamed.
One should not nest aliases; but nobody prevents him not to.
>> In the case of a read-only news server before authentication, it
>> would mean that every group has status "n". And "y"/"m" comes after
>> authentication.
>
> if the server requires auth it should ask early
Yes, it's better to do that.
Anyway, I realize that I talked nonsense with "n" on a transit server.
We have to send to the client (which is usually a peer) the right "y"/"m"
status, and not "n". Because it is true that local postings are allowed;
and the peer knows that it cannot locally post. Only "x" or similar
status matters for him.
So I believe there is no problem with how it is currently implemented
except that, when an user has in his *current* state local access rights,
"n" should be changed to "y".
We should not do that for everybody. Only for the user which has right
now the right to post to "n" groups.
I believe that's the best to do. Does it suit you? Do you see other
scenari for a change of advertised status?
>> I don't know if it's wise. Especially for the active list sent by transit
>> servers. Everything will be marked as "n".
>>
>> Wouldn't it disturb news readers? (or programs like actsync...)
>
> they just have to auth on such servers ,-)
No need to, in fact. They are on a transit server and, on second thoughts,
"y" is the right thing to advertise. Local postings are allowed, and they
can only use peering postings.
--
Julien �LIE
� J'aimerais un peu plus d'enthousiasme et un peu moins
de latin quand je demande un volontaire ! � (C�sar)
Julien ÉLIE
>> I would have thought reissuing LIST ACTIVE for only the newsgroups the
>> user is subscribed to.
>
> what if the user likes to post to a group he is not (yet) subscribed to?
> what if the user is subscibed to a lot of groups? multiple list active cmds.
> might be much slower than a single (but huge) response ...
You're totally right.
Hmm... We need ZLIST ACTIVE to send a compressed active list :)
D. Stussy
> >> When the group an alias points to does not allow postings ("X"), is it
> >> also properly seen? Because it is useless to write there if
> >> postings are not allowed. It requires to send the relevant LIST
ACTIVE
> >> command for it.
> >
> > No, nor do I see a reason why it would be checked. The "=" operator is
not
> > recursive. It says to file articles for group1 (LHS) into group 2
(RHS),
> > not to treat group 1 as if it were group 2. Articles for group1 are
> > blindly filed into group2, regardless of group 2's status.
>
> If group 2 does not allow any postings (status "n"), why wouldn't an
article
> posted to group 1 be rejected?
Because the operation is NOT recursive.
Group 1's status is checked, and "=group2" is seen. Therefore, the article
is filed into group 2. End-of-operation. Group 2's status is not checked.
To check group 2's status would be to define the operation as recursive
(like CNAME is in DNS). We don't have that here.
> >> (I'm writing a draft to try to standardize "x", "j", and alias groups.
> >> My question here was originally more an INN implementation issue but
> >> it appears that the problem is broader after second thought; I will
> >> mention it in the draft.)
> >
> > Note that "j" and "=junk" are NOT equivalent operations for
cross-posted
> > articles.
>
> Not only for crossposted articles, is it?
For non-cross-posted articles, the end result is the same: The article is
filed into the "junk" group - which means that the operations are
equivalent.
For cross-posted articles, "j" says to file in "junk" ONLY if there are no
other groups with which to file it. "=junk" says to file in "junk" for
that one group so designated. Therefore, "j" will result in the article
being filed ONLY in "junk" while "=junk" may result in an article filed in
"junk" cross-posted to other groups. Therefore, the operations are not
equivalent.
> If group1 is status "j", group2 is status "=junk" and group3 is status
"y":
>
> * a local post to group1 will be accepted (and filed into "junk")
whereas
> a local post to group2 will not be accepted;
>
> * a crosspost to group1,group3 will be filed only into only group3
whereas
> a crosspost to group2,group3 will be rejected if it is a local post
> and filed into "junk" and group3 if it comes from a peer.
>
> Do you confirm?
No.
A local post to group 1 (marked "j") will NOT be accepted. Articles from
peers will be accepted and filed in "junk" - as a place for articles for
groups NOT LOCALLY CARRIED to be passed through to other peers (like INN's
"wanttrash = true" except only for the groups so marked). "j" = "I do not
carry the group locally but will pass it through using the junk pseudogroup
to any peer that wants it." Naming either "junk" or "group 1"
affirmatively among the group name patterns in the newsfeeds file (i.e. not
negated or poisoned) passes it on to a peer.
A local post to group 2 (marked "=junk") will NOT be accepted. The client
program will get an error indicating that the group has been renamed and
will be directed to its new name. The client should then fix his posting.
Articles from peers will be accepted and filed in "junk."
A local post to groups 1 and 3 may be accepted (with a warning of a
"non-carried" group) and filed only in "group3." The newsgroups header
will NOT be altered. Articles from peers will be filed in "group3" -
without the warning given to local clients. Pseudogroup "junk" is
untouched.
A local post to groups 2 and 3 may be accepted (with a warning of a renamed
group) and filed in "group3." It is unclear as to whether a local post
will also end up in "junk", or if the client will ask the user to
redesignate group2 with its current name before resubmitting - a local
design choice. Articles from peers will be cross-posted to "junk" and
"group3."
Peering note: Newsfeeds patterns "!junk" and "@junk", and their
difference. A feed specifying "!junk" may pass articles cross-posted to
junk (via "=junk") if the other group(s) pass. A feed specifying "@junk"
should suppress all articles posted or cross-posted to "junk" even if the
other groups pass (subject to the ordering rules for newsfeeds group
patterns). Specifying "junk" will pass all non-carried groups that got
filed into "junk." Specifying "@*,junk" will pass all articles in junk NOT
cross-posted to another group.
> > Note that "junk", "control"/"control.*", and "to" (when
mergetogroups=TRUE)
> > work properly (under INN 2.5.1) even when marked with "x".
>
> I assume it is because INN does not check the status of these groups. It
> just files articles into them when it has to. It is what is should do,
isn't it?
Correct. INN files qualifying articles without a pseudogroup status check.
Note: INN's default (distribution) specifies these as "y". Perhaps they
should be "x" (that's what I use) to prevent someone from actually
attempting to post articles directly to such groups. I note that some
users have tried.
I have also noted that INN (and actsync) seem to support two other groups
that have NO dots: "general" and "test". Therefore, only 5 group names
exist without a period in them; all other group names must have at least
one period.
> Thanks for your two notes. I cannot unfortunately incorporate them in
> the first draft I wrote (draft-elie-nntp-list-additions-00) because I
> already submitted it yesterday -- and it is stuck for manual posting
> by the IETF secretariat because they do not recognize the format output
> by the current version of rfc2xml (the abstract is before the status
> of the memo).
> But I will certainly add them in the following version of the draft.
Here's a random thought for a new idea:
Pseudogroup "spam"
Group-status flag: "s"
Similar to the junk group in operation/implementation, except for the
"wanttrash" setting. Why a separate group? Because some servers may want
to preserve "junk" as a place to pass non-locally carried groups through to
peers, while designating other groups as spamtraps (only when not
cross-posted). The spam group would typically be used in newsfeeds to feed
a program to auto-cancel posts made to spamtrap groups. Groups marked with
"s" should accept local postings, but file into "spam" ONLY if there are no
other groups to file into.
I guess this could be done with "=spam" and a newsfeeds group pattern of
"@*,spam", so we don't have to change anything in the standards or in INN
except for the actsync program (so it would accept the "spam" group as a
valid name - the 6th without a period in it). However, "=spam" may lose
the local posting feature.
Groups like "de.alt.0d" which exist purely as spam collectors would likely
be redesignated with status flag "s".
Julien ÉLIE
>> If group1 is status "j", group2 is status "=junk" and group3 is status "y":
>>
>> * a local post to group1 will be accepted (and filed into "junk") whereas
>> a local post to group2 will not be accepted;
>>
>> * a crosspost to group1,group3 will be filed only into only group3 whereas
>> a crosspost to group2,group3 will be rejected if it is a local post
>> and filed into "junk" and group3 if it comes from a peer.
>>
>> Do you confirm?
>
> No.
>
> A local post to group 1 (marked "j") will NOT be accepted. "j" = "I do not
> carry the group locally but will pass it through using the junk pseudogroup
> to any peer that wants it."
Do you really see that behaviour with INN?
I believe you are actually relying on what the man page of the active file
mentions about the "j" status. Which is wrongly documented.
For your information, there is an implicit comment in the code source
for local postings:
case 'j':
/* Do NOT return an error. */
break;
I also quote what we have for these three other flags (maybe it will
interest Urs too):
case 'n':
case 'x':
if (!PERMaccessconf->locpost)
snprintf(Error, sizeof(Error),
"Postings to \"%s\" are not allowed here", p);
break;
case '=':
snprintf(Error, sizeof(Error),
"The newsgroup \"%s\" has been renamed\n", p);
break;
> Peering note: Newsfeeds patterns "!junk" and "@junk", and their
> difference. A feed specifying "!junk" may pass articles cross-posted to
> junk (via "=junk") if the other group(s) pass. A feed specifying "@junk"
> should suppress all articles posted or cross-posted to "junk" even if the
> other groups pass (subject to the ordering rules for newsfeeds group
> patterns). Specifying "junk" will pass all non-carried groups that got
> filed into "junk." Specifying "@*,junk" will pass all articles in junk NOT
> cross-posted to another group.
Interesting. Thanks!
> Pseudogroup "spam"
> Group-status flag: "s"
>
> Similar to the junk group in operation/implementation, except for the
> "wanttrash" setting. Why a separate group? Because some servers may want
> to preserve "junk" as a place to pass non-locally carried groups through to
> peers, while designating other groups as spamtraps (only when not
> cross-posted). The spam group would typically be used in newsfeeds to feed
> a program to auto-cancel posts made to spamtrap groups.
>
> Groups like "de.alt.0d" which exist purely as spam collectors would likely
> be redesignated with status flag "s".
Why not feed de.alt.0d to your auto-cancel program directly from newsfeeds?
--
Julien �LIE
� Nemo auditur turpitudinem allegans. �
Julien ÉLIE
>> I would have thought reissuing LIST ACTIVE for only the newsgroups the
>> user is subscribed to.
>
> what if the user is subscibed to a lot of groups? multiple list active cmds.
> might be much slower than a single (but huge) response ...
Hey! Do not forget that a wildmat can consist of several newgroups.
It may be a useful feature in this case :)
LIST ACTIVE news.software.nntp,fr.test,news.lists.misc
215 Newsgroups in form "group high low status"
news.software.nntp 0000007789 0000000001 y
news.lists.misc 0000000308 0000000001 m
fr.test 0000011312 0000003285 y
.
Only one command.
(You just have to split your requests into chunks of 497 bytes maximum
for the wildmat.)
--
Julien �LIE
� Nemo auditur turpitudinem allegans. �
Julien ÉLIE
>>>> If group1 is status "j", group2 is status "=junk" and group3
>>>> is status "y":
>>>> * a local post to group1 will be accepted (and filed into
>>>> "junk") whereas a local post to group2 will not be accepted;
>>>>
>>>> * a crosspost to group1,group3 will be filed only into only
>>>> group3 whereas a crosspost to group2,group3 will be rejected
>>>> if it is a local post and filed into "junk" and group3 if it
>>>> comes from a peer.
>>>>
>>>> Do you confirm?
>>>
>>> No.
[...]
> As a result of your query, I picked a group that was marked "j" on my
> server and attempted to post to it. My client prevented such. I then
> attempted to post to it as a crosspost with my "local.test" group (marked
> "y"). A warning did occur, but the post was accepted. When I reviewed the
> post via the local group, the "Xref:" header contained ONLY the
> "local.test" group's article number, so the cross-posting to "j" did NOT
> occur. The "j" group was blocked from local posting.
>
> Therefore, I conclude that the behavior is or is equivalent to in result to
> what I stated previously.
It it also what I said: a *crosspost* is filed only into the group
with status "y". (And a post to *only* the group with status "j" is
accepted.)
> 3) Create dummy entries in "newsgroups" indicating timestamp a hierarchy's
> checkgroups was last processed.
>
> --- control/docheckgroups.in 2009-10-12 18:24:04.000000000 +0000
> +++ control/docheckgroups.in 2009-10-20 00:00:00.000000000 +0000
> @@ -79,6 +79,9 @@
> ${AWK} '{ if ($1 !~ /'"${PATS}"'/) { print $0 } }' ${NEWSGROUPS} >>${T}/$$updatednewsgroups
> ${AWK} '{ if (($1 !~ /'"${1:-.}"'/) && ($1 ~ /'"${PATS}"'/)) { print $0 } }' ${NEWSGROUPS} >>${T}/$$updatednewsgroups
> cat ${T}/$$newdesc >>${T}/$$updatednewsgroups
> + DATE=`date --utc "+%Y-%m-%d %H:%M:%S UTC"`
> + for x in `grep "\." ${T}/$$msg|cut -d . -f 1|sort -u` ; do
> + echo -e $x.CHECKGROUPS\\tCheckgroups processed on $DATE >>${T}/$$updatednewsgroups ; done
> mv -f ${NEWSGROUPS} ${NEWSGROUPS}.old
> ${SORT} ${T}/$$updatednewsgroups | ${SED} 's/ [ ]*/ /' \
> | ${AWK} -F'\t' '{if (length($1) < 8) {print $1"\t\t\t"$2} \
What if a newsgroup named "fr.checkgroups" already exists
in the newsgroups file?
D. Stussy
> > As a result of your query, I picked a group that was marked "j" on my
> > server and attempted to post to it. My client prevented such. I then
> > attempted to post to it as a crosspost with my "local.test" group
(marked
> > "y"). A warning did occur, but the post was accepted. When I reviewed
the
> > post via the local group, the "Xref:" header contained ONLY the
> > "local.test" group's article number, so the cross-posting to "j" did
NOT
> > occur. The "j" group was blocked from local posting.
> >
> > Therefore, I conclude that the behavior is or is equivalent to in
result to
> > what I stated previously.
>
> It it also what I said: a *crosspost* is filed only into the group
> with status "y". (And a post to *only* the group with status "j" is
> accepted.)
A post ONLY to a "j" group should NOT be accepted. "j" groups should NOT
be returned to the users in a "LIST ACTIVE" output. Such are
"pass-through" groups which are NOT LOCALLY CARRIED. As such, they should
not be locally postable, and "don't exist" as far as clients are concerned.
"j" groups exist only for peers that include the "junk" pseudogroup in
their newsfeed distribution (i.e. the pass-through mechanism).
INN currently returns "j" groups in some places and not in others, and when
it does so, it presents an "n" to the client. (INN also seems to convert
"x" to "n", but I find that some (many?) clients understand "x".) As "x"
can exist on certain pseudogroups (e.g. "control"), where an adminstrator
may need to read it, I chose to return "x" groups when their overviews are
NOT EMPTY (when the highmark is not zero) to clients. My patch, in the
first 3 sections, seeks to harmonize the list to be consistent.
> > 3) Create dummy entries in "newsgroups" indicating timestamp a
hierarchy's
> > checkgroups was last processed.
> >
> > --- control/docheckgroups.in 2009-10-12 18:24:04.000000000 +0000
> > +++ control/docheckgroups.in 2009-10-20 00:00:00.000000000 +0000
> > @@ -79,6 +79,9 @@
> > ${AWK} '{ if ($1 !~ /'"${PATS}"'/) { print $0 } }' ${NEWSGROUPS}
>>${T}/$$updatednewsgroups
> > ${AWK} '{ if (($1 !~ /'"${1:-.}"'/) && ($1 ~ /'"${PATS}"'/)) {
print $0 } }' ${NEWSGROUPS} >>${T}/$$updatednewsgroups
> > cat ${T}/$$newdesc >>${T}/$$updatednewsgroups
> > + DATE=`date --utc "+%Y-%m-%d %H:%M:%S UTC"`
> > + for x in `grep "\." ${T}/$$msg|cut -d . -f 1|sort -u` ; do
> > + echo -e $x.CHECKGROUPS\\tCheckgroups processed on $DATE
>>${T}/$$updatednewsgroups ; done
> > mv -f ${NEWSGROUPS} ${NEWSGROUPS}.old
> > ${SORT} ${T}/$$updatednewsgroups | ${SED} 's/ [ ]*/
/' \
> > | ${AWK} -F'\t' '{if (length($1) < 8) {print $1"\t\t\t"$2} \
>
> What if a newsgroup named "fr.checkgroups" already exists
> in the newsgroups file?
Group names may NOT have upper-case characters. My marker does. The
update of the newsgroups file is case-sensitive as to group name.
Therefore, a collision should never occur (if it does, it's due to
administrative error).
When a subsequent checkgroups comes in, any existing entry is removed (as
it's not in the checkgroups message) and a new entry generated, effectively
replacing it.
Although I went with the timestamp of the actual processing, an alternative
would have been to extract the date from the message and use it instead.
Comparing the actual processing time vs. posted time could be used as a
measure of propagation.
This seems to work properly when a checkgroups message is for a TLH (top
level hierarchy). If not a TLH, it generates an entry for the
corresponding TLH - e.g. "checkgroups microsoft.public.*" generates an
entry for "microsoft.CHECKGROUPS". "cn.bbs.*" would generate an entry for
"cn.CHECKGROUPS". As most checkgroups messages are for TLHs, I decided to
ignore this problem for the meantime as I didn't see an easy solution.
Instead of the "for x" loop (which really applies to the big-8 message, as
all others will generally have a single TLH), it would have been nice to
use the parameter from the checkgroups control line (when specified), but
again, I was lazy and it didn't seem to matter. If you like the idea and
can generate a better solution for subhierarchies, feel free to do so.