Parametring cancel processing (Cancel-Lock vs unauthenticated cancels)
Martin Burmester
martin at burmester.org
Sun Jan 2 20:59:17 UTC 2022
Hi Julien,
from an admins perspective there are four possible polices regarding
cancels:
1. Execute all cancels, don't check Cancel-Lock. (the default now)
2. Execute no cancels. (with "-C" flag)
3. If the original article is protected by Cancel-Lock, check Cancel-Key
and execute the cancel if it authenticates. If it is not protected by
Cancel-Lock execute in any case.
4. If the original article is protected by Cancel-Lock, check Cancel-Key
and execute the cancel if it authenticates. If it is not protected by
Cancel-Lock, do not execute.
With your idea all four could be achieved without recompiling:
1: canlockcheck=false
2: -C, canlockcheck=false
3: canlockcheck=true
4: -C, canlockcheck=true
Wich would make 3 the new default, which is also a good idea.
But having to configure it in two places and think this through is not
so easy. What about a new parameter, eg. "docancels" with the options
"all", "none", "auth" and "require-auth"?
Cheers,
Martin
Am 02.01.2022 um 21:00 schrieb Julien ÉLIE:
> Hi all,
>
> innd can be started with a flag (-C) to accept and propagate, but *not*
> process cancel or supersedes messages. (NoCeM notices are processed
> anyway.)
>
> With the upcoming support of Cancel-Lock, should we add a new inn.conf
> parameter to enable/disable Cancel-Lock processing?
>
>
> If INN is compiled without Cancel-Lock support:
> - the "-C" flag given to innflags permits disabling the process of any
> cancels.
>
> If INN is compiled with Cancel-Lock support:
> - Cancel-Lock and Cancel-Key header fields are added by nnrpd if secrets
> are set in inn-secrets.conf (otherwise, this feature is disabled);
> - the "-C" flag given to innflags permits disabling the process of XXX
> (any kinds of cancels, including via Cancel-Lock? only unauthenticated
> cancels?)
>
> I would say that "-C" just disables the process of unauthenticated
> cancels only. But maybe some people will want to generate locks via
> nnrpd but not actually process any cancels (to keep all the articles in
> their spool)?
> So we would need a "canlockcheck" inn.conf parameter (set to true by
> default) to disable innd's processing if wanted.
>
> Any comments about that or a better suggestion of name for the parameter?
>
More information about the inn-workers
mailing list