Re: Message sans texte

Bonjour,

[Edit] grâce à llp on sait aussi que Forté Agent ne pourrait pas annuler ses
propres articles si c'était interdit :
<6v242il0umlkhtho84j2t6e7f4q4r30me7@consensus-omnium> [/Edit]

Ce n'est pas interdit mais, il est quand même mieux d'ajouter une ligne pour éviter que l'article puisse être refusé par le serveur lors du POST.

Pourquoi ne le pourrait-il pas ?
>
C'est ce message de Cancel qui m'a fait poser la question, un message
vide entrainant un problème dans MacCafé.

Comme expliqué dans un autre message, lorsqu'un agent de publication POSTe un cancel, il est également dépendant de la configuration du serveur qui va se charger d'injecter et propager l'article sur usenet.
Si ton lecteur de nouvelles *POSTe* un cancel avec un corps vide et que le serveur est configuré pour rejeter ce genre d'article, il sera impossible de traiter/propager le cancel.
INN traite notament ce cas dans nnrpd/post.c.
Spitfire News Server traite également ce cas et peut (s'il est configuré pour) refuser les articles sans corps.
Bien entendu, en mode relai, cette vérification n'est jamais effectuée et le cancel sera traité en fonction de la politique du serveur.
Pour éviter qu'un cancel puisse être rejeté lors d'un POST :
- MesNews ajoute par exemple "Article supprimé par MesNews".
- Thunderbird ajoute pour sa part "This message was cancelled from within Mozilla Thunderbird"

A mon sens , il serait quand même de mon ton que quand un pseudo annule
un de ses messages, il soit annoncé dans le body que cette annulation
est de sont fait (ce que fait MacCafé).

Rien ne t'en empêche :
RFC 5537
The body of the control message MAY contain anything, usually an explanatory text.

Car sans remonter au message annulé, on ne peut être sûr qu'il est de
lui, ou que c'est une annulation arbitraire (à juste raison ou pas, là
n'es pas le problème).

La seule manière d'être certain que le message de cancel est posté par la même personne que l'article à annuler se fait par l'ajout/vérification d'entêtes CL/CK.
Aucune autre entête que Control / Cancel-Lock / Cancel-Key n'est vérifiée à réception d'un cmsg (et encore moins le corps).
On peut même pousser plus loin en se rappelant ce que dit la RFC 5537 :
Contrary to [RFC1036], cancel control messages are not required to
contain *From* and *Sender* header fields *matching the target message*.
This requirement only encouraged cancel issuers to conceal their identity and provided no security.
Franck