Parametring cancel processing (Cancel-Lock vs unauthenticated cancels)
Julien ÉLIE <[email protected]> Sun, 2 Jan 2022 21:00:39 +0100
| Newsgroups | gmane.network.inn |
|---|---|
| Message-ID | <[email protected]> |
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? -- Julien ÉLIE « La terre étant ronde, le kilomètre devrait être rond et non pas carré. » (Ramón Gomez de La Serna) _______________________________________________ inn-workers mailing list [email protected] https://lists.isc.org/mailman/listinfo/inn-workers