Discussion about Cancel-Lock support
julien at trigofacile.com
Mon Nov 30 20:51:08 UTC 2020
>> First: do you all agree that support for Cancel-Lock/Key should be
>> natively integrated in both innd and nnrpd? (in C source code) or do you
>> prefer only an update to Perl filter hook samples to add an example of
>> code to deal with that feature?
> I think it's fine to integrate it directly since it will be an inn.conf
> option. It may be worth considering getting rid of verifycancels while
> we're at it to reduce some complexity, since the check it enables is
> essentially meaningless and RFC 5537 actively recommends against this.
> Cancel-Lock support is the correct approach to achieve the same ends
> (although of course most people don't generate Cancel-Lock headers).
I'll have a look next year. It will permit to have time to properly
implement and test it, before eventually integrating it into a stable
Thanks for all your comments.
>> - which hash algorithm to support? and how?
>> I suggest not to generate nor honour md5 hashes.
>> But what for sha1, sha224, sha256, sha384 and sha512? Honour all of them
>> but generate only sha256 and/or sha512?
>> Force for instance the generation of sha256 (the only MANDATORY algorithm
>> in RFC 8315)? or parameter the one to use? or parameter all that should
>> be used (multiple locks and keys to add)?
> My inclination would be to support all of the non-MD5 algorithms for
> verification but only generate SHA-256. I don't think there's much gained
> by using the other algorithms.
> It looks like Gnus still only supports SHA-1.
For interoperability reasons, it seems that we'll have to handle a
transition period, and generate two hashes for each message (SHA-1 and
SHA-256). And support all of the non-MD5 algorithms to verify cancel keys.
« Avec toutes les saletés que les gens jettent dans le fleuve, il n'y a
plus de poissons ! Tout ce que je pêche depuis ce matin sont des
amphores vides ! » (Astérix)
More information about the inn-workers