Mailman Betreuer Dokumentation

Info

Hier soll eine Anleitung für Mailinglisten-Betreuer entstehen. Erstmal können wir Tips hier auf der Seite sammeln und dann Unterseiten anlegen. Dabei die Seiten immer mit "Mailman" anfangen lassen, damit man sie leicht identifizieren kann.

s.a.

-> Mailman Benutzer Dokumentation

-> Mailman FAQ

---

Der folgende Text ist eine Übersetzung der englischen Hilfedatei von Barry A. Warsaw.

---

GNU Mailman - Handbuch zur Listenadministration

von Barry A. Warsaw

Version 2.1

12.September 2007

Zusammenfassung

Dieses Dokument beschreibt die Programmoberfläche für Listenadministratoren in GNU Mailman 2.1. Es enthält Informationen, die ein Listenadmin benötigt um seine Liste zu konfigurieren: sowohl über die Webschnittstelle als auch über E-Mail. Es behandelt auch die Moderatoren-Schnittstelle zur Prüfung zurückgehaltener E-Mails, die Bearbeitung der Nachrichten, die bei der Abonnierung verwendet werden sowie die Webschnittstelle für die Erstellung neuer Mailinglisten. Im Allgemeinen sind keine Informationen zur Kommandozeilen-Administration von Mailman, zur Installation von Mailman sowie zur Interaktion mit Mailman aus Benutzersicht enthalten. Diese Information wird in anderen Handbüchern behandelt.

Erstes Kennenlernen von GNU Mailman

GNU Mailman ist ein Programm, mit dem man Mailinglisten verwalten kann. Es unterstützt eine Vielzahl von Typen von Mailinglisten, wie z.B. allgemeine Diskussionslisten aber auch reine Informationslisten für Veröffentlichungen. Mailman hat zahlreiche Möglichkeiten für die Steuerung der Privatheit/Offenheit der Listen, verteilt die Listen als personalisierte Einzelnachrichten oder als Sammelnachricht (Digest), kann Nachrichten in das und aus dem Usenet vermitteln und bietet eine automatische Erkennung von Zustellproblemen (Bounce) an. Mailman bietet eine eingebaute Archivverwaltung an, unterstützt eine Reihe von Landessprachen ebenso wie hochentwickelte Inhalts- und Schlagwortfilter.

Mailman bietet einige Schnittstellen zur Steuerung seiner Funktionen. Die meisten Listen-Admins werden vor allem die Webschnittstelle nutzen, um ihre Listen zu konfigurieren. Es gibt weiterhin eine E-Mail-Kommando-Schnittstelle (mit eingeschränkter Funktionalität) zu den administrativen Funktionen sowie eine Kommandozeilen-Schnittstelle, sofern man Zugang zu einer Konsole auf dem Mailman Server hat. Dieses Dokument behandelt nicht diese Kommandozeilen-Schnittstelle, weitergehende Informationen dazu sind auf der GNU Mailman Site Administrator's Webseite zu finden.

Die E-Mail-Adressen der Liste

Jede Mailingliste hat eine Reihe von E-Mail-Adressen, die Nachrichten entgegennehmen. Darunter ist immer eine Adresse, die für die Verteilung von Nachrichten an die Listenteilnehmer vorgesehen ist. Eine weitere dient zum Empfang von Nachrichten über Zustellprobleme (Bounce) und schließlich eine für die Auswertung und Ausführung von E-Mail-Kommandos. So gibt es z.B. bei einer Mailingliste mit dem Namen MeineListe@Beispiel.de folgende Adressen:

• MeineListe@Beispiel.de - das ist die E-Mail-Adresse, die von den Teilnehmern für das Versenden von Nachrichten an die Liste verwendet werden soll.
• MeineListe-join@Beispiel.de - sendet man eine Nachricht an diese Adresse, kann damit das Abonnement dieser Liste durch ein neues Mitglied angefordert werden. Der verwendete Betreff (subject) und der Nachrichtentext (body) werden in diesem Fall beide ignoriert. Die Adresse MeineListe-subscribe@Beispiel.de wirkt gleichwertig (ist ein Alias) zur "-join"-Adresse.
• MeineListe-leave@Beispiel.de - sendet man eine Nachricht an diese Adresse, kann damit das Ende des Abonnement dieser Liste durch ein bestehendes Mitglied angefordert werden. Wie bei der "-join"-Adresse werden der verwendete Betreff (subject) und der Nachrichtentext (body) beide ignoriert. Die Adresse MeineListe-unsubscribe@Beispiel.de wirkt gleichwertig (ist ein Alias) zur "-leave"-Adresse.
• MeineListe-owner@Beispiel.de - über diese Adresse erreicht man direkt die Listeneigner und -moderatoren.
• MeineListe-request@Beispiel.de - über diese Adresse erreicht man einen Mail-Roboter, der E-Mail-Kommandos auswertet und ausführt, mit deren Hilfe Abonnements-Optionen von Teilnehmern gesetzt aber auch andere Aktionen ausgeführt werden können.
• MeineListe-bounces@Beispiel.de - diese Adresse erhält die Nachrichten über Zustellprobleme (bounce)bei Teilnehmern, deren Adressen zeitweilig oder endgültig inaktiv geworden sind. Die "-bounces"-Adressse ist auch ein Mail-Roboter, der Bounces auswertet und automatisch Teilnehmer auf der Liste deaktiviert oder sie von der Liste entfernt, so wie es für die Liste in den einstellungen für die Unzustellbarkeitsbearbeitung (bounce processing, Bounce-Bearbeitung) konfiguriert wurde. Unzustellbarkeits-Nachrichten, deren Inhalt vom Roboter nicht verstanden wurde oder die keine Teilnehmer zu enthalten scheint, wird an die Listen-Admins weitergeleitet.
• MeineListe-confirm@Beispiel.de - diese Adresse ist ein weiterer E-Mail-Roboter, der Bestätigungs-Nachrichten (confirmation messages) für den Beginn oder das Ende eines Abonnements auswertet und verarbeitet.

Es gibt ferner einer "-admin"-Adresse, die Nachrichten ebenfalls an die Listen-Admins weiterreicht: diese Adresse existiert jedoch nur noch zu Zwecken der Abwärtskompatibilität mit älteren Versionen von Mailman.

Administrative Rollen

Es gibt zwei wesentliche administrative Rollen (Aufgabenbereiche) für jede Mailingliste, den Listeneigner (list owner = Listenadmin) und den Listenmoderator.

Der Listeneigner darf die vielen Einstellungen der Liste ändern, z.B. die Datenschutz- und Archivierungsregeln, die Regelsätze für den Inhaltsfilter usw. Dem Listeneigner ist es ebenso gestattet, Teilnehmer in die Liste einzuschreiben oder sie dazu einzuladen, Teilnehmer von der Liste zu entfernen oder die Abonnementskonfiguration einzelner Teilnehmer zu ändern.

Der Listenmoderator hat andererseits nur die Berechtigung, angehaltene Nachrichten an die Liste weiterzureichen oder abzuhalten und Abonnementsanfragen zu bearbeiten. Der Listenmoderator kann ebenfalls solche Dinge tun, wie das Moderationskennzeichen (moderation flag) eines Teilnehmers zu entfernen oder eine E-Mail-Adresse zu der Liste der geprüften Sender zu ergänzen, die selbst keine Listenempfänger sind.

Normalerweise sind der Listeneigener und -moderator ein und die selbe Person. Tatsächlich kann der Listeneigner auch alle Handlungen ausführen, die einem Listenmoderator gestattet sind. Der Zugang zu beiden Konfigurationsseiten, der des Listeneigners und der des Listenmoderators, ist mit dem selben Paßwort geschützt. Allerdings kann der Listeneigner auf Wunsch das Recht, über zurückgehaltene Nachrichten und Abonnementswünsche zu entscheiden, an andere Leute delegieren, ein eigenes Paßwort für den Listenmoderator setzen und somit Listenmoderatoren den Zugang zu den entsprechenden Überprüfungsseiten geben, ohne die Konfigurationsseiten freizugeben. Aber auch in einer solchen Konfiguration können die Listeneigner natürlich weiterhin ihre Liste moderieren.

In den folgenden Abschnitten werden die Begriffe Listeneigener und Listenmoderatoren häufig austauschbar verwendet und damit beide Rollen gemeint. Sofern es notwendig wird, wird der Listenmoderator ausdrücklich separat erwähnt.

Die Webseiten der Liste

Jede Mailingliste ist auch über eine Reihe von Webseiten erreichbar. Der Administrator der Mailman-Gesamtinstallation (site) kann die exakte Webadresse (URL) dieser Seiten konfigurieren, so daß sie auch von den unten beschriebenen abweichen können. Wir beschreiben die gebräuchlichste Standard-Konfiguration, sie sollte aber vom Administrator oder dem Webhoster bestätigt werden.

Mailman bietet eine Reihe von Webseiten an, auf denen die Listenteilnehmer Informationen über die Liste erhalten oder ihre eigene Teilnehmerkonfiguration verwalten können. Es gibt weiterhin Seiten für das Listenarchiv, die zum Durchstöbern des webbasierten Online-Archives des Listenverkehrs dienen. Diese werden detaillierter im GNU Mailman Benutzerhandbuch beschrieben.

Mailman bietet außerdem eine Reihe von Webseiten an, auf denen die Liste individuell konfiguriert werden kann sowie eine Reihe von Webseiten zur Verwaltung der zurückgehaltenen Nachrichten und der Abonnementswünsche.

Die administrativen Seiten einer Mailingliste MeineListe, die auf der Maildomain lists.Beispiel.de gehostet wird, werden typischerweise über die Adressse http://lists.Beispiel.de/mailman/admin/MeineListe zu erreichen sein. Das erste Mal, wenn die Listenseite aufgerufen wird, erscheint eine Anmeldeseite, auf der nach dem Paßwort des Listeneigners gefragt wird. Das eingegebene Paßword wird von Mailman in einem Sitzungs-Cookie im Webbrowser gespeichert, so daß für die folgenden Aktionen keine weiteren Re-Authentifizierungen nötig werden. Dieser Cookie wird nur bis zum Ende der Browser-Sitzung gespeichert.

Um die Seite der administrativen Listentätigkeiten (zurückgehaltene Nachrichten, Abonnementswünsche) zu erreichen, ist die Adresse http://lists.Beispiel.de/mailman/admindb/MeineListe aufzusuchen (zu beachten ist dabei der Adreßteil admindb anstelle von admin). Erneut wird hier beim erstmaligen Besuch eine Anmeldeseite aktiv, auf der das Paßwort des Listeneigners oder des Listenmoderators akzeptiert wird. Auch dieses Paßwort wird in einem Sitzungs-Cookie des Browsers abgespeichert. Ebenso erübrigt eine vorherige Anmeldung als Listeneigner die erneute Anmeldung an dieser Stelle.

Überblick über die Basis-Architektur

Dieser Abschnitt stellt die Basis-Architektur von GNU Mailman dar, also wie Nachrichten durch das System verarbeitet werden. Ohne auf die zahlreichen Details einzugehen werden diese Informationen für das Verständnis hilfreich sein, wie die Konfigurations-Optionen Mailmans Funktionalität steuern.

Wenn eine Nachricht vom Mailserver eintrifft, wird sie in Abhängigkeit von der Empfänger-Adresse in eine von verschiedenen Warteschlangen von Mailman gestellt. Wenn zum Beispiel das System eine Liste MeineListe enthält und die Maildomäne Beispiel.de ist, können Nachrichten über die Liste veröffentlicht werden, indem sie an die Adresse MeineListe@Beispiel.de geschickt werden. Diese Nachrichten werden in die Eingangswarteschlange gestellt, die umgangssprachlich auch die "moderiere-und-lösche-Warteschlange" genannt wird (moderate-and-munge queue). An dieser Stelle finden auch die meisten Prüfprozesse statt sowie die Vorbereitungsaktionen vor dem Versenden an die Teilnehmer.

Es gibt eigene Warteschlangen für das eingebaute Archiv, die Verarbeitung der Nichtzustellbarkeitsmeldungen (bounce processing), die Verarbeitung von E-Mail-Kommandos genauso wie die Ausgangswarteschlangen für E-Mails und News. Weiterhin gibt es eine Warteschlange für die Nachrichten, die vom Mailman-System selbst generiert werden. Jede dieser Wartschlangen hat typischerweise einen eigenen Prozess zur Bearbeitung (queue runner oder qrunner) der jeweiligen Nachrichten. Wenn keine Nachrichten in der Warteschlange vorhanden sind, sind die qrunner in Bereitschaft.

Jede Nachricht in der Warteschlange wird durch zwei Dateien dargestellt: eine Nachrichten-Datei und eine Metadaten-Datei. Beide Dateien haben den selben Datei(haupt)namen, der sich aus einer Kombination eines eindeutigen Hash-Wertes und der Unix-Darstellung der Empfangszeit dieser Nachricht ergibt. die Metadaten-Datei hat dann die Dateierweiterung .db und die Nachrichten-Datei entweder .msg, wenn sie in einfachem Textformat oder .pck, wenn sie in einem effizienteren internen Format gespeichert ist.

Wenn sich die Nachricht durch die Eingangswarteschlange bewegt wird sie diversen Prüfungen unterzogen, z.B. ob sie einer der Moderatons-Kriterien genügt oder ob sie nichterlaubte MIME-Typen enthält. Sobald ihre Versendung an die Teilnehmer der Mailingliste gestattet wurde, wird sie dafür vorbereitet, indem Nachrichten-Kopfzeilen (message headers) ergänzt, entfernt oder geändert oder Fußzeilen ergänzt werden, usw. Nachrichten in der Eingangswarteschlange können ebenfalls für die Zusammenstellung einer Übersichtsnachricht (Digest) gespeichert werden.

Die Konfigurationsseite der Liste

Nachdem man sich für den Besuch der Konfigurationsseite der Liste angemeldet hat, sieht man die Konfigurations-Einstellungen der Liste, die in Kategorien gruppiert sind. Alle administrativen Seiten haben einige gemeinsame Elemente. Im oberen Teil kann man zwei Spalten mit der Überschrift Konfigurationskategorien erkennen. Manche Kategorien haben Unterkategorien, die erst sichtbar werden, wenn man auf den Kategorien-Link klickt. Die erste Seite, die man nach dem Anmelden sieht, ist die Kategorie Allgemeine Optionen. Die spezifischen Einstellungsmöglichkeiten in jeder Kategorie werden weiter unten beschrieben.

Auf der rechten Seite des oberen Seitenbereiches sieht man eine Spalte mit der Überschrift Andere administrative Tätigkeiten. Hier finden sich einige andere Dinge, die man mit der Liste machen kann gemeinsam mit praktischen Links auf die Informationsseite der Liste sowie deren Archivseite. Man beachte den großen Logout-Link (Abmelden); dieser Link kann nach Beendigung der Listenkonfiguration aufgerufen werden, wenn der Sitzungs-Cookie mit dem gespeicherten Paßwort aus dem Browser gelöscht werden soll.

Unter diesem gemeinsamen Kopfbereich findet man eine Liste mit den Konfigurationsvariablen der jeweiligen Kategorie, zweispaltig angeordnet. In der linken Spalte wird der Zweck der Variable kurz beschrieben, wobei hier ein Link Details zu ... enthalten ist. Für viele dieser Variablen ist eine detailliertere Beschreibung verfügbar, in der die Ausfüllvorschriften oder das Zusammenwirken mit anderen Variablen erläutert wird. Der Klick auf den Details-Link fördert eine Seite mit Informationen ausschließlich zur interessierenden Variable zutage, gemeinsam mit einem Schalter für die Speicherung der Eintragungen und einem Link zurück zur Kategorien-Seite.

Auf der rechten Seite des zweispaltigen Bereiches sieht man den aktuellen Wert der jeweiligen Variablen. Manche Variablen können Werte aus einem vorgegebenen Wertevorrat erhalten, die über Auswahl- (genau ein Wert) oder über Aktivierungsschalter (ein oder mehrere Werte) gewählt werden können. Andere Variablen können über auszufüllende ein- oder auch mehrzeilige Textfelder konfiguriert werden. Die meisten Variablen steuern das Verhalten von Listenaktionen, einige allerdings führen unmittelbar Aktionen durch (diese sind deutlich gekennzeichnet).

Im unteren Teil der Seite sieht man einen Schalter Änderungen speichern sowie eine Fußzeile mit weiteren nützlichen Links und einigen Logos. Die Aktivierung des Schalters Änderungen speichern aktiviert die eingetragenen Variablenwerte, nachdem sie überprüft worden sind. Alle ungültigen Werte werden ignoriert und eine Fehlermeldung erscheint in diesem Fall im oberen Teil der Folgeseite. Die Folgeseite ist immer die Seite der gerade bearbeiteten Kategorie.

Die Kategorie Allgemeine Optionen

In der Kategorie Allgemeine Optionen kann eine Vielzahl von Variablen eingestellt werden, die das Basis-Verhalten der Liste und die öffentlich sichtbaren Informationen beeinflussen.

Allgemeine Listenübersicht

Die Variablen, die im Abschnitt Allgemeine Listenübersicht gruppiert sind, steuern einige öffentliche Informationen zur Mailingliste.

Öffentlicher Name der Liste (real_name)

Jede Mailingliste hat sowohl einen Sendenamen als auch einen öffentlichen Namen. Der Sendename wird in den URLs und in den E-Mail-Adressen verwendet, z.B. meineliste in meineliste@Beispiel.de. Der Sendename wird immer durchgängig mit Kleinbuchstaben geschrieben, kann alphanumerische Zeichen enthalten, aber keine Leerzeichen. Der öffentliche Name der Liste wird in einigen öffentlich sichtbaren Informationen und in E-Mail-Antworten verwendet, so zum Beispiel in der Allgemeinen Übersicht aller Mailinglisten Der öffentliche Name kann vom Sendenamen abweichen, allerdings nur in der Groß-/Kleinschreibweise. Ist der Sendename z.B. meineliste kann der öffentliche Name MeineListe sein.

Listeneigner (owner)

Diese Variable enthält eine Liste mit E-Mail-Adressen des oder der Listeneigner, jeweils eine pro Zeile. Diese Adressen werden immer dann verwendet, wenn Kontakt zu den Listeneignern hergestellt werden soll, entweder durch das System oder durch die Endbenutzer selbst. Häufig werden diese Adressen in Kombination mit den Moderatoren-Adressen eingesetzt (siehe unten).

Listenmoderator (moderator)

Diese Variable enthält eine Liste mit E-Mail-Adressen des oder der Listenmoderatoren, jeweils eine pro Zeile. Häufig werden diese Adressen in Kombination mit den Adressen der Listeneigner eingesetzt. Wenn z.B. Nachrichten an die Adresse MeineListe-owner@Beispiel.de geschickt werden, erhalten sowohl die (Adressen der) Listeneigner als auch die der Listenmoderatoren eine Kopie davon.

Beschreibung (description)

Auf der allgemeinen Übersichtsseite (in der alle auf diesem Server verfügbaren Mailinglisten angezeigt werden) ist jede Liste durch einen kurzen Beschreibungstext aufgeführt. Der Inhalt der Variable description entspricht diesem Text. Beachte: dieser Text wird ebenfalls in der Kommentarsektion der To: Adresse beim Verschicken von E-Mails aus dieser Liste verwendet. Deshalb sollte der Text relativ kurz sein, auf keinen Fall mehr als eine Zeile.

ausführlichere Beschreibung (info)

Diese Variable enthält eine ausführlichere Beschreibung der Mailingliste. Sie wird am Anfang der Informationsseite der Mailingliste eingebunden und kann HTML enthalten. Leerzeilen werden allerdings automatisch in Absatzwechsel konvertiert. Verwendeter HTML-Text sollte vorher überprüft werden, da unvollständiger oder unkorrekter HTML-Text (z.B. fehlende schließende Tags) die Anzeige von Teilen der Informationsseite der Mailingliste verhindern kann.

Präfix für Betreffzeile der Listennachrichten (subject_prefix)

Dies ist eine Zeichenfolge, die der Betreff-Kopfzeile (subject header) jeder Nachricht an die Liste vorangestellt wird. Wird z.B. eine Nachricht mit dem Betreff "Das ist eine Nachricht" verschickt und der Präfix ist "[Meine Liste] " (man beachte das Leerzeichen am Ende!) würden die Listenteilnehmer eine Nachricht mit dem Betreff "[Meine Liste] Das ist eine Nachricht" erhalten. Wird diese Variable leer gelassen, so wird dem Betreff auch kein Präfix vorangestellt. Mailman achtet darauf, keinen Präfix zu ergänzen, sofern die Kopfzeile bereits einen hat, wie es z.B. bei Antwortnachrichten der Fall ist. Der Präfix kann auch Zeichen aus der bevorzugten Listen-Landessprache enthalten. In diesem Fall kann es wegen der diesbezüglich nicht eindeutigen E-Mail-Standards sinnvoll oder auch nicht sinnvoll sein, das nachgestellte Leerzeichen im Präfix zu verwenden.

Adresse verstecken (anonymous_list)

Diese Variable gestattet es, einige einfache Anonymisierungs-Optionen von Mailman zu verwenden. Wird diese Option auf Ja gesetzt, entfernt bzw. ersetzt Mailman die From:, Sender: und Reply-To: Kopfzeilen jeder Nachricht, die an die Liste gesendet wird. Man beachte, daß diese Option einfache eine Hilfe für die Anonymisierung von Mails ist, sie wird dadurch nicht sicher garantiert. So kann z.B. die Identität des Absenders aus seiner Signatur ersichtlich werden oder aus anderen Kopfzeilen der Nachricht oder auch aus dem Stil des Nachrichteninhaltes. Mailman kann nur wenig gegen solche Informationen unternehmen.

Reply-To: Kopfzeilen Optionen

Dieser Abschnitt steuert, was mit den Replay-To: Kopfzeilen (header) der an die Liste gesendeten Nachrichten geschieht.

Vorsicht! Das Verändern der Replay-To: Kopfzeile kann als religiöse Angelegenheit betrachtet werden und der Regelsatz, der hier festgelegt wird, kann eine der heißesten Diskussionen abseits des eigentlichen Listenthemas entfachen. Wir wollen uns dazu so neutral wie möglich verhalten, haben allerdings auch eine eigene Meinung, die sicherlich durchschimmern wird. Replay-To: ist eine Kopfzeile, die gewöhnlich dazu verwendet wird, um Antwortnachrichten an einen bestimmten Empfänger zu adressieren. Was nun genau geschieht, wenn auf eine Nachricht auf diese Weise geantwortet werden soll, hängt vom Mailprogramm ab, das vom Leser der Nachricht verwendet wird und welche Funktionen es unterstützt. Üblicherweise gibt es sowohl ein Antworten (nur an den Absender) als auch ein Allen antworten Schalter. Werden diese Schalter von allen Anwendern korrekt verwendet, gibt es wahrscheinlich keinen Grund die Reply-To: Kopfzeile zu verändern und die Standardeintragung sollte in Ordnung sein. Da eine auf Informationen beruhende, bewußte Entscheidung immer das Beste ist, folgen Links auf zwei Artikel, die die beiden gegensätzlichen Auffassungen dazu detaillierter besprechen:

• "Contra Reply-To: Veränderung"
• (Der Link zum Artikel "Pro Reply-To: Veränderung" konnte aktuell nicht mehr nachvollzogen werden!)

Die drei Optionen in diesem Abschnitt arbeiten zusammen, um so ausreichend Flexibilität für das anzubieten, was immer man beim Thema Reply-To: Anpassung meint machen zu müssen.

Original Reply-To Kopzeile verwerfen? (first_strip_reply_to)

Diese Variable steuert, ob eine in der zu versendenden Nachricht bereits vorhandene Reply-To: Kopfzeile vor allen weiteren Änderungsaktionen entfernt werden soll. Eine aktivierte Bereinigung wird auf jeden Fall ausgeführt, unabhängig davon, ob Mailman eine eigene Reply-To: Kopfzeile ergänzen soll oder nicht. Wird diese Option auf Nein gesetzt, bleiben alle möglicherweise in der Nachricht existierenden Reply-To: Kopfzeilen unangetastet. Ergänzt Mailman eine eigene Reply-To: Kopfzeile, so enthält sie die ursprünglich vorgelegenen Adressen, ergänzt um die von Mailman hinzugefügten Adresse(n). Die Mailstandards legen fest, daß eine Nachricht nur eine Reply-To: Kopfzeile haben darf, diese allerdings mehrere Adressen enthalten kann.

Adresse für die Beantwortung von Listennachrichten (reply_goes_to_list)

Diese Variable steuert, ob Mailman seine eigene Reply-To: Kopfzeile ergänzen soll, und welche Adresse im positiven Fall verwendet werden soll (ungeachtet Der Löschung der Originalkopfzeile - s.o.). Wird diese Variable auf Absender gesetzt, wird keine zusätzliche Kopfzeile von Mailman ergänzt. Diese Einstellung wird dringend empfohlen. Wird die Variable auf den Wert Diese Liste gesetzt, wird eine Reply-To: Kopfzeile ergänzt, die die Sendeadresse der Liste enthält. Wenn die Variable auf Explizite Adresse gesetzt wird, wird der Inhalt der Variablen reply_to_address (s.u.) ergänzt. Man beachte, daß es durchaus eine Situation gibt, wo das explizite Setzen der Reply-To: Kopfzeile einen legitimen Grund haben kann. Angenommen, es gibt zwei Listen: eine Veröffentlichungsliste und eine Diskussionsliste. Über die Veröffentlichungsliste können nur wenige, bewährte Benutzer Nachrichten verschicken, die meisten der Empfänger werden es wahrscheinlich nicht gestattet bekommen. Allerdings sollen allen Teilnehmern Kommentare zu Veröffentlichungen gestattet sein, die an die Diskussionsliste gerichtet werden sollen. In diesem Fall kann die Reply-To: Kopfzeile der Veröffentlichungsliste auf die Sendeadresse der Diskussionsliste gesetzt werden.

Expliziter Reply-To Header (reply_to_address)

Das ist die Adresse, die in die Reply-To: Kopfzeile eingetragen wird, sofern reply_goes_to_list auf Explizite Adresse gesetzt ist.

Einstellungen der Regenschirm-Listen

(noch auszuarbeiten) Es ist zu beachten, daß Regenschirm-Listen ("Listen von Listen") nicht mehr empfohlen sind und durch einen besseren Mechanismus in Mailman 3.0 ersetzt werden.

Benachrichtigungen

Mailman sendet Benachrichtigungen an die Listenadmins oder Listenmitglieder bei einer Reihe von Anlässen. Die meisten dieser Benachrichtigungen können in diesem Abschnitt konfiguriert werden, allerdings sollte auch in den Kategorien für Bounce-Bearbeitung (bounce processing) und Automatischer Beantworter nachgeschaut werden, wo weitere Benachrichtigungen von Mailman verendet werden.

Sende monatliche Passwort-Erinnerungsnachricht? (send_reminders)

Standardmäßig sendet Mailman allen Listenmitgliedern eine monatliche Paßworterinnerung. Diese Nachricht dient zweierlei Zwecken. Einerseits erinnert sie alle Benutzer an alle Listen, an die sie sich auf diser Domain angemeldet haben, einschließlich der Listen, auf denen das Abonnement momentan deaktiviert ist. Andererseits werden die Benutzer an die Paßworte auf ihren Listen sowie an die URL für die Einstellung ihrere Benutzeroptionen auf den Listen erinnert, so daß sie einfacher ihre Abonnementsoptionen verwalten können. Mancher fühlt sich durch diese monatlichen Erinnerungen belästigt, in diesem Fall kann auf der Konfigurationsseite des Benutzers für dieses Listenabonnement die Erinnerungsnachricht deaktiviert werden. Auf manchen Listen ist die monatliche Erinnerungsnachricht für alle Benutzer unangebracht, so daß sie listenweit deaktiviert werden sollte, indem die Variable send_reminders auf Nein gesetzt wird.

Text für den Willkommensgruss für neue Abonnenten (welcome_msg)

Wenn neue Abonnenten aus eigener Initiative oder durch die Aktion eines Admins in die Liste eingeschrieben werden, kann an sie ein Willkommensgruß an sie gesendet werden. Der Willkommensgruß enthält einige allgemeine Standardinformationen, wie z.B. den Namen der Liste, Anleitungen zum Versenden von Nachrichten an die Liste sowie das Listenpaßwort des neuen Abonnenten. Man kann weitere Informationen für den Willkommensgruß ergänzen, indem der gewünschte Text in die Textbox der Variable welcome_msg text. Man beachte dabei, daß dieser Text als Teil einer E-Mail keinen HTML-Text enthalten sollte.

Willkommensgruss an neue Abonnenten senden? (send_welcome_msg)

Dieser Schalter steuert, ob ein oder ob kein Willkommensgruß an neue Abonnenten geschickt wird.

Text für die Abbestellungsnachricht (goodbye_msg)

Wie der Willkommensgruß kann auch eine Abschiedsnachricht an diejenigen Mitglieder gesendet werden, die die Liste abbestellen. Im Unerschied zum Willkommensgruß gibt es hier keine Standardinformationen. Man trägt den gesamten Text, der an die ausscheidenden Teilnehmer gesendet werden soll, in die Textbox der Variablen goodbye_msg ein.

Abbestellungsnachricht senden? (send_goodbye_msg)

Dieser Schalter steuert, ob ein oder ob keine Abbestellungsnachricht an ausscheidende Abonnenten geschickt wird.

Sofortige Nachricht an den Listenadmin bei Anforderungen? (admin_immed_notify)

Listenmoderatoren erhalten eine Benachrichtigung über unbearbeitete administrative Aktionen, wie z.B. Bestell- oder Abbestellanfragen, die einen Moderatoreneingriff benötigen, oder die Bearbeitung von Nachrichten an die Liste, die für eine Moderation zurückgehalten wurden. Listenmoderatoren erhalten immer eine tägliche Zusammenfassung dieser offenen Aufgaben, sie können allerdings auch unmittelbar bei Eintreffen einer solchen Anforderung von Mailman benachrichtigt werden. Die Variable admin_immed_notify steuert, ob diese Einzelnachrichten unverzüglich gesendet werden sollen, oder nicht. Es ist generell eine gute Idee, diese Einstellung auf Ja zu belassen.

Nachricht an Admins bei Bestellung und Abbestellung? (admin_notify_mchanges)

Diese Variable steuert, ob die Listenadmins Benachrichtigungen bei Abonnements und Abbestelliungen erhalten sollen oder nicht.

E-Mail an Absender, wenn dessen Beitrag auf Genehmigung wartet? (respond_to_post_requests)

Diese Variable steuert, ob der eigentliche Sender einer Nachricht an die Liste eine Hinweis-E-Mail bekommt, daß die Versendung seiner Nachricht für eine Überprüfung durch einen Moderator angehalten wurde.

Zusätzliche Einstellungen

Dieser Abschnitt enthält einige zusätzliche Einstellungen für die Mailingliste.

Notmoderation (emergency)

Wenn diese Option aktiv gesetzt ist, werden alle eintreffenden Nachrichten, die an die Liste gesendet werden sollen, für eine Moderation (Begutachtung und folgende Freigabe oder Ablehnung) angehalten. Dis ist in den Fällen wertvoll, wenn die Liste durch Nachrichten geflutet wird und ein temporäres Schutzschild zunächst für Ruhe sorgen soll.

Standardeinstellungen für neue Mitglieder (new_member_options)

Jeder Listenteilnehmer hat einen Satz an Abonnementseinstellungen, mit denen gesteuert wird, wie Nachrichten empfangen werden sollen und anderweitig mit der Liste interagiert werden kann. Die Mitglieder der Liste können sich (nach einer Anmeldung) auf ihrer jeweiligen Optionsseite ihre Einstellungen selbst wählen, andererseits können einige der Einstellungen für neue Mitglieder voreingestellt werden. Das kann mit dieser Variablen geschehen, allerdings sind auch in anderen Variablen-Kategorien teilweise Voreinstellungen vergebbar. Diese Variable bietet einen Satz von Aktivierungs-Kästchen an, mit denen einige der Mitglieder-Optionen voreingestellt werden können. Listenmitgliedschaft nicht öffentlich anzeigen entscheidet darüber, ob die E-Mail-Adresse des Senders in den Kopfzeilen der Nachrichten versteckt oder angezeigt wird. Verteilte Mails dem Nutzer bestätigen entscheidet darüber, ob der Sender von Mailman eine Bestätigungsmail über die erfolgreiche Versendung der ursprünglichen Nachricht an die Liste erhält. Keine Mailinglisten-Mail zurück an den Absender selbst senden entscheidet darüber, ob der ursprüngliche Absender bei der Verteilung an die Liste eine Kopie seiner eigenen Mail erhält. Doppelte Mails an Listenmitglieder herausfiltern ermöglicht die Doppelversendung von Nachrichten an Empfänger zu verhindern, die gleichzeitig Listenmitglieder sind und z.B. in der ursprünglichen Nachricht explizit im CC: aufgeführt werden. Natürlich können die einzelnen Listeneilnehmer diese Voreinstellungen durch Änderungen auf ihrer eigenen Listen-Optionsseite überschreiben.

Administrative Mails filtern? (administrivia)

Diese Einstellung legt fest, ob Mailman die eigentlich an die Liste gesendeten Mails nach administrativen Mails durchsuchen soll, die Steueranweisungen enthalten, mit anderen Worten, nach E-Mail-Kommandos suchen soll, die eigentlich -request-Adresse der Liste gesendet werden sollten. Setzt man diese Option auf Ja wird verhindert, daß solche Dinge wie Abbestellungskommandos irrtümlicherweise an die Liste gesendet werden, sie werden für eine Moderation zurückgehalten.

Maximale Nachrichtentextgröße (max_message_size)

Diese Einstellung legt eine maximale Nachrichtengröße in Kilobyte fest. Größere Nachrichten werden für eine Moderatoren-Bearbeitung zurückgehalten.

Hostname (host_name)

Diese Option legt den Hostnamen-Teil der E-Mail-Adressen fest, die von von der Liste verwendet werden. Im Beispiel MeineListe@Beispiel.de ist dies Beispiel.de. Generell ist es keine gute Idee, diesen Wert zu verändern, da der Standardwert beim Anlegen der Liste eingestellt wird. Wird diese Variable auf einen inkorrekten Wert eingestellt, kann es schwierig werden, Kontakt zur Mailingliste aufzunehmen. Aus diesem Grund sind auch die URLs der administrativen Seiten der Liste nicht über die Webschnittstelle änderbar. Dies wurde deshalb vermieden, da Fehler an diser Stelle nur noch durch den Administrator der Site behoben werden könnten.

RFC 2369 Header einfügen? (include_rfc2369_headers)

RFC 2369 ist der Internet-Standard, der eine Reihe von Kopfzeilen (header) beschreibt, die Mailinglisten-Admins in Nachrichten ergänzen sollten, um den Teilnehmern die Zusammenarbeit mit der Liste zu erleichtern. Mailprogramme, die diesen Standard unterstützen, können Schalter anbieten, die den Zugang zum Listenarchiv, das Listenabonnement oder die -abbestellung vereinfachen. Es ist generell eine gute Idee, diese Kopfzeilen zu verwenden, denn sie gestatten eine verbessertes Nutzungsverhalten. Diese Kopfzeilen werden oft als List-* Kopfzeilen bezeichnet. Allerdings erfüllen nicht alle Mailprogramme die Standards und wenn ein größerer Anteil der Listenteilnehmer nicht standardkonforme Mailprogramme verwenden, können sich diese durch diese Kopfzeilen belästigt fühlen. Man sollte zunächst versuchen, den Listenteilnehmer zu erläutern, welchen Zwecken diese Kopfzeilen dienen und wie sie in den verwendeten Mailprogrammen versteckt werden können. Erst als letztes Mittel sollten diese Kopfzeilen deaktiviert werden, allerdings wird dies nicht empfohlen.

List-Post-Header verwenden? (include_list_post_header)

Die List-Post: Kopfzeile (header) ist einer der vom RFC 2369 empfohlenen Kopfzeilen. Allerdings ist es bei manchen Veröffentlichungs-Mailinglisten nur einer genau ausgewählten Gruppe von Teilnehmern gestattet, Nachrichten an die Liste zu versenden; die generelle Teilnehmerschar hat üblicherwiese dieses Recht nicht. Für Listen dieser Convinience führt die List-Post: Kopfzeile zu Fehlern. Man setzt hier besser ein Nein, um die Verwendung dieser Kopfzeile zu verhindern. (Dies hat keine Auswirkung auf die Verwendung oder Nichtverwendung der anderen List-* Kopfzeilen.)

Die Kategorie Passwörter

Wie oben bereits erwähnt gibt es bei den Mailinglisten zwei primäre administrative Rollen. In dieser Kategorie können die Paßwörter für diese beiden Rollen gesetzt werden. Der Listeneigner hat vollen Zugriff auf die gesamte Konfiguration der Liste (innerhalb gewisser Grenzen, die vom Site Admininistrator gezogen werden). Man beachte, daß in diesem Text aus historischem Bezug die Rolle des Listeneigners als Listenadmin beschrieben ist. Man kann das Passwort des Listeneigners setzen, indem es in des Feld links eingetragen wird. Man muß das Passwort ein weiteres Mal zur Bestätigung eintragen. Man beachte, daß ein vergessenes Listenadmin-Passwort nur durch den Site Administrator zurückgesetzt werden kann, es gibt keine Erinnerungsmail für den Listenadmin, so daß es keinen weiteren Weg zu den administrativen Webseiten gäbe. Wenn die Listenmoderation an jemand anderes delegiert werden soll, kann auf der rechten Seite ein Passwort für den Listenmoderator eingetragen werden, auch hier mit einem zweiten Eintrag zur Bestätigung. Man beachte, daß in dem Fall, wo keine personelle Trennung zwischen Listenadministratoren und -moderatoren vorgesehen wird, auch kein Moderatoren-Passwort vergeben wird. Wenn ein separates Moderatoren-Passwort vergeben wird, müssen auch Einträge in der Variable moderator auf der Seite Allgemeine Optionen gemacht werden.

Die Kategorie Sprachoptionen

Mailman ist mehrsprachig und internationalisiert, d.h. man kann eine Liste so konfigurieren, daß die Teilnehmer in einer der zahlreichen Landessprachen mit der Liste interagieren können. Selbstverständlich kann Mailman keine an die Liste geschickte Nachricht übersetzen. :) Man kann allerdings, sofern der Site Administrator diese Unterstützung aktiviert hat, die Liste so konfigurieren, daß sie eine oder mehrere der ungefähr zwei Dutzend Landessprachen unterstützt, wie z.B. Deutsch, Italienisch, Japanisch, oder Spanisch. Die Listenteilnehmer können dann eine der unterstützten Sprachen als ihre bevorzugte Sprache für die Interaktion mit der Liste einstellen. Solche Dinge wie ihre Webseite der Mitglieder-Listen-Einstellungen werden dann in dieser Sprache angezeigt. Jede Mailingliste hat ebenfalls ihre eigene bevorzugte Listensprache, die zur Geltung kommt, wenn keine anderen Sprachkontxte erkennbar sind.

Diese Variablen steuern die Sprachoptionen der Mailingliste:

Voreingestellte Sprache (preferred_language)

Das ist die bevorzugte Listensprache, in der auch die administrativen Seiten der Liste angezeigt werden, genauso wie alle Nachrichten, die von Mailman an die Listeneigner. Für die Werte dieser Option wird eine Auswahlliste der Sprachen angeboten, die in der Variablen available_languages enthalten sind.

Unterstützte Sprachen (available_languages)

Dieser Satz an Auswahlkästchen enthält alle Landessprachen, die der Site Administrator für alle Mailinglisten als erreichbar eingerichtet hat. Man aktiviert hier alle Sprachen, in denen die Anwender die Liste sehen wollen oder die in der Variablen preferred_language benutzbar sein soll.

Betreff MIME-codieren, auch wenn reiner ASCII-Code? (encode_ascii_prefixes)

Wenn auf der Mailingliste eine Sprache verwendet werden soll, die einen nicht-ASCII-Zeichensatz einsetzt und der Präfix im Betreff Nicht-ASCII-Zeichen verwendet, wird der Präfix immer entsprechend den geltenen Standards codiert. Enthält der Betreff-Präfix allerdings ausschließlich ASCII-Zeichen, kann diese Option auf Nie gesetzt werden und so die Umcodierung unterdrückt werden. Das kann die Betreffzeile für Benutzer mit Mailprogrammen, die Nicht-ASCII-Zeichen nicht korrekt verwerten, etwas lesbarer machen. Man beachte allerdings, daß in dem Fall, wenn die Mailingliste sowohl codierte als auch uncodierte Betreffzeilen erhält, auch die Einstellung Soweit benötigt sinnvoll sein kann. In diesem Fall wird Mailman ASCII-Präfixe nicht codieren, wenn der Rest der Betreffzeile nur ASCII-Zeichen enthält, enthält die Originalkopfzeile Nicht-ASCII-Zeichen, wird auch der Präfix codiert. Das verhindert eine Mehrdeutigkeit in der Standardauslegung, die manche Mailprogrmme dazu bringt, zwischen dem Präfix und dem Betreff zusätzliche Leerzeichen anzuzeigen oder Leerzeichen zu veschlucken.

Die Kategorie Mitglieder-Verwaltung

Die Kategorie Mitglieder-Verwaltung unterscheidet sich von den anderen administrativen Kategorien. Sie enthält keine Konfigurationsvariablen oder Listeneinstellungen. Anstelle dessen wird eine Reihe von Seiten angeboten, über die die Mitgliedschaft der Liste verwaltet werden kann. Dies beinhaltet Seiten, auf denen Mitglieder aufgenommen oder entfernt werden können, die Suche nach Mitgliedern sowie für die Anpassung diverser mitgliederspezifischer Einstellungen. Weitere Einzelheiten sind im Kapitel Mitglieder-Verwaltung nachzulesen.

Die Kategorie Non-Digest-Optionen

Mailman liefert die Nachrichten in zwei Versionen aus, die von den Listenbenutzern frei gewählt werden können: im Bündel (als Digest, Nachrichtensammlung) einmal oder einige wenige Male am Tag oder einzeln und sofort, sobald sie zum Versenden eintreffen. Der letzere Modus wird auch Non-Digest genannt. Es gibt zwei administrative Kategorien für die separate Steuerung der Digest- und Non-Digest-Zustellung. Man kann jeweils eine (aber nicht beide) Arten deaktivieren. Beide Zustellformen können listenspezifische Kopf- und Fußbereiche ergänzen, die ergänzende und hilfreiche Informationen für die Listenteilnehmer enthalten können. So kann man z.B. Erläuterungen zum Abbestellen der Liste oder die URL zum Listen-Digest oder andere hilfreiche Informationen eintragen. Die Non-Digest Zustellung kann auch personalisiert werden, d.h. daß einzelne Teile der Mail an den jeweiligen konkreten Empfänger von der Liste angepaßt werden kann. So kann z.B. die To:-Kopfzeile die Adresse des jeweiligen Empfängers anstelle der Mailinglisten-Sende-Adresse enthalten. Fuß- und Kopfbereiche können ebenfalls mit personalisierten Informationen ausgestattet werden, wie z.B. den Link auf die Benutzer-Verwaltungsseite. Zusätzlich erhalten personalisierte Nachrichten Extra-Informationen, mit Hilfe derer Mailman eindeutig Zustellprobleme (bounces) einzelner Mitglieder nachvollziehen kann. Gewöhnlich unternimmt Mailman den Versuch, in Bounces einige Muster wieder zu erkennen, um Listenteilnehmer zu selektieren, bei denen die Adresse ungültig geworden ist, aufgrund von "Launen" einiger Mailsysteme und der zahllosen Weiterleitungen, die die Leute einrichten können, sind mitunter keine verwertbaren Informationen in den Nachrichten mehr enthalten. Personalisierte Nachrichten umgehen dieses Problem, da hier in einigen Kopfzeilen Informationen kodiert eingebracht werden, die die eindeutige Identifikation des Nachrichtenempfängers ermöglichen. Wenn die Zustellung scheitert, weiß Mailman genau, welcher Empfänger ursprünglich gemeint war. Man beachte, daß die Personalisierung zusätzliche Systemressourcen bindet. Daher muß sie zunächst vom Site Administrator generell freigegeben werden, bevor sie überhaupt für eine Liste aktiviert werden kann. Es folgen die Variablen, die für die Steuerung der Non-Digest-Zustellung:

Sofortige Zustellung (Non-Digest) wählbar? (nondigestable)

Diese Option steuert, ob die Teilnehmer die sofortige Zustellung auswählen können oder nicht. Falls nicht, erhalten sie die Nachrichen durchgängig als Digest. Die Non-Digest-Zustellung kann nicht deaktiviert werden, wenn die Digest-Zustellung bereits deaktiviert ist.

Personalisieren? (personalize)

Diese Option schaltet die Nachrichtenpersonalisierung ein.

Kopfbereich (msg_header)

In diese Textbox kann man Informationen eintragen, die in den Kopfbereich jeder Nachricht eingebunden wird, die im Non-Digest-Modus versendet wird. Weiter unten gibt es zusätzliche Erläuterungen zur Verwednung von Parametern in Kopf- und Fußbereichen. Bleibt die Box leer, wird kein Kopfbereich eingerichtet.

Fußbereich (msg_footer)

Analog zum Kopfbereich, nur eben unten. Es gelten dieselben Regeln entsprechend.

Kopf- und Fußbereiche können jeglichen gewünschten Text enthalten. In nicht-englischen Listen können für diese Bereiche alle Zeichen aus dem auf der Liste verwendeten Zeichensatz bzw. bevorzugten Landessprache eingesetzt werden. Es können auch Platzhalter verwendet werden, die Mailman mit den Informationen aus der Konfiguration der Mailingliste ersetzt. Die Platzhalter sind in der Python-Zeichenketten-Erweiterungs-Sysntax zu formulieren, bei der z.B. der Ausdruck %(list_name)s durch den Namen der Mailingliste (den Wert der Variablen list_name) ersetzt wird. Man beachte, daß hier das nachfolgende s benötigt wird. Ein Fußbereich, der den folgenden Text enthält:

Info

Das ist die Mailingliste \%(list_name)s.
Beschreibung: \%(description)s

würde in der Mailingliste Beispiel mit dem Erklärungstext Ein Beispiel einer Mailman Mailingliste etwas so in den Nachrichten am unteren Ende ergänzt werden:

Info

Das ist die Mailingliste Beispiel.
Beschreibung: Ein Beispiel einer Mailman Mailingliste

Es folgt die Liste der verwendbaren Platzhalter-Variablen für die Kopf- und Fußbereiche:

real_name

Wert der Konfigurationsvariablen real_name in der Kategorie Allgemeine Optionen.

list_name

Das ist der kanonische Name der Mailingliste. Mit anderen Worten ist das die Sende-Adresse der Liste.

host_name

Das ist der Domänen-Namensteil der E-Mail-Adresse dieser Liste.

web_page_url

Das ist die Basis-URL für die Erreichbarkeit der Liste über das Web. Sie kann erweitert werden mit listinfo/%(list_name)s, um die Adresse der Listen-Hauptseite zu erhalten.

description

Die Kurzbeschreibung der Mailingliste.

info

Das ist die volle Beschreibung der Mailingliste.

cgiext

Das ist die Dateierweiterung, die CGI-Scripts haben sollen. Sie kann leer sein, .cgi oder auch ein anderer Wert, in Abhängigkeit von der Site-Konfiguration. Man beachte, daß die Werte für die Platzhalter real_name (Öffentlicher Name der Liste aus Allgemeine Optionen), host_name (Hostname aus Allgemeine Optionen), description (Beschreibung aus Allgemeine Optionen), und info (Ausführlichere Beschreibung aus Allgemeine Optionen) aus der Konfigurationsseite der Liste entnommen werden. Wenn die Personalisierung aktiv ist, sind weitere Platzhalter verfügbar:

user_address

Die Adresse des Empfängers, komplett umgewandelt in Kleinbuchstaben.

user_delivered_to

Die Empfänger-Adresse des Anwenders, mit der er sich in die Liste eingetragen hat (in exakt dieser Groß-/Kleinschreibweise)

user_password

Das Benutzerkennwort in Klartext.

user_name

Der volle Name der Benutzers

user_optionsurl

Die Webadresse (URL) der Benutzer-Konfigurationsseite.

Die Kategorie Optionen für Nachrichtensammlungen

Nachrichtensammlungen (Digest, Digest delivery) ist ein Weg, um viele Einzelartikel in einem einzigen Päckchen (einer Digest-Nachricht) einmal am Tag zuzustellen (sofern welche vorliegen), bzw. sobald die Anzahl ein vorgegebene Größe überschreitet. Manche Benutzer bevorzugen diese Zustellungsart auf Listen mit hohem Nachrichtenaufkommen, da sie dadurch weniger Nachrichten erhalten.

Mailman unterstützt zwei Standard-Digest-Formate. Wird die Digest-Zustellung zugelassen können die Benutzer zwischen diesen beiden Formen wählen.

Das eine ist der MIME-Digest, bei dem jede Nachricht ein Anhang (attachment) innerhalb eines multipart/digest-Blockes ist. Dieses Format beinhaltet auch eine Zusammenfassung (Inhaltsverzeichnis) und natürlich einen optionalen Kopf- und Fußtext-Bereich swie die meisten der Kopfzeilen der Original-Nachrichten.

Die zweite Form wird plaintext Digests (Digest im reinen Textformat) genannt, da sie in Mailprogrammen lesbar sind, die kein MIME unterstützen. Tatsächlich entsprechen sie dem RFC 1153 Digest Standard. Sie beinhalten einige, aber nicht alle Originalnachrichten und können ebenfalls eine Zusammenfassung sowie Kopf- und Fußtext-Bereiche umfassen.

Wie die Non-Digest-Zustellung kann man auch die Digest-Zustellung aktivieren und deaktivieren, allerdings können nicht beide gleichzeitig deaktiviert werden. Man kann unterschiedliche Kopf- und Fußtext-Bereiche für die Digest- und Nicht-Digest-Zustellung festlegen. Digest-Zustellungen können nicht personalisiert werden.

Als Administrator der Liste könnten Sie in die Situation kommen, an alle Listenteilnehmer eine dringende Nachricht schicken zu müssen, dabei aber die Verzögerung bei der Digest-Zustellung (bis genügend Nachrichten zusammengekommen sind) umgehen. Um dies zu erreichen, senden Sie die Nachricht mit einer Kopfzeile Urgent:, wobei der Wert der Kopfzeile das Administratoren-Paßwort der Liste ist. Non-Digest-Teilnehmer werden diese Nachricht wie alle anderen erhalten, Digest-Teilnehmer allerdings werden diese Nachricht sofort ausgeliefert bekommen.

Hier sind die Variablen, die die Digest-Zustellung steuern:

Nachrichtensammlungen beziehbar? (digestable)

Die Einstellung steuert, ob die Teilnehmer Digest-Zustellungen aktivieren können oder nicht. Falls nicht, erhalten Sie immer alle Nachrichten einzeln und sofort (Non-Digest). die Digest-Zustellung kann nicht global deaktiviert werden falls Non-Digest bereits global deaktiviert ist.

Welche Voreinstellung für neue Abonnenten? (digest_is_default)

Die Einstellung steuert, welche Art der Zustellung standardmäßig bei neuen Teilnehmern voreingestellt wird. Man kann zwischen Normal (Non-Digest) und Nachrichtensammlung (Digest) wählen.

Welches Format der Nachrichtensammlungen ist Voreinstellung? (mime_is_default_digest)

Wenn den Listenteilnehmern freigestellt wurde, den Digest-Versand zu nutzen, wird mit dieser Variable gesteuert, welches Format standardmäßig verwendet wird: Einzelnachrichten (plain) oder MIME. Plain Digest entsprechen dem oben beschriebenen RFC 1153 Format.

Wie groß (in KB) soll eine Sammlung vor dem Verschicken werden? (digest_size_threshold)

Normalerweise erhalten Teilnehmer am Digest-Versand wenigstens eine Nachricht am Tag, wenn überhaupt Nachrichten über die Liste versendet worden sind. Auf viel genutzten Listen kann es sinnvoll sein, die Digest-Nachrichten bereits vorher, bei Erreichen einer Größenschranke, zu versenden, anderenfalls könnte die einzelne Digest-Nachricht sehr (zu) groß werden. Diese Variable steuert die Größengrenze, ab der eine Digest-Nachricht bereits vor dem Tagesende versendet wird. Sie wird in Kilobyte angegeben, diese Grenze wirkt allerdings nicht exakt. Setzt man den Wert dieser Variablen auf Null, wird keine Größenschranke aktiv, es gibt maximal eine Digest-Nachricht am Tag.

Sammlung täglich schicken wenn die Größe nicht erreicht wird? (digest_send_periodic)

Diese Variable steuert insbesondere, ob eine tägliche Digest-Nachricht versendet werden soll, auch wenn die Größenschranke am Ende des Tages noch nicht erreicht worden ist. Setzt man sie auf Nein, werden überhaupt Digest-Nachrichten nur versendet, wenn ihre Größe die Größengrgenze (digest_size_threshold) überschreitet.

Nachrichtenkopf für jede Nachrichtensammlung (digest_header)

In diesen Textkasten kann man Informationen eintragen, die in den Kopfzeilenbereich (header section) jeder Digest-Nachricht eingetragen wird, die über die Liste versendet wird. Es können dieselben Informationen und WErte verwendet werden wie bei msg_header, mit Ausnahme der Personalisierungsvariablen.

Nachrichtenfußzeile jeder Sammlung (digest_footer)

Genau wie beim Kopfzeilenbereich können auch im Fußzeilenbereich jeder Nachricht Inforamtionen ergänzt werden. Es gelten die gleichen Regeln wie bei digest_header.

Wie oft soll eine neuer Sammlungsband angelegt werden? (digest_volume_frequency)

Jede Digest-Nachricht ist nummeriert mit einer Sammelband- (volume) und einer Ausgabenummer (issue). Diese Variable steuert, wie oft ein neuer Sammelband angelegt werden soll (täglich, wöchentlich, quartalsweise, monatlich, jährlich). Wenn die Sammelbandnummer hochgezählt wird, wird die Ausgabenummer auf Eins zurückgesetzt.

Soll Mailman einen neuen Sammlungsband anlegen? (_new_volume)

Das ist eine Aktionsvariable, die einen neuen Sammelband anlegen läßt, sobald sie mit dem Wert Ja gespeichert wird.

Soll Mailman die nächste Nachrichtensammlung (Digest) gleich jetzt senden, wenn sie nicht leer ist? (_send_digest_now)

Das ist eine weitere Aktionsvariable. Man setze Ja und speichere das Formular, um die aktuelle Digest-Nachricht zu komplettieren und an die Listen-Teilnehmer mit Digest-Zustellung senden zu lassen, ohne daß die Größenschranke (digest_size_threshold) berücksichtigt wird. Allerdings muß wenigstens eine Nachricht in der Sammlung vorliegen.

Die Kategorie Abo-Regeln und Adreßfilter (privacy)

Die Kategorie Abo-Regeln und Adreßfilter (privacy) ermöglicht die Steuerung, wieviel von der Listeninformation öffentlich sichtbar wird sowie wer Nachrichten an die Liste schicken darf. Sie enthält auch einen gewissen Spam-Erkennungs-Filter. Man beachte, daß diese Sektion nicht steuert, ob die Archive öffentlich sichtbar sind oder nicht. Dafür steht die Kategorie Archivierungsoptionen zur Verfügung.

Es gibt vier Unterkategorien:

• Abo-Regeln (Subscription rules) - z.B. Regeln für das Abonnieren und Verlassen der Liste.
• Absender-Filter (Sender filters) - Regeln, wer Nachrichten an die Liste senden darf.
• Empfänger-Filter (Recipient filters) - Moderations-Regeln, basierend auf den Adressen der Nachrichtenempfänger
• Spam-Filter (Spam filters) - einige auf regulären Ausdrücken basierende Regeln für die Erkennung von Nachrichten-Kopfzeilen (header)

Die Absender-, Empfänger- und Spam-Filter-Regeln sind Teil der generellen Konfigurations-Möglichkeiten für die Listen-Moderation bei Mailman. Wenn eine Nachricht an die Liste geschickt wird, wird sie anhand einer Anzahl von Kriterien untersucht, wobei das Ergebnis dann darüber entscheidet, ob die Nachricht an die Teilnehmer weitergeleitet wird oder nicht. Das Ergebnis kann generell vier Werte annehmen:

• Geprüft (Approved) oder Akzeptiert (Accepted) - diese Nachricht kann an die Teilnehmer der Mailingliste weitergereicht werden.
• Anhalten (Hold) - die Nachricht wird für eine Überprüfung durch den Moderator angehalten. Die Administratoren und Moderatoren der Liste müssen über die Nachricht explizit entscheiden und sie freigeben, damit sie an die Liste versendet wird.
• Zurückweisen (Reject) - die Nachricht wird an den Original-Absender zurückgeschickt (bounce) meist mit einer Nachricht über den Grund der Ablehnung. Die Teilnehemr der Liste sehen niemals die abgelehnten Nachrichten.
• Verwerfen (Discard) - die Nachricht wird ohne weitere Bearbeitung einfach weggeworfen .

Viele der Felder dieser Sektion sind Textboxen, die zeilenweise Adressen erwarten. Sofern nichts anderes vermerkt ist werden auch reguläre Ausdrücke akzeptiert, die gegen eine Adresse geprüft werden, sofern die Zeile mit einem Caret-Zeichen (^) beginnt.

Abo-Regeln und Adreßfilter (Subscription rules)

Diese Unterkategorie steuert die Regeln zur öffentlichen Sichtbarkeit der Listenexistenz und was neue Teilnehmer tun müssen, um die Liste zu abonnieren.

Liste anzeigen, wenn verfügbare Listen angefragt werden? (advertised)

Dies Einstellung steuert, ob diese Liste in der Listenübersicht der Site mit angezeigt wird oder nicht. Normalerweise enthält die Listenübersicht den Namen und die Beschreibung jeder eingerichteten Mailingliste in dieser virtuellen Domain. Setzt man diese Variable auf Nein/No, wird sie weder in diese öffentliche Übersicht aufgenommen noch in der administrativen Übersicht angezeigt. Der einzige Weg die Liste zu finden ist dann, den Namen zu erraten bzw. zu kennen.

Was muss ich tun, um eine Mailingliste zu abonnieren? (subscribe_policy)

Diese Einstellung steuert die Schritte, die ein neues Mitglied unternehmen muß, um die Liste zu abonnieren. Die tatsächlich verwendbaren Einstellungen können je nach Vorgaben des Site Administrators etwas differieren. Es gibt insgesamt:

• Nichts (None) - Es wird keine Überprüfung des Abonnenten vorgenommen und wird auch offenes Abonnement (open subscription) genannt, allerdings standardmäßig nicht verfügbar gemacht. Der Site Administrator muß den Listenadministratoren diese Option separat gestatten, ansonsten wird sie gar nicht sichtbar.
• Rückbestätigung durch den User (Confirm) - Ein Email-Bestätigungs-Schritt ist erforderlich, bevor die Adresse zur Liste ergänzt wird. Wenn ein Benutzer das Abonnement anfordert (über die Webseite oder durch das Versenden einer Nachricht an MeineListe-join@Beispiel.de sendet Mailman eine Bestätigungsmail an die anfordernde Adresse. Diese Bestätigungs(rück)mail enthält einen eindeutigen Identifikationstext, die der Anfordernde an Mailman zurückschicken kann und damit seine Anforderung bestätigt. Das kann geschehen, indem die Mail an die Rücksendeadresse unverändert geschickt wird oder die darin enthaltene Webadresse (URL) aufgerufen wird. Auf der Webseite kann der Anwender die Anforderung dann stornieren oder bestätigen.
• Genehmigung durch den Listenadministrator (Require approval) - Alle Abonnementanforderungen werden für eine Überprüfung durch den Listenmoderator zurückgehalten. Es wird keine Mail zur Bestätigung durch den Anwender versendet. Die Listenadministratoren erhalten allerdings eine Mail, die auf die unbearbeiteten Anforderungen hinweist.
• Bestätigung und Genehmigung (Confirm and approve) - Hier muß zunächst die Anforderung durch den Anwender über eine Bestätigungsmail erneuert werden (Confirm), danach muß sie noch durch den Listenadministrator geprüft werden (approve). Dies ist die sicherste Methode des Abonnements, da beide Seiten den Vorgang prüfen und bestätigen müssen.

Zustimmung des Administrators bei Abbestellung erforderlich? (unsubscribe_policy)

Legt fest, ob der Listenadministrator eine Abbestellung bestätigen muß. Nein/No wird sehr empfohlen, das es sich als sehr unhöflich darstellt, einem Listenteilnehmer die Abbestellung zu verweigern. Ja/yes ist in manch speziellen Kontexten nützlich, wenn sie z.B. Angestellten nicht gestatten wollen, sich vom Newsletter der Firma zu befreien.

Verbannte Adressen (ban_list)

Dieser Parameter enthält eine zeilenweise Liste von Adressen (oder regulären Ausdrücken für sie), denen für immer ein Abonnement verweigert wird. Wenn während des Anmeldeprozesses die anfordernde Adresse auf eine der angeführten Adressen (oder Ausdrücke) paßt, wird die Anforderung automatisch abgelehnt und der Anfordernde erhält eine Ablehnungsnachricht. Man kann dies einsetzen, um schwierige Teilnehmer von einer Liste fernzuhalten, an die z.B. nur Teilnemhmer schreiben dürfen.

Wer darf die Mitgliederliste einer Mailingliste einsehen? (private_roster)

Dieser Parameter legt fest, wer die Teilnehmerliste mit den Adressen einsehen darf. Wenn sie Jeder wählen, ist die Mitgliederliste komplett öffentlich. Sie können die Sichtbarkeit der Liste auf die Teilnehmer oder gar nur auf den Listenadministrator einschränken. Im ersteren Fall muß ein Teilnehmer eine gültige Abonennten-Mailadresse und das dazugehörige Paßwort eingeben, bevor die Teilnehmerliste gezeigt wird. Im letzteren Fall muß ein Listenadministratoren-Paßwort eingegeben werden, paßt es auf eines der gültigen Listenadministratoren-Paßworte, wird der Wert des Adreßfeldes ignoriert.

e-Mailadressen so darstellen, dass sie nicht mehr direkt als Mailadresse erkannt werden (z.B. von Suchrobotern der SPAM-Versender) (obscure_addresses)

Steuert, ob eine einfache Verschleierung der Adressen verwendet wird, wenn Mailadressen der Teilnehmer auf Webseiten angezeigt werden. Das sollte die Möglichkeit, Adressen für Spammer automatisch einzusammeln, ein wenig erschweren, obwohl es diese wahrscheinlich nicht komplett unterbindet.

Absender-Filter (Sender filters)

Wenn eine Nachricht an die Liste geschickt wurde, wird sie einer ganzen Reihe von Prüfungen unterzogen, um zu entscheiden, wie mit ihr zu verfahren ist. Dieser Abschnitt enthält die Steuerung dieser Entscheidungen in Bezug auf die Versendung von Nachrichten mit Absendern, die auf der Liste enthalten bzw. nicht enthalten sind.

Beiträge neuer Listenmitglieder moderieren? (default_member_moderation)

Nachrichten von Listenteilnehmern werden für eine Moderation angehalten, wenn deren Moderations-Kennzeichen gesetzt ist. Man beachte, daß nur die Listenadministratoren das Moderations-Kennzeichen eines Teilnehmers ändern kann.

Man kann steuern, ob neue Mitglieder ihr Moderations-Kennzeichen im Zustand gesetzt bzw. nicht gesetzt initial eingetragen bekommen. Wird das Kennzeichen als nicht gesetzt initialisiert, wird der Nachrichtenversand neuer Mitglieder ohne weiteren Eingriff gestattet (natürlich im Rahmen und unter Beachtung anderer Kriterien wie Nachrichtengröße oder der impliziten Empfängerliste - siehe weiter unten). Wird das Kennzeichen gesetzt, können neue Mitglieder auf Quarantäne gesetzt werden, um sicherzustellen, daß sie die Nettikette und den Subjektbezug der Liste einhalten usw. Kann eingeschätzt werden, daß die neuen Mitglieder die Listen-Regeln verstanden haben, kann deren Moderations-Kennzeichen zurückgesetzt werden und ihre Nachrichten ohne Zwischenhalt an die Liste gehen.

Listen im E-Newsletter-Stil können auch mit dem Moderations-Kennzeichen gesteuert werden. Setzt man member_moderation_action auf Ablehnen (Reject) und entfernt nur bei den wenigen gestatteten Sendern das Moderations-Kennzeichen, wird die Liste als Einbahnstraße funktionieren. Man beachte, daß in diesem Fall auch die Nachrichten von Nicht-Mitgliedern abgelehnt oder verworfen werden müssen.

Was soll passieren, wenn ein auf moderiert geschaltetes Mitglied an die Liste sendet? (member_moderation_action)

Das ist die Aktion, die bei Nachrichten von Mitgliedern anzuwenden ist, deren Moderations-Kennzeichen gesetzt ist. Für typische Diskussions-Listen, werden Sie dies wahrscheinlich auf Zurückhalten (Hold) setzen, so daß der Listenmoderator die Chance erhält, manuell die Nachricht zu bestätigen, zurückzuweisen oder zu verwerfen. Für Newsletter- und Veröffentlichungs-Listen werden Sie es auf Ablehnen (Reject) oder Verwerfen (Discard) setzen wollen.

Man beachte, daß, sofern die Moderations-Aktion auf Zurückhalten (Hold) steht, Nachrichten, die von einem moderierten Absender geschickt werden, auf der Webseite der Administrativen Anfragen erscheint. Wenn die Nachricht bearbeitet wird, gibt es dort die Möglichkeit, gleichzeitig das Moderations-Kennzeichen des Teilnehmers zurückzusetzen. Hat man neue Mitglieder auf Quarantäne gesetzt, ist dies eine komfortable Möglichkeit, sowohl die Nachrichten zu bestätigen und die Moderation der Absender gleichzeitig zu entfernen.

Text der jeder Reject-Nachricht beigefügt wird, wenn e-Mails der Nutzer nicht an eine moderierte Liste durchgelassen werden. (member_moderation_notice)

Wenn ein Mitglied moderiert wird und die Moderations-Aktion ist Ablehnen (Reject) enthält diese Variable den Text, der in der Ablehnungsnachricht mitgesendet wird.

Die nächste Gruppe von Variablen steuern, was passiert, wenn Nicht-Mitglieder Nachrichten an die Liste schicken. Jede von ihnen gestattet eine zeilenweise Angabe von E-Mail-Adressen oder von regulären Ausdrücken, sofern die Zeile mit dem Sonderzeichen "^" beginnt. Diese Adreßlisten werden immer in der Reihenfolge abgearbeitet, in der sie auf dieser Seite angegeben werden (d.h. zuerst die erlaubten, gefolgt von den anzuhaltenden, abzulehnenden und den wegzuwerfenden).

Adressliste der Nichtmitglieder, deren Nachrichten automatisch akzeptiert werden (accept_these_nonmembers)

Nachrichten von Nicht-Mitgliedern, deren Adressen auf eine Zeile dieser Liste passen, werden akzeptiert, unter Beachtung der weiteren Listenbeschränkungen (Größe, implizite Empfänger, etc.) Man kann hier auch alternative Absenderadressen von Mitgliedern angeben.

Adressliste der Nichtmitglieder, deren Nachrichten automatisch für eine Moderation zurückgehalten werden (hold_these_nonmembers)

Nachrichten von Nicht-Mitgliedern, deren Adressen auf eine Zeile dieser Liste passen, werden für eine moderierende Überprüfung zurückgehalten.

Adressliste der Nichtmitglieder, deren Nachrichten automatisch zurückgewiesen werden. (reject_these_nonmembers)

Nachrichten von Nicht-Mitgliedern, deren Adressen auf eine Zeile dieser Liste passen, werden abgelehnt, d.h. an den Originalsender zurückgeschickt. Gegenwärtig gibt es keinen Weg, ergänzenden Text in die Zurückweisungs-Nachricht zu ergänzen.

Adressliste der Nichtmitglieder, deren Nachrichten automatisch verworfen werden (discard_these_nonmembers)

Nachrichten von Nicht-Mitgliedern, deren Adressen auf eine Zeile dieser Liste passen, werden ohne Rücksendung einer Nachricht verworfen. Sie können die Absenderadressen von bekannten Spammern auf diese Liste setzen.

Aktion, die beim Eingang einer Nachricht eines Nichtmitgliedes ausgeführt werden soll, wenn für dieses Nichtmitglied bislang keine Aktion hinterlegt ist (generic_nonmember_action)

Diese Variable steuert, was mit Nachrichten von Nicht-Mitgliedern passiert, wenn die Absender-Adresse keine der bisherigen vier Listen entspricht. Setzt man dies auf Zurückhalten (Hold), erscheinen die Nachrichten auf der Seite der Administrativen Anfragen und man erhält die Möglichkeit, die Sender-Adresse auf eine der vier Listen zu ergänzen, während gleichzeitig über die Nachricht entschieden werden kann.

Sollen automatisch verworfene Nachrichten von Nichtmitgliedernan den Moderator der Liste weitergeleitet werden? (forward_auto_discards)

Werden Nachrichten von Nicht-Teilnehmern verworfen weil entweder die Absender-Adresse auf eine Zeile in der Liste discard_these_nonmembers oder weil die generelle Aktion für Nicht-Mitglieder auf Wegwerfen steht, kann hier entschieden werden, ob diese Nachrichten an die Listenadministratoren weitergeleitet werden sollen oder nicht.

Empfänger-Filter (Recipient Filters)

Die Variablen in diesem Abschnitt steuern verschiedene Filter auf der Grundlage des Empfängers der Nachricht.

Nachrichten an die Liste müssen exakt an die Listen-Mailadresse oder einen Alias gehen. (require_explicit_destination)

Dies steuert, ob die allgemeine Verteileradresse der Mailingliste (posting address) explizit im An:- oder CC:-Feld genannt werden muß. Der Hauptgrund, daß dies nicht geschieht, wäre, wenn die Adresse nur im BCC:-Feld eingetragen wurde. Spammer tun dies häufig, aber mitunter werden auch legale Nachrichten auf diese Weise an die Liste gesendet.

Wird die Liste nicht explizit adressiert und diese Einstellung ist aktiv, wird die Nachricht zur Moderation zurückgehalten.

Weitere e-Mailadressen (Aliase) der Liste, die Mailman akzeptieren soll (acceptable_aliases)

Dies ist eine Liste von alternativen Adressen, die als Verteileradresse der Mailingliste akzeptiert werden sollen, wenn require_explicit_destination aktiv ist. Das ist von Nutzen, wenn es Aliase (Ersatznamen) für die Hauptadresse existieren (z.B. Hilfe@Beispiel.de könnte ein Alias für Hilfe-Liste@Beispiel.de sein).

Obergrenze der Empfängeranzahl einer Veröffentlichung (max_num_recipients)

Das ist die Obergrenze explizit aufgeführter Empfänger, die in einer Nachricht gestattet wird. Spammer senden manchmal Nachrichten mit einer großen Zahl an expliziten Empfängern. Setzt man diese Variable auf einen sinnvollen Wert, kann Spam herausgefiltert werden.

Spam-Filter (Spam Filters)

Dieser Abschnitt liefert einige Ergänzungen zu Werkzeugen zur Spambekämpfung; er ersetzt nicht spezielle Anti-Spam-Werkzeuge wie SpamAsassin oder Spambayes.

Zurückhalten von Nachrichten in Abhängigkeit vom Headerinhalt (bounce_matching_headers)

Diese Variable enthält zeilenweise reguläre Ausdrücke für Kopfzeilen (header). Entspricht mindestens eine der Nachrichten-Kopfzeilen einer dieser Muster, wird die Nachricht zur Moderation zurückgehalten. Das Format besteht aus dem Namen und dem WErt der Kopfzeile, durch ein Doppelpunkt getrennt, wobei die Namensangabe unabhängig von der Groß- und Kleinschreibung ist und der Wert ein gültiger regulärer Ausdruck aus der Programmiersprache Python ist. Zeilen, die mit dem Zeichen "#" beginnen, werden ignoriert.

Diese Variable kann verwendet werden, um bekannte Spammer herauszufinden, indem reguläre Ausdrücke für die An:- und CC:-Felder oder für bekannte Nachrichten-IDs (Message-ID:) geschrieben werden. Wahrscheinlich sind jedoch Muster nützlicher, die auf Kopfzeilen zielen, die von Spam-Erkennungs-Werkzeugen etwas eher in der Abfolge der Werkzeuge bereits in die Nachricht ergänzt wurden. So kann z.B. SpamAssassin so konfiguriert werden, daß er eine Kopfzeile X-Spam-Score: ergänzt und in Abhängigkeit von der Spam-Bewertung mit einer Zeichenkette aus Sternen (zwischen null und 5 Stück) als Wert versieht. Dann kann eine Zeile zu dieser Variablen ergänzt werden, wie z.B.:

   X-Spam-Score: [*]{3,5}

Diese Zeile paßt auf 3 bis 5 Sterne als Wert dieses Feldes.

Die Kategorie Bounce-Bearbeitung

Diese Richtlinien steuern das automatischen Rückmeldungs-Beantwortungs-System (Automatischer Beantworter) von Mailman. Hier ist ein Überblick, wie es funktioniert:

Wenn eine Rückmeldung (bounce) eintrifft, versucht Mailman zwei Informations-Teile aus der Nachricht zu extrahieren: die Adresse des Mitglieds, für den die Nachricht bestimmt war und der Schweregrad des Problems, das die Rückmeldung ausgelöst hat. Der Schweregrad kann entweder hard für schwerste (fatal) Fehler sein oder soft für temporäre Fehler. Falls der Grad nicht eindeutig ist, wird der Grad hard verwendet.

Kann keine Teilnehmer-Adresse aus der Rückmeldung extrahiert werden, wird sie gewöhnlich verworfen. Jeder Teilnehmer hat einen Bounce-Punktestand, der mit null initialisiert wird und jedesmal erhöht wird, wenn eine Rückmeldung von ihm kommt. Rückmeldung mit dem Schweregrad hard erhöhen den Punktestand um 1 während soft-Rückmeldungen ihn um 0,5 erhöhen. Der Punktestand wird nur einmal täglich erhöht, auch dann, wenn von einem Teilnehmer zehn Rückmeldungen an diesem Tag eingetroffen sein sollten.

Wird die Bounce-Punktezahl eines Mitgliedes größer als der Bounce-Schwellwert (s.u.), wird das Abonnement des Mitgliedes deaktiviert. Einmal deaktiviert, erhält das Mitglied keine weiteren Nachrichten von der Liste bis die Mitgliedschaft explizit reaktiviert wird, entweder durch den Listenadministrator oder durch das Mitglied selbst. Allerdings erhält er gelegentlich Erinnerungs-Nachrichten, daß seine Listenmitgliedschaft deaktiviert wurde und diese Erinnerungen enthalten eine Anleitung, wie die Mitgliedschaft reaktiviert werden kann. Sowohl die Anzahl der Erinnerungs-Nachrichten als auch deren Abstand können eingestellt werden.

Es gibt eine weitere wichtige Konfigurations-Variable; nach Ablauf einer gewissen Zeitperiode, während der keine weiteren Rückmeldungen vom Mitglied eintreffen, wird die Bounce-Information als veraltet angesehen und verworfen. Paßt man diesen Wert und den Bounce-Schwellwert geschickt an, kann darüber gesteuert werden, wie schnell Mitglieder mit Rückmeldungen deaktiviert werden. Beide Werte müssen der Nachrichtenhäufigkeit auf der Liste angepaßt werden.

Bounce-Erkennung aktivieren? (bounce_processing)

Legt fest, ob auf dieser Liste Rückmeldungen ausgewertet werden sollen oder nicht.

Max. Anzahl von Bounces, bevor die Listenmitgliedschaft des Mitgliedes deaktiviert wird (bounce_score_threshold)

Das ist der Schwellwert, bei dessen Überschreitung das Abonnement eines Mitgliedes automatisch deaktiviert wird. Wird die Mitgliedschaft reaktiviert, wird der Bounce-Wert auf null gesetzt. Dieser Wert kann eine reelle Zahl sein.

Anzahl der Tage, nach denen die Bounce-Überwachung eines Nutzers beendet wird, sofern keine Bounces mehr zurückkommen (bounce_info_stale_after)

Die Anzahl von Tagen, nach der die Bounce-Information eines Mitgliedes als veraltet angesehen wird. Werden in dieser Zeit keine weiteren Bounces empfangen, wird der Bounce-Wert auf null zurückgesetzt. Diese Zahl muß ganz sein.

Anzahl Warnungen vor der Entfernung von der Liste (bounce_you_are_disabled_warnings)

Die Anzahl von Hinweis-Nachrichten, die ein deaktiviertes Mitglied erhält, bevor seine Adresse von der Mailingliste entfernt wird. Wird dieser Wert auf null gesetzt, wird die Adresse sofort von der Liste entfernt, sobald sein Bounce-Wert das erste Mal den Schwellwert überschreitet. Diese Zahl muß ganz sein.

Anzahl der Tage zwischen zwei deaktiviert-Warnungen (bounce_you_are_disabled_warnings_interval)

Die Anzahl von Tagen zwischen zweier Hinweis-Nachrichten zur Deaktivierung.

Soll Mailman an den Listenbesitzer nicht erkannte Bounce-Nachrichten zur Ansicht weiterleiten? (bounce_unrecognized_goes_to_list_owner)

Diese Variable steuert, ob nicht interpretierbare Rückmeldungen verworfen oder an den Listenadministrator weitergeleitet werden sollen. Die Analyse der Rückmeldungen ist nicht perfekt, eine Untersuchung durch einen Menschen kann sie wesentlich verbessern. Der Listen-Eigentümer kann sich die nicht erkannten Bounces zuschicken lassen, so daß die entsprechenden Mitglieder manuell deaktiviert oder entfernt werden können.

Soll Mailman den Listeninhaber benachrichtigen, wenn ein Nutzer wegen permanenter Bounces deaktiviert wird? (bounce_notify_owner_on_disable)

Diese Einstellung steuert, ob der Listen-Eigentümer informiert wird, wenn ein Abonnement aufgrund der Überschreitung des Bounce-Schwellwertes automatisch deaktiviert wurde, oder ob nicht.

Soll Mailman den Listeninhaber benachrichtigen, wenn ein Nutzer wegen permanenter Bounces ausgetragen wird? (bounce_notify_owner_on_removal)

Diese Einstellung steuert, ob der Listen-Eigentümer informiert wird, wenn ein Mitglied aufgrund der Ausschöpfung der maximalen Anzahl von Deaktivierungs-Hinweis-Nachrichten (bounce_you_are_disabled_warnings) von der Liste entfernt wurde, oder ob nicht.

Die Kategorie Archivierungsoptionen

Mailman ist mit einem web-basierten Archiver ausgestattet (Pipermail), kann aber auch auf die Nutzung externer Archiver weiterer Anbieter konfiguriert werden.

Nachrichten archivieren? (archive)

Diese Einstellung sagt Mailman, ob die erhaltenen Nachrichten archiviert werden sollen oder nicht, unabhängig davon, ob Pipermail oder ein Archiver eines Drittanbieters genutzt wird. Möchte man keine Nachrichten archivieren, sollte der schalter auf Nein gestellt werden.

Man beachte, daß die Absender für jede ihrer eigenen versendeten Nachrichten steuern können, ob diese archivert werden sollen oder nicht. Hat die gesendete Nachricht die Kopfzeile X-No-Archive: (unabhängig von dessen Wert) oder eine Kopfzeile X-Archive: mit dem Wert No (Groß-/Kleinschreibung ist dabei unerheblich), wird die Nachricht nicht archiviert, in allen anderen Belangen aber normal behandelt.

Sind die Archivdateien für ein privates oder öffentliches Archiv? (archive_private)

Steuert, ob Pipermail-Archive privat oder öffentlich sind. Private Archive erfordern eine gültige Mitglieder-Mailadresse und das Paßwort oder das Paßwort des Listenadministrators, um auf sie zugreifen zu können. Diese Einstellung hat keinen Effekt, wenn ein Archiver eines Drittanbieters verwendet wird.

Wie oft soll eine neue Nachrichtensammlung angelegt werden ? (archive_volume_frequency)

Steuert wie Pipermail Nachrichten im Archiv verteilt. Die verbreitetste Einstellung ist monatlich, was bewirkt, daß jeden Monat ein neuer Archivblock eingerichtet wird. Listen mit einem sehr hohen Nachrichten-Aufkommen können auf kürzere Abstände eingestellt werden (z.B. wöchentlich oder täglich), wohingegen Listen mit geringem Aufkommen längere Abstände benötigen könnte (z.B. jährlich). Diese Einstellung hat keinen Effekt bei Archivern von Drittanbietern.

Die Kategorie Mail<->News Schnittstelle

Mailman hat eine ausgefeilte Mail-zu-News-Schnittstelle. Er kann unabhängig Nachrichten aus dem News-Bereich als E-Mail-Nachrichten weiterreichen genau wie umgekehrt und kann sogar genutzt werden, um moderierte Newsgroups zu verwalten.

---