Re: Erreur bizarre INN2

Bonjour Stéphane,

Ton rejet "Cancel of non-existing ID" ne provient-il vraiment pas de ton
cleanfeed.local ??
>
      https://home.gegeweb.org/rfc8315.html
>
    return "$descr of non-existing ID $target";

 Serait-ce gênant en cas de cleanfeed gérant le cancel-Lock de ne pas
rejeter ce type de post?

Le cas d'usage est de pouvoir annuler un article avant même que l'original ne parvienne au serveur. Par exemple lorsqu'un robot anti-spam détecte un spam, envoie un cancel associé et que tu reçoives ce cancel avant l'article initial. Ton serveur pourra directement refuser le Message-ID proposé par un feed, et ainsi économiser un peu de bande passante.
Je pense que de nos jours, avec les connexions actuelles, ce cas ne se produit que rarement. Les spams sont reçus avant leur annulation. (Je peux me tromper, je n'ai pas de stats là dessus, mais ça ne me semble pas déraisonnable.)
Et donc ici, on serait dans le cas d'une annulation avec un Cancel-Key. Je doute encore plus qu'un article d'annulation envoyé par le *même* serveur/client ou qui a envoyé l'article originel avant, parvienne plus tôt... (car c'est bien le même serveur qui a la clef d'annulation à envoyer, et non un autre)

Dans ce cas comment ne pas traiter ce message mais ne pas faire de
reject qui l'exclue des feeds?

Je ne pense pas qu'il faille s'en soucier. Autant accepter l'annulation et la retransmettre.
Soit l'article initial te parvient après, et il sera rejeté par ton serveur (je ne suis pas persuadé que ce cas se produira, surtout si l'original a un Cancel-Lock). À moins d'une attaque par un serveur, qui annule à vue tous les messages avec un Cancel-Key forgé... et dans ce cas il faut traiter cette attaque à la source (UDP).
Soit il ne te parvient pas, et ça ne changeait rien d'accepter son annulation préventive ou non.
--
Julien ÉLIE
« Tout homme devrait un jour se marier ; après tout, le bonheur n'est
   pas la seule chose dans la vie. »