dev@xmlfr.org : liste de discussion des développeurs du site XMLfr
[dev@xmlfr.org] Re: mailing-list
From: Eric van der Vlist (vdv@dyomedea.com)
Date: 28/01/2004 - 09:04
On Tue, 2004-01-27 at 16:54, frederic.glorieux@ajlsm.com wrote:
> [ecartis]
> > Ce que je lui reproche le plus est de ne pas avoir une vision d'ensemble
> > sur ce qui se passe sur les différentes listes qu'il traite comme si
> > elles étaient totalement indépendantes.
> >
> > Cela veut dire qu'un abonné doit se déclarer en vacances sur toutes les
> > listes sur lesquelles il est abonné et que lorsqu'un abonné est effacé
> > parce que les mails qui lui sont envoyés reviennent en erreur, il est
> > effacé liste par liste.
>
> > Je pense qu'une gestion des utilisateurs "orthogonale" à celle des
> > listes serait nettement plus pertinente.
>
> C'est la logique de Sympa, sur un SQL ou un LDAP. Mailman en parle pour
> sa version 3.
Il me semble qu'on peut imaginer des fonctionnements intéressants qui
dissocieraient plus les droits de poster des abonnements en s'inspirant
notamment du gestionnaire de liste utilisé par le W3C.
Aujourd'hui, si vous voulez poser une question sur xml-tech, il faut
d'abord vous abonner et cela pour deux raisons principales :
* C'est un moyen efficace de lutter contre le spam : très peu de
spammeurs savent s'inscrire sur les listes avant de poster (mais
cela commence à se répandre)
* C'est une manière de faire en sorte que celui qui pose la
question reçoive les réponses.
Imaginons maintenant un système un peu plus intelligent...
En réception d'un mail, ce système pourrait commencer par faire analyser
le mail par un anti spam. Si c'est du spam, il pourrait faire parvenir
le message à un administrateur avec un titre particulier permettant de
filtrer ce type de messages. Il pourrait filtrer les auto-reply de la
même manière.
Sinon, il pourrait regarder si l'émetteur a déjà posté un message qui a
été approuvé sur une des listes gérées par le système. Si c'est le cas,
il pourrait diffuser le message (et lui diffuser les réponses à sa
question) que l'émetteur soit abonné ou non.
Si l'émetteur est sur "liste noire" il pourrait envoyer le message aux
administrateur.
Enfin, si l'émetteur n'est pas connu, il pourrait lui envoyer un message
l'informant que, s'agissant d'un premier message, celui-ci va être
modéré.
Ce message aurait en fait deux rôles : prendre gentiment contact avec
l'émetteur, mais aussi voir si son adresse email est correcte. La
réception d'un message d'erreur dans les quelques minutes indique avec
une probabilité très forte qu'il s'agit d'un spammeur ou d'une erreur de
config et le message peut être traité comme tel. Si au bout de quelques
minutes nous n'avons pas reçu d'erreur, nous pouvons par contre envoyer
le message au modérateur en lui indiquant qu'il a de bonnes chances
d'être correct.
Il me semble qu'un tel système serait beaucoup plus agréable à utiliser
pour les utilisateurs mais aussi pour les administrateurs sans être
beaucoup plus complexe que les systèmes actuels.
> [ecartis: interface web]
> > Oui, mais assez rudimentaire.
>
> (ecartis.org ne répond toujours pas). Donc, pas pour mes usagers. Il ne
> faut pas négliger le temps nécessaire à s'habituer à une interface web.
>
> >>Je me dis qu'avec un pipe cocoon, on peut arriver à attraper des choses
> >>?
>
> > Oui, on peut faire beaucoup de choses, comme par exemple aller
> > directement interroger un serveur mail IMAP ou lire des "folders" mail.
>
> Mais au fond, un reader cocoon reviendrait probablement à recoder ou
> brancher une sorte d'hypermail ?
>
> En cherchant, j'ai touvé ce comparatif
> <http://www.oac.uci.edu/indiv/ehood/MHonArc/doc/faq/general.html#whatis>
>
> <http://eyebrowse.tigris.org/> semblerait plus lié à JAVA, j'ai
> d'ailleurs trouvé des messages de Mazzochi dans leurs archives. C'est
> beau, mais même chez apache, ça à l'air lent, à moins que je ne sois le
> premier à aller voir les archives par ce canal.
>
> Sympa est MHonAr.
>
> > Je ne sais plus comment la discussion en était arrivé là, mais lors du
> > dernier sparklingPoint, quelqu'un a dit à juste titre que les outils
> > mails (individuels ou collectifs) idéaux restaient encore à inventer...
>
> sparklingPoint ? J'ai vu sur un vos de sites. Intéressant, un point de
> rencontre pour voir ailleurs qu'en XML.
Oui, les rencontres y sont toujours intéressantes!
> > Ecartis est également assez figé sur les formats des messages d'erreurs
> > qu'il comprend et il n'y a pas moyen de lui "apprendre" à comprendre des
> > messages sortant de l'ordinaire.
>
> Comme le junk mail de Mozilla ?
Non, je pensais plutôt aux messages d'erreurs non conformes aux specs
qui sont hélas envoyés par beaucoup de serveurs. Ils ne sont pas compris
par ecartis et dans ce cas, le traitement des désabonnements doit être
manuel...
Eric
--
Tired to type XML tags?
http://wikiml.org
Upcoming XML schema languages tutorial:
- Santa Clara -half day- (15/03/2004) http://masl.to/?J24916E96
------------------------------------------------------------------------
Eric van der Vlist http://xmlfr.org http://dyomedea.com
(ISO) RELAX NG ISBN:0-596-00421-4 http://oreilly.com/catalog/relax
(W3C) XML Schema ISBN:0-596-00252-1 http://oreilly.com/catalog/xmlschema
------------------------------------------------------------------------
--
Devenez redacteur <XML>fr et contribuez au developpement du
xml francophone (http://xmlfr.org/infos/redacteurs/) !
Liste de diffusion "dev@xmlfr.org" (http://xmlfr.org).
Cette liste est a votre disposition pour discuter en francais de
tout sujet technique lie au developpement du site XMLfr.
Pour resilier votre abonnement, envoyez un message contenant
la commande "unsubscribe" a dev-request@xmlfr.org
(mailto:dev-request@xmlfr.org?Subject=unsubscribe)
Archive générée par hypermail 2.1.3 le 28/01/2004 - 09:12 UTC
webmaster@xmlfr.org
|
