Re: Parametring cancel processing (Cancel-Lock vs unauthenticated cancels)

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?
> 
_______________________________________________
inn-workers mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/inn-workers