Hello,

I need some clarification on both the way INN works and the preferred
policy.

I try to setup for the fr.* hierarchy a server as easily accessible as possible. That is, just now, without the need of authentication.

I already use nocem to prevent spam, and I plan to setup control-lock/control-key soon.

In the mean time I want to forgive cancels on this servers (I can cancel
a message manually for a user if necessary).

To achieve this I setup

innflags: "-C"

However, the documentation is not that clear.

https://www.eyrie.org/~eagle/software/inn/docs-2.6/inn.conf.html

say:

"In order not to actually process any cancel or supersedes messages, you
can start innd with the -C flag, or add this flag to the innflags
parameter. "

what I did.

But

https://www.eyrie.org/~eagle/software/inn/docs-2.5/innd.html

say:

"-C

This flag tells innd to accept and propagate but not actually
process cancel or supersedes messages. This is intended for sites
concerned about abuse of cancels, or that wish to use another cancel
mechanism with stronger authentication. "

the difference here is in the "propagate".

and effectively, the cancel message received is shared with peers, and
it may be processed by them.

The problem I have right now (with a nearly flame war against me on
french group) is that somebody found funny to send a forged cancel
message to cancel a message of an other user. funny because the
cancelled message was unimportant.

so my question is: giving I don't process cancel messages, do I need to propagate them anyway or use some way to stop them completely? what's do
I have to do?

In the second case, is the "refusecybercancel: true" option in inn.conf
a good solution, or is there an other better one?

thanks
jdd

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Le 21/08/2022 à 17:28, Russ Allbery a écrit :

jdanield <jdd@dodin.org> writes:

innflags: "-C"

Yeah, that doesn't do what you want; that still lets anyone post cancels
and propagates them, it just doesn't honor them locally.

yes, I just discovered this some days ago :-)

so my question is: giving I don't process cancel messages, do I need to
propagate them anyway or use some way to stop them completely? what's do
I have to do?

You would need to prevent them from being posted entirely.

OK. Thanks

find one off-hand.) Feels like there should be an access: letter for readers.conf permissions that controls whether users can post cancel messages, but it doesn't look like that's something that's already implemented.

yep. As cancels are done internally it's difficult to get how manage
them (looking at the source is beyond my capability)

The posting filter is very simple, though: just reject any message with a Control or Supersedes header.

ok.

I wonder if the "refusecybercancels" option or Ac flag in peers config
may have a similar result?

thanks
jdd

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

jdanield <jdd@dodin.org> writes:

In the mean time I want to forgive cancels on this servers (I can cancel a message manually for a user if necessary).

To achieve this I setup

innflags: "-C"

Yeah, that doesn't do what you want; that still lets anyone post cancels
and propagates them, it just doesn't honor them locally.

so my question is: giving I don't process cancel messages, do I need to propagate them anyway or use some way to stop them completely? what's do
I have to do?

You would need to prevent them from being posted entirely.

I'm not sure INN has a good way of doing this other than using a Perl or
Python posting filter. (I'm a bit surprised that we don't, but I can't
find one off-hand.) Feels like there should be an access: letter for readers.conf permissions that controls whether users can post cancel
messages, but it doesn't look like that's something that's already
implemented.

The posting filter is very simple, though: just reject any message with a Control or Supersedes header. (You could do something finer-grained with
the Control header if you want to allow users to post newgroup and rmgroup control messages, although for your use case I'm not sure I'd bother.)

--
Russ Allbery (eagle@eyrie.org) <https://www.eyrie.org/~eagle/>

Please post questions rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Le 21/08/2022 à 18:20, Russ Allbery a écrit :

or Ac flag in peers config may have a similar result?

That will mean you'll still accept the cancel message but won't propagate
it to any peer with that flag, but unfortunately it won't do anything
about Supersedes (since those aren't control messages).

OK, thanks
jdd

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

jdanield <jdd@dodin.org> writes:

ok.

I wonder if the "refusecybercancels" option

refusecybercancels is unrelated. That only blocks cancels in a very
specific format that used to be used for spam cancels.

or Ac flag in peers config may have a similar result?

That will mean you'll still accept the cancel message but won't propagate
it to any peer with that flag, but unfortunately it won't do anything
about Supersedes (since those aren't control messages).

--
Russ Allbery (eagle@eyrie.org) <https://www.eyrie.org/~eagle/>

Please post questions rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Jean-Daniel,

the documentation is not that clear.

https://www.eyrie.org/~eagle/software/inn/docs-2.6/inn.conf.html

say:

"In order not to actually process any cancel or supersedes messages, you
can start innd with the -C flag, or add this flag to the innflags
parameter. "

But

https://www.eyrie.org/~eagle/software/inn/docs-2.5/innd.html

say:

"-C

    This flag tells innd to accept and propagate but not actually
process cancel or supersedes messages. This is intended for sites
concerned about abuse of cancels, or that wish to use another cancel mechanism with stronger authentication. "

the difference here is in the "propagate".

Both of the paragraphs say cancels are not processed (= honoured / treated). Anyway, the "-C" parameter in innd has been replaced with the docancels parameter in inn.conf since INN 2.7.0; so only the inn.conf man page now documents the behaviour. The issue is solved :-)

The wording is:

"""
docancels

Unless rejected by the use of a filter hook, innd always accepts and
propagates cancel articles and supersede requests. However, actually processing such articles on the local news server depends on this
parameter which can take the following values:

[and then follows the definition of require-auth, auth, none, all]
"""

Is it clear enough? Maybe "honouring" should be used instead of
"processing" if it makes it clearer?

--
Julien ÉLIE

« Nous agissons comme si le confort et le luxe étaient essentiels à
notre existence, alors qu'il suffit pour être réellement heureux de
trouver quelque chose qui nous intéresse passionnément. » (Charles
Kingsley)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Russ,

I'm not sure INN has a good way of doing this other than using a Perl or Python posting filter. (I'm a bit surprised that we don't, but I can't
find one off-hand.)

Indeed, there's no native way in INN to configure whether a user can
post cancels.
One has to add a rule in the nnrpd Perl filter hook (we do not support
Python hooks for nnrpd). Alternately, using Paolo's Postfilter great
script would do the job as a Perl hook.

Just changing in postfilter.conf:

# $config{'allow_control_cancel'} -> [ "true" | "false" ]
#
# This key sets whether the control cancel messages are allowed. The
value of "true" authorizes them,
# "false" rejects them. This command has no effect if innd is started
with -C flag.
#
'allow_control_cancel',
"false", # false = disallow ;

# true = allow
#
# $config{'allow_supersedes'} -> [ "true" | "false" ]
#
# Whether an article can include Supersedes, Replaces, Cancels headers
that replace an article with another
#
'allow_supersedes', "false",

Feels like there should be an access: letter for
readers.conf permissions that controls whether users can post cancel messages, but it doesn't look like that's something that's already implemented.

That could be useful, yes.
I see that we have ticket #117:

readers.conf already has read: and post: parameters.

We should also provide newnews:, ihave:, localpost: and approve: in
order to specify the newsgroups on which the user can use these
facilities.


We could add all these ones, along with a cancel: parameter.


I'm wondering if we should keep 3 different ways to parameter read & co accesses:

1/ newsgroups: "pattern" (for reading and posting)
2/ read/post and possible other parameters not yet implemented:
"pattern" (for fine-grained configuration)
3/ access: "RPAINL" (used in conjunction with newsgroups or read/post/xxx)

It makes the documentation and the functional rules more complex.


Couldn't we just keep the 2/ way in the next major release? (the most
explicit and understandable)

--
Julien ÉLIE

« Il ne faut jamais gifler un sourd : il perd la moitié du plaisir. Il
sent la gifle mais il ne l'entend pas. » (Georges Courteline)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)