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.

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 Ankündigungsliste und eine Diskussionsliste. Über die Ankündigungsliste 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 Ankündigungen gestattet sein, die an die Diskussionsliste gerichtet werden sollen. In diesem Fall kann die Reply-To: Kopfzeile der Ankündigungsliste 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 Ankündigungs-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 Ausdurck %(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.

  mime_is_default_digest
         If a member is allowed to choose digests, this variable controls
         which is the default digest style they will receive. Plain
         digests are RFC 1153 format as described above.

  digest_size_threshold
         Normally, digest members get at least one message per day, if
         there have been any messages posted to the list. However, for
         high volume lists, you may want to send out digests when the
         size has reached a certain threshold, otherwise, the one digest
         they receive could be huge. This variable controls the size
         threshold by specifying the maximum digest size in kilobytes.
         Note that this threshold isn't exact. Set this variable to zero
         to specify that there is no size threshold, in which case no
         more than one digest will be sent out per day.

  digest_send_periodic
         This variable actually controls whether or not a digest is sent
         daily when the size threshold has not yet been met. If set to
         No, then digests will only be sent when they are bigger than
         digest_size_threshold.

  digest_header
         This text box lets you enter information that will be included
         in the header of every digest message sent through the list. The
         same information can go in this header as can go in the
         msg_header, except for the personalization variables.

  digest_footer
         Just like with the header, you can add a footer to every
         message. The same rules apply to digest footers as apply to
         digest headers.

  digest_volume_frequency
         Each digest is numbered with a volume and an issue. This
         variable controls how often a new digest volume is sent. When
         the digest volume number is incremented, the issue number is
         reset to 1.

  _new_volume
         This is an action variable, which forces an increment of the
         volume number as soon as you submit the form.

  _send_digest_now
         This is another action variable. Select Yes, submit the form,
         and the current digest is packaged up and sent to digest
         members, regardless of size (well, there has to be at least one
         message in the digest).

The Privacy Options Category

  The Privacy category lets you control how much of the list's
  information is public, as well as who can send messages to your list.
  It also contains some spam detection filters. Note that this section is
  not used to control whether your list's archives are public or private;
  for that, use the category.

  There are four sub-categories:
    * Subscription rules - i.e. the rules for joining and leaving your
      mailing list
    * Sender filters - the rules for who may post messages to your list
    * Recipient filters - moderation rules based on the recipient of the
      message
    * Spam filters - some regular expression based rules for header
      matching

  The sender, recipient, and spam filtering rules are part of the general
  list moderation features of Mailman. When a message is posted to the
  list, it is matched against a number of criteria, the outcome of which
  determines whether the message is reflected to the membership or not.
  In general, the outcome is one of four states:

    * Approved or Accepted - the message may be sent on to the members of
      the mailing list.
    * Hold - the message will be held for moderator approval. The list
      owners and moderators will then have to explicitly approve the
      message before the list members will see it.
    * Reject - the message is bounced back to the original sender, often
      with a notice containing the reason the message was rejected. The
      list members never see rejected messages.
    * Discard - the message is simply thrown away without further
      processing.

  Many of the fields in this section are text boxes accepting addresses,
  one per line. Unless otherwise noted, these also accept regular
  expressions which will be matched against an address, if the line
  begins with a (caret) character.

Subscription rules

  This subcategory controls the rules for exposing the existance of this
  list, and for what new members must do in order to subscribe to the
  list.

  advertised
         This option controls whether this list will show up in the list
         overview for the site. Normally, an overview contains the name
         and short description of every mailing list in the virtual
         domain. By setting this variable to No, it will not show up in
         this overview, nor will it show up in the administrative
         overview. The only way then to find the list is to guess (or
         know!) its name.

  subscribe_policy
         This option controls the steps that a new member must take to
         join the list. The available options may differ based on some
         defaults that the site administrator chooses. They are:

         + None - No verification is done on the subscribing member. This
           is also called open subscriptions and is generally disabled by
           default. The site administrator must allow list admins to
           choose this option; if not, this option will not be presented
           to you.
         + Confirm - An email confirmation step is required before the
           address is added to the list. When a member requests
           subscription, either via the web page or by sending a message
           to yourlist-join@example.com, Mailman will send a confirmation
           message to the requesting address. This mail-back confirmation
           contains a unique identifier, which the requester can present
           to Mailman in order to confirm their subscription. This can be
           done either by replying to the mail-back, or by visiting the
           url in the mail-back message. The url points to a page that
           lets the user either discard or confirm their request.
         + Require approval - All subscription requests are held for
           approval of the list moderator. No mail-back confirmation is
           sent, but the list admins will recieve a message indicating
           that approval is pending.
         + Confirm and approve - Here, a mail-back notice must first be
           confirmed by the requester. Once confirmed, the list moderator
           must then approve the request. This is the most secure method
           for users to subscribe since it both verifies the requesting
           address, and forces the list moderators to approve the
           request.

  unsubscribe_policy
         Specifies whether the list moderator's approval is required for
         unsubscription requests. No is highly recommended, since it is
         exceedingly impolite to not allow people to leave a mailing list
         whenever they want (i.e. opt-out). Yes is useful in some
         specialized contexts; e.g. you may not want to allow employees
         to unsubscribe from the company newsletter.

  ban_list
         This contains a list of addresses (or regular expressiosn), one
         per line, that are banned from ever subscribing to your mailing
         list. If a match occurs during the subscription process, the
         request will be automatically rejected, and the requester will
         get a rejection notice. You can use this to permanently ban
         troublesome posters to a members-only list.

  private_roster
         This specifies who is allowed to view the roster of member
         addresses. If you choose Anyone, then the list membership is
         completely public. You can limit exposure of the roster to just
         list members, or just to the list administrators. In the former
         case, a user must enter a valid member's address and password
         before they can view the roster. In the latter case, a list
         administrator's password must be enter; if a matching admin
         password is entered, address field is ignored.

  obscure_addresses
         Controls whether some simple obfuscation of addresses is used
         when member addresses are included on web pages. This should
         reduce the opportunity for email address harvesting by spammers,
         although it probably doesn't eliminate it.

Sender filters

  When a message is posted to the list, a series of moderation criteria
  are applied to determine the disposition of the message. This section
  contains the modeation controls for postings from both members and
  non-members.

  default_member_moderation
         Member postings are held for moderation if their moderation flag
         is turned on. Note that only the list administrators can change
         the value of a member's moderation flag.

         You can control whether new members get their moderation flag
         turned on or off by default when they subscribe to the list. By
         turning this flag off by default, postings by members will be
         allowed without further intervention (barring other restrictions
         such as size or implicit recipient lists - see below). By
         turning the flag on, you can quarantine new member postings to
         make sure that they meet your criteria for netiquette,
         topicality, etc. Once you determine that the new member
         understands the community's posting rules, you can turn off
         their moderation flag and let their postings go through
         unstopped.

         E-newsletter style lists can also be set up by using the
         moderation flag. By setting the member_moderation_action to
         Reject, and by turning off the moderation flag for just the few
         approved senders, your list will operate in essentially a
         one-way direction. Note that you'd also need to reject or
         discard postings from non-members.

  member_moderation_action
         This is the action to take for postings from a member who's
         moderation flag is set. For typical discussion lists, you'll
         likely set this to Hold so that the list moderator will get a
         chance to manually approve, reject, or discard the message. For
         e-newsletter and announcement lists, you might want to set this
         to Reject or Discard.

         Note that when a moderated member posts to your list, and the
         member_moderation_action is set to Hold, the message will appear
         on the administrative requests page. When you dispose of the
         message, you will be given an opportunity to clear the
         moderation flag at the same time. If you're quarantining new
         posts, this makes it very convenient to both approve a new
         member's post and de-moderate them at the same time.

  member_moderation_notice
         When a member's moderation flag is turned on and
         member_moderation_action is Reject, this variable contains the
         text sent in the rejection notice.

  The next batch of variables controls what happens when non-members post
  messages to the list. Each of these accepts one email address per line;
  regular expressions are allowed if the line starts with the (caret)
  character. These address lists are always consulted in the order in
  which they're presented on this page (i.e. accepts first, followed by
  holds, rejections, and discards).

  accept_these_nonmembers
         Postings from non-members whose addresses match this list are
         accepted, barring other list restrictions due to size, implicit
         recipients, etc. You might want to add alternative addresses of
         approved posters to this list.

  hold_these_nonmembers
         Postings from non-members whose addresses match this list are
         held for moderator approval.

  reject_these_nonmembers
         Postings from non-members whose addresses match this list are
         rejected, i.e. bounced back to the original sender. There
         currently is no way to add additional text to the rejection
         message.

  discard_these_nonmembers
         Postings from non-members whose addresses match this list are
         discarded, with no bounce back message. You might want to add
         the addresses of known spammers to this list.

  generic_nonmember_action
         This variable controls what happens to non-member posts when the
         address of the sender doesn't match any of the above four lists.
         If you set this to Hold, the posting will appear on the
         administrative requests page, and you will be given an
         opportunity to add the non-member to one of the above four lists
         at the same time you dispose of the held message.

  forward_auto_discards
         When messages from non-members are discarded, either because the
         sender address matched discard_these_nonmembers, or because
         generic_nonmember_action is Discard, you can choose whether such
         messages are forwarded to the lsit administrators or not.

Recipient Filters

  The variables in this section control various filters based on the
  recipient of the message.

  require_explicit_destination
         This controls whether the mailing list posting address must be
         explicitly named in the To: or Cc: recipient lists. The main
         reason why it wouldn't is if the message was blind-carbon-copied
         (i.e. Bcc:'d) to the list. Spammers like to do this, but
         sometimes legitimate messages are forwarded to the list this
         way.

         If the list is not explicitly addressed and this setting is
         turned on, the message will be held for moderator approval.

  acceptable_aliases
         This is the list of alternative addresses that are acceptable as
         a list posting address when require_explicit_destination is
         enabled. This is useful for when there aliases for the main
         posting address (e.g. help@example.com may be an alias for
         help-list@example.com).

  max_num_recipients
         This is the maximum number of explicit recipients that are
         allowed on the posted message. Spammers sometimes send messages
         with lots of explicit recipients, so setting this number to a
         reasonable value may cut down on spam.

Spam Filters

  This section provides some adjuncts to spam fighting tools; it doesn't
  replace dedicated anti-spam tools such as SpamAssassin or Spambayes.

  bounce_matching_headers
         This variable contains header regular expressions, one per line,
         and if any of a message's headers matches one of these patterns,
         it will be held for moderation. The format is a colon separated
         header and value, where the header is case insensitive and the
         value is any valid Python regular expression. Lines that start
         with # are ignored.

         This variable can be used to catch known spammers by writing
         regexps that match against To: or Cc: lines, or known-bad
         Message-ID:s. Perhaps more useful though are patterns that match
         headers added by spam detection tools higher up in the tool
         chain. For example, you might configure SpamAssassin to add an
         X-Spam-Score: header with between zero and 5 stars depending on
         the spam score. Then you can add a line to this variable like:

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

         This line will match from 3 to 5 stars in the value of this
         field.

Die Kategorie Bounce-Bearbeitung

  These policies control the automatic bounce processing system in
  Mailman. Here's an overview of how it works:

  When a bounce is received, Mailman tries to extract two pieces of
  information from the message: the address of the member the message was
  intended for, and the severity of the problem causing the bounce. The
  severity can be either hard for fatal errors, or soft for transient
  errors. When in doubt, a hard severity is used.

  If no member address can be extracted from the bounce, then the bounce
  message is usually discarded. Every member has a bounce score,
  initialized at zero, and every time we encounter a bounce from a member
  we increment that member's score. Hard bounces increment by 1 while
  soft bounces increment by 0.5. We only increment the bounce score once
  per day, so even if we receive ten hard bounces from a member per day,
  their score will increase by only 1 for that day.

  When a member's bounce score is greater than the bounce score threshold
  (see below), the member's subscription is disabled. Once disabled, the
  member will not receive any postings from the list until their
  membership is explicitly re-enabled, either by the list administrator
  or the user. However, they will receive occasional reminders that their
  membership has been disabled, and these reminders will include
  information about how to re-enable their membership. You can control
  both the number of reminders the member will receive and the frequency
  with which these reminders are sent.

  There is one other important configuration variable; after a certain
  period of time - during which no bounces from the member are received -
  the bounce information is considered stale and discarded. Thus by
  adjusting this value, and the score threshold, you can control how
  quickly bouncing members are disabled. You should tune both of these to
  the frequency and traffic volume of your list.

  bounce_processing
         Specifies whether or not this list should do automatic bounce
         processing.

  bounce_score_threshold
         This is the bounce score above which a member's subscription
         will be automatically disabled. When the subscription is
         re-enabled, their bounce score will be reset to zero. This value
         can be a floating point number.

  bounce_info_stale_after
         Thenumber of days after which a member's bounce information is
         considered stale. If no new bounces have been received in the
         interrim, the bounce score is reset to zero. This value must be
         an integer.

  bounce_you_are_disabled_warnings
         The number of notices a disabled member will receive before
         their address is removed from the mailing list's roster. Set
         this to 0 to immediately remove an address from the list once
         their bounce score exceeds the threshold. This value must be an
         integer.

  bounce_you_are_disabled_warnings_interval
         The number of days between each disabled notification.

  bounce_unrecognized_goes_to_list_owner
         This variable controls whether unrecognized bounces are
         discarded, or forwarded on the list administrator. The bounce
         detector isn't perfect, although personalization can make it
         much more accurate. The list owner may want to receive
         unrecognized bounces so that they can manually disable or remove
         such members.

  bounce_notify_owner_on_disable
         This option controls whether or not the list owner is notified
         when a member's subscription is automatically disabled due to
         their bounce threshold being reached.

  bounce_notify_owner_on_removal
         This option controls whether or not the list owner is notified
         when a member is removed from the list after their disabled
         notifications have been exhausted.

The Archiving Options Category

  Mailman comes with a built-in web-based archiver called Pipermail,
  although it can be configured to use external, third party archivers.

Bei genealogy.net wird der Archiver MMonArc benutzt, der einzige wirksame Schalter auf der Seite Archiving Options ist der Schalter public/private Archive.

  archive
         This option tells Mailman whether to archive messages it
         receives or not, regardless of whether Pipermail or a third
         party archiver is used. Turn this off if you don't want to
         archive messages.

         Note that senders can control whether their own posts are
         archived, on an individual per-message basis. If the posted
         message has a X-No-Archive: header (regardless of value), or a
         X-Archive: header with a value of No (case insensitive), then
         the message will not be archived, although it will be treated as
         normal in all other ways.

  archive_private
         Controls whether Pipermail archives are private or public.
         Private archives require a valid member address and password, or
         a list administrator password in order to access them. This
         option has no effect when a third party archiver is used.

  archive_volume_frequency
         Controls how Pipermail splits messages in the archive. The most
         common option is Monthly meaning a new archive volume is started
         every month. Very high volume lists may want a shorter frequency
         (e.g. Weekly or Daily) where as lower volume lists may want a
         longer frequency (e.g. Yearly). This option has no effect when a
         third party archiver is used.

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.

Fußnoten

  ... immediately^5
         They'll also receive the message in the digest.

---