POSS Chap 3 Part 2

Un article de Framalang Wiki.

Jump to: navigation, search
Pseudo Code Rôle Statut
GaeliX GLX Traduction Terminé
Olivier OLV Traduction Terminé
Olivier OLV Relecture Terminé
??? Validation

Sommaire

[modifier] Mailing lists

Mailing lists are the bread and butter of project communications. If a user is exposed to any forum besides the Web pages, it is most likely to be one of the project's mailing lists. But before they experience the mailing list itself, they will experience the mailing list interface—that is, the mechanism by which they join ("subscribe to") the list. This brings us to Rule #1 of mailing lists:

Don't try to manage mailing lists by hand—get list management software.

It will be tempting to put this off. Setting up mailing list management software might seem like overkill at first. Managing small, low-traffic lists by hand will seem seductively easy: you just set up a subscription address that forwards to you, and when someone mails it, you add (or remove) their e-mail address in some text file that holds all the addresses on the list. What could be simpler?

The trick is that good mailing list management—which is what people have come to expect—is not simple at all. It's not just about subscribing and unsubscribing users when they request. It's also about moderating to prevent spam, offering the mailing list in digest versus message-by-message form, providing standard list and project information by means of auto-responders, and various other things. A human being monitoring a subscription address can supply only a bare minimum of functionality, and even then not as reliably and promptly as software could.

Modern list management software usually offers at least the following features:

Both e-mail- and Web-based subscription

When a user subscribes to a list, she should promptly get an automated welcome message in reply, telling her what she has subscribed to, how to interact further with the mailing list software, and (most importantly) how to unsubscribe. This automatic reply can be customized to contain project-specific information, of course, such as the project's Web site, FAQ location, etc.

Subscription in either digest mode or message-by-message mode

In digest mode, the subscriber receives one e-mail per day, containing all the list activity for that day. For people who are following a list loosely, without participating, digest mode is often preferable, because it allows them to scan all the subjects at once and avoid the distraction of e-mails coming in at random times.

Moderation features

To "moderate" is to check posts to make sure they are a) not spam, and b) on topic, before they go out to the entire list. Moderation necessarily involves humans, but software can do a lot to make it easier. There is more said about moderation later.

Administrative interface

Among other things, this enables an administrator to go in and remove obsolete addresses easily. This can become urgent when a recipient's address starts sending automatic "I am no longer at this address" replies back to the list in response to every list post. (Some mailing list software can even detect this by itself and unsubscribe the person automatically.)

Header manipulation

Many people have sophisticated filtering and replying rules set up in their mail readers. Mailing list software can add and manipulate certain standard headers for these people to take advantage of (more details below).

Archiving

All posts to the managed lists are stored and made available on the Web; alternatively, some mailing list software offers special interfaces for plugging in an external archiving tool such as MHonArc (http://www.mhonarc.org/). As the section called “Conspicuous Use of Archives” in Chapter 6, Communications discusses, archiving is crucial.

The point of all this is merely to emphasize that mailing list management is a complex problem that has been given a lot of thought, and mostly been solved. You certainly don't need to become an expert in it. But you should be aware that there's always room to learn more, and that list management will occupy your attention from time to time in the course of running a free software project. Below we'll examine a few of the most common mailing list configuration issues.

Les listes de diffusion

Les listes de diffusion sont la base de la communication au sein d'un projet. Si un utilisateur est confronté à un forum, hormis les pages Web, il y a de fortes chances que ce soit une des listes de diffusion du projet. Mais avant d'expérimenter la liste de diffusion elle-même, il sera en contact avec l'interface de la liste de diffusion ; c'est à dire le mécanisme par lequel il peut rejoindre la liste (« souscrire »). Ceci nous amène à la règle #1 des listes de diffusion : ne pas essayer de gérer une liste de diffusion à la main ; se procurer une logiciel de gestion de listes.

Il serait tentant de repousser cela à plus tard. L'installation d'un logiciel de gestion de listes peut sembler peu rentable en terme de temps au début. Gérer à la main de petites listes générant peu de trafic semble séduisant : établissez simplement une adresse d'abonnement qui redirige vers votre boite mail et quand quelqu'un l'utilise ajoutez (ou enlevez) son adresse mail dans un fichier texte qui contient toutes les adresses de la liste. Qu'y a-t-il de plus simple ?

Le hic, c'est qu'une bonne gestion de listes de diffusion, ce que les gens sont en droit d'attendre, n'est pas simple du tout. Il ne s'agit pas simplement d'abonner et de désabonner les utilisateurs quand ils demandent. Il s'agit également de faire de la modération pour empêcher le spam, d'offir des versions résumées et message par message, de fournir de l'information standard et de l'information orientée projet grâce à des messages pré-écrits, ainsi que diverses autres choses. Un être d'humain gérant lui-même une adresse de souscription ne peut assurer que le strict minimum, et même en cela il n'est pas aussi fiable et performant qu'un logiciel.

Les logiciels modernes de gestion de liste offrent au moins les fonctionnalités suivantes :

Inscription par e-mail et par le Web

Quand un utilisateur s'abonne à une liste il devrait recevoir rapidement un message d'accueil automatique en réponse, lui indiquant ce à quoi il s'est abonné, quels sont les possibilités qu'offre le logiciel de liste de diffusion et (ce qui est le plus important) comme se désincrire. Bien sûr, cette réponse automatique peut être personnalisée pour donner plus d'informations sur le projet, comme par exemple l'adresse du projet, où trouver la FAQ, etc.

L'abonnement en mode résumé ou message par message

En mode résumé, l'abonné reçoit un courrier par jour contenant toutes les activités du jour de la liste. Pour les gens qui suivent une liste de manière détachée, sans participer, le mode résumé est souvent préférable car il permet de survoler rapidement tous les sujets et évite la distraction de recevoir des e-mails à n'importe quel moment.

Les possibilités de modération

La modération sert à vérifier les messages pour s'assurer que ce n'est pas a) du spam et b) hors sujet avant qu'ils ne soient envoyés à la liste entière. La modération demande une intervention humaine, mais les logiciels peuvent mâcher une grosse partie du travail. Nous en dirons plus sur la modération plus tard.

Interface administrative

L'interface administrative permet, entre autres choses, à l'administrateur de retirer les adresses obsolètes facilement. Cela peut devenir urgent quand l'adresse d'un destinataire commence à renvoyer automatiquement des messages du type « Je ne suis plus à cette adresse » à la liste à chaque e-mail. (Certains logiciels de listes de diffusion peuvent même les détecter seuls et désabonner ces personnes automatiquement.)

Manipulation des en-têtes

Beaucoup de gens ont mis en place des filtrages sophistiqués et des règles de réponse dans leur logiciel de messagerie. Les logiciels de listes de diffusion peuvent ajouter et manipuler certaines en-têtes standards pour permettre à ces personnes d'en tirer partie (plus de détails plus tard).

Archivage

Tous les messages des listes sont enregistrés et mis à disposition sur le Web, certains logiciels de listes de diffusion proposent des interfaces spéciales pour s'interfacer avec des utilitaires d'archivage tiers comme MHonArc (http://www.mhonarc.org/). Comme nous le verrons dans la section « Utilisation visible des archives » dans le Chapitre 6, Communication, l'archivage est crucial.

Ce que vous devez retenir ici est que la gestion des listes de diffusion est un problème complexe qui a déjà reçu beaucoup d'attention et qui a été en grande partie résolu. Vous n'êtes pas obligé de devenir expert sur le sujet mais vous devriez savoir qu'il y a toujours de nouvelles choses à découvrir et que la gestion des listes demandera votre attention de temps à autres au cours de la vie de votre projet de logiciel libre. Ci-dessous nous allons examiner quelques uns des principaux problèmes rencontrés lors de la configuration des listes de diffusion.

[modifier] Spam Prevention / Se prémunir du spam

Between when this sentence is written and when it is published, the Internet-wide spam problem will probably double in severity—or at least it will feel that way. There was a time, not so long ago, when one could run a mailing list without taking any spam-prevention measures at all. The occasional stray post would still show up, but infrequently enough to be only a low-level annoyance. That era is gone forever. Today, a mailing list that takes no spam prevention measures will quickly be submerged in junk e-mails, to the point of unusability. Spam prevention is mandatory.

We divide spam prevention into two categories: preventing spam posts from appearing on your mailing lists, and preventing your mailing list from being a source of new e-mail addresses for spammers' harvesters. The former is more important, so we examine it first.

Entre le moment où j'écris cette phrase et le moment où elle sera publiée, le problème du spam sur Internet aura sûrement pris des proportions beaucoup plus importantes ou, en tout cas, on le ressentira comme tel. Il fut un temps, il n'y a pas si longtemps, où l'on pouvait créer une liste de diffusion sans avoir à prendre de mesures de protection contre le spam. De temps en temps on pouvait recevoir un mail égaré, mais c'était suffisamment rare pour que cela reste peu gênant. Cette période est perdue à jamais. De nos jours, une liste de diffusion qui ne se prémunie pas contre le spam sera rapidement noyée sous les mails indésirables, au point qu'elle devienne inutilisable. Les protections contre le spam sont indispensables.

On peut séparer les protections contre le spam en deux catégories : celles qui empêchent les courriers indésirables d'apparaître sur la liste de diffusion et celles qui protègent les listes de diffusions contre les collecteurs d'adresses des spammeurs. La première étant la plus importante c'est celle que nous allons détailler en premier.

[modifier] Filtering posts / Filtrer les messages

There are three basic techniques for preventing spam posts, and most mailing list software offers all three. They are best used in tandem: 

  1.

     Only auto-allow postings from list subscribers.

     This is effective as far as it goes, and also involves very little administrative overhead, since it's usually just a matter of changing a setting in the mailing list software's configuration. But note that posts which aren't automatically approved must not be simply discarded. Instead, they should be passed along for moderation, for two reasons. First, you want to allow non-subscribers to post. A person with a question or suggestion should not need to subscribe to a mailing list just to make a single post there. Second, even subscribers may sometimes post from an address other than the one by which they're subscribed. Email addresses are not a reliable method of identifying people, and shouldn't be treated as such.
  2.

     Filter posts through spam-filtering software.

     If the mailing list software makes it possible (most do), you can have posts filtered by spam-filtering software. Automatic spam-filtering is not perfect, and never will be, since there is a never-ending arms race between spammers and filter writers. However, it can greatly reduce the amount of spam that gets through to the moderation queue, and since the longer that queue is the more time humans must spend examining it, any amount of automated filtering is beneficial.

     There is not space here for detailed instructions on setting up spam filters. You will have to consult your mailing list software's documentation for that (see the section called “Software” later in this chapter). List software often comes with some built-in spam prevention features, but you may want to add some third-party filters. I've had good experiences with these two: SpamAssassin (http://spamassassin.apache.org/) and SpamProbe (http://spamprobe.sourceforge.net/). This is not a comment on the many other Open Source spam filters out there, some of which are apparently also quite good. I just happen to have used those two myself and been satisfied with them.
  3.

     Moderation.

     For mails that aren't automatically allowed by virtue of being from a list subscriber, and which make it through the spam filtering software, if any, the last stage is moderation: the mail is routed to a special address, where a human examines it and confirms or rejects it.

     Confirming a post takes one of two forms: you can accept the post just this once, or you can tell the list software to allow this and all future posts from the same sender. You almost always want to do the latter, in order to reduce the future moderation burden. Details on how to confirm vary from system to system, but it's usually a matter of replying to a special address with the command "accept" (meaning accept just this one post) or "allow" (allow this and future posts).

     Rejecting is usually done by simply ignoring the moderation mail. If the list software never receives confirmation that something is a valid post, then it won't pass that post on to the list, so simply dropping the moderation mail achieves the desired effect. Sometimes you also have the option of responding with a "reject" or "deny" command, to automatically disapprove future mails from the same sender without even running them through moderation. There is rarely any point doing this, since moderation is mostly about spam prevention, and spammers tend not to send from the same address twice anyway.
Be sure to use moderation only for filtering out spams and clearly off-topic messages, such as when someone accidentally posts to the wrong mailing list. The moderation system will usually give you a way to respond directly to the sender, but don't use that method to answer questions that really belong on the mailing list itself, even if you know the answer off the top of your head. To do so would deprive the project's community of an accurate picture of what sorts of questions people are asking, and deprive them of a chance to answer questions themselves and/or see answers from others. Mailing list moderation is strictly about keeping the list free of junk and off-topic e-mails, nothing more.

Il existe trois techniques de base pour éviter les messages indésirables et la plupart des logiciels de listes de diffusions les proposent tous les trois. Il vaut mieux les utiliser de concert :

1. Autoriser automatiquement les messages uniquement envoyé par les abonnés.

Cette méthode remplit très bien son rôle et ne demande que peu de travail puisqu'en général il suffit de modifier un paramètre dans les réglages du logiciel de liste de diffusion. Mais prenez garde, les messages qui ne sont pas automatiquement approuvés ne doivent pas être rejetés pour autant. Ils devraient subir une inspection pour deux raisons. D'abord vous feriez mieux de laisser la possibilité aux non-abonnés d'envoyer des messages. Une personne ayant une question ou une idée à soumettre ne devrait pas avoir besoin de s'inscrire à la liste de diffusion juste pour y envoyer un message. Ensuite, même les abonnés envoient parfois des messages depuis d'autres adresses que celle qu'ils ont utilisées pour s'inscrire. Les adresses mails ne sont pas une méthode sure pour identifier les personnes et par conséquent ne doivent pas servir à cela.


2. Filtrer les messages grâce à un logiciel de filtrage.

Si la liste de diffusion le permet (la plupart le font), vous pouvez filtrer les messages grâce à un logiciel de filtrage de spam. Le filtrage automatique des spams n'est pas parfait et ne le sera jamais comme les spammers et les développeurs de filtres se sont engagés dans une course à l'armement sans fin. Malgré cela le filtre peut largement réduire le nombre de spams en attente de modération. Comme la longueur de la liste d'attente se traduit en temps de travail manuel, tout gain obtenu a ce niveau grâce au filtrage automatique est profitable.

Je ne peux pas détailler ici comment mettre en place des filtres à spam. Je vous renvoie donc à la documentation de votre logiciel de liste de diffusion pour en savoir plus (voir la section appelée « Logiciel » plus loin dans ce chapitre). Les logiciels de liste de diffusion incluent souvent des fonctionnalités anti-spam mais vous pouvez aussi choisir d'utiliser un programme de filtrage tiers. J'apprécie ces deux programmes : SpamAssassin (http://spamassassin.apache.org/) et SpamProbe (http://spamprobe.sourceforge.net/). Je ne ferai pas de liste exhaustive, il existe bien d'autres logiciels de filtrage de spam Open Source et certains semblent également très performants. C'est simplement que j'ai utilisé moi même les deux logiciels pré-cités et j'en ai été très satisfait.

3. Modération

En ce qui concerne les courriers qui ne sont pas automatiquement admis parce qu'ils n'émanent pas d'un abonné et qui passent au travers du logiciel anti-spam, s'il y en a, la dernière étape est la modération : le mail est redirigé vers une adresse spéciale où une personne l'examinera et l'acceptera ou le rejettera.

Accepter un message peut se faire de deux manières différentes : vous pouvez autoriser le message juste cette fois ou encore dire au logiciel de liste de diffusion de laisser passer dans le futur tous les messages de cet expéditeur. En général c'est la deuxième option qui est favorisée afin de faciliter la tâche de modération à l'avenir. La manière de procéder est différente selon les systèmes, mais en général il faut répondre à une adresse particulière en incluant la commande « accepter » (ce qui signifie « accepter uniquement ce message ») ou « autoriser » (autoriser ce message ainsi que tous les futurs messages).

Le rejet se fait en général simplement en ignorant le courrier de modération. Si le logiciel de la liste de diffusion ne reçoit jamais de consigne pour dire qu'un message est valide alors il ne fera pas suivre ce message sur la liste, laisser le message de côté aura donc l'effet désiré. Il arrivera aussi parfois que vous ayez la possibilité de répondre avec une commande « rejeter » ou « empêcher » pour rejeter automatiquement et de façon permanente les messages de cet utilisateur sans même qu'ils ne repassent par la case « Modération ». En général ce n'est pas très utile puisque la modération sert principalement à éviter le spam et que les spammeurs utilisent rarement la même adresse deux fois de toute façon.

La modération doit servir uniquement au filtrage des spams et des messages hors-sujet, comme par exemple lorsque quelqu'un envoie un message sur la mauvaise liste de diffusion. Le système de modération devrait vous fournir un moyen de répondre directement à l'expéditeur, mais n'employez pas cette méthode pour répondre directement à une question adressée à la liste de diffusion, même si vous pouvez fournir une réponse rapidement. Fonctionner ainsi empêcherait le projet de se faire une idée précise du genre de questions que les gens se posent et enlèverait aux membres l'occasion de répondre aux questions eux-mêmes et/ou de voir les réponses des autres. La modération des listes de diffusion doit se restreindre à l'entretien de la liste de diffusion, rien d'autre.

[modifier] Address hiding in archives / Masquer les adresses dans les archives

To prevent your mailing lists from being a source of addresses for spammers, a common technique is for the archives to obscure people's e-mail addresses, for example by replacing 

   jrandom@somedomain.com

with 

   jrandom_AT_somedomain.com

or 

   jrandomNOSPAM@somedomain.com

or some similarly obvious (to a human) encoding. Since spam address harvesters often work by crawling through Web pages—including your mailing list's online archives—and looking for sequences containing "@", encoding the addresses is a way of making people's e-mail addresses invisible or useless to spammers. This does nothing to prevent spam from being sent to the mailing list itself, of course, but it does avoid increasing the amount of spam sent directly to list users' personal addresses.

Address hiding can be controversial. Some people like it a lot, and will be surprised if your archives don't do it automatically. Other people think it's too much of an inconvenience (because humans also have to translate the addresses back before using them). Sometimes people assert that it's ineffective, because a harvester could in theory compensate for any consistent encoding pattern. However, note that there is empirical evidence that address hiding is effective, see http://www.cdt.org/speech/spam/030319spamreport.shtml.

Ideally, the list management software would leave the choice up to each individual subscriber, either through a special yes/no header or a setting in that subscriber's list account preferences. However, I don't know of any software which offers per-subscriber or per-post choice in the matter, so for now the list manager must make a decision for everyone (assuming the archiver offers the feature at all, which is not always the case). I lean very mildly toward turning address hiding on. Some people are very careful to avoid posting their e-mail addresses on Web pages or anywhere else a spam harvester might see it, and they would be disappointed to have all that care thrown away by a mailing list archive; meanwhile, the inconvenience address hiding imposes on archive users is very slight, since it's trivial to transform an obscured address back to a valid one if you need to reach the person. But keep in mind that, in the end, it's still an arms race: by the time you read this, harvesters might well have evolved to the point where they can recognize most common forms of hiding, and we'll have to think of something else.

Pour éviter que vos listes de diffusion ne deviennent une mine d'adresses pour les spammeurs, une technique courante est de masquer les adresses e-mail des personnes dans les archives en remplaçant par exemple 

   a.nonyme@undomaine.com

par 

   a.nonyme_AT_undomaine.com

ou par 

   a.nonymeNOSPAM@undomaine.com

ou d'autres codes similaires évidents pour un humain. Comme les collecteurs d'adresses à spammer fonctionnent souvent en naviguant sur les pages Web, y compris vos archives en ligne des listes de diffusion, à la recherche de séquences contenant « @ », coder les adresses est une manière de rendre les adresses e-mail invisibles ou inutilisables par les spammeurs. Cela ne change rien à la quantité de spam envoyée directement à la liste de diffusion évidemment, mais au moins vous évitez d'augmenter encore la quantité de spams envoyés directement aux utilisateurs des listes. Le masquage d'adresse peut être sujet à controverse. Certaines personnes apprécient beaucoup cette technique et seront surprises si vos archives ne le font pas automatiquement. D'autres pensent plutôt que c'est un désagrément (parce que les vraies personnes doivent aussi traduire les adresses avant de les utiliser). Certains doutent de l'efficacité de la méthode puisqu'un collecteur peut en théorie s'adapter aux codes les plus répandus. Notez malgré tout que par expérience le masquage d'adresse se montre efficace, voir http://www.cdt.org/speech/spam/030319spamreport.shtml.

Idéalement le programme de gestion de listes devrait laisser le choix à chaque abonné, grâce à une en-tête oui/non ou un paramètre dans les préférences du compte de l'abonné. Mais je ne connais aucun logiciel qui donne un choix individuel ou par message, donc pour l'instant le responsable des listes doit faire ce choix pour tout le monde (en supposant que le logiciel d'archivage propose cette option, ce qui n'est pas toujours le cas). Je penche légèrement en faveur du masquage d'adresse. Certaines personnes sont très prudentes et n'affichent par leur adresse e-mail sur les pages Web ou n'importe où un collecteur d'adresse pourrait tomber dessus et elles seraient déçues de voir tous les efforts réduits à néant par une archive de liste de diffusion, en même temps, le désagrément imposé aux utilisateurs des archives par le masquage est très faible puisqu'il est très simple de « traduire » ces adresses si vous avez besoin de contacter quelqu'un. Mais n'oubliez pas qu'au final ça reste une course à l'armement : au moment où vous lirez ceci les collecteurs auront peut-être évolués au point qu'ils pourront reconnaître les techniques classiques de masquage d'adresse mail et alors nous devrons trouver une autre solution.

[modifier] Identification and Header Management / Identification et gestion des en-têtes

List subscribers often want to put mails from the list into a project-specific folder, separate from their other mail. Their mail reading software can do this automatically by examining the mail's headers. The headers are the fields at the top of the mail that indicate the sender, recipient, subject, date, and various other things about the message. Certain headers are well known and effectively mandatory:

From: ... To: ... Subject: ... Date: ...

Others are optional, though still quite standard. For example, e-mails are not strictly required to have the

Reply-to: sender@e-mail.address.here

header, but most do, because it gives recipients a foolproof way to reach the author (it is especially useful when the author had to send from an address other than the one to which replies should be directed).

Some mail reading software offers an easy-to-use interface for filing mails based on patterns in the Subject header. This leads people to request that the mailing list add an automatic prefix to all Subjects, so they can set their readers to look for that prefix and automatically file the mails in the right folder. The idea is that the original author would write:

Subject: Making the 2.5 release.

but the mail would show up on the list looking like this:

Subject: [discuss@lists.example.org] Making the 2.5 release.

Although most list management software offers the option to do this, I strongly recommend against turning the option on. The problem it solves can easily be solved in much less obtrusive ways, and the cost of eating space in the Subject field is far too high. Experienced mailing list users typically scan the Subjects of the day's incoming list mail to decide what to read and/or respond to. Prepending the list's name to the Subject can push the right side of the Subject off the screen, rendering it invisible. This obscures information that people depend on to decide what mails to open, thus reducing the overall functionality of the mailing list for everyone.

Instead of munging the Subject header, teach your users to take advantage of the other standard headers, starting with the To header, which should say the mailing list's name:

To: <discuss@lists.example.org>

Any mail reader that can filter on Subject should be able to filter on To just as easily.

There are a few other optional-but-standard headers expected for mailing lists. Filtering on these is even more reliable than using the "To" or "Cc" headers; since these headers are added to each post by the mailing list management software itself, some users may be counting on their presence:

list-help: <mailto:discuss-help@lists.example.org> list-unsubscribe: <mailto:discuss-unsubscribe@lists.example.org> list-post: <mailto:discuss@lists.example.org> Delivered-To: mailing list discuss@lists.example.org Mailing-List: contact discuss-help@lists.example.org; run by ezmlm

For the most part, they are self-explanatory. See http://www.nisto.com/listspec/list-manager-intro.html for more explanation, or if you need the really detailed, formal specification, see http://www.faqs.org/rfcs/rfc2369.html.

Notice how these headers imply that if you have a mailing list named "list", then you also have administrative addresses "list-help" and "list-unsubscribe" available. In addition to these, it is normal to have "list-subscribe", for joining, and "list-owner", for reaching the list administrators. Depending on the list management software you use, these and/or various other administrative addresses may be set up; the documentation will have details. Usually a complete explanation of all these special addresses is mailed to each new user as part of an automated "welcome mail" on subscribing. You yourself will probably get a copy of this welcome mail. If you don't, then ask someone else for a copy, so you know what your users are seeing when they join the list. Keep the copy handy so you can answer questions about the mailing list functions, or better yet, put it on a Web page somewhere. That way when people lose their own copy of the instructions and post to ask "How do I unsubscribe from this list?", you can just hand them the URL.

Some mailing list software offers an option to append unsubscription instructions to the bottom of every post. If that option is available, turn it on. It causes only a couple of extra lines per message, in a harmless location, and it can save you a lot of time, by cutting down on the number of people who mail you—or worse, mail the list!—asking how to unsubscribe.

Les utilisateurs des listes rangeront souvent les messages dans des dossiers réservés au projet, séparés de leurs autres courriers. Leur logiciel de lecture de courrier peut faire cela automatiquement en vérifiant les en-têtes du message. Les en-têtes sont le champs au début du courrier qui indiquent l'expéditeur, le destinataire, le sujet, la date et d'autres informations à propos du message. Certaines en-têtes sont bien connues et obligatoires :

De : ...

A : ...

Sujet : ...

Date : ...

D'autres sont optionnels bien que plutôt courants. Par exemple vous n'êtes pas obligés de remplir l'en-tête Répondre à : expéditeur@adresse.e-mail.ici mais la plupart des gens le font puisque cela permet au destinataire de répondre de manière certaine à l'auteur du message (c'est particulièrement utile si l'auteur a du recourir à une autre adresse que celle à laquelle les réponses devraient être adressées). Certains logiciels de courrier fournissent une interface simple d'emploi pour trier les messages en fonction du sujet. Certaines personnes demandent par conséquent que les listes de diffusions ajoutent automatiquement un préfixe aux sujets afin que leur logiciel puisse automatiquement ranger ces messages dans le bon dossier. L'idée est que l'auteur du message écrive :

Sujet : Préparation de la version 2.5

mais que le message au final soit envoyé sous cette forme :

Sujet : [discussion@listes.exemple.org] Préparation de la version 2.5 (par exemple).

Bien que la plupart des logiciels de gestion de listes de diffusion proposent cette option je ne vous recommande pas de l'activer. Le problème réglé ici peut l'être par des moyens beaucoup moins marquée et le prix à payer, l'utilisation de l'espace dans le champ « Sujet », est bien trop élevé. Les utilisateurs habitués aux listes de diffusion passent en général en revue les sujets des messages pour décider ce qu'ils vont lire et ce à quoi ils vont répondre. Ajouter le nom de la liste au sujet peut repousser la partie importante du sujet hors de l'écran, la rendant ainsi invisible. Cela masque les informations sur lesquels les gens se reposent durant leur inspection des sujets, réduisant par conséquent l'utilité de la liste de diffusion. Plutôt que de grignoter une partie du champ « Sujet », enseignez aux utilisateurs à utiliser les autres champs, en commençant par le champ « A : » qui devrait afficher le nom de la liste :

A : <discussion@listes.exemple.org>.

N'importe quel logiciel de messagerie pouvant filtrer les sujets devrait également pouvoir filtrer le champ « A : » aussi facilement. D'autres champs optionnels sont en général remplis pour les listes de diffusion. Baser le filtrage sur ces champs est encore plus efficace que d'utiliser les champs « A : » ou « Cc » puisque ces champs sont remplis automatiquement par le logiciel de la liste de diffusion, certains utilisateurs s'attendent à les trouver :

list-help: <mailto:discuss-help@lists.example.org>

list-unsubscribe: <mailto:discuss-unsubscribe@lists.example.org>

list-post: <mailto:discuss@lists.example.org>

Delivered-To: mailing list discuss@lists.example.org

Mailing-List: contact discuss-help@lists.example.org; run by ezmlm

Pour la plupart leur sens est transparent. Voir http://www.nisto.com/listspec/list-manager-intro.html pour plus d'informations ou si vous cherchez des spécifications vraiment détaillées et formelles voir http://www.faqs.org/rfcs/rfc2369.html.

Vous remarquerez que ces champs insinuent que si vous avez une liste nommée « list », alors vous possédez aussi les listes administratives « list-help » et « list-unsubscribe ». En plus de celles-ci il est normal que vous proposiez « list-subscribe » pour s'inscrire et « list-owner » pour contacter les administrateurs des listes. En fonction du logiciel que vous utilisez pour gérer vos listes ces adresses et/ou plusieurs autres adresses administratives peuvent être mises en place, vous trouverez des explications dans la documentation. En général, un descriptif complet de toutes ces adresses spéciales est communiqué à chaque nouvel utilisateur au sein d'un message de bienvenue lors de l'inscription. Vous recevrez aussi certainement une copie de ce courrier. Si vous ne le recevez pas alors demandez en une copie à quelqu'un afin de savoir ce que reçoive les utilisateurs lorsqu'ils s'inscrivent à une liste. Gardez ce message à porté afin que vous puissiez répondre aux questions à propos des fonctions de la liste de diffusion ou, encore mieux, affichez le sur une page Web afin que quand quelqu'un perd sa copie des instructions et envoi un message demandant comment il peut se désinscrire vous n'ayez qu'à lui envoyer l'URL.

Certains logiciels de liste de diffusion possèdent une option pour ajouter les instructions pour se désabonner à chaque message. Si cette option est présente activez là. Cela n'ajoute que quelques lignes au message, ne gène pas sa lecture et peut vous faire gagner beaucoup de temps en évitant que les gens vous écrive, ou pire encore, écrive à toute la liste, pour demander comment se désinscrire.

[modifier] The Great Reply-to Debate / Le grand débat du « Répondre à »

Earlier, in the section called “Avoid Private Discussions”, I stressed the importance of making sure discussions stay in public forums, and talked about how active measures are sometimes needed to prevent conversations from trailing off into private e-mail threads; furthermore, this chapter is all about setting up project communications software to do as much of the work for you as possible. Therefore, if the mailing list management software offers a way to automatically cause discussions to stay on the list, you would think turning that feature on would be the obvious choice.

Well, not quite. There is such a feature, but it has some pretty severe disadvantages. The question of whether or not to use it is one of the hottest debates in mailing list management—admittedly, not a controversy that's likely to make the evening news in your city, but it can flare up from time to time in free software projects. Below, I will describe the feature, give the major arguments on both sides, and make the best recommendation I can.

The feature itself is very simple: the mailing list software can, if you wish, automatically set the Reply-to header on every post to redirect replies to the mailing list. That is, no matter what the original sender puts in the Reply-to header (or even if they don't include one at all), by the time the list subscribers see the post, the header will contain the list address:

Reply-to: discuss@lists.example.org

On its face, this seems like a good thing. Because virtually all mail reading software pays attention to the Reply-to header, now when anyone responds to a post, their response will be automatically addressed to the entire list, not just to the sender of the message being responded to. Of course, the responder can still manually change where the message goes, but the important thing is that by default replies are directed to the list. It's a perfect example of using technology to encourage collaboration.

Unfortunately, there are some disadvantages. The first is known as the Can't Find My Way Back Home problem: sometimes the original sender will put their "real" e-mail address in the Reply-to field, because for one reason or another they send e-mail from a different address than where they receive it. People who always read and send from the same location don't have this problem, and may be surprised that it even exists. But for those who have unusual e-mail configurations, or who cannot control how the From address on their mails looks (perhaps because they send from work and do not have any influence over the IT department), using Reply-to may be the only way they have to ensure that responses reach them. When such a person posts to a mailing list that he's not subscribed to, his setting of Reply-to becomes essential information. If the list software overwrites it, he may never see the responses to his post.

The second disadvantage has to do with expectations, and in my opinion is the most powerful argument against Reply-to munging. Most experienced mail users are accustomed to two basic methods of replying: reply-to-all and reply-to-author. All modern mail reading software has separate keys for these two actions. Users know that to reply to everyone (that is, including the list), they should choose reply-to-all, and to reply privately to the author, they should choose reply-to-author. Although you want to encourage people to reply to the list whenever possible, there are certainly circumstances where a private reply is the responder's prerogative—for example, they may want to say something confidential to the author of the original message, something that would be inappropriate on the public list.

Now consider what happens when the list has overridden the original sender's Reply-to. The responder hits the reply-to-author key, expecting to send a private message back to the original author. Because that's the expected behavior, he may not bother to look carefully at the recipient address in the new message. He composes his private, confidential message, one which perhaps says embarrassing things about someone on the list, and hits the send key. Unexpectedly, a few minutes later his message appears on the mailing list! True, in theory he should have looked carefully at the recipient field, and should not have assumed anything about the Reply-to header. But authors almost always set Reply-to to their own personal address (or rather, their mail software sets it for them), and many longtime e-mail users have come to expect that. In fact, when a person deliberately sets Reply-to to some other address, such as the list, he usually makes a point of mentioning this in the body of the message, so people won't be surprised at what happens when they reply.

Because of the possibly severe consequences of this unexpected behavior, my own preference is to configure list management software to never touch the Reply-to header. This is one instance where using technology to encourage collaboration has, it seems to me, potentially dangerous side-effects. However, there are also some powerful arguments on the other side of this debate. Whichever way you choose, you will occasionally get people posting to your list asking why you didn't choose the other way. Since this is not something you ever want as the main topic of discussion on your list, it might be good to have a canned response ready, of the sort that's more likely to stop discussion than encourage it. Make sure you do not insist that your decision, whichever it is, is obviously the only right and sensible one (even if you think that's the case). Instead, point out that this is a very old debate, there are good arguments on both sides, no choice is going to satisfy all users, and therefore you just made the best decision you could. Politely ask that the subject not be revisited unless someone has something genuinely new to say, then stay out of the thread and hope it dies a natural death.

Someone may suggest a vote to choose one way or the other. You can do that if you want, but I personally do not feel that counting heads is a satisfactory solution in this case. The penalty for someone who is surprised by the behavior is so huge (accidentally sending a private mail to a public list), and the inconvenience for everyone else is fairly slight (occasionally having to remind someone to respond to the whole list instead of just to you), that it's not clear that the majority, even though they are the majority, should be able to put the minority at such risk.

I have not addressed all aspects of this issue here, just the ones that seemed of overriding importance. For a full discussion, see these two canonical documents, which are the ones people always cite when they're having this debate: 

   * Set Reply-to to list, by Simon Hill   http://www.metasystema.net/essays/reply-to.mhtml
Despite the mild preference indicated above, I do not feel there is a "right" answer to this question, and happily participate in many lists that do set Reply-to. The most important thing you can do is settle on one way or the other early, and try not to get entangled in debates about it after that.

Précédemment, dans une partie appelée « Eviter les discussions privées » j'ai insisté sur l'importante du fait que les discussions doivent se dérouler dans les forums publics et j'ai dit que certaines fois des mesures doivent être prises pour éviter que les conversations ne migrent dans des échanges privés d'e-mails. Ce chapitre traite de la mise en place des logiciels de communications du projet afin qu'ils facilitent au maximum la vie du projet. Par conséquent, si le logiciel de gestion des listes de discussion vous offre la possibilité de garder automatiquement les discussions sur la liste vous vous direz qu'il est logique d'activer cette fonctionnalité. En fait ce n'est pas si évident. Cette option existe, mais elle comporte des inconvénients plutôt restrictifs. Son utilisation est sujette à l'un des plus importants débats concernant la gestion des listes de diffusion, rien qui ne fera la une des journaux du soir, mais parfois les discussions peuvent devenir tendues à ce propos au sein des projets de logiciels libres. Ci-dessous je vais décrire la fonctionnalité, donner les arguments principaux des deux côtés et je vous donnerai mes meilleures recommandations.

La fonctionnalité en elle-même est très simple : le logiciel peut, si vous le souhaitez, remplir le champ « Répondre à : » automatiquement afin que les réponses soient redirigées sur la liste de diffusion. C'est à dire que, peu importe ce que l'expéditeur met dans le champ « Répondre à : » (ou même s'il ne le remplit pas), quand les abonnés de la liste recevront le message l'en-tête contiendra l'adresse de la liste :

Répondre à : discuss@lists.example.org

De prime abord cela semble être une bonne chose parce que quasiment tous les logiciels de messagerie inspectent le champ « Répondre à : » et donc quand quelqu'un enverra une réponse, elle sera automatiquement envoyée à la liste entière, pas uniquement à l'expéditeur du message auquel on répond. Bien sûr, la personne qui répond peut modifier à la main le destinataire du message, mais ce qui est important est que par défaut les réponses sont directement envoyées à la liste. C'est un très bon exemple d'utilisation de la technologie pour encourager la collaboration. Malheureusement il existe quelques inconvénients. Le premier est connu sous le nom du problème de « Je ne peux plus retrouver mon chemin » : il se peut que l'expéditeur mette sa « véritable » adresse e-mail dans le champ « Répondre à : » parce que pour une raison ou pour une autre il a utilisé une autre adresse pour envoyer le message que celle qu'il utilise pour les recevoir. Les personnes qui expédient et lisent les messages à partir de la même adresse n'ont pas ce problème et sont même parfois surpris de savoir qu'il existe. Mais pour ceux qui utilisent leurs comptes mail de manière particulière ou qui n'ont pas de contrôle sur le champ « De : » dans leurs courriers (parce qu'ils écrivent depuis leur travail ou parce qu'ils n'ont pas assez d'influence sur le département informatique), utiliser le champ « Répondre à : » peut être la seule manière d'être sûr que les réponses leur parviennent. Quand une personne dans cette situation envoie un message à une liste de diffusion à laquelle il n'est pas abonné, l'adresse dans le champ « Répondre à : » devient une information essentielle. Si le logiciel remplace cette adresse il se peut qu'il ne reçoive jamais de réponse. Le deuxième inconvénient est lié aux attentes et, d'après moi, c'est l'argument qui a le plus de poids contre l'automatisation du champ « Répondre à : » La plupart des gens ayant l'habitude de se servir des e-mails sont accoutumés à deux possibilités simples pour répondre : Répondre à tous et Répondre. Tous les logiciels de messagerie modernes possède deux boutons distincts pour ces deux fonctions. Les utilisateurs savent que pour répondre à tout le monde (ce qui inclut la liste) ils doivent utiliser le bouton « Répondre à tous » et que pour répondre en privé à l'auteur ils doivent utiliser le bouton « Répondre ». Même si votre but est d'encourager les gens à répondre à toute la liste chaque fois que possible, il y aura parfois des circonstances qui font qu'une réponse privée est plus appropriée, par exemple si une personne veut dire quelque chose de confidentiel à l'auteur du message original, quelque chose qui n'aurait pas sa place sur la liste publique.


Maintenant penchons sur le cas où la liste a ré-écrit le champ « Répondre à : ». La personne qui répond appuie sur le bouton « Répondre » en s'attendant à envoyer un message privé à l'auteur du courrier. Puisque c'est ce qu'il se passe normalement il ne prendra par forcément la peine de vérifier l'adresse du destinataire du message. Il écrit alors son message privé et confidentiel où il pourrait dire des choses gênantes sur une autre personne de la liste et appuie ensuite sur « Envoi ». Alors qu'il ne s'y attendait pas, quelques minutes plus tard son message apparaît sur la liste de diffusion ! Il aurait effectivement dû prendre le temps de regarder avec précaution au champ « Destinataire » en théorie et n'aurait pas dû supposer qu'il n'avait pas à se soucier du champ « Répondre à ». Mais les expéditeurs règlent quasiment à chaque fois le champ « Répondre à : » de telle sorte qu'ils reçoivent la réponse (ou pour être plus précis c'est leur logiciel de messagerie qui le fait pour eux) et de nombreux utilisateurs des courriers électroniques de longue date le prennent pour argent comptant. En fait, lorsqu'une personne met une autre adresse que celle d'expédition dans le champ « Répondre à : », comme celle de la liste par exemple, il prendra en général la peine de le notifier dans le message, ainsi les gens ne sont pas surpris par ce qui se passe lorsqu'ils appuient sur « Répondre ».


A cause des possibles lourdes conséquences que cela peut entraîner, je préfère configurer le logiciel de gestion de liste de manière à ce qu'il ne modifie pas le champ « Répondre à : ». C'est l'un des cas où l'utilisation de la technologie pour encourager la collaboration peut, à mon sens, avoir des effets pervers. Mais il y a aussi de très bons arguments en faveur de l'autre camp. Quelque soit votre choix, vous aurez de temps en temps des gens qui demanderont pourquoi vous n'avez pas fait l'autre choix. Comme c'est quelque chose que vous ne voulez pas voir prendre de trop grandes proportions il vaut mieux que vous ayez une réponse toute prête déjà, une réponse qui mettrait un terme au débat plutôt que de l'encourager. Ne faites pas paraître votre décision, que vous choisissiez une solution ou l'autre, comme étant la seule et unique valable et bonne (même si vous pensez que c'est le cas). Insistez plutôt sur le fait que c'est un très vieux débat que les deux côtés possèdent de bon arguments, mais qu'aucun choix ne peut satisfaire tous les utilisateurs et que par conséquent vous avez pris la décision qui vous semblait la meilleure. Demandez poliment à ce que le sujet ne soit pas ré-ouvert à moins que quelqu'un ait quelque chose de vraiment nouveau à apporter au débat puis ne participez plus à la discussion en espérant qu'elle s'éteigne d'elle-même. Quelqu'un pourrait suggérer de voter pour choisir une méthode ou l'autre. Vous pouvez le faire si c'est votre choix, mais je ne pense pas qu'un vote à main levée soit la meilleure solution dans ce cas. Le risque que quelqu'un se fasse surprendre par le modification du champ « Répondre à : » est trop important et le désagrément pour chacun est plutôt faible (devoir rappeler occasionnellement aux gens de répondre à la liste entière) pour qu'une majorité, même si c'est la majorité, impose un tel risque à une minorité. Je n'ai pas abordé ici tous les aspects de ce problème, seulement ceux qui semblaient les plus importants. Si le sujet vous intéresse je vous conseille de lire ces deux documents canoniques qui sont ceux que les gens citent toujours dans ce débat :


Malgré cette légère préférence énoncée ci-dessus je ne pense pas qu'il existe une vérité « transcendante » dans ce débat et je participe gaiement à de nombreuses listes qui imposent le « Répondre à : ». Le mieux que vous puissiez faire est de vous décider assez tôt pour une solution ou pour l'autre et d'éviter de vous faire engluer dans un débat par la suite.

[modifier] Two fantasies /Deux rêves

Someday, someone will get the bright idea to implement a reply-to-list key in a mail reader. It would use some of the custom list headers mentioned earlier to figure out the address of the mailing list, and then address the reply directly to the list only, leaving off any other recipient addresses, since most are probably subscribed to the list anyway. Eventually, other mail readers will pick up the feature, and this whole debate will go away. (Actually, the Mutt mail reader does offer this feature. Now, if only others would copy it.)

An even better solution would be for Reply-to munging to be a per-subscriber preference. Those who want the list to set Reply-to munged (either on others' posts or on their own posts) could ask for that, and those who don't would ask for Reply-to to be left alone. However, I don't know of any list management software that offers this on a per-subscriber basis. For now, we seem to be stuck with a global setting.

Un jour quelqu'un aura cette idée brillante d'ajouter un bouton « Répondre à la liste » dans un logiciel de messagerie. Pour ce faire il se servirait des en-têtes pour déterminer l'adresse de la liste de diffusion et enverrai donc la réponse directement à la liste, en ne se préoccupant pas des adresses d'autres destinataires puisqu'ils sont pour la plupart déjà inscrits à la liste de toute façon. Finalement, d'autres logiciels de messagerie reprendraient l'idée et le débat deviendrait obsolète. (En fait, le logiciel de messagerie Mutt propose déjà cette fonctionnalité. Il ne reste plus aux autres qu'à la copier.)

Une meilleure solution : laisser le choix à chaque abonné. Ceux qui veulent que la liste remplisse le champ « Répondre à : » (que se soit pour leurs propres messages ou ceux des autres) pourraient régler cette option et ceux qui ne le veulent pas pourraient choisir aussi. Je ne connais cependant aucun logiciel de gestion de liste qui permette ce choix individuel. Pour le moment on doit faire avec une configuration identique pour tous.

[modifier] Archiving / L'archivage

The technical details of setting up mailing list archiving are specific to the software that's running the list, and are beyond the scope of this book. When choosing or configuring an archiver, consider these qualities:

Prompt updating

People will often want to refer to an archived post made within the last hour or two. If possible, the archiver should archive each post instantaneously, so that by the time a post appears on the mailing list, it's already present in the archives. If that option isn't available, then at least try to set the archiver to update itself every hour or so. (By default, some archivers run their update processes once per night, but in practice that's far too much lag time for an active mailing list.) Referential stability

Once a message is archived at a particular URL, it should remain accessible at that exact same URL forever, or as close to forever as possible. Even if the archives are rebuilt, restored from backup, or otherwise fixed, any URLs that have already been made publicly available should remain the same. Stable references make it possible for Internet search engines to index the archives, which is a major boon to users looking for answers. Stable references are also important because mailing list posts and threads are often linked to from the bug tracker (see the section called “Bug Tracker”) later in this chapter or from other project documents.

Ideally, mailing list software would include a message's archive URL, or at least the message-specific portion of the URL, in a header when it distributes the message to recipients. That way people who have a copy of the message would be able to know its archive location without having to actually visit the archives, which would be helpful because any operation that involves one's Web browser is automatically time-consuming. Whether any mailing list software actually offers this feature, I don't know; unfortunately, the ones I have used do not. However, it's something to look for (or, if you write mailing list software, it's a feature to consider implementing, please). Backups

It should be reasonably obvious how to back up the archives, and the restoration recipe should not be too difficult. In other words, don't treat your archiver as a black box. You (or someone in your project) should know where it's storing the messages, and how to regenerate the actual archive pages from the message store if it should ever become necessary. Those archives are precious data—a project that loses them loses a good part of its collective memory. Thread support

It should be possible to go from any individual message to the thread (group of related messages) that that original message is part of. Each thread should have its own URL too, separate from the URLs of the individual messages in the thread. Searchability

An archiver that doesn't support searching—on the bodies of messages, as well as on authors and subjects—is close to useless. Note that some archivers support searching by simply farming the work out to an external search engine such as Google. This is acceptable, but direct search support is usually more fine-tuned, because it allows the searcher to specify that the match must appear in a subject line versus the body, for example.

The above is just a technical checklist to help you evaluate and set up an archiver. Getting people to actually use the archiver to the project's advantage is discussed in later chapters, in particular the section called “Conspicuous Use of Archives”.

Les détails techniques concernant la mise en place de l'archivage d'une liste de diffusion sont particuliers au logiciel qui fait fonctionner la liste et dépassent le cadre de ce livre. Lors du choix ou de la configuration de l'archive vous devez prendre en compte les facteurs suivants :

Mise à jour rapide

Les gens se référeront souvent à un message archivé envoyé une ou deux heures auparavant. Si c'est possible, le logiciel devrait archiver chaque message instantanément afin que dès qu'un message apparaît dans la liste de diffusion il soit aussi présent dans les archives. Si cette option n'est pas disponible, alors essayez de faire en sorte que l'archive soit remise à jour au moins toutes les heures. (Par défaut certains logiciels d'archives se mettent à jour automatiquement chaque nuit, mais dans la pratique ce délai est bien trop important pour une liste de diffusion active.)

La stabilité du référentiel

Une fois qu'un message est archivé à une URL donnée, il devrait rester accessible par la même URL pour toujours, ou le plus longtemps possible au moins. Même si les archives sont reconstruites, rétablies à partir d'une sauvegarde ou réparées d'une quelconque manière, chaque URL qui a été rendue publique ne devrait pas être modifiée. Des coordonnées stables rendent possible l'indexation des archives par les moteurs de recherche qui sont les meilleures compagnons des utilisateurs en quête de réponses. Des coordonnées stables sont aussi importantes car les messages et les sujets dans les listes de diffusion contiennent souvent des liens vers le système de suivi de bogues (voir la section nommée « Système de suivi de bogues » plus loin dans ce chapitre) ou à d'autres documents du projets.

Idéalement, les logiciels de listes de diffusion devraient inclure l'URL du message dans les archives, ou au moins une portion particulière de l'URL, dans les en-têtes du message lorsqu'il est distribué aux destinataires. Ainsi, ceux qui ont une copie du message peuvent savoir où est rangé le message dans les archives sans avoir à se rendre sur la page des archives. C'est utile en effet car toute opération nécessitant l'utilisation d'un navigateur prend du temps. Par contre, je ne sais pas s'il existe un logiciel qui propose cette fonctionnalité. Ceux que j'ai utilisés ne le faisaient pas. C'est quand même une fonctionnalité que vous devriez chercher (ou, si vous écrivez un logiciel de gestion de listes de diffusion, c'est une fonctionnalité que vous devriez penser à ajouter s'il vous plaît).

Les sauvegardes

La méthode de sauvegarde des archives devrait être plutôt évidente et la manière de les restaurer ne devrait pas être trop compliquée non plus. En d'autres termes, ne voyez pas votre logiciel d'archivage comme une boîte noire. Vous (ou quelqu'un de votre projet) devrait savoir ou il range les messages et comment recréer la page d'archives depuis les messages sauvegardés si cela est nécessaire. Ces archives sont des données précieuses, un projet qui perd ses archives perd une grande partie de sa mémoire collective.

La gestion des sujets

Il devrait être possible de naviguer depuis n'importe quel message vers le sujet (groupe de messages ayant un lien) auquel appartient ce message. Chaque sujet devrait avoir sa propre URL, différente de l'URL des messages composant ce sujet.

Recherche

Un logiciel d'archivage ne proposant pas d'outil de recherche ni dans le corps des messages ni par auteur ou par sujet est quasiment inutile. Remarquez que certains logiciels proposent un outil de recherche simplement en sous-traitant le travail à un moteur de recherche tiers comme Google. Ça peut passer, mais le support natif des recherches est en général plus précis puisqu'il permet à la personne qui fait la recherche de spécifier que le mot doit se trouver dans le sujet et pas dans le corps du texte par exemple.

Ceci n'est qu'une liste technique pour vous aider à évaluer et mettre en place un outil d'archivage. Comment amener les gens à vraiment utiliser cet outil pour le bien du projet est un autre sujet qui sera abordé dans d'autres chapitres plus loin dans ce livre, en particulier le chapitre intitulé « Utilisation visible des archives ».

[modifier] Software / Les logiciels

Here are some Open Source tools for doing list management and archiving. If the site where you're hosting your project already has a default setup, then you may not ever have to decide on a tool at all. But if you must install one yourself, these are some possibilities. The ones I have actually used are Mailman, Ezmlm, MHonArc, and Hypermail, but that doesn't mean the others aren't good too (and of course, there are probably other tools out there that I just didn't happen to find, so don't take this as a complete list).

Mailing list management software: 

* Dada — http://mojo.skazat.com/

(Despite the Web site's bizarre attempts to hide the fact, this is free software, released under the GNU General Public License. It also has a built-in archiver.)

Mailing list archiving software: 

*  MHonArc — http://www.mhonarc.org/
*  Hypermail — http://www.hypermail.org/
*  Lurker — http://sourceforge.net/projects/lurker/
* Procmail — http://www.procmail.org/

     (Companion software to SmartList, this is a general mail processing system that can, apparently, be configured as an archiver.)

Voici une liste d'outils Open Source pour la gestion et l'archivage de listes. Si le site qui héberge votre projet propose déjà une configuration par défaut vous n'aurez peut-être jamais à faire de choix. Mais si vous devez en installer un vous même, en voici quelques uns. Ceux que j'ai utilisés sont Mailman, Ezmlm, MHonArc et Hypermail, mais cela ne veut pas dire que les autres ne sont pas bons (et bien sûr, il existe probablement d'autres outils sur lesquels je ne suis pas tombé, ne considérez pas cette liste comme une liste exhaustive). Les logiciels de gestion de listes de diffusions sont :

Les logiciels d'archivage sont :

Récupérée de « http://www.framalang.org/wiki/POSS_Chap_3_Part_2 »