1. Forum
  2. Usenet
  3. NEWS.SOFTWARE.NNTP

  • cancels, innflags: "-C" and propagation

    From jdanield@21:1/5 to All on Sun Aug 21 10:29:38 2022
    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)
  • From jdanield@21:1/5 to All on Sun Aug 21 18:09:40 2022
    Le 21/08/2022 à 17:28, Russ Allbery a écrit :
    jdanield <[email protected]> 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)
  • From Russ Allbery@21:1/5 to jdanield on Sun Aug 21 08:28:44 2022
    jdanield <[email protected]> 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 ([email protected]) <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)
  • From jdanield@21:1/5 to All on Sun Aug 21 18:28:06 2022
    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)
  • From Russ Allbery@21:1/5 to jdanield on Sun Aug 21 09:20:30 2022
    jdanield <[email protected]> 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 ([email protected]) <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)
  • From =?UTF-8?Q?Julien_=c3=89LIE?=@21:1/5 to All on Thu Sep 1 20:13:21 2022
    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)
  • From =?UTF-8?Q?Julien_=c3=89LIE?=@21:1/5 to All on Thu Sep 1 20:30:55 2022
    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)