Dans les préférences pour la création des messages, j'ai prévu de donner
la possibilité d'ajouter dans le "header" du message des champs
facultatifs. Par exemple X-No-Archive, Organization...
Actuellement, l'utilisateur à la possibilité de saisir le nom du champs
et son paramètre. Ce serait un plus, si (tout en gardant la possibilité
de saisir le nom du champs) les plus utilisés étaient proposés via un
pop-up.
Cela me ferais gagner un peu de temps et je suis sur des oublis, si vous
m'en proposiez quelques un.
Cela me ferais gagner un peu de temps et je suis sur des oublis, si vous m'en proposiez quelques un.
Actuellement, MacSoup peut proposer Approved Bcc Comments Cc Content-Type Content-Transfert-Encoding Distribution Date Expires Followup-To From In-Reply-To Keywords Lines Mail-Copies-To MIMe-Version Message-ID Newsgroups Organization Path Reply-To References Sender Summary Subject To User-Agent X-Face X-Sender X-Mailer X-Newsreader X-No-Archive: Yes n'est pas dans la liste d'origine Certains entêtes sont dédiés au courriel, évidemment. HTH et bon courage -- J. B.
Cela me ferais gagner un peu de temps et je suis sur des oublis, si vous m'en proposiez quelques un.
Actuellement, MacSoup peut proposer Approved Bcc Comments Cc Content-Type Content-Transfert-Encoding Distribution Date Expires Followup-To From In-Reply-To Keywords Lines Mail-Copies-To MIMe-Version Message-ID Newsgroups Organization Path Reply-To References Sender Summary Subject To User-Agent X-Face X-Sender X-Mailer X-Newsreader X-No-Archive: Yes n'est pas dans la liste d'origine Certains entêtes sont dédiés au courriel, évidemment. HTH et bon courage -- J. B.
gilbert.olivier
Joseph-B wrote:
Actuellement, MacSoup peut proposer
Merci, j'avais déjà vu dans les pref de MacSoup ;-) C'était surtout pour m'éviter de faire le tri avec celles qui sont liées au courrier, d'avoir celles qui n'y sont pas comme le X-No-Archive, et de se concentrer sur les plus utilisées. -- Gilbert
Joseph-B <josephb@nowhere.invalid> wrote:
Actuellement, MacSoup peut proposer
Merci, j'avais déjà vu dans les pref de MacSoup ;-)
C'était surtout pour m'éviter de faire le tri avec celles qui sont liées
au courrier, d'avoir celles qui n'y sont pas comme le X-No-Archive, et
de se concentrer sur les plus utilisées.
Merci, j'avais déjà vu dans les pref de MacSoup ;-) C'était surtout pour m'éviter de faire le tri avec celles qui sont liées au courrier, d'avoir celles qui n'y sont pas comme le X-No-Archive, et de se concentrer sur les plus utilisées. -- Gilbert
josephb
Gilbert OLIVIER wrote:
C'était surtout pour m'éviter de faire le tri avec celles qui sont liées au courrier, d'avoir celles qui n'y sont pas comme le X-No-Archive, et de se concentrer sur les plus utilisées.
Ça ne va pas faire le travail à ta place, hélas, mais sur cette page il y a une belle liste expliquée des champs d'entête <https://www.activexperts.com/smtp-pop3-component/headers/> Il y a bien la RFC 3977 mais sa lecture sera bien pire que celle du lien au-dessus. -- J. B.
C'était surtout pour m'éviter de faire le tri avec celles qui sont liées
au courrier, d'avoir celles qui n'y sont pas comme le X-No-Archive, et
de se concentrer sur les plus utilisées.
Ça ne va pas faire le travail à ta place, hélas, mais sur cette page il
y a une belle liste expliquée des champs d'entête
C'était surtout pour m'éviter de faire le tri avec celles qui sont liées au courrier, d'avoir celles qui n'y sont pas comme le X-No-Archive, et de se concentrer sur les plus utilisées.
Ça ne va pas faire le travail à ta place, hélas, mais sur cette page il y a une belle liste expliquée des champs d'entête <https://www.activexperts.com/smtp-pop3-component/headers/> Il y a bien la RFC 3977 mais sa lecture sera bien pire que celle du lien au-dessus. -- J. B.
gilbert.olivier
Joseph-B wrote:
Gilbert OLIVIER wrote:
C'était surtout pour m'éviter de faire le tri avec celles qui sont liées au courrier, d'avoir celles qui n'y sont pas comme le X-No-Archive, et de se concentrer sur les plus utilisées.
Merci c'est assez synthétique ça devrait déjà aider.
Il y a bien la RFC 3977
et il n' a pas qu'elle
mais sa lecture sera bien pire que celle du lien au-dessus.
Les RFC c'est par là que j'ai commencé pour comprendre au mieux les headers, voir comment dialoguer avec le serveur... première étape obligatoire avant de se lancer dans un tel projet. Trouver les protocoles et savoir que l'on sait écrire le code pour se connecter au serveur et dialoguer avec lui ;-) -- Gilbert
> C'était surtout pour m'éviter de faire le tri avec celles qui sont liées
> au courrier, d'avoir celles qui n'y sont pas comme le X-No-Archive, et
> de se concentrer sur les plus utilisées.
Ça ne va pas faire le travail à ta place, hélas, mais sur cette page il
y a une belle liste expliquée des champs d'entête
Merci c'est assez synthétique ça devrait déjà aider.
Il y a bien la RFC 3977
et il n' a pas qu'elle
mais sa lecture sera bien pire que celle du lien au-dessus.
Les RFC c'est par là que j'ai commencé pour comprendre au mieux les
headers, voir comment dialoguer avec le serveur... première étape
obligatoire avant de se lancer dans un tel projet. Trouver les
protocoles et savoir que l'on sait écrire le code pour se connecter au
serveur et dialoguer avec lui ;-)
C'était surtout pour m'éviter de faire le tri avec celles qui sont liées au courrier, d'avoir celles qui n'y sont pas comme le X-No-Archive, et de se concentrer sur les plus utilisées.
Merci c'est assez synthétique ça devrait déjà aider.
Il y a bien la RFC 3977
et il n' a pas qu'elle
mais sa lecture sera bien pire que celle du lien au-dessus.
Les RFC c'est par là que j'ai commencé pour comprendre au mieux les headers, voir comment dialoguer avec le serveur... première étape obligatoire avant de se lancer dans un tel projet. Trouver les protocoles et savoir que l'on sait écrire le code pour se connecter au serveur et dialoguer avec lui ;-) -- Gilbert
DV
Joseph-B a écrit ceci :
Il y a bien la RFC 3977 mais sa lecture sera bien pire que celle du lien au-dessus.
Je suggérerais plutôt de consulter la RFC 5536, bien plus digeste et surtout strictement consacrée aux news : <https://tools.ietf.org/html/rfc5536> Parmi les en-têtes optionnels qui y sont détaillés, les suivants me semblent mériter d'être proposés par MacCafé : Archive (joue le même rôle que X-No-Archive, mais à ce que j'ai compris, les sites d'archivage respectent tantôt l'un, tantôt l'autre... et parfois aucun des deux, hélas.) Organization Supersedes (permet d'annuler ses propres articles) D'autres devraient en principe être ajoutés par le lecteur de news lui-même : Followup-To en cas de suivi, References, User-Agent. Quant à Reply-To, si les réglages de MacCafé prévoient la possibilité pour l'utilisateur de spécifier une adresse de réponse alternative, alors c'est à l'application de gérer cet en-tête. Dans le cas contraire, ce serait bien de l'ajouter à la liste des propositions. Enfin, parmi les en-têtes non standards (les "X") qui sont absents de cette RFC, j'ajouterais personnellement X-No-Archive et X-Face. Ceci posé, je pense que Gilbert devrait aussi aller à la pêche aux infos sur fr.comp.usenet.lecteurs-de-news. Il y a là-bas de vrais spécialistes ès NNTP, bien plus pointus que moi, qui auraient peut-être d'autres suggestions à lui faire. -- Denis
Joseph-B a écrit ceci :
Il y a bien la RFC 3977
mais sa lecture sera bien pire que celle du lien au-dessus.
Je suggérerais plutôt de consulter la RFC 5536, bien plus digeste et
surtout strictement consacrée aux news :
<https://tools.ietf.org/html/rfc5536>
Parmi les en-têtes optionnels qui y sont détaillés, les suivants me
semblent mériter d'être proposés par MacCafé :
Archive (joue le même rôle que X-No-Archive, mais à ce que j'ai compris,
les sites d'archivage respectent tantôt l'un, tantôt l'autre... et
parfois aucun des deux, hélas.)
Organization
Supersedes (permet d'annuler ses propres articles)
D'autres devraient en principe être ajoutés par le lecteur de news
lui-même : Followup-To en cas de suivi, References, User-Agent.
Quant à Reply-To, si les réglages de MacCafé prévoient la possibilité
pour l'utilisateur de spécifier une adresse de réponse alternative,
alors c'est à l'application de gérer cet en-tête. Dans le cas contraire,
ce serait bien de l'ajouter à la liste des propositions.
Enfin, parmi les en-têtes non standards (les "X") qui sont absents de
cette RFC, j'ajouterais personnellement X-No-Archive et X-Face.
Ceci posé, je pense que Gilbert devrait aussi aller à la pêche aux infos
sur fr.comp.usenet.lecteurs-de-news. Il y a là-bas de vrais spécialistes
ès NNTP, bien plus pointus que moi, qui auraient peut-être d'autres
suggestions à lui faire.
Il y a bien la RFC 3977 mais sa lecture sera bien pire que celle du lien au-dessus.
Je suggérerais plutôt de consulter la RFC 5536, bien plus digeste et surtout strictement consacrée aux news : <https://tools.ietf.org/html/rfc5536> Parmi les en-têtes optionnels qui y sont détaillés, les suivants me semblent mériter d'être proposés par MacCafé : Archive (joue le même rôle que X-No-Archive, mais à ce que j'ai compris, les sites d'archivage respectent tantôt l'un, tantôt l'autre... et parfois aucun des deux, hélas.) Organization Supersedes (permet d'annuler ses propres articles) D'autres devraient en principe être ajoutés par le lecteur de news lui-même : Followup-To en cas de suivi, References, User-Agent. Quant à Reply-To, si les réglages de MacCafé prévoient la possibilité pour l'utilisateur de spécifier une adresse de réponse alternative, alors c'est à l'application de gérer cet en-tête. Dans le cas contraire, ce serait bien de l'ajouter à la liste des propositions. Enfin, parmi les en-têtes non standards (les "X") qui sont absents de cette RFC, j'ajouterais personnellement X-No-Archive et X-Face. Ceci posé, je pense que Gilbert devrait aussi aller à la pêche aux infos sur fr.comp.usenet.lecteurs-de-news. Il y a là-bas de vrais spécialistes ès NNTP, bien plus pointus que moi, qui auraient peut-être d'autres suggestions à lui faire. -- Denis
Jean-Pierre Kuypers
In article (Dans l'article) <1o9xs3d.6o5mv6xmczzgN%, Gilbert OLIVIER wrote (écrivait) :
Cela me ferais gagner un peu de temps et je suis sur des oublis, si vous m'en proposiez quelques un.
À toutes fins utiles, voici ci-dessous les champs que Thoth se propose d'utiliser pour filtrer les messages. Quant aux lignes d'en-tête d'article supplémentaires, c'est ad libitum et permet donc de mettre n'importe kwâ. À l'utilisateur de savoir ce qu'il fait, sans oublier le "X-", le cas échéant. Il fut un temps où on pouvait trouver dans fcsm, force messages vides. Tout était dans l'en-tête. resource 'MENU' (1002, "Filter Header Popup") { 1002, textMenuProc, 0x7FFFFDFD, enabled, "
In article (Dans l'article)
<1o9xs3d.6o5mv6xmczzgN%gilbert.olivier@orange.fr>, Gilbert OLIVIER
<gilbert.olivier@orange.fr> wrote (écrivait) :
Cela me ferais gagner un peu de temps et je suis sur des oublis, si vous
m'en proposiez quelques un.
À toutes fins utiles, voici ci-dessous les champs que Thoth se propose
d'utiliser pour filtrer les messages.
Quant aux lignes d'en-tête d'article supplémentaires, c'est ad libitum
et permet donc de mettre n'importe kwâ. À l'utilisateur de savoir ce
qu'il fait, sans oublier le "X-", le cas échéant.
Il fut un temps où on pouvait trouver dans fcsm, force messages vides.
Tout était dans l'en-tête.
In article (Dans l'article) <1o9xs3d.6o5mv6xmczzgN%, Gilbert OLIVIER wrote (écrivait) :
Cela me ferais gagner un peu de temps et je suis sur des oublis, si vous m'en proposiez quelques un.
À toutes fins utiles, voici ci-dessous les champs que Thoth se propose d'utiliser pour filtrer les messages. Quant aux lignes d'en-tête d'article supplémentaires, c'est ad libitum et permet donc de mettre n'importe kwâ. À l'utilisateur de savoir ce qu'il fait, sans oublier le "X-", le cas échéant. Il fut un temps où on pouvait trouver dans fcsm, force messages vides. Tout était dans l'en-tête. resource 'MENU' (1002, "Filter Header Popup") { 1002, textMenuProc, 0x7FFFFDFD, enabled, "
Matt
On sam. 29 juin 2019 (19:26), Gilbert OLIVIER wrote:
Les RFC c'est par là que j'ai commencé pour comprendre au mieux les headers, voir comment dialoguer avec le serveur... première étape obligatoire avant de se lancer dans un tel projet. Trouver les protocoles et savoir que l'on sait écrire le code pour se connecter au serveur et dialoguer avec lui ;-)
Laisser à l'utilisateur le choix d'afficher ce qu'il veut parmi tous les en-têtes disponibles reçus par le serveur et émis par le client me semble parfait et permettrait la même souplesse qu'offre beaucoup de lecteurs UseNet (tin, trn, slrn, Pan, Sylpheed, etc.) -- <@XaO> ma bite c'est un peu comme un monument au mort, on la regarde avec tristesse en se disant qu'on l'a pas connu assez longtemps <+Manu> la différence : le monument au morts est toujours dressé ! * bashfr.org
On sam. 29 juin 2019 (19:26),
Gilbert OLIVIER <gilbert.olivier@orange.fr> wrote:
Il y a bien la RFC 3977
et il n' a pas qu'elle
Eh oui : <http://tin.org/docs.html>
Les RFC c'est par là que j'ai commencé pour comprendre au mieux les
headers, voir comment dialoguer avec le serveur... première étape
obligatoire avant de se lancer dans un tel projet. Trouver les
protocoles et savoir que l'on sait écrire le code pour se connecter au
serveur et dialoguer avec lui ;-)
Laisser à l'utilisateur le choix d'afficher ce qu'il veut parmi tous les
en-têtes disponibles reçus par le serveur et émis par le client me
semble parfait et permettrait la même souplesse qu'offre beaucoup de
lecteurs UseNet (tin, trn, slrn, Pan, Sylpheed, etc.)
--
<@XaO> ma bite c'est un peu comme un monument au mort, on la regarde avec
tristesse en se disant qu'on l'a pas connu assez longtemps
<+Manu> la différence : le monument au morts est toujours dressé !
* bashfr.org
Les RFC c'est par là que j'ai commencé pour comprendre au mieux les headers, voir comment dialoguer avec le serveur... première étape obligatoire avant de se lancer dans un tel projet. Trouver les protocoles et savoir que l'on sait écrire le code pour se connecter au serveur et dialoguer avec lui ;-)
Laisser à l'utilisateur le choix d'afficher ce qu'il veut parmi tous les en-têtes disponibles reçus par le serveur et émis par le client me semble parfait et permettrait la même souplesse qu'offre beaucoup de lecteurs UseNet (tin, trn, slrn, Pan, Sylpheed, etc.) -- <@XaO> ma bite c'est un peu comme un monument au mort, on la regarde avec tristesse en se disant qu'on l'a pas connu assez longtemps <+Manu> la différence : le monument au morts est toujours dressé ! * bashfr.org
gilbert.olivier
Matt wrote:
Laisser à l'utilisateur le choix d'afficher ce qu'il veut parmi tous les en-têtes disponibles reçus par le serveur et émis par le client me semble parfait et permettrait la même souplesse qu'offre beaucoup de lecteurs UseNet (tin, trn, slrn, Pan, Sylpheed, etc.)
Heu, non, là ma demande était pour dans l'autre sens, j'ai du mal m'exprimer... Ma requête est ce que les "posteurs" ajoutent comme champs facultatif dans leurs messages afin d'en proposer la liste pour le paramétrage. Comme annoncé, il y a actuellement et il restera la possibilité de saisir manuellement le nom du champs désiré. Mais ce serait plus cool de le trouver dans un pop-up ;-) -- Gilbert
Matt <matt@lv426.eu.invalid> wrote:
Laisser à l'utilisateur le choix d'afficher ce qu'il veut parmi tous les
en-têtes disponibles reçus par le serveur et émis par le client me
semble parfait et permettrait la même souplesse qu'offre beaucoup de
lecteurs UseNet (tin, trn, slrn, Pan, Sylpheed, etc.)
Heu, non, là ma demande était pour dans l'autre sens, j'ai du mal
m'exprimer...
Ma requête est ce que les "posteurs" ajoutent comme champs facultatif
dans leurs messages afin d'en proposer la liste pour le paramétrage.
Comme annoncé, il y a actuellement et il restera la possibilité de
saisir manuellement le nom du champs désiré. Mais ce serait plus cool de
le trouver dans un pop-up ;-)
Laisser à l'utilisateur le choix d'afficher ce qu'il veut parmi tous les en-têtes disponibles reçus par le serveur et émis par le client me semble parfait et permettrait la même souplesse qu'offre beaucoup de lecteurs UseNet (tin, trn, slrn, Pan, Sylpheed, etc.)
Heu, non, là ma demande était pour dans l'autre sens, j'ai du mal m'exprimer... Ma requête est ce que les "posteurs" ajoutent comme champs facultatif dans leurs messages afin d'en proposer la liste pour le paramétrage. Comme annoncé, il y a actuellement et il restera la possibilité de saisir manuellement le nom du champs désiré. Mais ce serait plus cool de le trouver dans un pop-up ;-) -- Gilbert
mv
DV n'a pas hésité à écrire :
Supersedes (permet d'annuler ses propres articles)
Je ne crois pas, non. Le "Supersede" (quand les serveurs de news veulent bien l'accepter) sert à remplacer un article par un autre. L'annulation se fait plutôt avec "Cancel" (là aussi, ça dépend du bon vouloir des serveurs). Cordialement -- Michel VAUQUOIS - http://michelvauquois.fr
DV <dv@reply-to.not.invalid> n'a pas hésité à écrire :
Supersedes (permet d'annuler ses propres articles)
Je ne crois pas, non.
Le "Supersede" (quand les serveurs de news veulent bien l'accepter) sert
à remplacer un article par un autre.
L'annulation se fait plutôt avec "Cancel" (là aussi, ça dépend du bon
vouloir des serveurs).
Cordialement
--
Michel VAUQUOIS - http://michelvauquois.fr
Supersedes (permet d'annuler ses propres articles)
Je ne crois pas, non. Le "Supersede" (quand les serveurs de news veulent bien l'accepter) sert à remplacer un article par un autre. L'annulation se fait plutôt avec "Cancel" (là aussi, ça dépend du bon vouloir des serveurs). Cordialement -- Michel VAUQUOIS - http://michelvauquois.fr
DV
MV a écrit ceci :
DV n'a pas hésité à écrire :
Supersedes (permet d'annuler ses propres articles)
Je ne crois pas, non. Le "Supersede" (quand les serveurs de news veulent bien l'accepter) sert à remplacer un article par un autre. L'annulation se fait plutôt avec "Cancel" (là aussi, ça dépend du bon vouloir des serveurs).
Tout à fait, j'ai fait un malencontreux amalgame entre les deux actions. Merci d'avoir rectifié. -- Denis
MV a écrit ceci :
DV <dv@reply-to.not.invalid> n'a pas hésité à écrire :
Supersedes (permet d'annuler ses propres articles)
Je ne crois pas, non.
Le "Supersede" (quand les serveurs de news veulent bien l'accepter) sert
à remplacer un article par un autre.
L'annulation se fait plutôt avec "Cancel" (là aussi, ça dépend du bon
vouloir des serveurs).
Tout à fait, j'ai fait un malencontreux amalgame entre les deux actions.
Merci d'avoir rectifié.
Supersedes (permet d'annuler ses propres articles)
Je ne crois pas, non. Le "Supersede" (quand les serveurs de news veulent bien l'accepter) sert à remplacer un article par un autre. L'annulation se fait plutôt avec "Cancel" (là aussi, ça dépend du bon vouloir des serveurs).
Tout à fait, j'ai fait un malencontreux amalgame entre les deux actions. Merci d'avoir rectifié. -- Denis
