Mailinglisten sind im Projekt das tägliche Brot der Kommunikation. Sieht der Nutzer irgend ein anderes Forum außer der Webseite, wird es wahrscheinlich eine der Mailinglisten sein. Vorher werden sie sich aber mit der Anmeldung beschäftigen müssen. Das bringt uns zur ersten Regel von Mailinglisten:
Versuchen Sie nicht, die Mailingliste händisch zu verwalten – Besorgen Sie sich dazu die nötige Software.
Es wird verlockend sein, diese Aufgabe hinauszuschieben. Am Anfang scheint es überflüssig diese Software einzurichten. Kleine Verteiler mit geringem Nachrichtenverkehr, scheinen verlockend einfach zu verwalten: Man richtet einfach eine Adresse für die Anmeldung ein, die Anmeldungen werden an Sie weiterleitet, worauf Sie seine Adresse in einer Text-Datei eintragen, indem alle Adressen enthalten sind. Was könnte einfacher sein?
Es gibt allerdings einen Haken. Ein gut verwalteter Verteiler – was viele mittlerweile erwarten – ist alles andere als einfach. Es geht nicht nur darum Leute an- und abzumelden wenn sie eine entsprechende Anfrage stellen. Es geht u.a. darum Spam zu verhindern, nicht einzelne Nachrichten, sondern Zusammenfassungen zu verteilen und Informationen über den Verteiler und das Projekt mittels automatisierter Antworten zu verschicken. Ein Mensch der die Adresse eines Verteilers beobachtet, bietet nur ein Mindestmaß an Funktionen, und selbst dann nicht so zuverlässig und schnell wie es eine Software könnte.
Moderne Mailinglisten-Software bietet für gewöhnlich mindestens folgende Funktionen:
Wenn ein Nutzer sich bei der Mailingliste anmeldet, sollte er umgehend eine automatisierte Willkommensnachricht bekommen, in der beschrieben steht, wofür er sich angemeldet hat, wie man weiter mit der Mailingliste umgeht und (am wichtigsten) wie man sich abmeldet. Diese automatische E-Mail kann natürlich bearbeitet werden, um projektspezifische Informationen einzuschließen, wie z.B. die Webseite des Projekts, wo man die FAQ findet, usw.
Im Digest-Modus wird einmal am Tag eine E-Mail verschickt. Sie ist eine Zusammenfassung der gesamten Aktivität auf der Mailingliste, die im Verlauf des Tages aufgekommen ist. Wer die Liste nur nebenher verfolgt, ohne selbst beteiligt zu sein, bevorzugt oft diese Form, da dies ihnen erlaubt, alle Themen auf einmal durchzusehen und hat den Vorteil, die Ablenkung durch ständig eintreffende E-Mails zu vermeiden.
"Moderieren" bedeutet sicherzustellen, dass Nachrichten a) kein Spam sind und b) zum Thema gehören, bevor sie verteilt werden. Moderation muss zwangsläufig von Menschen erledigt werden, aber Software kann eine Menge dazu beitragen, die Aufgabe einfacher zu gestalten. Zu diesem Thema später mehr.
Diese ermöglichen es einem Administrator u.a. ohne Umstände veraltete Adressen zu löschen. Was dringend werden kann, wenn die Adresse eines Empfängers anfängt, Antworten wie "Ich bin nicht mehr bei dieser Adresse" auf jede Nachricht von der Liste zu schicken. (Manche Listensoftware kann so etwas automatisch erkennen und die Person abmelden.)
Viele Leute haben ausgeklügelte Filter- und Antwort-Regeln für ihre E-Mail-Programm eingerichtet. Mailinglisten-Software kann bestimmte Header hinzufügen und manipulieren, die die Empfänger ausnutzen können (mehr dazu später).
Alle Nachrichten an die Liste werden gespeichert und im Netz bereitgestellt; alternativ bietet manche Software spezielle Schnittstellen an um externe Archivierungssoftware einzubinden wie z.B. (http://www.mhonarc.org/). Archivierung ist unerlässlich, mehr dazu in „Auffällige Nutzung der Archive“ im Kapitel Kapitel 6, Kommunikation.
Der Sinn dieser Punkte ist lediglich zu betonen, dass die Verwaltung einer Mailingliste ein komplexes Problem ist, mit dem sich schon viele beschäftigt haben und weitestgehend gelöst haben. Sie müssen sicherlich kein Experte auf diesem Gebiet werden. Aber Sie sollten sich bewusst machen, dass es immer mehr zu lernen gibt, und dass die Verwaltung der Liste im Verlauf eines freien Software Projekts ab und zu etwas Zeit in Anspruch nehmen wird. Im weiteren werden wir ein paar der häufigsten Punkte beim Konfigurieren einer Antworten angehen.
Seit ich diesen Satz schrieb, bis zu seiner Veröffentlichung, ist das Internet-weite Spam-Problem wahrscheinlich doppelt so schlimm geworden – oder zumindest wird es einem so vorkommen. Es gab eine Zeit, nicht all zu lange her, in der man eine Liste betreiben konnte ohne überhaupt irgend welche Maßnahmen gegen Spam vornehmen zu müssen. Gelegentlich verirrte sich eine Nachricht, aber selten genug um nur eine geringes Ärgernis zu sein. Diese Ära ist für immer vorbei. Heutzutage wird eine Mailingliste, die keine Maßnahmen gegen Spam unternimmt, schnell von Werbemüll überflutet und dadurch unbenutzbar. Schutz vor Spam ist unerlässlich.
Wir unterteilen Schutz vor Spam in zwei Kategorien: Spam daran zu hindern auf Ihrer Liste aufzutauchen, und zu verhindern, dass Ihre Liste für Spam harvester zu einer Quelle von Adressen wird. Ersteres ist wichtiger also untersuchen wir es zuerst.
Es gibt drei grundsätzliche Arten, Spam zu vermeiden und die meisten Mailinglisten bieten alle drei an. Gemeinsam arbeiten sie am effizientesten:
Es sollten nur Nachrichten von angemeldeten Nutzern automatisch angenommen werden.
Diese Einstellung ist weitestgehend effektiv und ist nicht besonders schwer einzurichten, da es für gewöhnlich nur eine kleine Änderung an der Konfiguration der Software des Verteilers bedeutet. Beachten Sie aber, dass Nachrichten, die nicht automatisch akzeptiert werden, nicht einfach verworfen werden sollten. Es gibt zwei Gründe, warum sie stattdessen für weitere Moderation aufbewahrt werden sollten. Erstens wollen Sie auch unangemeldeten Benutzer erlauben, Nachrichten an die Liste zu senden, schließlich sollte eine Person mit einer Frage oder einem Vorschlag sich nicht gleich anmelden müssen, um eine einzige E-Mail zu senden. Zweitens kann es vorkommen, dass auch angemeldete Benutzer eine anderen E-Mail-Adresse benutzen als die, mit der sie angemeldet sind. E-Mail-Adressen sind keine zuverlässige Möglichkeit, Menschen zu identifizieren und sollten nicht als solche behandelt werden.
Benutzen Sie einen Spam-Filter
Wenn die Software des Verteilers es ermöglicht (was die meisten tun), können Sie Nachrichten durch einen Spam-Filter laufen lassen. Automatisierte Spam-Filterung ist nicht perfekt und wird es aufgrund des andauernden Wettrüstes zwischen Spammern und den Autoren der Filtersoftware auch nie sein. Es kann aber einen großen Teil des Spams reduzieren, der bis zu den Moderatoren durchkommt. Jede solche Filterung ist vorteilhaft, da die Moderatoren weniger Zeit mit dem Untersuchen von Nachrichten verbringen müssen, und deshalb sehr wünschenswert.
Hier ist nicht der Raum für eine detailierte Anleitung, wie man einen Spam-Filter einrichtet. Sie werden hierzu die Dokumentation Ihrer Mailinglisten-Software lesen müssen (siehe „Mailinglisten-Software“ später in diesem Kapitel). E-Mail-Verteiler haben oft eingebaute Möglichkeiten um Spam zu verhindern, es kann aber sein, dass Sie weitere Filter von einem dritten Anbieter hinzufügen wollen. Mit diesen Beiden habe ich gute Erfahrungen gemacht: SpamAssassin (http://spamassassin.apache.org/) und SpamProbe (http://spamprobe.sourceforge.net/). Das soll allerdings kein Urteil über andere Open-Source-Filter sein, von denen einige scheinbar auch ziemlich gut sind. Ich habe zufällig diese Beiden benutzt und war mit ihnen zufrieden.
Moderation.
Die Letzte Stufe für Nachrichten die nicht von einem angemeldeten Benutzer stammen und es durch den Spamfilter schaffen, ist die Moderation: Die E-Mail wird an eine bestimmte Adresse geleitet, wo es von einem Menschen untersucht wird, der sie entweder annimmt oder ablehnt.
Eine E-Mail zu akzeptieren, kann eine von zwei Formen annehmen: Sie können die E-Mail nur dieses eine Mal annehmen oder Sie können die Software anweisen, diese eine und alle weiteren Nachrichten von dieser Adresse anzunehmen. Letzteres ist fast immer vorzuziehen, um die zukünftige Bürde der Moderation zu verringern. Wie man Nachrichten annimmt, kann sich von System zu System unterscheiden, für gewöhnlich reicht es aber eine E-Mail, an eine bestimmte Adresse zu senden, mit einem Befehl wie "accept" (um nur diese eine E-Mail zu erlauben) oder "allow" (um diese und alle weiteren Nachrichten zu erlauben).
Um eine Nachricht abzulehnen reicht es meistens sie einfach zu ignorieren. Wenn der Verteiler niemals eine Bestätigung erhält, wird er die E-Mail auch nicht verteilen. Das erwünschte Ergebnis erreicht man also, indem man die E-Mail einfach ignoriert. Manchmal haben Sie auch die Möglichkeit mit "reject" oder "deny" an den Verteiler zu antworten, was dazu führt, dass alle weiteren Nachrichten von dieser Adresse automatisch abgelehnt werden, ohne moderiert zu werden. Es gibt selten einen Grund dafür, da es bei der Moderation meistens darum geht, Spam zu vermeiden und Spammer selten zwei mal die gleiche Adresse benutzen.
Die Moderierung sollte allerdings ausschließlich für Spam und Nachrichten benutzt werden, die eindeutig nicht auf die Liste gehören, wie z.B. wenn jemand aus versehen eine Nachricht an die falsche Adresse schickt. Das System wird Ihnen meistens eine Möglichkeit geben eine E-Mail direkt an den Absender zu schicken, nutzen Sie diese aber nicht, um Fragen zu beantworten die eigentlich auf die Mailingliste gehören, selbst wenn Ihnen sofort die Antwort einfällt. Das würde der Gemeinschaft des Projekts nur die Möglichkeit entziehen sich ein klares Bild zu machen, welche Fragen von der Öffentlichkeit gestellt werden und Sie der Gelegenheit berauben, diese Fragen selber zu beantworten und/oder die Antworten anderer zu sehen. Die Moderation einer Mailingliste sollte sich ausschließlich auf Werbemüll und irrelevante Nachrichten beschränken und sonst nichts.
Um zu verhindern, dass Ihr Verteiler zu einer Quelle von E-Mail-Adressen für Spammer wird gibt es die gebräuchliche Methode, Adressen in den Archiven zu verschleiern indem man z.B.
hmustermann@einedomain.de
mit
hmustermann_AT_einedomain.de
oder
hmustermannKEINSPAM@einedomain.de
oder irgendetwas (für Menschen) ähnlich offensichtliches ersetzt. Da Spam-Harvester oft nach dem Prinzip funktionieren, Webseiten abzugrasen – auch die Archive Ihres Verteilers – und nach Zeilen mit einem "@" suchen, ist diese Art der Verschleierung eine effektive Methode E-Mail-Adressen vor Spammern zu verstecken oder unbrauchbar zu machen. Was natürlich nichts am Spam, der an die Liste selbst geschickt wird ändert, aber es kann die Menge an Spam reduzieren, die direkt an die persönlichen Adressen der Nutzer des Verteilers gesandt wird.
Die Verschleierung von Adressen kann kontrovers sein. Manche finden, dass es eine gute Idee ist und werden sich wundern wenn Ihre Archive es nicht automatisch machen. Andere denken es ist eine zu große Unbequemlichkeit (da Menschen auch die Adresse wieder korrigieren müssen, vor sie benutzt werden können). Manche behaupten, dass es nicht effektiv sei, da Harvester theoretisch jede konsistente Verschleierung, ausgleichen können. Es gibt jedoch empirische Beweise, dass die Verschleierung von Adressen tatsächlich funktioniert, siehe http://www.cdt.org/speech/spam/030319spamreport.shtml.
Im Idealfall würde die Listensoftware diese Entscheidung jedem Benutzer überlassen, entweder durch einen zusätzlichen Header oder in den Einstellungen seines Listenkontos. Ich kenne allerdings keine Software, die diese Entscheidung für jede Nachricht oder jeden Nutzer ermöglicht, also wird vorerst der Administrator der Liste, diese Entscheidung für alle übernehmen müssen (angenommen die Archivierungssoftware bietet diese Einstellung überhaupt an, was nicht immer der Fall ist). Ich ziehe es vor die Verschleierung anzuschalten. Manche sind sehr vorsichtig Ihre Adresse nicht auf Webseiten oder irgendwo anders zu platzieren, an dem ein Spam-Harvester sie finden könnte und sie wären enttäuscht, wenn all ihre Mühe vom Archiv einer Mailingliste zunichte gemacht würden; zudem ist der Aufwand der durch die Verschleierung den Nutzern auferlegt wird nur sehr gering, da es trivial ist eine verschleierte Adresse zu korrigieren, sollte man die Person erreichen wollen. Behalten Sie aber das Wettrüsten im Hinterkopf: Bis Sie diese Zeilen lesen kann es durchaus sein, dass die Harvester sich so weit entwickelt haben, dass sie die häufigsten Verschleierungen erkennen können und wir müssen uns wieder etwas neues einfallen lassen.
Die Nutzer einer Mailingliste wollen oft die davon stammenden E-Mails in einem bestimmten Ordner sortieren, getrennt von ihren anderen E-Mails. E-Mail-Software kann das automatisch übernehmen, indem sie die Header der E-Mails untersucht. Header sind die Felder im Kopf einer E-Mail, wie Absender, Empfänger, Betreff, Datum und verschiedenes andere das Informationen über die Nachricht enthält. Bestimmte Header sind weit verbreitet und im wesentlichen Pflichtangaben:
Von: ... An: ... Betreff: ... Datum: ...
Andere sind optional, wenn auch ziemlich üblich. E-Mails müssen z.B. genau genommen keinen
Antwort An: absender@email.adresse.hier
Header angeben, tun es aber trotzdem, da es den Empfängern eine narrensichere Möglichkeit gibt den Autoren zu erreichen (was besonders nützlich ist wenn der Autor die E-Mail von einer anderen Adresse senden musste, als diejenige an die die Antworten gerichtet sein sollten).
In manchen E-Mail-Programmen ist es einfach, E-Mails anhand von verschiedenen Mustern im Betreff unterschiedlich abzulegen. Das führt zum Bedarf, dass der Verteiler automatisch einen Präfix vor jeden Betreff setzen soll, damit E-Mail-Programme danach suchen und automatisch Nachrichten in den richtigen Ordnern ablegen können. Die Idee ist, dass der Autor folgendes schreiben würde:
Betreff: Erstelle die Version 2.5.
die Nachricht aber wie folgt ankommen würde:
Betreff: [diskussion@verteiler.beispiel.org] Erstelle die Version 2.5.
Obwohl die meisten Listenlösungen diese Möglichkeit bieten, empfehle ich diese Option nicht anzuschalten. Das Problem, kann viel einfacher auf eine sehr viel weniger aufdringliche Art gelöst werden, und der Preis den man durch verlorenen Platz im Betreff verliert ist viel zu hoch. Erfahrene Nutzer von Mailinglisten, suchen die Betreffzeilen ihrer im Laufe des Tages eingetroffenen E-Mails ab und entscheiden daran, ob sie eine Nachricht lesen oder auf sie antworten. Den Namen der Liste vor dem eigentlichen Betreff zu setzen, kann die rechte Seite des Betreffs über den Bildschirmrand hinausschieben, wodurch er verschwindet. Die Informationen auf denen sich Leser verlassen um zu entscheiden, welche Nachrichten Sie öffnen sollen gehen damit z.T. verloren und der Nutzen der Liste wird dadurch insgesamt für alle verringert.
Anstatt die Betreffzeile zu verunstalten, sollten Sie Ihren Nutzern beibringen, andere übliche Header zu verwenden, angefangen mit dem To("An:")-Header indem die Adresse der Liste angeben werden sollte:
An: <diskussion@verteiler.beispiel.org>
Jede E-Mail-Software die nach Betreff filtern kann, sollte ebenso einfach auch in der Lage sein, nach dem To-Header zu filtern.
Es gibt ein paar weitere optionale, aber üblicherweise angegebene Header, die bei Mailinglisten erwartet werden. Nach ihnen zu filtern ist noch zuverlässiger als die "To" oder "Cc" Header; da diese Header von dem Verteiler an jede Nachrichten angehängt werden, verlassen sich manche Nutzer möglicherweise auf sie:
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
Zum größten Teil sind diese selbsterklärend. Siehe http://www.nisto.com/listspec/list-manager-intro.html für eine weitergehende Erklärung, oder http://www.faqs.org/rfcs/rfc2369.html für die ausführliche formale Spezifikation.
Beachten Sie auch, dass diese Header durch den Prefix "list" implizieren, dass Sie auch administrative Adressen mit den Namen "list-help" und "list-unsubscribe" eingerichtet haben. Weitere üblich Adressen sind "list-subscribe", um die Liste zu abonnieren und "list-owner", um seine Administratoren zu erreichen. Je nachdem welche Software Sie für Ihre Liste verwenden, werden diese und verschiedene andere eingerichtet sein; die Dokumentation wird dazu weitere Angaben bietem. Eine vollständige Liste aller Adressen wird meistens jedem Nutzer als Teil der "Willkommensnachricht", bei der Anmeldung zugeschickt. Sie werden selber wahrscheinlich eine Kopie dieser E-Mail bekommen. Wenn nicht sollten Sie jemand um eine Kopie bitten, damit Sie wissen was Ihre Nutzer sehen, sobald sie die Liste abonnieren. Behalten Sie sie in Griffweite um Fragen über die Funktionen der Liste beantworten zu können, bzw. noch besser wäre, es irgendwo auf Ihre Webseite zu stellen, um bei Fragen der Form "Wie kann ich mich abmelden?", Sie einfach auf eine URL weisen können.
Manche Verteiler bieten die Option, an jede Nachricht Anweisungen anzuhängen, um sich abmelden. Wenn es sie gibt, sollten sie angeschaltet werden. Es verbraucht für jede Nachricht nur ein paar zusätzliche Zeilen an einer harmlosen Stelle und kann viel Zeit ersparen, indem es die Anzahl der Nutzer reduziert die an Sie – oder schlimmer noch an die ganze Liste – Anfragen schicken, wie man sich abmelden kann.
Ich habe vorhin in „Private Diskussionen vermeiden“ betont, wie wichtig es ist, Diskussionen in den öffentlichen Foren zu halten und erwähnte, dass aktive Maßnahmen manchmal nötig sind, um zu verhindern, dass Unterhaltungen ins private abgleiten; weiterhin geht es in diesem Kapitel darum, die Kommunikationssoftware soweit zu konfigurieren, dass sie möglichst viel Arbeit übernimmt. Es wäre deshalb anzunehmen, dass Verteiler mit einer Möglichkeit, alle Nachrichten öffentlich zu halten, diese Option offensichtlich anschalten sollte.
Nun ja, nicht ganz. Es gibt solch eine Funktion, allerdings hat sie ein paar schwerwiegende Nachteile. Die Frage ob man sie benutzen soll oder nicht, ist eine der am heißesten debattierten bei der Verwaltung von Mailinglisten – zugegeben, es ist nicht unbedingt eine Kontroverse die es auf die Titelseite Ihres Tageblatts schaffen würde, aber Sie kann in einem freien Software-Projekt ab und zu aufflammen. Unten werde ich die Funktion beschreiben, die Hauptargumente beider Seiten erläutern und die mir bestmögliche Empfehlung geben.
Die Funktion selbst ist relativ einfach: Wenn Sie wollen, kann die Listen-Software automatisch den Reply-to (de. Antwort an) Header auf die Adresse der Liste setzen. Was so viel heißt, dass egal was der Autor einer E-Mail in den Reply-to Header schreibt (bzw. selbst wenn er nicht einmal angegeben wird), bei den Empfängern der Header mit der Adresse der Liste erscheint:
Reply-to: discuss@lists.example.org
Oberflächlich scheint das eine gute Sache zu sein. Praktisch jede E-Mail-Software berücksichtigt den Reply-to Header. Wenn nun jemand auf eine Nachricht antwortet, wird seine Nachricht an die gesamte Liste gerichtet sein und nicht nur an den Autor der ursprünglichen Nachricht. Natürlich kann der Antwortende immer noch händisch den Empfänger ändern, wichtig ist aber, dass Antworten standardmäßig an die Liste gerichtet sind. Es ist ein perfektes Beispiel für eine Technik, um gemeinschaftliche Arbeit zu unterstützen.
Leider gibt es einige Nachteile. Der erste ist bekannt als das Ich-finde-nicht-den-Weg-nach-Hause-Problem: Manchmal setzt der ursprüngliche Absender seine "echte" E-Mail-Adresse in den Reply-to Header, da er aus irgendeinem Grund die Nachricht von einer anderen Adresse absendet, als er Antworten empfangen möchte. Personen, die immer von der gleichen Adresse absenden und empfangen, kennen dieses Problem nicht und viele sind überrascht, dass es das Problem überhaupt gibt. Für Leute mit einer ungewöhnlichen E-Mail-Konfiguration oder ohne Einfluss auf die Gestalt ihrer E-Mails (vielleicht weil sie von der Arbeit schreiben und keinen Einfluss auf ihre IT-Abteilung haben), kann der Reply-to Header die einzig sichere Möglichkeit sein, Antworten an die richtige Adresse zu leiten. Wenn Sie nun an eine Liste schreiben, ohne in dieser angemeldet zu sein, wird ihre Reply-to Einstellung zu einer unabdingbaren Information. Wenn der Verteiler diese nun überschreibt, wird Sie die Rückmeldung auf Ihre Nachricht vielleicht niemals erreichen.
Der zweite Nachteil betrifft eine Erwartungshaltung, und das ist meiner Meinung nach das stärkste Argument gegen die Verunstaltung von Reply-to. Die meisten erfahrenen E-Mail-Nutzer, sind an zwei grundsätzliche Arten zu antworten gewohnt: reply-to-all (Antwort an alle) und reply-to-author (Antwort an Autor). Alle modernen E-Mail-Programme bieten beide Optionen an. Nutzer wissen, dass sie reply-to-all wählen sollten um an alle zu antworten (d.h. inklusive der Personen auf der Liste), und dass sie reply-to-author wählen sollten, um eine private Nachricht an den Autor zu schicken. Auch wenn Sie an jeder möglichen Stelle zu offenen Diskussionen ermutigen sollten, gibt es doch Situationen, bei denen der Antwortende eine private Nachricht bevorzugen sollte – zum Beispiel wenn er etwas im Vertrauen an den Autor schreiben möchte, was unangemessen für die öffentliche Liste wäre.
Schauen Sie, was nun passiert, wenn der Verteiler den ursprünglichen Reply-to Eintrag überschreibt und der Antwortende auf den reply-to-author Knopf drückt, in der Erwartung eine private E-Mail an den Absender zu schicken. Aufgrund seiner Erwartungshaltung, wird er die Adresse des Empfängers vielleicht nicht nochmals überprüfen. Er hat dabei vielleicht eine geheime, vertrauliche Nachricht verfasst, mit peinlichen Details über ein Mitglied des Verteilers und drückt nun auf absenden. Seine Nachricht erscheint nun unerwartet, etwas später auf dem Verteiler! Zugegeben, theoretisch hätte er sorgfältig auf das Empfänger-Feld achten sollen, und keine Annahmen über den Reply-to Header machen sollen. Autoren setzen aber fast immer Reply-to auf ihre eigene persönliche Adresse (bzw. ihre E-Mail-Software macht es für sie), und viele langjährige Nutzer, erwarten es mittlerweile. Das geht sogar soweit, dass wenn jemand absichtlich reply-to auf irgendeine andere Adresse setzt als den Verteiler, er es explizit in dem Text der E-Mail erwähnt, damit Leute sich bei ihrer Antwort nicht wundern.
Aufgrund der potentiell schwerwiegenden Folgen dieses unerwarteten Verhaltens, bevorzuge ich es, Verteiler so zu konfigurieren, dass sie den reply-to Header niemals anfassen. Es ist ein Beispiel für eine Technik um Zusammenarbeit zu unterstützen, mit wie es mir scheint, potentiell gefährlichen Nebenwirkungen. Auf der anderen Seite dieser Debatte gibt es jedoch auch starke Argumente. Es werden Leute, egal wie Sie sich entscheiden, ab und zu fragen, warum Sie sich nicht anders entschieden haben. Da sowas niemals zum Hauptthema einer Diskussion werden sollte, kann es angebracht sein, hierfür eine vorformulierte Antwort parat zu haben, die so gestaltet ist, dass sie die Diskussion eher beendet als anfeuert. Stellen Sie klar, dass Sie nicht darauf bestehen, die einzig richtige und sinnvolle Entscheidung getroffen zu haben, (selbst wenn Sie das denken). Deuten statt dessen darauf wie alt diese Debatte ist, dass es gute Argumente auf beiden Seiten gibt, keine Entscheidung alle zufriedenstellen wird und dass Sie einfach die Ihnen bestmögliche Entscheidung getroffen haben. Bitten Sie höfflich darum diese Diskussion nicht weiterzuführen, es sei denn jemand hat etwas wirklich neues zu sagen. Halten Sie sich danach aus dem Thread heraus und hoffen Sie, dass er eines natürlichen Todes stirbt.
Jemand wird vielleicht vorschlagen eine Wahl darüber zu halten. Wenn Sie möchten können Sie das tun, ich persönlich finde es in diesem Fall jedoch unzureichend einfach Köpfe zu zählen. Für jemanden, der ein gewisses Verhalten erwartet, wäre die Strafe unangemessen hoch (versehentliche Sendung einer privaten E-Mail an die Liste) und die Unbequemlichkeit für die übrigen Teilnehmer ist relativ gering (ab und zu jemand daran erinnern an den ganzen Verteiler zu antworten, statt nur an den Autor), weshalb man nicht eindeutig sagen kann dass die Mehrheit, auch wenn sie das ist, eine Minderheit in solch eine Gefahr bringen darf.
Ich habe nur die wichtigsten Aspekte dieses Themas hier angesprochen. Für eine vollständige Behandlung des Themas verweise ich auf folgende zwei anerkannten Dokumente, die bei dieser Debatte immer wieder zitiert werden:
Lass Reply-to in Ruhe, von Chip Rosenthal
Setze Reply-to auf die Liste, von Simon Hill
Trotz meiner angedeuteten leichten Präferenz, denke ich nicht, dass es auf diese Frage eine "richtige" Antwort gibt und beteilige mich auch gerne auf vielen Listen die Reply-to setzen. Das wichtigste zu diesem Thema ist, sich frühzeitig für das eine oder andere zu entscheiden und sich danach nicht zu Debatten über das Thema verleiten zu lassen.
Eines Tages wird jemand auf die geniale Idee kommen, einen reply-to-list Schlüssel in einer E-Mail Software zu implementieren. Es würde irgendwelche der vorher erwähnten spezifischen Header benutzen, um die Adresse der Mailingliste herauszufinden und direkt bzw. nur an die Liste zu antworten, ohne gesonderte Adresse für den Empfänger, da diese höchst wahrscheinlich sowieso die Liste abonniert haben. Mit der Zeit werden andere E-Mail-Programme diese Funktion übernehmen und diese ganze Debatte wird sich auflösen. (Tatsächlich gibt es sogar eine E-Mail-Software namens Mutt mit einer solchen Funktion.[31])
Eine noch bessere Lösung wäre es, die Verunstaltung von Reply-to jedem selbst zu überlassen. Wer haben möchte, dass der Verteiler ihre Reply-to Header ändert (entweder nur für ihren eigenen oder für alle Nachrichten) könnten darum bitten und solche die es nicht wollen, könnten bitten es in Ruhe zu lassen. Ich kenne jedoch keine Software die so etwas für jeden Benutzer einzeln einstellen lässt. Es scheint, dass wir derzeit mit einer globalen Einstellung für alle leben müssen.[32]
Wie man genau ein Archiv für Mailinglisten einrichtet, ist bei jeder Listen-Software unterschiedlich, und würde den Rahmen dieses Buchs sprengen. Wenn Sie ein Programm zur Archivierung wählen oder konfigurieren, sollten Sie auf folgendes achten:
Teilnehmer werden oft auf eine archivierte Nachricht verweisen wollen, die erst vor ein oder zwei Stunden gepostet wurde. Wenn möglich sollte die Software jede Nachricht sofort archivieren, sodass im gleichen Moment, indem es vom Verteiler versandt wird, es auch im Archiv ist. Wenn diese Option nicht verfügbar ist, versuchen Sie die Software zumindest so einzustellen, dass es sich ca. jede Stunde aktualisiert. (Standardmäßig lässt mache Software die Aktualisierung ein Mal jede Nacht laufen, was aber bei einer aktiven Mailingliste in der Praxis eine viel zu große Verzögerung bedeutet.)
Sobald eine E-Mail unter einer bestimmten URL archiviert wurde, sollte sie ewig, bzw. so lang wie möglich unter genau der gleichen URL erreichbar sein. Selbst wenn die Archive neu aufgebaut werden, aus einem Backup wiederhergestellt werden oder sonstwie repariert werden, sollte jede öffentlich bekannte URL weiterhin gültig sein. Stabile Verweise ermöglichen es Suchmaschinen die Archive zu indexieren und das ist für Nutzer die auf der Suche nach einer bestimmten Nachricht sind, ein großer Segen. Stabile Verweise sind auch wichtig, da der Bugtracker (siehe „Bugtracker“) später in diesem Kapitel oder Dokumente des Projekts oftmals auf darin enthaltene Nachrichten verweisen.
Idealerweise würde die Mailinglisten-Software eine URL der jeweiligen Nachricht im Archiv, in einem Header mitschicken oder zumindest den URL-Teil, spezifisch für die E-Mail. So weiß jeder mit einer Kopie der E-Mail, wo es im Archiv zu finden ist, ohne die Archive tatsächlich aufsuchen zu müssen, was hilfreich wäre da jeder Vorgang mit dem Browser, automatisch einen größeren Zeitaufwand bedeutet. Ich weiß nicht ob irgendeine Listen-Software diese Funktion anbietet; diejenigen die ich benutzt habe, können es leider nicht. Es ist allerdings etwas nachdem man suchen sollte (oder falls Sie Mailinglisten-Software schreiben, wäre es eine Funktion, die Sie bitte in Erwägung ziehen sollten).
Es sollte ziemlich offensichtlich sein wie man Sicherungen des Archivs macht und der Vorgang um sie wiederherzustellen sollte nicht zu schwierig sein. Mit anderen Worten, behandeln Sie Ihr Archiv nicht wie eine Blackbox. Sie (oder jemand aus Ihrem Projekt) sollte wissen wo die Nachrichten gespeichert werden und wie die Seiten des Archivs sich wiederherzustellen lassen, sollte es jemals nötig werden. Diese Archive sind wertvolle Daten – wenn ein Projekt sie verliert, geht auch ein großer Teil seiner kollektiven Erinnerung verloren.
Es sollte möglich sein, von jeder Nachricht aus, zu seinem zugehörigen thread (eine Gruppe verwandter Nachrichten) zu gehen. Jeder Thread sollte auch seine eigene URL haben, getrennt von denen seiner einzelnen Nachrichten.
Ein Archiv das man nicht durchsuchen kann – sowohl Volltext, als auch Betreffzeilen – ist nahezu wertlos. Bedenke, dass manche Archive ihre Suchfunktion über eine externe Suchmaschinen wie Google anbieten, indem sie die Arbeit einfach auslagern. Das ist zwar akzeptable, aber eine direkte Suchfunktion ist meistens besser abgestimmt, da es dem Suchenden z.B. erlaubt, nur die Betreffzeile zu durchsuchen oder den gesamten Text.
Obiges ist lediglich eine Checkliste, um Ihnen die Evaluierung und Einrichtung der Software für ihre Archive zu erleichtern. Leute zu überreden es wirklich zum Vorteil des Projekts zu benutzen wird in späteren Kapiteln behandelt, insbesondere im Abschnitt „Auffällige Nutzung der Archive“.
Hier sind einige Open-Source-Programme für die Verwaltung von Listen und Archives. Wenn Ihre Projektseite bereits vorkonfiguriert wurde, werden Sie sich u.U. niemals für eines entscheiden müssen. Wenn Sie es jedoch selber einrichten müssen, sind hier einige Optionen. Zu der Software, die ich tatsächlich benutzt habe gehört Mailman, Etmlm, MHonArc, und Hypermail, was aber keine Aussage über andere sein soll (und natürlich gibt es bestimmt auch andere Programme die ich einfach nicht gefunden habe, betrachten Sie diese Liste also nicht als vollständig).
Software für Mailinglisten:
Mailman – http://www.list.org/
(Mit einem eingebauten Archiv und die Möglichkeit externe einzubinden. Mailman ist seit langer Zeit der Standard; seine administrative Schnittstellen, insbesondere für die Moderation von Spam und frisch angemeldeten Mitgliedern, wirken recht angestaubt und können besonders auf diejenigen frustrierend wirken, die modernere Schnittstellen gewohnt sind.)
GroupServer – http://www.groupserver.org/
(Hat eingebaute Archivierung und integriertes Web-Interface. GroupServer ist etwas schwerer einzurichten als Mailman, und erfordert (Stand: Anfang 2012) eine sehr spezielle Menge an Voraussetzungen, aber wenn Sie ihn erst einmal zum Laufen gebracht haben, bietet es den Benutzern ein besseres Arbeiten.)
Sympa — http://www.sympa.org/
(Entwickelt und gepflegt durch einen Verband französischer Universitäten, sowohl für sehr große Listen ausgelegt (> 700000 Mitglieder) als auch eine große Anzahl von Listen. Es kann mit einer Vielzahl von Abhängigkeiten umgehen; z.B. können Sie es mit sendmail, postfix, qmail oder exim als unterliegenden Message Transfer Agent nutzen. Eine Web-basierte Archivierung ist eingebaut.)
SmartList – http://www.procmail.org/
(Für die Nutzung mit Procmail gedacht.)
Ecartis – http://www.ecartis.org/
ListProc – http://listproc.sourceforge.net/
Ezmlm – http://cr.yp.to/ezmlm.html
(Entworfen für Qmail.)
Dada – http://mojo.skazat.com/
(Trotz des bizarren Versuchs der Webseite die Tatsache zu verstecken, dass sie freie Software ist, wird sie unter der GNU GPL veröffentlicht. Es hat auch einen eingebauten Archiv.)
Software zur Archivierung:
MHonArc – http://www.mhonarc.org/
Hypermail – http://www.hypermail.org/
Procmail – http://www.procmail.org/
(Begleitend zu SmartList, eine allgemeine Software zur Verarbeitung von E-Mails und scheinbar auch als Archiv konfigurierbar.)
[31] Kurz nachdem dieses Buch erschien, schrieb mir Michael Bernstein folgende Nachricht: "Es gibt weitere E-Mail-Programme außer Mutt, die eine reply-to-list Funktion implementiert haben. Evolution bietet diese Funktion z.B. wenn auch ohne eigene Schaltfläche, über die Tastenkombination (Strg+L)."
[32] Seitdem ich das schrieb, habe ich zumindest von einer Mailinglisten-Software erfahren, die diese Funktion anbietet: Siesta. Siehe dazu auch diesen Artikel: http://www.perl.com/pub/a/2004/02/05/siesta.html